Speaker 1: Hey, folks, welcome back to another episode of JavaScript Jabber.
Speaker 2: This week, on our panel, we have Steve Edwards.
Speaker 3: You had to think about which one you were going
Speaker 3: to go to their first second, didn't you.
Speaker 1: Well, I didn't want to say dad Joker. Oh sorry
Speaker 1: what my brain said?
Speaker 3: Oh well that's what most people think. I'll do my
Speaker 3: age as yo yo yo, come in at you live
Speaker 3: from cold and rainy Portland.
Speaker 2: We also have Dan Shapier.
Speaker 4: Hi from a freezy tel Aviv at fifty degrees fahrenheit
Speaker 4: nine degrees celsius, which is, you know, literally freezing for us.
Speaker 3: That's freezing. That would be that's above where I'm at
Speaker 3: now in the middle of the day.
Speaker 2: Yeah. I'm Charles Maxwood from top Ed Devson. Yeah.
Speaker 1: It's it's forty some degrees here. Yeah, and I went
Speaker 1: for a walk, so.
Speaker 3: Yeah, I know it's far better for us.
Speaker 2: Man.
Speaker 3: Yeah.
Speaker 2: We also have Lee Robinson. Lee, welcome back.
Speaker 5: It's good to be here. It's fifty eight degrees fahrenheit here,
Speaker 5: which is like a sauna because it was negative fahrenheit
Speaker 5: like last week.
Speaker 1: So yeah, I was gonna say when I come out there,
Speaker 1: but if you're getting negatives, forget it.
Speaker 5: Yeah, that's classic Midwest. It's very cold.
Speaker 2: Yeah.
Speaker 1: So it's been what a year or so since we
Speaker 1: had you on What's New.
Speaker 5: A lot, there's lots we can talk about through next Yes,
Speaker 5: per Sell, V zero and AI, all sorts of fun stuff.
Speaker 1: Yeah, sounds like you're mostly doing the same kind of
Speaker 1: thing that you were doing last time.
Speaker 5: Yes, Yes, definitely.
Speaker 4: I was saying before we started that it's pretty amazing
Speaker 4: to me that such a small company relatively speaking, of course,
Speaker 4: because you're a multi billion dollar company with a few
Speaker 4: hundred employees, but it's still relatively small, is able to
Speaker 4: have such a huge impact on web development. Like it
Speaker 4: seems like everything is kind of revolving around you these
Speaker 4: days in one way or another.
Speaker 5: One thing that I think has worked well for us
Speaker 5: that Ghermo likes to call recursive founder mode, which I
Speaker 5: think is kind of funny if you've see in all
Speaker 5: the discourse about founder mode, is trying to hire former
Speaker 5: founders or people who have that energy and then giving
Speaker 5: them ownership and agency over a domain and letting them
Speaker 5: kind of run with it. So a good example of
Speaker 5: this is just last week we released a flags SDK
Speaker 5: for feature flags, an open source toolkit you can use
Speaker 5: to implement feature flags correctly in your app using the server,
Speaker 5: preventing layout shift with any feature flag provider that you want.
Speaker 5: And this is kind of a founder led thing. We
Speaker 5: have Dominic who is really owning this project from end
Speaker 5: to end. It's a very small team working on this,
Speaker 5: but small teams can do amazing things when empowered and
Speaker 5: given the right direction and resources.
Speaker 4: I was curious if it's based on edge computing.
Speaker 5: So we do really recommend people to use the server
Speaker 5: in general because most of the jank that you see
Speaker 5: in websites that have feature flags is because they wait
Speaker 5: for the initial document to get on the page, the
Speaker 5: first bundle of JS to load, and then they're evaluating
Speaker 5: what feature flags are on and you get that weird
Speaker 5: shift of maybe one experiment and then the other. Or
Speaker 5: you also see this with authentication, like the logged out
Speaker 5: state and then it switches to the logged in state.
Speaker 5: So we are strongly pushing for server side experimentation server
Speaker 5: side flagging, and to do that, generally you want to
Speaker 5: put your flags close to where your database is, so
Speaker 5: it's not necessarily that the flags need to live at
Speaker 5: the edge. Generally, they'd live at origin by your database,
Speaker 5: but you can still do some things early in the
Speaker 5: routing layer at the edge. Maybe that's redirects or rewrites.
Speaker 5: Maybe that's pre computing multiple different variants of the page
Speaker 5: and putting the static shells of those pages at the edge,
Speaker 5: like at a CDN layer, so you can fetch those early.
Speaker 5: So it's kind of a bit of both. We want
Speaker 5: to use the edge layer for the static assets, uh,
Speaker 5: and then put your data next to your compute at origin.
Speaker 4: Yeah. What some people actually do to reduce shift in
Speaker 4: these scenarios when they use client side is to actually
Speaker 4: intentionally put render blocking scripts at the very top of
Speaker 4: the page. But that obviously comes at a very high
Speaker 4: cost for coor vitals Totally.
Speaker 5: I think the biggest offender that I see is teams
Speaker 5: who don't realize that they're actually leaking all of their
Speaker 5: flags on the client side. They're using client side experimentation.
Speaker 5: But if you inspect the dom or you you know,
Speaker 5: do some magic in your deb tools, you can actually
Speaker 5: see every single experiment or every single flag, and you know,
Speaker 5: for the you.
Speaker 4: Know, it's not necessarily bad.
Speaker 5: It's not it's not necessarily bad. Although sometimes I think
Speaker 5: maybe on a large enough team. The developer thinks that
Speaker 5: is a secret value, and in reality it is not.
Speaker 5: They don't realize that they're actually exposing that to the
Speaker 5: client side. So it can be fine if you know
Speaker 5: what you're doing. I've just seen it misused a few times.
Speaker 4: Don't put credentials in feature flex.
Speaker 1: Yes, yes, definitely, don't put credentials in your source code
Speaker 1: at all.
Speaker 5: Yeah.
Speaker 1: One thing that I want to just touch on here
Speaker 1: because I love the idea of kind of the internal entrepreneur.
Speaker 1: I have to say that when I've worked like contracts
Speaker 1: or full time jobs, a lot of times it's we're
Speaker 1: going to give you features and then you're just going
Speaker 1: to implement them. And I really like that open feeling
Speaker 1: of hey, we need this solution, go make it like that.
Speaker 1: That would kind of be if I didn't want to
Speaker 1: take the entrepreneurial risk, that would be my ideal job.
Speaker 5: So Yeah, we like to think about empowering startups within
Speaker 5: a startup. So another good example of this is our
Speaker 5: productvzero dot dev, which allows you to very quickly build
Speaker 5: websites and web applications with AI or just better understand
Speaker 5: how to use web tools like next yess and react
Speaker 5: through AI, and that team is very small and it's
Speaker 5: led by a former founder who really understands how to
Speaker 5: build great products and has been given you know, a
Speaker 5: budget autonomy to build this product into end and really
Speaker 5: monitor success and own their numbers. And it's it's working
Speaker 5: pretty well.
Speaker 4: So, since you didn't mention, V zero and AI seems
Speaker 4: to be a fairly popular topic.
Speaker 2: Yeah, not around here.
Speaker 5: Yeah, what does AI stand for?
Speaker 4: Okay, Apple Intelligence? I think there you go. Yeah, anyway, anyway,
Speaker 4: what can you tell us about V zero? I mean
Speaker 4: I've seen it, I played with it. It's really cool,
Speaker 4: but you know what, what can you tell us about it?
Speaker 5: Yeah? So we've been working on vzo for over a
Speaker 5: year now. The first version that we released was kind
Speaker 5: of our first experimentation into the generative UI space, taking
Speaker 5: these new large language models. At the time that we're
Speaker 5: getting really really good at being able to produce code
Speaker 5: and figure out how we could help them better craft
Speaker 5: the front end, you know, do animations, do CSS. And
Speaker 5: over time we've just been slowly and slowly adding more functionality.
Speaker 5: So vzero now supports building full stack applications. You can
Speaker 5: integrate through databases through Purcell, you can add secrets or
Speaker 5: environment variables through for sell to connect to any external services,
Speaker 5: maybe some AWSQ service you want to use, could be
Speaker 5: really anything. And we've also launched a community that has
Speaker 5: published many different VZO generations that you can fork and
Speaker 5: get started with. So what once started as a very
Speaker 5: small tool to allow you to quickly build some UIs
Speaker 5: is now this kind of full featured prototyping and app
Speaker 5: building platform that allows devs to take an idea, whether
Speaker 5: something they want to build from a screenshot or a
Speaker 5: prompt or a pre existing kind of template, take it,
Speaker 5: fork it, prompt it, turn it into something that they
Speaker 5: would like to build or they would like to use,
Speaker 5: and then deployed to purcell and just a couple of
Speaker 5: clicks and have that thing actually live on the internet
Speaker 5: to share. And since we've been slowly adding more of
Speaker 5: these features, the growth trajectory of Vizerra has been it's
Speaker 5: been really wild to see. Obviously, AI is very popular
Speaker 5: right now and lots of people are interested in getting
Speaker 5: excited in how these tools can help them kind of
Speaker 5: level up their careers as developers. But I think more
Speaker 5: interestingly bring in a whole new group of people into
Speaker 5: what it means to be a developer. It's less about
Speaker 5: writing the code for these people. It's more about they
Speaker 5: have great ideas and they now have tools that actually
Speaker 5: allow them to build those ideas. So think about, for example,
Speaker 5: the product market is the product managers, maybe some of
Speaker 5: the designers who don't have as much coding experience, A
Speaker 5: lot of them are being able to use tools like
Speaker 5: the Zero and actually build and publish their ideas.
Speaker 4: So I have a ton of questions about that. So
Speaker 4: first of all, do you want to start?
Speaker 2: No, go ahead, Actually let me.
Speaker 3: I'm gonna get in. So I don't worship at the
Speaker 3: react alter myself. I'm a view DV myself, and so
Speaker 3: I tend to work more with you and Laura Vellen,
Speaker 3: Nursha and stuff. So I've heard Burssell talked a lot
Speaker 3: about but I don't really know it, and I suspect
Speaker 3: there's a lot of people listening who might not know
Speaker 3: it as well.
Speaker 5: So before you.
Speaker 3: Dive anymore into Dan's question that I was wondering if
Speaker 3: you could just give an overview on what Brossell is
Speaker 3: and who it's target audience is, I guess.
Speaker 5: Yeah, absolutely, Bricell is a developer cloud. So we're trying
Speaker 5: to give you, as a developer all the tools you
Speaker 5: need to build websites and applications, from hosting and managing
Speaker 5: your react or view or Spelt applications, to having observability
Speaker 5: into your production infrastructure usage, integrating with databases or other
Speaker 5: back end services and other cloud providers or hyperscalers, bringing
Speaker 5: all of these tools into kind of one place that
Speaker 5: you can use as you know, you put all your
Speaker 5: lego bricks together to actually be able to build your
Speaker 5: your amazing piece of art. And that's that's Brissell at
Speaker 5: a fifty thousand foot view.
Speaker 3: So now you just mentioned VT. I'm sorry you mentioned View,
Speaker 3: but I'm looking at your supported frameworks docs and I
Speaker 3: don't see you listed anywhere.
Speaker 5: Yeah, we Next and Sevelt. I see Next, and now
Speaker 5: we support Next is the primary way we see people
Speaker 5: deploying view applications to Rosell, but we also support doing
Speaker 5: a more traditional just client only view application as well.
Speaker 5: Generally we like to recommend NEXT. I think they're building
Speaker 5: something really great with the framework. But also if you
Speaker 5: want to use a like VT and view application for example,
Speaker 5: that's also supported.
Speaker 4: Okay, So going back to V zero, first of all,
Speaker 4: V zero V one.
Speaker 5: Yeah, right, it's like, Okay, as we continue to iterate
Speaker 5: on it, do we bump above the version number? No,
Speaker 5: the naming it's it's kind of funny.
Speaker 2: One.
Speaker 5: Yeah, yeah, yeah, I didn't expect this to happen, but
Speaker 5: we've seen a lot of people have a play on
Speaker 5: the name of V zero. So we saw an email zero.
Speaker 5: I think there's a YC company now doing a zero
Speaker 5: or something like that. So it's been fun to see
Speaker 5: other people take this idea of gen ui and apply
Speaker 5: it to other domains, emails, mobile apps, et cetera. But really,
Speaker 5: the whole intention behind the name was you can get
Speaker 5: started here. It's not necessarily saying it's gonna replace your
Speaker 5: production code. It's not going to, you know, prevent the
Speaker 5: need from still writing a lot of code. It's helping
Speaker 5: you get started quickly and building something great.
Speaker 4: By the way, there's the void zero that's even us
Speaker 4: in your company.
Speaker 5: Yeah, yeah, it was funny. I think that name was
Speaker 5: after V zero, but then it's pretty pretty similarly named,
Speaker 5: which is kind of funny.
Speaker 2: Yeah.
Speaker 4: So the fact that it's V zero kind of and
Speaker 4: also looking at the demos that you primarily show, it
Speaker 4: seems to indicate that what you're building is literally version
Speaker 4: zero of a product that it's taking either an idea,
Speaker 4: a concept like you said, maybe an image or a screenshot.
Speaker 4: Does it also support Figma or something like that.
Speaker 5: Yeah. Yeah, you can paste in a Figma link and
Speaker 5: it can understand your design system, colors and what's on
Speaker 5: the page and then start building an UI from there.
Speaker 4: Yeah. And basically it turns that into code that interactively
Speaker 4: replicates the design that you gave to it, correct.
Speaker 5: Yeah. Yeah. And the big difference in the way to
Speaker 5: think about this versus a no code or a low
Speaker 5: code tool is generally with the previous generation of tools
Speaker 5: kind of pre AI was the code that you got
Speaker 5: out from the low code or no code tool was
Speaker 5: not necessarily production quality code. It was not code that
Speaker 5: was using the popular frameworks of the world that you
Speaker 5: could then take and kind of eject and actually start
Speaker 5: building your application into something that was a real app.
Speaker 5: It was more so like maybe just a big blob
Speaker 5: of HTML with some JS in there. It wasn't using
Speaker 5: the ecosystem of the MPM libraries that we have today
Speaker 5: versus kind of rebuilding everything from scratch, and it wasn't
Speaker 5: also built on top of reusable accessible component primitives, which
Speaker 5: is something that zero does use. Which is a component
Speaker 5: distribution system called chad cyn ui M.
Speaker 4: Yeah, I'm familiar of course with chat CN. Chats chad CN.
Speaker 4: It's a component library UI component library popular one, probably
Speaker 4: popular one.
Speaker 5: It's a it has a unique approach because the traditional
Speaker 5: way of distributing component libraries, you know, think about maybe
Speaker 5: material UI is a very popular one, for example, from
Speaker 5: from Google. They build these abstractions that are very good.
Speaker 5: They get published as MPM packages, and then you pull
Speaker 5: them down and you use them in your app. But
Speaker 5: what happens when you want to take that and kind
Speaker 5: of transform it to your own design system, your own brand. Well,
Speaker 5: you can extend them to an amount, but you don't
Speaker 5: control the code. You're using the substraction through MPM, and
Speaker 5: you can't go in and actually modify the source code
Speaker 5: very easily. Of course, there's hacks, right. What chadzyen is
Speaker 5: trying to do is it's more of a component library
Speaker 5: distribution system or a way for you to build your
Speaker 5: own component library. So it gives you all of the code.
Speaker 5: You can effectively copy paste it into your you know,
Speaker 5: into your editor, into your project tweak all the tokens
Speaker 5: and the design system colors, and install packages, delete packages,
Speaker 5: and then there's a nice CLI that helps you add
Speaker 5: new components as as you need them.
Speaker 2: I gotcha, I have to say.
Speaker 1: I went on there and I mashed the button for
Speaker 1: a landing page, and uh, it gave me a next
Speaker 1: st app and then I clicked preview and it said
Speaker 1: it couldn't load because I could find the CSS file.
Speaker 1: But I mean, the code looks good. Is Yeah, it's
Speaker 1: just a little but it's a I and it generates
Speaker 1: and sometimes misses things I've seen.
Speaker 5: Yeah, you should try the Is there a fixed button
Speaker 5: in the bottom left. Ideally if there's an air thrown,
Speaker 5: there will be a little fixed button. Which is a
Speaker 5: good time to talk about the general philosophy of these tools,
Speaker 5: part of the reason why we called it V zero two.
Speaker 5: With with these you know, non determinis AI systems, they're
Speaker 5: going to get things wrong right there. It's never going
Speaker 5: to be perfect.
Speaker 1: And our generative it predicts the next word or in
Speaker 1: this case, the next token of your code.
Speaker 2: Yep, and so it'll miss stuff.
Speaker 5: Yeah, totally. So one thing we've tried to do from
Speaker 5: the unbounded space of you can generate any code in
Speaker 5: the world. To try to narrow that down into something
Speaker 5: that's predictably outputting consistent UI is we try to add
Speaker 5: a lot of systems and pieces in place to narrow
Speaker 5: in and improve the quality ratio, because ideally, at the
Speaker 5: end of the day, as a consumer of this product,
Speaker 5: you want quality generations, both in the UI itself but
Speaker 5: in getting working functional code. And the biggest lever that
Speaker 5: we've done to do that is really focusing in on
Speaker 5: our niche, which is React applications. That's the pipeline where
Speaker 5: we're reviewing and ensuring that the data that goes into
Speaker 5: the system is really high quality, and also reviewing the
Speaker 5: output if somebody has a bad time. So, yeah, I'm
Speaker 5: curious if that works for you.
Speaker 4: So questions about that, First of all, which model are
Speaker 4: you using?
Speaker 5: There's a bunch. Actually, generally you can think about it
Speaker 5: as a big decision tree. Because the user puts in
Speaker 5: a prompt. That prompt, we first kind of have to
Speaker 5: classify what they were even trying to do. Were they
Speaker 5: trying to just ask a knowledge question, were they wanting
Speaker 5: to generate some code. There's a lot of branches that
Speaker 5: can go down and then even as it goes down
Speaker 5: the branches, we might want to flip between models on
Speaker 5: the fly depending on the quality of one model, or
Speaker 5: maybe a new model comes out. I think the new
Speaker 5: claud model was just released today, for example. So we
Speaker 5: try to make this system that helps us get the
Speaker 5: best quality output, and then we abstract away everything else
Speaker 5: in the middle and just focus on having really high
Speaker 5: quality data in and evals or tests to ensure that
Speaker 5: the quality is predictable.
Speaker 4: Or you could use deep sick if you don't mind
Speaker 4: a bit of Chinese propaganda on your page.
Speaker 1: Well maybe, but you can also run deep seek. I
Speaker 1: think it's unbiased on like a lama or something, and
Speaker 1: then you don't have all the filters in front of it.
Speaker 1: I mean, they still trained it on their own data,
Speaker 1: and so if you ask it questions about.
Speaker 2: History that are inconvenient, it.
Speaker 1: Just doesn't give you a correct answer because it has
Speaker 1: no idea.
Speaker 5: But yeah, I think a lot of the enforced were
Speaker 5: coming at the inference time compute. The test time compute
Speaker 5: was where they were doing a lot of the cloud
Speaker 5: hosted version of deep seq was where they were doing
Speaker 5: a lot of the biasing towards the answers that they
Speaker 5: didn't want to answer. So the open source models definitely
Speaker 5: in the training data, they are still biased in a
Speaker 5: certain direction, but you can get you can get better
Speaker 5: results by doing it that way. Which I've already seen
Speaker 5: a few models on hugging Face, and I think there's
Speaker 5: like a Lama distilled version as well.
Speaker 1: So yeah, I've played with I've played with deep Seek,
Speaker 1: and I've played with some of the other ones and
Speaker 1: it is really it's really good in a lot.
Speaker 4: Of So the name v zero seems to indicate that
Speaker 4: the focus on the product is on the initial generation
Speaker 4: and less so about taking an existing app and modifying
Speaker 4: it or adding capabilities into it. Is that correct or
Speaker 4: is that just my interpretation?
Speaker 5: That was definitely where we got started. As we've added
Speaker 5: more functionality to the product, we're now getting to a
Speaker 5: point where you know, in the future you'll be able
Speaker 5: to connect to a get repo and bring in the
Speaker 5: code you already have in your application and make changes
Speaker 5: from there. So I think in the future V zero
Speaker 5: will evolve to be more of your general purpose AI
Speaker 5: assistant that you can use for many different things, or
Speaker 5: is trying to incrementally get there as we tackle one
Speaker 5: problem and hopefully do it well before kind of moving
Speaker 5: on and expanding scope.
Speaker 4: So if that's the case, how is it different from
Speaker 4: something like Cursor or co pilot or or something like that.
Speaker 5: Yeah, totally. I think of Cursor and Windsurf and some
Speaker 5: of the AI enabled IDEs as tools for I'll call
Speaker 5: them professional programmers or professional coders who are primarily you know,
Speaker 5: in their ide in their editor all day. You know,
Speaker 5: they're fantastic at that. And I use z personally, which
Speaker 5: also has AI tools, but they're all incredibly good at this. Versus,
Speaker 5: I think the market for v zero and other tools
Speaker 5: doing more of the generative UI space is more so
Speaker 5: I think for the kind of adjacent folks who are
Speaker 5: now getting into development. Certainly, obviously I'm a professional programmer
Speaker 5: and I still use v zero, but I've seen a
Speaker 5: lot of people either learning to build products through v zero,
Speaker 5: or maybe they had an idea and they weren't really
Speaker 5: sure how to build it yet, all using v zero
Speaker 5: as a starting point to kind of kick off that
Speaker 5: knowledge where it's more about the design and the ideas
Speaker 5: and the product experience is just the code itself, and
Speaker 5: of course you can still view the code It's still
Speaker 5: important that you can observe the code and modify the code,
Speaker 5: but first and foremost is the actual thing that you're building,
Speaker 5: which is kind of just a different model than the
Speaker 5: professional programmers the IDEs, just a different different model.
Speaker 4: So I'll challenge you a bit about this, if you
Speaker 4: don't mind. I've been told that I sometimes ask tough
Speaker 4: questions and hopefully you're you're fine with it. Yeah, okay,
Speaker 4: if that's the case, if that's your target audience, the
Speaker 4: way that you're presenting it isn't React potentially too low
Speaker 4: of a level of abstraction, because you know, if I'm
Speaker 4: more of a designed person, you know, it's great that
Speaker 4: I can give my code to a developer later on,
Speaker 4: but if i'm playing with it, maybe I would like
Speaker 4: to play with, you know, at the higher level of abstraction,
Speaker 4: with more sophisticated box but less complicated boxes.
Speaker 5: Yeah. So, while we do use React, the default for
Speaker 5: v zero generally is going to be an XTGS application,
Speaker 5: so it is a higher level abstraction on the underlying
Speaker 5: React primitives generally. Though, the reason why I think React
Speaker 5: is a good fit for this type of model is
Speaker 5: when people are getting started with building their first application
Speaker 5: and they don't have a lot of experience. The mental
Speaker 5: model of components actually makes a lot of sense to people,
Speaker 5: more so than a vanilla HTML or a vanilla JavaScript file.
Speaker 5: Like if we go back to jQuery days and you
Speaker 5: have a thousand line j Query file, this is totally
Speaker 5: fine and it totally works. But you know, looking at
Speaker 5: specific query selectors, they're looking up an element by ID
Speaker 5: and then swapping out you know, the data from there,
Speaker 5: the styling from there is it as in two for
Speaker 5: the first time user, I think as looking at some
Speaker 5: React code, maybe not at first, but I think you
Speaker 5: pick it up a little bit more conceptually as you
Speaker 5: kind of get into the code a bit. At least
Speaker 5: that's been my experience talking with folks who are kind
Speaker 5: of learning or looking at React code for the first time.
Speaker 5: And secondly, the nice thing about the component model and
Speaker 5: composition of React is an LLM generates a bunch of stuff.
Speaker 5: You know, maybe there's ten different files, fifteen different files.
Speaker 5: You want to be able to place those into different
Speaker 5: you know, spots in your application without there being these
Speaker 5: global side effects. And that's one really nice thing that
Speaker 5: the React model does pretty well. Now, I will say
Speaker 5: if you are a little bit more uh maybe not
Speaker 5: super beginner, but maybe intermediate, and you kind of know
Speaker 5: a little bit. You know that you want to just
Speaker 5: work with HTML and male JavaScript. You can explicitly prompt
Speaker 5: the zero to say like, hey, I know what I'm
Speaker 5: doing here, Like, give me more of that low level
Speaker 5: primitive and I can kind of build from there.
Speaker 2: Cool, I want.
Speaker 4: Will it be just one more thing?
Speaker 2: Oh, go ahead.
Speaker 4: Will it be able to also generate let's say, stuff
Speaker 4: for Svelt.
Speaker 5: Yeah, I think right now it can do. It can
Speaker 5: answer spelt questions, and it can help you build Svelt applications.
Speaker 5: In terms of the completely dynamic running of SVELT applications
Speaker 5: in the browser, we don't have support for that yet,
Speaker 5: but I would like to get there in the future
Speaker 5: for sure. It kind of goes back to that quality
Speaker 5: of the unbounded space of next token prediction is already
Speaker 5: tough enough. So we're trying to slowly, you know, build
Speaker 5: a system that helps us get predictable, repeatable success and
Speaker 5: then we can consider expanding up further.
Speaker 2: Yeah, just related to that.
Speaker 1: So I told it what my error was in here,
Speaker 1: and it fixed it, just gave me a global CSS.
Speaker 1: But then the next thing I did is I said,
Speaker 1: can you give this to me as a next app
Speaker 1: instead of a next app? And of course then what
Speaker 1: it did is it gave me a next app with
Speaker 1: the source folder for the next step still in it,
Speaker 1: you know, but you know, and so you know, you
Speaker 1: figure this stuff out with your prompt engineering and things.
Speaker 1: But I think it's just fascinating how far you can get.
Speaker 1: And I've done this with other projects with AI, where
Speaker 1: I've essentially said, Okay, give me an app, you know,
Speaker 1: this kind of an app, you know, with chat, GPT
Speaker 1: or some of the other ones. Give me this kind
Speaker 1: of an app with these kind of features and these
Speaker 1: kinds of you know, deals.
Speaker 2: And I'm using tailwind and and and it'll do it.
Speaker 1: And then if I go and run it, I can
Speaker 1: come back and tell it I got this error and
Speaker 1: it will generally fix it within in one go.
Speaker 2: Sometimes it just it can't quite figure it out.
Speaker 1: And that's, you know, that makes me feel good because
Speaker 1: I'm never gonna not be able to get a job
Speaker 1: as a programmer. But yeah, it's it's pretty interesting to
Speaker 1: see how far you can get on this stuff.
Speaker 4: And yeah, how manytainable is the code that rates?
Speaker 5: How maintainable. Is the code mm hmm, I mean this
Speaker 5: is This is one of the biggest advantages, in my opinion,
Speaker 5: of building on foundations like existing popular open source frameworks,
Speaker 5: is that you're ejecting the code out into a system
Speaker 5: that is an open standard. It can be deployed to
Speaker 5: any infrastructure in the world, whether it's a S three
Speaker 5: bucket or deployed to something like Versell. And there's this
Speaker 5: thriving community of developers who are you know, consistently with
Speaker 5: every release, making the docks a little bit better, making
Speaker 5: the examples a little bit better, building all these templates
Speaker 5: in the community, you know, fixing bugs, making improvements, and
Speaker 5: it has the backing of a you know, a decently
Speaker 5: sized staff team in the next ys team who is
Speaker 5: helping make it better every day.
Speaker 2: Yep, I did run into a rate limit.
Speaker 1: I asked too many questions and then I said, you
Speaker 1: have to sign up for Versille to keep using.
Speaker 5: Yeah, yeah, sign up twenty dollars a month more.
Speaker 4: I know.
Speaker 2: Yeah, no, I've I've used Forversell in the past and
Speaker 2: I like it. Edit things going on there.
Speaker 4: I saw relatively new capability in it. I guess I'm
Speaker 4: guessing that you can select a component and ask it
Speaker 4: to modify just that component RRECT. That's a relatively new feature,
Speaker 4: I think. M I think the next step would be
Speaker 4: to add some sort of dragon drop capabilities or something.
Speaker 5: Yeah, we'd love to find a good way to you know,
Speaker 5: bridge the gap of a little more visual editing, you know,
Speaker 5: tooling that helps you think about the UI from a
Speaker 5: higher level of abstraction versus just prompting. Of course, you
Speaker 5: can get very far with prompting, but sometimes you like
Speaker 5: the tools that you know, things like a figma might have.
Speaker 5: There's some pretty helpful stuff in there.
Speaker 4: Yeah, okay, So anything else you want to say about
Speaker 4: V zero before moving on to the next one. Yeah,
Speaker 4: you've got one, the whole bunch of tools.
Speaker 1: Yeah, I just wanted to jump in on V zero.
Speaker 1: So it's targeted at people who maybe don't have a
Speaker 1: ton of coding experience or you know, I could see this,
Speaker 1: you know, it gave me a nice enough layout on
Speaker 1: the thing that I clicked on that I could see
Speaker 1: this as just kind of a hey, this is a
Speaker 1: kickoff point for me, and I'm confident at this stuff.
Speaker 2: Are you seeing this.
Speaker 1: As something that could conceivably become a proper dev tool
Speaker 1: or are you looking to go in that direction with
Speaker 1: something else, or where do you land on that?
Speaker 5: Yeah, at least for me in my experience, I already
Speaker 5: consider it a proper dev tool. It's something that I
Speaker 5: use to build a lot of applications that or ideas
Speaker 5: that I have that maybe I want to almost run
Speaker 5: in parallel. But you can try out a couple different
Speaker 5: ideas and like, Okay, I like this version better. I'm
Speaker 5: going to prompt this one and go a little bit further.
Speaker 5: I recently wrote a blog post about this called personal software.
Speaker 5: I think other people have called it vibe vading, whichld
Speaker 5: I like the name of. Basically, it's it's not necessarily
Speaker 5: saying this is, you know, production software used by the government.
Speaker 5: But there's lots of software and applications to be built,
Speaker 5: and it can be very fun to do it in
Speaker 5: that way. So I think we're seeing a lot of
Speaker 5: adoption for those type of use cases. The only other
Speaker 5: thing I'll mention on v zero is if you're really
Speaker 5: curious about how it's built, everything that powers V zero,
Speaker 5: we have open sourced a chat GPT like application doing
Speaker 5: very similar things, so it's kind of build your own
Speaker 5: chat GPT chatbot that can you know, generate code and
Speaker 5: run code in the browser. It can generate spreadsheets and
Speaker 5: create images, and you know have the canvas or artifacts
Speaker 5: like features that claude and chatcheeps you have. And that's
Speaker 5: part of our AI s d K, which is another
Speaker 5: framework that we maintain. It's like lower level primitives to
Speaker 5: help you build AI applications. So chatt for cell dot
Speaker 5: ais that template if you want to try it out,
Speaker 5: and it's all open source so you can fork it
Speaker 5: and build your own.
Speaker 2: Awesome.
Speaker 4: I just want to mention that my connection has become
Speaker 4: a bit spotty all of a sudden. So if I
Speaker 4: drop off for anything, that's hopefully that won't happen, but.
Speaker 5: You know, no worries.
Speaker 1: If it happens, then people will miss you because I'll
Speaker 1: ask all my dumb questions.
Speaker 4: So anything else about v zero.
Speaker 5: No. I think that's that's the majority of it. If
Speaker 5: you haven't given a shot, please do, and I'd love
Speaker 5: to hear feedback. For anybody listening, feel free to shoot
Speaker 5: me a message.
Speaker 2: Nice.
Speaker 4: So, of course, I think versall is best known for
Speaker 4: next JS. I think, although it's important to note that
Speaker 4: for Cell and next JS are not the same thing,
Speaker 4: So maybe that's actually something worth talking about, like the
Speaker 4: relationship between selling next js.
Speaker 5: Yeah. Yeah, So going back to twenty sixteen, kind of
Speaker 5: a ways away, when Vercell was getting started, Germa was
Speaker 5: trying to build a really high quality front end, a
Speaker 5: really high quality application, and at the time wasn't very
Speaker 5: satisfied with the state of tooling and like you know,
Speaker 5: every engineer, well, rather than building my product, I'm going
Speaker 5: to build the tooling for the product. Instead, I spent
Speaker 5: you know, a decent chunk of time building out what
Speaker 5: was you know, the first version of next js back
Speaker 5: in twenty sixteen, and the idea at the time was
Speaker 5: putting together a React application is kind of hard, and
Speaker 5: he wanted to build a server first or a server
Speaker 5: side rendered React framework that would make that easy to create,
Speaker 5: you know, application UI marketing pages, dashboards, e commerce sites,
Speaker 5: and so on. And this was really about the same
Speaker 5: time that Create React App came out, so only a
Speaker 5: few months apart, and they both kind of served unique purposes.
Speaker 5: Over the years since then, nextgs has grown to add
Speaker 5: a lot more functionality. The community has grown to be
Speaker 5: a React framework that can build pretty much any type
Speaker 5: of application, If you want to build an interactive dashboard
Speaker 5: like some kind of single page app, that's totally doable.
Speaker 5: If you want to build SEO optimized marketing pages or
Speaker 5: logged out e commerce experiences, that's also possible. If you
Speaker 5: want to build new AI chatbots where you can stream
Speaker 5: in responses from the server, that's another prominent use case
Speaker 5: of NEXTGS. So it all kind of sits on the
Speaker 5: foundation of react as the UI rendering layer, the UI
Speaker 5: engine for your components, and then we add some nice
Speaker 5: views in the middle to simplify working with images and
Speaker 5: optimizing fonts and optimizing third party scripts and streaming content
Speaker 5: from the server and building out your API layer and
Speaker 5: so on and so forth. So going back to your
Speaker 5: original question on the relationship, over the years, we've just
Speaker 5: continuously been investing in this MIT license open source framework
Speaker 5: to a point now where we have one point three
Speaker 5: million monthly active developers on NEXTGS and I think we're
Speaker 5: at eight point five million weekly downloads on MPM. So
Speaker 5: really the trajectory has been great for folks picking up
Speaker 5: and adopting and putting next gs in production for both
Speaker 5: you know, personal sites, small startups and really large enterprises.
Speaker 5: For sell.
Speaker 4: I would just like to interject there an interesting statistics
Speaker 4: the statistic that I saw. So, there's the Google Crux database.
Speaker 4: Are you familiar with it? Yes, so, they obviously so
Speaker 4: they Mostly it's used for looking at the performance of
Speaker 4: production websites that Google scans, but it also analyzes the
Speaker 4: technologies with which those sites are constructed. So you can
Speaker 4: actually ask it, you know, show me the performance of
Speaker 4: all the reacts sites, so show me the overall performance
Speaker 4: of all the view sites and so forth. But you
Speaker 4: can also just basically ask it a simple question like
Speaker 4: how many sites do you see that use React? How
Speaker 4: many sites do you see that use Next? And it
Speaker 4: seems to me, looking at the numbers, it seems to
Speaker 4: me that if you're building a new website using React,
Speaker 4: you're probably it's probably being built with Next because looking
Speaker 4: at this again, at the statistics from from twenty twenty
Speaker 4: two up to now, the numbers seem to indicate that
Speaker 4: that that period of time, React websites that Crux analysis
Speaker 4: have grown by something like ten percent, but the next
Speaker 4: GS websites have like tripled or something along these lines.
Speaker 4: So effectively, it means that if you're building a React website,
Speaker 4: then it's probably being built with NEXTGS. Is that does
Speaker 4: that kind of match what you're saying.
Speaker 5: So, the last time I checked out the http archive
Speaker 5: data which backs the crux report, was in the December
Speaker 5: of last year of twenty twenty four, and at the
Speaker 5: time there were twenty eight thousand of the top million
Speaker 5: sites that we're using NEXTGS, which is pretty good. I'm
Speaker 5: pretty happy with that. And of those twenty eight thousand,
Speaker 5: fifty percent of them were using the new routing system
Speaker 5: inside of NEXTGS called the app router, which under the
Speaker 5: hood uses some of these new React features like React
Speaker 5: server components and server actions, and some of the lower
Speaker 5: level things like streaming that overall helped get better core
Speaker 5: web vitals. So it's been awesome to see on two fronts. One,
Speaker 5: just the general adoption of folks building React sites too,
Speaker 5: those who are choosing to pick next gs as their
Speaker 5: React framework of choice. But then three, those who are
Speaker 5: now starting to build with the app router or incrementally
Speaker 5: migrating over to the app router are generally seeing better
Speaker 5: COREBA vitals across pretty much all dimensions versus kind of
Speaker 5: the previous model of next Yes, that still exists, but
Speaker 5: we're kind of investing in this on ramp over time
Speaker 5: for people to take better advantage of the server for
Speaker 5: some things and better advantage of the client for other things.
Speaker 4: So GTP Archive actually identifies websites that use the new
Speaker 4: app router.
Speaker 5: Yeah, yeah, by looking at the different tags in the body.
Speaker 4: Oh that's cool. I didn't know that. I knew that
Speaker 4: it identifies next. Yes, I didn't know that it actually
Speaker 4: is able to distinguish between the patriarter and the app router.
Speaker 4: That's really cool. But conversely, what I'm also saying so
Speaker 4: about well over half a year ago, I switched jobs,
Speaker 4: and while I was, you know, hunting for a new position,
Speaker 4: I was looking at I was speaking with various companies
Speaker 4: and also because of the type of position that I
Speaker 4: was looking for, I was also kind of looking at
Speaker 4: the technology stacks that they were using and whatnot. And
Speaker 4: it was what I saw was that, again it's anecdotal,
Speaker 4: but it's it was still fairly you know, consistent, let's
Speaker 4: call it. It seemed that indeed, if you're building a
Speaker 4: website using React, then you're highly and by website I
Speaker 4: mean something that you know Google would would likely rank
Speaker 4: or scan. Then it's highly likely that you're using next JS.
Speaker 4: But a lot of organizations that are building web apps
Speaker 4: there are a lot of time still predominantly client side
Speaker 4: only in terms of their React usage, and then they're
Speaker 4: kind of not using React or any other kind of
Speaker 4: full stack framework, and they're like mostly just doing React
Speaker 4: on the client side and using not necessarily even JavaScript
Speaker 4: on the back end. They might be talking directly to
Speaker 4: you know, RESTful endpoints implemented in whatever. Yep, So are
Speaker 4: you thinking about somehow addressing that market as well?
Speaker 5: Yeah, totally. I think our story today is maybe under discuss,
Speaker 5: but we have a pretty strong story for building single
Speaker 5: page applications in next yes, or kind of fully client
Speaker 5: applications most of the time. Obviously, I talk a lot
Speaker 5: about the server stuff because I'm particularly excited about making
Speaker 5: it easier for developers to use features on the server.
Speaker 5: But for a lot of apps, especially, I don't know,
Speaker 5: an internal dashboard at some very large company where they've
Speaker 5: already got an established you know, it's probably not even
Speaker 5: a node back in. Maybe it's a go back in
Speaker 5: or Java or something else. They've got to RESTful API somewhere,
Speaker 5: and their infra team hands them down this opportunity you
Speaker 5: can deploy a site to S three. Right, you can't
Speaker 5: run a server, but you can put some static files
Speaker 5: here and doing that, their only option basically is to
Speaker 5: do a client only application, and we want to make
Speaker 5: nextys a great opportunity for those folks who are wanting
Speaker 5: to use React as well. So we have inside of
Speaker 5: nextgs this thing called a static export basically where you
Speaker 5: can tell the app basically strip away the no jess server.
Speaker 5: I just want to generate a bundle of HTML, JavaScript,
Speaker 5: CSS files and then I can drop them in an
Speaker 5: S three bucket and just kind of be on with
Speaker 5: my day. And you know, even further, if I want
Speaker 5: to basically opt into one hundred percent rendering in the
Speaker 5: browser on Clyde side rendering, we have a way you
Speaker 5: can basically skip server side rendering entirely, which for some
Speaker 5: teams they're like, yeah, like, I know it's maybe not
Speaker 5: the best UX. I know that maybe it's a little
Speaker 5: bit slower, but it's fine. Like I'm just building something
Speaker 5: that has a bunch of heavy charting libraries and I
Speaker 5: just want to go straight client only and that can
Speaker 5: be okay too.
Speaker 4: So you're basically saying that you can SSG static side
Speaker 4: generation into an S three bucket, and you can take
Speaker 4: it a step further and basically SSG a blank page
Speaker 4: into an S three bucket.
Speaker 5: Totally. Yeah. The way I think about it is there
Speaker 5: is a strict SPA which i'll define strict single page application,
Speaker 5: which is basically that blank HTML shell that boots up
Speaker 5: some client JS. There's a ton of websites built this way, right,
Speaker 5: Like a lot of the client React only apps are
Speaker 5: just built this way, and that's fine. You can do
Speaker 5: that in next GS. What we try to do is
Speaker 5: build this gradual ramp so you can do that. You
Speaker 5: can also pre statically generator pre render more of that
Speaker 5: page so it's not necessarily a blank HTML page, but
Speaker 5: like a good chunk of the shell that then boots
Speaker 5: up React on the client. Taking another step further, you
Speaker 5: can pre render multiple inputs. So maybe you have Slash
Speaker 5: the Slash route, maybe you have Slash dashboard, maybe you
Speaker 5: have Slash users. Each one of them has a different shell,
Speaker 5: so you're not looking at the like the page loads.
Speaker 5: You see one spinner while you're waiting for the client
Speaker 5: JAS to boot up, and then you've kind of loaded
Speaker 5: your client app. You can still get a little bit
Speaker 5: better UX by loading those shells and having different shells.
Speaker 5: And that's like three steps along this journey. But there's
Speaker 5: actually five more steps if you want to take it.
Speaker 5: I get if you decide. Actually, I am okay with
Speaker 5: doing a little bit of stuff on the server. You
Speaker 5: can even run a what sometimes called a back end
Speaker 5: for front end, but you can use the next day
Speaker 5: a server just to effectively, you know, have your secrets
Speaker 5: to talk to your API, have your bear token, and
Speaker 5: still have your rest API somewhere else, so you don't
Speaker 5: have to do some kind of like you know, wild
Speaker 5: proxy situation. It's basically just a proxy.
Speaker 4: Interesting. It's especially interesting given that react to the React
Speaker 4: core team is effectively retired Create React app.
Speaker 5: Yeah, I think from their perspective, which makes a lot
Speaker 5: of sense, you know, going back in time, when create
Speaker 5: React app came out, like I mentioned, it was basically
Speaker 5: the exact same time as next gs, and the state
Speaker 5: of building a React app was way more difficult than
Speaker 5: it is today. Today, there's this vibrant ecosystem of frameworks
Speaker 5: and even lower level tools like bundlers, who are building
Speaker 5: deeper integration into all of the bits of React. And
Speaker 5: I think for dev's getting started. It's just dramatically easier
Speaker 5: to be productive right away, but to have a great UX.
Speaker 5: And that's kind of why I mentioned there's like this
Speaker 5: graduation curve. Yes, you can start here in the strict
Speaker 5: SPA mode, but like along the way, you're probably gonna
Speaker 5: want some of these things, Like you probably want to
Speaker 5: have that little bit better UX so you don't have
Speaker 5: to stare at that loading spinner while the user's loading
Speaker 5: the page. And you know, it'd be kind of great
Speaker 5: if I could prefetch some of that stuff on the
Speaker 5: server ahead of time, rather than having to wait for
Speaker 5: the client and like offloading all this work into the client.
Speaker 5: So it's kind of like we know, based on you know,
Speaker 5: let's call it ten years of React, you're probably going
Speaker 5: to run into like these three or four things and
Speaker 5: how you do routing, how you do data fetching, how
Speaker 5: you load your assets. So that's kind of why nexty
Speaker 5: has gives you all the building blocks for that, but
Speaker 5: then it's up to you and you get the choice
Speaker 5: as the developer on how much or how little you
Speaker 5: want to use if you want to use NEXTGS. Just
Speaker 5: as easy mode React, that's all client rendered like that's
Speaker 5: fine too.
Speaker 4: It's interesting or I'm using that. It's basically you guys,
Speaker 4: and then everybody else using VT.
Speaker 5: Yeah, yeah, I think V has been a great tool
Speaker 5: for those people who want to kind of build their
Speaker 5: own type of system. So maybe they want to do
Speaker 5: you know, they pick their own bundler and V. They
Speaker 5: pick their own router, maybe a React router, they picked
Speaker 5: their own other pieces of the puzzle, a data fetching solution.
Speaker 5: Maybe they're using something like a React query for example,
Speaker 5: and they can kind of put those pieces together based
Speaker 5: on whatever the needs are for their app. That's totally fine.
Speaker 5: I still see a ton of people doing that. What
Speaker 5: we've tried to do with NEXTGS is provide another option,
Speaker 5: which is like, if you want to have all of
Speaker 5: that baked into the framework itself, that's one solution that
Speaker 5: we offer. But yeah, it's totally fine. I think it's
Speaker 5: a lot of a thousand Flowers Bloom type situation where
Speaker 5: it's it's not a bad thing to have a lot
Speaker 5: of options in the ecosystem. I think this is primarily
Speaker 5: why React is still so popular ten years later.
Speaker 4: But is it really that way, Because it does seem
Speaker 4: that a lot of the React Core team has moved
Speaker 4: from Meta into Versall to the extent that it almost
Speaker 4: seems like the next version of React is next GS.
Speaker 4: So is it a kind of world where next GS
Speaker 4: is kind of eating React.
Speaker 5: That's not really how I see it, because if you
Speaker 5: look at the percentage of the people who work and
Speaker 5: contribute to React that work at Versal, it's still pretty
Speaker 5: small in comparison to the broader scope of the React team.
Speaker 5: I think a lot of people don't know the extent
Speaker 5: of how big the React team is. At Meta, they
Speaker 5: do a lot of fantastic work, not only for the
Speaker 5: React core team itself, but for React Native and for
Speaker 5: supporting all the React development for other kind of pieces
Speaker 5: of the ecosystem. At Meta, Vercelle certainly is helping push
Speaker 5: React forward insofar as we're contributing some of the server features.
Speaker 5: Things that we're helping with like server actions, for example.
Speaker 5: We've played a decent chunk in contributing a lot of
Speaker 5: that work. But ultimately, at the end of the day,
Speaker 5: it's still a partnership between Meta and us and hopefully
Speaker 5: more companies in the future as well. I think from
Speaker 5: the React team's perspective, they would love to have more
Speaker 5: kind of full time contributors to help build this out.
Speaker 5: But it's a pretty big investment in terms of your
Speaker 5: companies R and D spend, and it's something that Versella
Speaker 5: is kind of motivated to do because we also are
Speaker 5: trying to make next to us a great framework that
Speaker 5: built on top of reactions. We're willing to invest the
Speaker 5: capital in terms of funding people on our team to
Speaker 5: help contribute to the core library. So yeah, that's the
Speaker 5: way I think about it. I think it's great that
Speaker 5: we help contribute to reaction. I would love to see
Speaker 5: other companies join as well.
Speaker 4: Cool I like that approach.
Speaker 1: So are there are there new innovations in next JS
Speaker 1: that you want to tell us about or things that
Speaker 1: are coming up that people might want to hear about.
Speaker 5: Yeah. I think for me, the whole journey of twenty
Speaker 5: twenty five is it's basically two things. The first one
Speaker 5: is continuing to make one percent iterations every release, every
Speaker 5: day on the foundations the fundamentals, really great stack traces,
Speaker 5: really great air overlays that are beautiful and they help
Speaker 5: you find the answer quickly. Really great performance when you're
Speaker 5: working locally, fast compilation, fast, hot module reload, fast, builds
Speaker 5: a lot of the things that are the bread and
Speaker 5: butter of the framework per se. Maybe not the most
Speaker 5: sexy fee in the world, but we think that performance
Speaker 5: in stability is a really important piece of what people
Speaker 5: who have signed up to use NEXTGS in their company
Speaker 5: appreciate in terms of frequent updates and improvements. So that's
Speaker 5: a heavy, heavy focus for us. The next release of
Speaker 5: NEXTGS here in a few weeks probably or maybe shorter.
Speaker 5: We have a new redesigned air overlay that looks so great.
Speaker 5: It's it's got better stack traces, it's easier to find
Speaker 5: the information, it's got some nice animations, like just the
Speaker 5: little delights of polish that make the everyday experience of
Speaker 5: working in the framework better. So there's a ton of
Speaker 5: stuff in that category. And then the second category is
Speaker 5: how do we take, you know, years of feedback on
Speaker 5: the framework and kind of continuously innovate and simplify the
Speaker 5: existing model along the way while still respecting that you know,
Speaker 5: a lot of people are building their apps in a
Speaker 5: certain way and we don't want to disrupt their workflows,
Speaker 5: but we want to give them a solution over time
Speaker 5: that's increasingly more simple for them to adopt, especially for
Speaker 5: new people who are just getting started in the framework.
Speaker 5: So an example of this is in two ways, one
Speaker 5: and around casing and two around the story with data fetching.
Speaker 5: So probably the biggest piece of feedback on next yiest
Speaker 5: for the past couple of years is very powerful that
Speaker 5: it has cashing, but would love to see the default
Speaker 5: experience be a little bit easier. It's like it felt
Speaker 5: like the ramp from okay, I can do cashing to like,
Speaker 5: oh yeah, this is why cashing is really hard was
Speaker 5: like happening too quickly. So we've been working on an
Speaker 5: improved system that allows you to define directives. It's like
Speaker 5: a string like use cash and cash a function or
Speaker 5: cash a React component in a much more granular, composable way.
Speaker 5: That's going to be coming here very soon. Then the
Speaker 5: next piece that builds on top of that is the
Speaker 5: ability to write code that looks asynchronous and have it
Speaker 5: actually be a page that's dynamically rendered. So I'll give
Speaker 5: you an example. You have a React server component. You
Speaker 5: might think, okay, that server component requires a server. The
Speaker 5: first misconception there is you can take a server component
Speaker 5: and you can do that static expert I mentioned and
Speaker 5: run it as a pre rendered component that just spits
Speaker 5: out some HTML. Right, So it's kind of like, yeah,
Speaker 5: it's like a React build time component, just it has
Speaker 5: the access to the server. So you've got the server component.
Speaker 5: You say async function await get data from database. If
Speaker 5: you write a call like await get data from database,
Speaker 5: you're probably expecting that to be fresh data like this
Speaker 5: is you're making a call and you didn't say that
Speaker 5: you wanted anything to be cashed, right. But the inherent
Speaker 5: confusion here comes with this idea of pre rendering. If
Speaker 5: it's running during the build, you're trying to pre render
Speaker 5: as much of the page as possible, and that's really
Speaker 5: good because you can get that fast initial response when
Speaker 5: you have the pre render. So the two kind of
Speaker 5: pieces in parallel in this next phase are if I
Speaker 5: write code that looks dynamic, the page should default to
Speaker 5: being dynamic. And then me as a developer, I get
Speaker 5: the opportunity to say, you know, which way do I
Speaker 5: want to go? Should this be fresh on every request? Okay, great,
Speaker 5: I'd put suspense around it. Reacts suspense. If it's not
Speaker 5: and it's something I want to pre render, I put
Speaker 5: use cash on it. So you have these like two
Speaker 5: paths of which way you want to take, and those
Speaker 5: three things, the first two and then the third one
Speaker 5: being partial pre rendering, which is effectively just a way
Speaker 5: to get a larger amount of the page pre rendered.
Speaker 5: I think will simplify the experience of making next years
Speaker 5: apps quite a bit, So I'm looking forward to that
Speaker 5: future as well.
Speaker 4: It's interesting. Well, of course, you know that they say
Speaker 4: that there are two hard problems in computer science naming things, cashing, validation,
Speaker 4: and off by one errors. So yeah, cashing is hard.
Speaker 4: The need for cashing, by the way, I mean, it's
Speaker 4: worthwhile to touch a little bit about why all this
Speaker 4: discussion about cashing. I think it has to do with
Speaker 4: the fact that we encapsulating data access and that can
Speaker 4: really easily lead to waterfalls and and so one way
Speaker 4: is to basically obviously just break encapsulation and get all
Speaker 4: the data as efficiently as possible yourself and stream it
Speaker 4: into the components. But then the components aren't self contained.
Speaker 4: So the alternative is to say, I will get the
Speaker 4: data at the component level, but I'm really smart about
Speaker 4: cashing to avoid really getting the same data multiple times
Speaker 4: and making all the data retrieval as efficient as possible,
Speaker 4: and that's the route that you guys seem to be taking.
Speaker 4: It will be very interesting to see how efficient, how
Speaker 4: how we are able to achieve this combination of efficiency,
Speaker 4: ease of use, and correctness. It's not going to be
Speaker 4: a trivial combination.
Speaker 5: M Yeah. Just to your point on like why cashing
Speaker 5: the cash exists somewhere in the system. If it's not
Speaker 5: in your front end, then you're caching your API responses
Speaker 5: or you have some like a in memory cash in
Speaker 5: front of your database. Like most of the time, there's
Speaker 5: a cash somewhere in the stack. And I think what
Speaker 5: we're seeing with a next year's app router app and
Speaker 5: being more involved across the full stack basically react having
Speaker 5: more of an opinion about the network layer is that
Speaker 5: those caches are moving into more user code than a developer,
Speaker 5: a product developer is having to think about, which is
Speaker 5: very powerful, but it's maybe not something they had to
Speaker 5: consider previously because like, well that was some other team
Speaker 5: who worked on the rest API they added to casing layer.
Speaker 5: I just hit that endpoint as much as I want,
Speaker 5: I don't really have to think about it. You can
Speaker 5: still build that model in an extati.
Speaker 6: Comes out of the back of the computer right right
Speaker 6: or until your cash expires, and you didn't realize that
Speaker 6: your cash control headers were misconfigured, and then actually you
Speaker 6: overloaded your database and you didn't have the proper deal
Speaker 6: with air caching headers.
Speaker 5: So now your pages is down and you have to
Speaker 5: do a roll back. And there's a lot of hard
Speaker 5: parts in getting that right for sure, and building it
Speaker 5: into the system, like you said, while still maintaining correctness
Speaker 5: is tough. One of the things we use cash because
Speaker 5: we can use the compiler, which shout out to spelt
Speaker 5: who does a great job of using the compiler as
Speaker 5: well and making that kind of a core part of
Speaker 5: the design of both the language and the framework with
Speaker 5: spell Kit is that we can look at the inputs
Speaker 5: into the function, the actual variables being used inside of
Speaker 5: the code where you've marked it with this directive, and
Speaker 5: automatically figure out the cash keys. So you know, oh, shoot,
Speaker 5: I forgot to mark this as a cash key for
Speaker 5: something that actually changes, so I'm not able to automatically
Speaker 5: invalidate that cash when it changes. Like a lot of
Speaker 5: those really hard things, we can automate some of that
Speaker 5: away by using the compiler. It's obviously not perfect. There
Speaker 5: are still cases where you have to be aware of
Speaker 5: what you're doing with the cash and tag it correctly
Speaker 5: and validate it correctly. But more and more of that
Speaker 5: that we can build into the framework itself, the more
Speaker 5: little edge cases that you don't have to deal with.
Speaker 4: Yeah, at this point, it's worthwhile mentioning that we actually
Speaker 4: had Joe Savona and Satya from Meta to talk about
Speaker 4: React compiler, which is all about minimoralization, which is another
Speaker 4: way of saying cashing. So for sure, I'm totally with
Speaker 4: you on that.
Speaker 1: I wanted to point out one other thing, and that
Speaker 1: is that you know, you're you're talking about kind of
Speaker 1: figuring these things out as you go, and I think
Speaker 1: sometimes we kind of take for granted that things are
Speaker 1: just going to work without recognizing that. Yeah, sometimes the
Speaker 1: first pass is not great or at least not ideal,
Speaker 1: and so just keep that in mind when you give
Speaker 1: the feedback, Right, it's like, hey, look, you've got some
Speaker 1: great tools here, and we're going to give you better tools,
Speaker 1: you know, based on your feedback and things like that.
Speaker 5: Yeah, I think in an ideal world, right, you would
Speaker 5: never ship, and you would just cook away and private
Speaker 5: until you had the perfect API, and oh man, it
Speaker 5: was just the best thing in the world. People are
Speaker 5: gonna love this and I'm just going to keep waiting
Speaker 5: until I get it just right. And the reality is.
Speaker 2: Sounds nice too.
Speaker 4: Well. My dad likes to say that the worst enemy
Speaker 4: of good is better.
Speaker 5: The enemy I've done is perfection.
Speaker 2: Yes, yeah, I am.
Speaker 4: I am amused though that. You know, I'm still old
Speaker 4: enough to remember that the big selling point of JavaScript
Speaker 4: that was that it wasn't compiled. So it's really interesting
Speaker 4: to see how much of modern web development is actually
Speaker 4: based on bundlers and compilers. What you can think about
Speaker 4: bundlers as the modern day linkers, the fact that we
Speaker 4: are effectively compiling and linking the JavaScript code to get
Speaker 4: it to work the way that we need it to work.
Speaker 5: M yeah, I love the ambition. I think there's a
Speaker 5: lot of push in the web development community, especially those
Speaker 5: who have been programming for a while, like can we
Speaker 5: get back to the roots of a compiler free, bundler
Speaker 5: free experience? And I love the ambition of that age.
Speaker 5: Yeah yeah, I think I think there's good ideas there.
Speaker 5: I like the pragmatism of it. I think the reality
Speaker 5: is where do you want to make the trade off?
Speaker 5: And unfortunately, the trade off with that approach usually comes
Speaker 5: at the user experience, and that's like a trade off
Speaker 5: that I'm not usually willing to make because I'd rather
Speaker 5: have a compiler automate a lot of that work for me.
Speaker 5: But you know, things if you have to revisit your
Speaker 5: priors and recheck it year every year as technology continues
Speaker 5: to get better and better. So I agree spiritually with
Speaker 5: some of what he's saying, but I disagree on the
Speaker 5: effectiveness of compilers and bundlers in twenty twenty five.
Speaker 1: Yeah, I have to say, you know, just kind of
Speaker 1: coming from the other side of this too, may be
Speaker 1: a stronger degree.
Speaker 2: There's a lot of it depends in there.
Speaker 1: Right, If you're doing some things, you know, maybe you
Speaker 1: don't need it, and then in other cases it makes
Speaker 1: a lot of sense, and so you have to look
Speaker 1: at it. You have to look at your approach, You
Speaker 1: have to look at what you're using, your what your
Speaker 1: tools are, you know, what your framework expects of you.
Speaker 1: And then yeah, I don't know that there's necessarily a
Speaker 1: right way or a wrong way. A lot of times
Speaker 1: it's just you know, this makes a lot more sense here,
Speaker 1: and that makes a lot more sense there.
Speaker 4: Yeah, it's about the trade offs really. I mean, you know,
Speaker 4: if you can look at the extreme other direction as
Speaker 4: expressed by somebody like like Alex Russell. So so for sure,
Speaker 4: you know, it really depends on what you're trying to build,
Speaker 4: the functionality that you're trying to ship and whatnot. I mean,
Speaker 4: obviously the fastest website is going to be the blank page.
Speaker 4: So you know, it really depends on what you're trying
Speaker 4: to achieve. By the way, I saw another thing that
Speaker 4: might be worth men in the short time that we
Speaker 4: have left that you guys I think recently introduced, which
Speaker 4: is something called fluid. Can you say something about that?
Speaker 5: Yeah, so a quick kind of well, I'll try to
Speaker 5: make it quick. A little history on Vercell's computing back
Speaker 5: in the day. I'm sure you've probably familiar, but back
Speaker 5: in the day, we offered a server full platform where
Speaker 5: you could deploy Docker containers. You know, this was many,
Speaker 5: many years ago, and in some instances like that's really great.
Speaker 5: You can have a lot of flexibility with what you
Speaker 5: bring to the platform. It's it's unbounded. You can do
Speaker 5: anything as long as you can get it into Docker.
Speaker 5: It's harder though, to get a consistently good time because
Speaker 5: again it can be literally anything. This is back in
Speaker 5: the day kind of pre Verseell moving to a serverleist model.
Speaker 5: Along the way, we kind of found our footing, I think,
Speaker 5: with focusing on frameworks and focusing on being able to
Speaker 5: automatically find and generate the infrastructure as an output of
Speaker 5: the framework. So we call this framework to find infrastructure. Basically,
Speaker 5: it means you take a NEXTGS or next or SPELLCIT
Speaker 5: or whatever framework you want to use, you write code
Speaker 5: in the open source way, you bring it to Bursell,
Speaker 5: and Vercell looks at the output of the build process.
Speaker 5: So you run next build and you get a bunch
Speaker 5: of files, and we do the work to actually convert
Speaker 5: that into cloud infrastructure. We turn it into distributing those
Speaker 5: files to a CDN or running the on demand compute
Speaker 5: through for Cell functions and so on and so forth.
Speaker 5: So for many years now we've been doing servilest compute
Speaker 5: on top of AWS Lambda, and that also has a
Speaker 5: lot of benefits, but also some notable downsides. I think
Speaker 5: the biggest downsides that we've faced over the years. Number one,
Speaker 5: I think serverleists as a term has become increasingly unhelpful
Speaker 5: because it means everything to everyone and it's just so, yeah,
Speaker 5: it is basically cloud. It's like, okay, so what exactly
Speaker 5: do you mean by that? Do you mean auto scaling?
Speaker 5: Do you mean cost effective? Like? What are the more
Speaker 5: specific things that you mean? So I've increasingly struggled to
Speaker 5: explain what I'm talking about when I say server lists.
Speaker 5: The second and like the product feature that was the
Speaker 5: most damming or hard with lambda is for every one
Speaker 5: request to my nogs lambda, I can only use one function,
Speaker 5: so it doesn't have the multiicincurrency of what you can
Speaker 5: get out of a server. You can send many requests
Speaker 5: into one box. Generally, that means it's going to be
Speaker 5: a lot less efficient with your actual infrastructure usage, you know,
Speaker 5: one request to one function versus load balancing in many
Speaker 5: different requests into a box. Effectively a server that ultimately
Speaker 5: ends up saving customers a lot of money when you
Speaker 5: can be more efficient with how you route the compute.
Speaker 5: So over the years, we had these kind of warts
Speaker 5: of server lists that we were trying to fix and
Speaker 5: pay rover. We would add new functionality to add streaming
Speaker 5: to for self functions, we would add new functionality to
Speaker 5: prevent you unbounded recursions that could rack up denial of wallets.
Speaker 5: We would add functionality into run very long workloads on
Speaker 5: top of functions. And then the latest things here is
Speaker 5: actually optimizing the lower level bits, so like the underlying
Speaker 5: infrastructure on top of the function We rewrote it in
Speaker 5: rust to make it very optimized, which you know, of course,
Speaker 5: just rewrite and rust and makes it faster right now,
Speaker 5: But we have really been optimizing every part of the
Speaker 5: stack to where now the last piece was making it
Speaker 5: much more concurrent, and we've now taken all of this
Speaker 5: and kind of bundled it into a new computing model
Speaker 5: that we're calling fluid compute. It's not necessarily something that
Speaker 5: is for sell only. We think you could you build
Speaker 5: your own version of this on cloud primitives if you
Speaker 5: would prefer, But generally it is trying to be a
Speaker 5: hybrid of servers and server lists, building off of our
Speaker 5: experience what some other people in the industry have done
Speaker 5: a lot of inspiration from things like Google Cloud Run
Speaker 5: for example, which is kind of coming at this from
Speaker 5: the opposite side, from the server side and having auto
Speaker 5: scaling servers with the general goal of being it's very
Speaker 5: cost effective. So if I'm doing a bunch of network
Speaker 5: io to a database or to an AM model, you
Speaker 5: know I want to I don't want to have to
Speaker 5: spend a bunch of extra money while I'm just waiting
Speaker 5: on all that network io, which for a lot of
Speaker 5: apps that's kind of the predominant, predominant usage of your
Speaker 5: compute is just talking back and forth. It's not the
Speaker 5: actual CPU time, so very cost efficient, very fast to
Speaker 5: start up and scale down, so it auto scales based
Speaker 5: on your traffic, which I think is really important, and
Speaker 5: ideally you can eliminate this cold start problem that has
Speaker 5: plagued server lists for a very long time. And we
Speaker 5: do that by keeping a pre warmed functions which is
Speaker 5: basically like Google Cloud runs minimum active instance is one.
Speaker 5: It's like you always have compute running that you can load,
Speaker 5: balance and send request into. So all of that is
Speaker 5: fluid compute and it's something that for Cell customers can
Speaker 5: opt into using today and we've seen some pretty awesome
Speaker 5: results from it.
Speaker 4: So it's kind of like Lambda functions, but they can
Speaker 4: live longer and service multiple requests and don't have to
Speaker 4: immediately shut down when they're done. Am I missing something?
Speaker 5: Yeah, totally. And if you're doing network IO, you're being
Speaker 5: charged for the CPU, right, you can be a lot
Speaker 5: more efficient when you're waiting on a bunch of calls
Speaker 5: your AI model or to your database, which ultimately drives
Speaker 5: down costs for very concurrent applications that are doing a
Speaker 5: lot of IO. So in some instances we've seen people
Speaker 5: saving as much as eighty five percent of their bill
Speaker 5: previously on the server list model. It obviously depends on
Speaker 5: your traffic patterns how concurrent your traffic actually is, but
Speaker 5: in almost all cases it's better for the customer.
Speaker 1: You said, this isn't running on Lambda or things like that,
Speaker 1: What is it running on?
Speaker 2: Is this your own platform or yeah?
Speaker 5: So we still use AWS, but over the years we've
Speaker 5: had to excuse me, over the years, we've had to
Speaker 5: kind of build our own custom pieces to handle support
Speaker 5: before Landa eventually had it. In some instances never had it,
Speaker 5: so for example, excuse me one second, got a cough.
Speaker 5: For example, Landa didn't have streaming until recently, I think
Speaker 5: maybe like a year ago. But when we launched the
Speaker 5: next year's app router, we wanted to have streaming and
Speaker 5: had to build that kind of independently on our system.
Speaker 5: So we still use AWS, still love AWS, but we've
Speaker 5: had to build a lot of that stuff ourselves said
Speaker 5: in another way, you can't go to AWS and purchase
Speaker 5: would compute off.
Speaker 4: The shelf, right, So you're using AWS as kind of
Speaker 4: like the hardware as it were, but you're building a
Speaker 4: lot of the functionality on top of that stuff that
Speaker 4: other that others might try to get from AWS but
Speaker 4: can't necessarily get from them, at least not yet.
Speaker 5: Yeah, and we've seen this exact same thing play out
Speaker 5: in our build infrastructure as well. So yes, you can
Speaker 5: go run a bunch of builds on EC two, but
Speaker 5: we had done that for many, many years and found
Speaker 5: there were a lot of little optimizations we wanted to
Speaker 5: make to make it more efficient and more cost effective.
Speaker 5: And it's not like we set out with the goal like, man,
Speaker 5: we really want to rebuild our build infrastructure and do
Speaker 5: something custom. It was more of an innovation was a
Speaker 5: necessity here. So we have a technical blog post that
Speaker 5: talks about this. But our internal build system is called
Speaker 5: HIVE and it's effectually we outgrew EASY two based on
Speaker 5: you know, millions and millions and millions of builds and
Speaker 5: ended up kind of building our own system on top
Speaker 5: of the underlying as primitives.
Speaker 4: Cool.
Speaker 5: So aw US is still great for like super reliable, fast,
Speaker 5: efficient cloud infrastructure. We're just trying to build. We're trying
Speaker 5: to build the right abstractions for a developers so they
Speaker 5: can take the best advantage of that infrastructure.
Speaker 2: Gotcha.
Speaker 1: So for the stuff in Fluid, how much of it
Speaker 1: is sort of transparent? You know, like I just build
Speaker 1: the next app and then I fluid it and then
Speaker 1: it just works and I get those optimizations versus Okay,
Speaker 1: you're going to deploy this to Fluid, You've got to
Speaker 1: use some of these APIs to get some of the goodies.
Speaker 5: Yeah, it's fully transparent. And this is kind of the
Speaker 5: beauty of the framework defined infrastructure model is you wrote
Speaker 5: an xtgs app or any framework app, and you had
Speaker 5: some kind of API and it works on your local machine.
Speaker 5: You've got your API. Awesome, you deployed to Purcell. We
Speaker 5: understand the output of the framework was an API. We
Speaker 5: convert it into a forceell function and you flip on
Speaker 5: the switch that says yes, I would like to use
Speaker 5: Fluid compute. You now have more cost effective, more concurrent
Speaker 5: optimized infrastructure without having to write the infrastructure code to yourself.
Speaker 5: It's still an output of the framework.
Speaker 2: So what frame we also have work then?
Speaker 5: Sorry, say the game.
Speaker 2: What frameworks do you support then?
Speaker 5: For fluid, any framework that can run compute unver sell,
Speaker 5: so any server rendered framework, any framework that allows APIs,
Speaker 5: or even you know, if you want to do, for example,
Speaker 5: a client VT application that uses the ver Cell Functions
Speaker 5: API directory, which is a way to add server side
Speaker 5: code to just a client on the app, those functions
Speaker 5: can also use Fluid as well. And also you can
Speaker 5: you know, maybe not as well known, but you can
Speaker 5: deploy Express apps to for sell or you know, newer
Speaker 5: frameworks like Ono, which is like a back end Express
Speaker 5: replacement and it also supports Python, so we run you
Speaker 5: can run Python APIs on versel too.
Speaker 2: Very cool.
Speaker 4: How about Ruby on rails?
Speaker 5: Yeah, yeah, it would it would be interesting. Not something
Speaker 5: that is kind of top of our list right now
Speaker 5: for Ruby or for PHB, but there are community libraries
Speaker 5: that do it, so some people have kind of hacked
Speaker 5: around it in the community, which I think is pretty interesting.
Speaker 1: So what else should people know what's going on at versaill.
Speaker 1: It's always interesting to see what you guys are doing.
Speaker 5: Yeah, So we talked about v zero, We talked about
Speaker 5: the AI s TK, We talked about next years and
Speaker 5: some of our improvements there, talked about for sale and
Speaker 5: fluid Compute, We talked about the flags SDK. We talked
Speaker 5: a little bit about shad cn UI, which I think
Speaker 5: is interesting. Shad cn works at for sale, so it's
Speaker 5: something that we are, you know, always investing in as well.
Speaker 5: And v zero natively understands chad cy end components as
Speaker 5: well as kind of funnily enough, chat Gubt and Claude
Speaker 5: also like their their UI applications on the web, also
Speaker 5: understand chad cend and can generate chadsand components, which is
Speaker 5: pretty cool. So it's awesome to see that standardization there.
Speaker 5: I think that pretty much covers everything. I mean, we
Speaker 5: can we can talk about other bits if you would
Speaker 5: want around for sales, infrastructure and or other next shift features,
Speaker 5: but that we've we've covered quite a bit of service area.
Speaker 2: Yeah.
Speaker 1: Well, we're kind of getting toward the end of our
Speaker 1: time too. If people want to connect, they have questions
Speaker 1: about versell or v zero or anything else we've asked about.
Speaker 1: How do they reach you or get help from other
Speaker 1: people at Vercell.
Speaker 5: Yeah, if you want to reach out to me, please
Speaker 5: send me a message on x Twitter. Uh. If you
Speaker 5: have feedback on any of our product there should be
Speaker 5: a feedback button in the UI on every single one
Speaker 5: of our surfaces if you want to just go directly there,
Speaker 5: that all gets red and routed to the right teams.
Speaker 5: So just know your feedback is heard. And you can
Speaker 5: also email me Lee at verssel dot com for those
Speaker 5: of you who used to like email.
Speaker 4: All right, I love Well, I'll tell you one thing.
Speaker 4: You know, we predominantly use Slack, and I keep losing
Speaker 4: things on Slack. Somebody sends a message in one of
Speaker 4: the channels I'm like subscribed to like a million channels
Speaker 4: because of the type of role that I perform at
Speaker 4: the company. Yeah, and if somebody something is sent on
Speaker 4: some channel and I didn't catch it when it was sent,
Speaker 4: there's a good chance that I will never catch it.
Speaker 5: Hmm. Yeah. I've had to get very I've had to
Speaker 5: become a very skilled Slack sleuth. I don't know the
Speaker 5: right the right words, but I'm I'm I'm very good
Speaker 5: at navigating the mess of Slack channel now and staying
Speaker 5: on top of what I need to be on top of, because, yeah,
Speaker 5: as a company grows, there's just lots of information happening
Speaker 5: in real time in slack.
Speaker 4: Yep, all right, right right for machine learning. Yes, here's
Speaker 4: the summary of all the things. Here's the summary of
Speaker 4: all the things I should know that happened in Slack
Speaker 4: since the last time I checked.
Speaker 5: Totally.
Speaker 1: Yeah, all right, let's have Dan starts with picks, Dan,
Speaker 1: what are your picks?
Speaker 4: I don't have that much, you know what, I'll mention
Speaker 4: just the one thing. So I think I picked this
Speaker 4: one before a while back. It's a podcast called Revolutions
Speaker 4: by Mike Duncan, the same guy that did the History
Speaker 4: of Rome podcast. I'm very much a history buff, and
Speaker 4: Revolutions is like him going through big revolutions in history,
Speaker 4: starting from the English Revolution, the less well known English
Speaker 4: Revolution with Oliver Cromwell, and then going to the French Revolution,
Speaker 4: the American or the American Revolution, the French Revolution, the
Speaker 4: Mexican Revolution, the Russian Revolution, et cetera. And it's highly
Speaker 4: recommended and very interesting. But he's now doing something that's
Speaker 4: kind of out there. I mean after the Russian Revolution,
Speaker 4: he got to the point where if he kept on
Speaker 4: talking about even more modern revolutions, it would stop being
Speaker 4: so much about history and being more about politics, I guess.
Speaker 4: So instead, what he did he kind of invented his
Speaker 4: own revolution. He's talking about a revolution on Mars in
Speaker 4: the twenty fourth century or twenty third or twenty fourth
Speaker 4: century or something like that. So it's really interesting how
Speaker 4: he's inventing a revolution to talk about, and it's kind
Speaker 4: of like a science fiction story in a way. But
Speaker 4: it's very engaging and I highly recommend it. So that
Speaker 4: would be if you've not listened to any of that podcasts,
Speaker 4: I would recommend to go back from the start. It's
Speaker 4: got hundreds of episodes. It's of course not the same
Speaker 4: type of podcast as ours. It's not in discussion, it's
Speaker 4: not an interview. It's all scripted. He basically reads out
Speaker 4: the script that he wrote, but he does a ton
Speaker 4: of research. It's highly engaging, very amusing, very informative. Again,
Speaker 4: highly recommended, and the new stuff is recommended as well,
Speaker 4: And that would be my pick.
Speaker 2: Awesome, Steve, what are your picks?
Speaker 3: All?
Speaker 5: Right?
Speaker 3: So before I get into the high point of every
Speaker 3: episode of The Dad Jokes of the Week. I'm going
Speaker 3: to do a shameless plug here in terms of a
Speaker 3: email I got through LinkedIn from somebody who's a listener,
Speaker 3: and I won't share his name to protect him from
Speaker 3: the abuse he would receive somebody who likes my dad jokes.
Speaker 3: But uh, he did say that, Hey, I'm a longtime
Speaker 3: listener of JS jabber and enjoy it very much, particularly
Speaker 3: your dad jokes. I have retold a few of them
Speaker 3: and got mostly eye rolling but a few guffaws. So like, okay,
Speaker 3: that's good, making some good progress there. So now to
Speaker 3: the reasons for that email the Dad Jokes of the Week.
Speaker 3: So recently I changed the voice you know on my
Speaker 3: my car GPS you can use the different accents and stuff,
Speaker 3: you know. I changed it to nail. So now it
Speaker 3: just says it's around here somewhere, keep driving. Oh my
Speaker 3: dad joke isn't drum roll is not working, bumming me
Speaker 3: out here?
Speaker 5: Okay.
Speaker 2: So, uh, I was.
Speaker 3: Ordering a pizza the other day and they asked me
Speaker 3: if I wanted to cut it into four or eight slices.
Speaker 3: I said four, There's no way I could eat eighth.
Speaker 5: There we go.
Speaker 4: You kind of reminded me of the fact that I
Speaker 4: say that I don't care but the price of gas
Speaker 4: because I always pay fifty dollars.
Speaker 5: Gotcha.
Speaker 3: Sorry, let me give you that oh damn drum that's
Speaker 3: not working in. Sorry, tried to give you a drum joke.
Speaker 3: There I go, little delayed. Sorry, we're back to Riverside again.
Speaker 3: The uys that there's a little delay there. It's messing
Speaker 3: me up. So I gotta get back on the train again.
Speaker 4: You need to to play the drum role before you
Speaker 4: tell the joke.
Speaker 5: And yeah, but.
Speaker 3: Yeah, there's enough of a lag there.
Speaker 5: I gotta do it.
Speaker 3: So two more so, my favorite suit, I come up
Speaker 3: with a new superhero and you know, Chuck's Marble shirt
Speaker 3: that he's wearing today sort of inspired me this. I
Speaker 3: don't know if he's part of the Marvel universe or
Speaker 3: maybe another one, but it's Typo Man because he rights
Speaker 3: all the wrongs that's writ right. And then finally I
Speaker 3: told my wife I wanted to be cremated. She made
Speaker 3: an appointment for Tuesday.
Speaker 4: Well, there was the Monty Python Meaning of Life movie
Speaker 4: where they they you know, they knock on his door
Speaker 4: and say you you've signed to be an organ donor.
Speaker 4: We've come to collect.
Speaker 3: Right, always look on the bride.
Speaker 4: That's a different one though.
Speaker 1: All right, I'm going to go in with my picks.
Speaker 1: I usually do a board game pick. I haven't played
Speaker 1: anything new lately. I'm gonna pick one that I haven't
Speaker 1: picked in a while. So my wife and I went
Speaker 1: down to Saint George, Utah for the Parade of Homes.
Speaker 1: We do this every year on the last weekend in February, basically,
Speaker 1: and uh, my sister in law and her husband come
Speaker 1: and they always bring the same game, and we really
Speaker 1: enjoy playing. It's called The Quacks of Quedlinberg, and what
Speaker 1: you're doing is you're basically brewing a potion and if
Speaker 1: you get too many of the wrong element, the white
Speaker 1: elements in it, it'll blow up. And so you're trying
Speaker 1: to get a big as big a potion as you can,
Speaker 1: often with as many elements as possible unique elements, without
Speaker 1: blowing up your pot. And then you get bonuses for
Speaker 1: playing it. I think we were playing with some of
Speaker 1: the extensions, but the base game is actually pretty good.
Speaker 1: Let me see, I didn't look it up on board
Speaker 1: game Geeks, so let me grab that real quick, and
Speaker 1: I can tell you what the It's got a board
Speaker 1: game weight of one point ninety four. So if you like,
Speaker 1: if you like a game that'll make you think, but
Speaker 1: it's not like super complicated. That's about where this clock's in.
Speaker 1: I think we played it in an hour anyway, fun game,
Speaker 1: so I'm gonna pick that. I'm also going to and
Speaker 1: I'm just that guy sometimes. So we are on Riverside.
Speaker 1: It's been mentioned a few times we were on stream Yard.
Speaker 1: I was having some issues with stream Yard, working things
Speaker 1: out to get the payments to work with them and
Speaker 1: things like that, and eventually they downgraded the account and
Speaker 1: deleted some of the episodes.
Speaker 2: That we hadn't released yet.
Speaker 1: Oh wow, And so yeah, caveat emptor if you're going
Speaker 1: to go use stream Yard.
Speaker 2: They have a great tool, but they might just stab
Speaker 2: you in the kidney. So anyway, do.
Speaker 4: You think content is a big no? No?
Speaker 2: I mean yeah, And I tried to work with them.
Speaker 1: I tried to figure out how to get it, and
Speaker 1: they just came back and said we deleted it. So anyway, yeah,
Speaker 1: So if you're gonna do this kind of a thing,
Speaker 1: just be aware. We've never had that issue with Riverside.
Speaker 1: I did go through a bit of a process just
Speaker 1: talking to Riverside, and it was the process was them
Speaker 1: showing me all the things it does now, and it
Speaker 1: does like all of the things that I had wished
Speaker 1: it had done before.
Speaker 2: It basically does now.
Speaker 1: You can actually edit your episodes in Riverside and it
Speaker 1: uses AI to clean up a bunch of stuff, automatically
Speaker 1: generates your transcripts, it'll write you show notes. You know,
Speaker 1: all all the things that I've either been paying for
Speaker 1: other systems to do or wishing that I had a
Speaker 1: system to do. It does all those things. So I'm
Speaker 1: going to pick Riverside. Riverside is not cheap either, but.
Speaker 4: You know, anyway, anything's better than some getting your episodes deleted.
Speaker 2: Yeah. So yeah, we lost a couple.
Speaker 1: I think we lost more on Ruby rogues and we
Speaker 1: did on JavaScript ever, but we may have to reach
Speaker 1: out a couple of people and say, hey, they deleted it,
Speaker 1: We're going to record it. But yeah, I'm delighted to
Speaker 1: be on Riverside. And apparently it's an Israeli company, which
Speaker 1: is also cool. I don't I don't know that I
Speaker 1: care a ton where the where any company I use
Speaker 1: is based unless but I'm.
Speaker 4: Kind of curious because it was streamed live, so it's
Speaker 4: it's on YouTube, it's on on Oh.
Speaker 2: Yes, we could get them that way. That's a good.
Speaker 1: That's a good. Here we go, troubleshooting live on JavaScript chever. Yeah,
Speaker 1: we should be able to pull them off of YouTube
Speaker 1: because they're on they're on the channel for the network,
Speaker 1: and so we can download them off of there.
Speaker 2: You just saved us a little work, thanks Dan.
Speaker 4: Besides that, I still remember that episode that we that
Speaker 4: we did with pressing the record button.
Speaker 2: That once or twice. I've done that before. Yeah, that
Speaker 2: that's a mistake.
Speaker 1: You only make a couple of times, and then you're
Speaker 1: very first podcast.
Speaker 3: Let's throw out the very first podcast episode I ever did.
Speaker 3: I did that and had to re record it. The
Speaker 3: guy is gracious enough to re record it with me. Yeah,
Speaker 3: never forget that.
Speaker 4: By the way, you know, as an interesting pick, we
Speaker 4: now use for some reason Google Meet at work instead
Speaker 4: of Zoom, which is not necessarily what I would have chosen.
Speaker 4: But they have a good feature, which is you can
Speaker 4: pre configure the session to be recorded because you never
Speaker 4: remember to press record in real time, so it's it's
Speaker 4: one thing that I do now when it when it's
Speaker 4: sessions that I schedule that I know need to be recorded.
Speaker 2: Yep, I think Lee needs to run. Do you have
Speaker 2: anything you want to throw out real quick?
Speaker 5: I'll give a shout out to Z my code editor,
Speaker 5: and mentioned it a little bit in the podcast. But
Speaker 5: it's been enjoy to use and they're shipping tons of
Speaker 5: good improvements. So big fan.
Speaker 1: All right, good deal. Well thanks again for coming. So
Speaker 1: much interesting stuff going on. You're right in the middle
Speaker 1: of it.
Speaker 2: All right. We'll wrap it up here, folks. Until next time.
Speaker 2: Max out