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