Qwik 1.0 === Paul: ~Test, test, test.~ Steve: ~Test, test, test.~ Paul: ~All right.~[00:00:00] Hi there and welcome to Pod Rocket, a podcast brought to you by Log Rocket. Log Rocket helps software teams improve user experience with session replay, ever tracking and product analytics. Try for free@logrocket.com today. My name is Paul and joined with us is the C e O of builder.io. Steve Sewell. Welcome to the podcast, Steve. We're gonna be talking about quick 1.0 and a little bit of course of some AI mix-ins about what's going on, about how we can accelerate our lives and our workflows. Steve: thanks for having me. I'm excited. Paul: Could you talk ~about a little~ about ~yourself and~ how you stepped into the role of being c e O and the co-founder of Builder io? Steve: ~Totally. Yeah.~ Yeah. I'll try and keep it,~ uh,~ brief. I could probably talk forever about this, but, ~um,~ the high level of it was, so at the last couple I worked at, ~um,~ a company called CHOP Style. They are an e-commerce business. They do ~like~ half a billion dollars in gmv, so they're driving a lot of, ~um,~ Purchases of e-commerce products across different retailers. They like, they do a crawl operation and then you can chop a bunch of, ~uh,~ [00:01:00] different stores in one place. And, ~um, you know,~ way back in the day they were on this really monolithic, kinda legacy Java stack. We modernized them and brought them what people now call headless, quote unquote, like headless commerce, ~you know,~ back end, except from the front end to the front end can be like a pwa, ~uh,~ so it can feel totally native and never reload the page when you're on mobile. ~Stuff like that.~ And we learned a lot in kind of changing the tech stack. ~Um,~ two huge things. ~Uh,~ first one was we moved to angular js and performance for angular js for the first page load was brutally slow. And certain businesses like e-commerce need a really fast page load. ~Uh,~ for that initial page. It makes a big difference on how many people will actually purchase things. And it was something that we didn't really properly account for the importance of, we wanted every transition and page navigation after that to be fast, to feel like a native app on mobile. But that first one was very hard to do in this kind of modern JavaScript tevy setup. The second thing we learned was for an e-commerce business, ~uh,~ generally speaking, those are marketing driven businesses and a marketing [00:02:00] team needs to run. Tests and change content all the time, every week. ~The marketing team had new things that had to be on the homepage, uh, different buttons, different layouts, different combinations, landing pages, all this stuff. And we found that with the sore kind of more modern stack, we had a lot of benefits to developer productivity.~ ~Uh,~ the decoupling, our front end backend was really great for team structure and our ability to ship quickly and a lot of really good stuff on the engineering side, but there was not really a good solution for. ~Um,~ managing all the content of the front end. Specifically. We had cases where, ~um, you know, well we started by hooking builder, or~ we started hooking shop style up to a headless c m s. And then we said, Hey, marketing team, ~you know,~ you can edit like the title of this page. And they're like, great. Now I wanna rearrange the page. I wanna add a second button. It should have a new link. And they would go into all these details on new things. We're like, wait, wait, wait, wait. No. Headless. C m s means we tell you what you can change and anything else you still need engineering tickets for. ~Um,~ that got crazy and tedious because we needed a lot of tickets. We needed to change things all the time. And it eventually got crazy to the point where our backlogs were so long that the marketing team went and they were trying to figure out how can we make it, ~um,~ So that they can get a page update they've been asking for forever on the site without having to depend on the engineers. And so what they did is they went to Webflow, like a drag and drop, no code thing. They built out this page [00:03:00] they've been asking for forever, totally on their own. Doesn't take any engineering, just drag, drop done. ~Um,~ Webflow is pretty great in that it actually generates pretty high quality code. And so just H M L C S S pretty much just like a developer would've written. And they brought that to us and said, Hey, we made this new page. Can you please just ~kind of~ copy paste it onto this Angular site? And I love the intent behind it, but the unfortunate part was these tools don't really connect to whatever tech stack you have. We have an angular JS site, not just generic H M L C S S, which is a difference. ~Um,~ we have a custom backend, we have components we've already written that should be used for this, these angular components ~that~ that should be part of this, ~uh,~ ui. And eventually we really. We're like wrestling with what they need. Is that. Drag and drop that you can get for these kind of SMB oriented tools. But what the engineering needs is actual angular code with angular components. And that kind of led to the idea of ~like, well,~ what if, like what if you could have a drag and drop gooey? Cuz these things have gotten a lot better recently. They have gotten. ~You know,~ very clean in terms of the code they can produce and generate.[00:04:00] What if you could just deliver that over an API ~and,~ and connect to any tech stack? ~Um,~ that kinda led to the idea of ~like,~ wow, that would've removed all this horrible backlog that our developers don't wanna do because ~it's like, move this button. It's like, change this color. It's just boring,~ tedious stuff. ~They want to work on fun stuff, which was pretty much never that. Um, And it would allow the marketing team to just run their tests on their own, make the new page, run the test, ab test, like, who cares? Just do it yourself.~ And so that's where I, ~uh,~ quit my job and, ~uh,~ built out the first version of Builder, which was like, okay. How do you design like an API interface for ~like~ react components or angular components? So you can deliver Jason over the wire, ~um,~ provide a drag and drop interface in the visual editor and allow people to take those Lego blocks you have which components are supposed to be these drag and drop pieces and combine them in all kinds of new ways and just hit publish and make it go live. And that's how we ~kind of~ got into builder and that led to a whole lot of really awesome stuff. But ~it,~ it remains that there was one last challenge we were running into, which is, ~We,~ we see that by default, people tend to see a drag and drop interface and they go, oh, ~you know,~ I've seen Microsoft Front page, or I've seen Dream Weaver. I've seen how these can generate really messed up code that's really bad for performance and all this stuff, and. Oh yeah, so we went crazy on making sure that what [00:05:00] we outputted was extremely high performance. All of the images, we do crazy stuff. So like when you make something in builder, we actually will load up that page in puppeteer and we will look at the exact dimensions of all the images used. At all screen sizes and we'll find the exact compressed image, ~uh,~ formats that you need. We'll find the exact image sizes and add a whole bunch of HTML attributes so the browser will load exactly the right size and format for exactly the type of browser and screen dimensions you're using. All kinds of stuff that even with modern image components, developers don't usually do because, ~uh,~ it's actually very manual. You have to ~kind of~ know information that you don't know at the time of coding. ~Um,~ and all sorts of crazy stuff. How we deliver the content from the edge and blah, blah, blah. So we start telling people, Hey, this is super duper high performance. This is the best way. And it's often on average, can generate a higher performance output than your average developer would code up. Cuz there's all this nuances that we don't have time to do day-to-day as developers that we can automate with this type of system. But, What people would do is they'd plug Builder into their mega Giant React app that's made with ~like~ Create React [00:06:00] app, and it would probably already score like a five out of a hundred on Google's page, bin Insights or Lighthouse. And they'd plug Builder in and it would go from ~like~ five to six. And they're like, ~well,~ the whole page I made in Builder, why is it not fast? And so I'd look at it and be like, ~well this,~ this is a massive site. Just by adding some stuff from builder and removing a few divs does not remove the gigantic amount of other issues you already have, which are. They don't take up screen real estate on the page, but they're way more impactful than just the things that you see. It's this massive amount of third party scripts. It's a massive amount of third, ~uh,~ first party code. It was just all this. ~Kind of, you know,~ for ~lack of~ lack of a better term, junk that's not needed is right there in the browser and we can't do anything about, ~uh,~ without completely suggesting to change your whole stack eventually. This actually became such a important thing for us to try and figure out how to solve on behalf of our customers because they would adopt us with performance so heavily in mind that we were trying to be like, okay, ~well~ let's start with creating one website. Let's make our website fast. And so I was doing all these tests of making our website as fast as humanly possible. It was, ~um,~ using [00:07:00] Reacts, ~uh,~ and a modern React framework over the top of it. So server side rendering, static generation, all that. ~Um,~ and I was, I. Playing with it like crazy. And I was getting into about 60 out of a hundred for mobile, which is way better than average, but it's still yellow, ~you know,~ for Lighthouse it's not green. We wanted green and I was going crazy and I was going deeper on image optimization and font optimization, all this weird nuanced stuff. ~And eventually I was just, I was giving up cuz I was doing anything to get like one more point. A 61 out of a hundred would've made me happy at this point and I was not even getting it.~ And so I decided to do what I just call hack and slashing, which is, ~Um, you know,~ and I'm really desperate and I need to fix something. I don't know how I just start deleting huge swaths of code. I just go crazy deleting and it's almost like ~a,~ a get bisect, let me delete things until I find the specific thing that once I delete that the score goes up. And I tried everything and it was all like death by a thousand cuts. ~It's like~ if I deleted 30%, we got 30% faster. If I deleted 50%, we got 50% faster. But nothing was different than anything else. Until I went super hacky and I just deleted all the scripts, tags, even the React script and ~the~ the framework script. So basically deliver the page with no JavaScript. And at this point I would've been happy with two points, but the score shot to a hundred, like [00:08:00] as soon as the JavaScript was just gone, it made sense. You're just delivering, I. Optimal H T M L C S S and images over the wire and there's nothing else to download and parse and execute before that page is quote unquote downloading. And that's where it was a bit of ~like,~ huh. And I would add the scripts back and I would see how Lighthouse would punish us to,~ like, it's,~ it's downloading so much, it's executing so much. It's parsing so much. There's a lot happening. And take it off again and it's gone again. And I was like, wow, I, maybe I should have known this, like maybe we were right with P H P the whole time and we should have never done this whole modern front end stuff. But I couldn't live with that either because components are so elegant ~and,~ and not worrying about these server client boundaries like you used to. And using jQuery, which is very difficult for complex things like our drag and drop editor. I couldn't live with that. So we started experimenting with, ~well,~ can we do some kind of custom compilation output where we generate pure H D M L and just tiny fragments of js? Like why are we re downloading the whole page in a JavaScript format and re-cutting it all and binding. Doing all these things for builder pages are often pretty static. ~You know,~ our homepage is a homepage. [00:09:00] Yeah. Images and texts and buttons. It didn't need to have a lot of JavaScript on it for what? The purpose it served. And while I was doing that and I was having trouble finding exactly the right way to do it, that we think could scale well and fit a variety of use cases, ~uh,~ I ran into, ~uh,~ Mishko, who was, ~uh,~ still on the Angular team looking to, ~uh,~ move on and find his next thing to do. And he's like, Hey, I have this new framework where I found a way to write components, just like you always do. But when they load in the browser, zero JavaScript needs to load at all actually. Less than a kilobyte, this boot loader, which we could talk about, and then you can make, applications are huge and complex, but they never have this hydration problem. You just. Deliver HTML to the browser. At the time, I learned later that he was actually having trouble getting people to realize why this mattered. People didn't seem to care that much, and because I had done all this exhaustive testing, I was like, oh my goodness, that is exactly what we, and ~like~ everybody needs. And the way he had solved it, and with his experience, he made Anglo js and angular. ~He,~ he's experienced ~the, the,~ the problems and the ways to approach these [00:10:00] things and try so many things. That's where we're like, okay. We need to develop out this framework so that we can use it and we can recommend it to those who have this problem. When paired with Builder, suddenly Builder plus Quick was just a hundred out of a hundred. Any site, any complexity, everything was insanely fast. Perfect. And, ~um,~ we realize it's a good way for people to learn about the fact that we exist ~in,~ in our platform too. ~So that may have been more than you bargained for, but that's, I think, a whole big old backstory of why builder and, and quick exist right now.~ Paul: So when you embarked on the journey of. Wanting to make an a p I interface for, let's say a React component right on builder. Was that sort of your first foray into the depths of, ~you know,~ the React library ~and, and,~ and how those dumb fundamentals are tied together? Steve: ~Yes.~ So yes and no.~ Um,~ no in the sense that ~like, You know,~ back before I started using angular js I was actually making my own framework that was,~ uh,~ a layer on top of backbone trying to add like kind of reactive systems on top of backbone cuz we were using backbone for prior projects. Not really good at the view layer. ~And um,~ so it was getting really gnarly on that. And I actually used, ~uh,~ RIV for a little while, ~which is, um, Uh, rich Harris's prior framework before Speltz,~ and there's some similarities [00:11:00] and I liked it, but there's some parts he didn't like. So I made my own template system and~ blah, blah, blah, and kind of~ went crazy on it. Eventually realized that I was actually just ~kind of~ rebuilding or, or reinventing angular js just in a worse way. So we started adopting Angular, and funny enough, when I started doing these experiments for pure HDML output from what we've created for the things in builder, and then using minimal js, I was. Very poorly creating some type of thing like quick, just a lot worse than Mishko had with quick in a lot of ways. And so it definitely hadn't messed with some of ~this,~ this wacky, gnarly stuff before. But the big difference for me ~that~ that kept ~kind of.~ Breaking my brain a lot was that idea of how we ship it over an api. Like what does that even look like? Are we shipping JavaScript code that looks like reactor create elements? Are we shipping, ~um,~ un compiled code like jsx? What would that look like? ~Um,~ are we shipping Jason? ~And, and if so, what does the Jasons look like? ~And that took a lot of trial and error to actually realize that Jason is definitely the way to go. Like the way that it works Paul: ~Why are you so sure?~ Steve: ~Cause I tried everything and I could tell you, I mean, if you have more time, I could tell you all the trade outs of all the approaches, but I could give you the, the quick summary. So, At the end of the day, the way people wanna do this is they want to just integrate.~ ~Um, you know, any headless c m s like builder, they want integrate into what they already have. So they have a site, it's got its pages, it's got it structure, and they just wanna start pulling in pieces of content from A C M S. Uh, in our case, it's very common to integrate builder first to just a part of a page.~ ~Or use it to generate like net new pages, like build out new landing pages, but write in your stack. Like if you use njs, just add a.dot.page, dot jsx. Um, add your header, footer and a region for where you want builder to deliver, um, contents. And so there's a, an API call you make that gives you Jason, and you pass that through the props to a component that can render that adjacent dynamically.~ ~Um, The reason people want it this way is one, incremental adoption is important. We're not telling you you should build your whole site with drag and drop. It's really the opposite. You should build your site the way you build it. And when you have marketers that need to constantly edit some of these areas and, and, uh, a structured data approach is to, um, Problematic in terms of code needing to be updated, just to move buttons and stuff.~ ~That's when you want to kind of move over to a, a more visual, uh, editor of, uh, uh, a way to give you this kind of drag and drop component composition. And, but what you want is you want to use your components. And so if we send over the wire, Jason, and the Jason is just a tree, and it just kind of says, put your hero here with these props.~ ~Put, you know, an image here with these props and you know your product here with these props. Then we can have our own component that just iterates over, that looks up your hero, puts it there, and this and that. And it's really simple and elegant. If we send other formats over the wire, um, There can be issues with compatibility, like, uh, previous React versions versus newer React versions use a different, uh, like newer React.~ ~You can, uh, no longer use, sorry. You can use either format, but a lot of people don't use React dot Create Element anymore. They use the, I forget what it's called, but there's a new way they can generate the, the JSX functions. Um, you have to deal with how do you bind the references? Like what if a component is referenced but somehow not in your code in Jason at Runtime, we can just say like, oh, skip this one, and we could print a warning and say like, You're missing components, but if it was pre-generated code, it would just throw an error.~ ~It'd be like a missing reference. It would be a bad idea. And. The most important part is you always have to have a, what you see is what you get. So in our visual editor, we're always dynamically rendering out, um, what you're kind of building with the drag and drop. And it's absolutely critical that what you see there is exactly what goes to your website.~ ~And if you have like a co-generation process in between, like we experimented with, um, there's a high risk that the cogen is not a hundred percent identical in. Every single way in behavior as the kind of runtime generates stuff. And that creates big problems when you hit publish and suddenly things in production are different.~ ~So I'll pause there. There are a lot of other learnings, but I, I hope that covers the gist.~ Paul: Totally. So would you recommend J s o N as [00:12:00] a universal go-to if you're trying to ~like~ serialize a concept and send it over the wire? ~I,~ I feel like I've, it's always served me pretty well. It sounds like ~if,~ if you can stir, do a react component, that's like the pinnacle in my head. ~Yeah.~ Curious on your thoughts. Steve: Yes. So this is a fantastic question. So 100% yes. ~Um,~ with some like nuances worth noting. So yeah, I think the serialization format that's best for this is Jason. ~Um,~ now what that requires though is you need a way to create and edit that Jason. And doing it as Jason text is a huge pain. And so you don't wanna write Jason from scratch. That represents like dynamic components. Now it's worth noting too, though that I was talking to some engineers at Meta recently. And within the react org there actually is this whole project called Blocks, I think it's called. And they also do the same thing and it solves a different problem. ~Um,~ the problem it solves for them and they actually hand write this code, and I'll explain how that works. In a project we have works similar. So they have a problem, which is their native apps that use React native. ~Um,~ Unlike the [00:13:00] web, they don't just magically update to the latest versions. They can push a new version of the React app that has, ~um, you know, ~Instagram may wanna add a new promotion for something for influencers. And normally you'd have to~ like~ submit the code to Apple and then Apple reviews it. And then some people will update it immediately, but not everybody. And so it's really annoying and customers of Builder have the same problem too. And they're like, ~well,~ how do we get new things, new components on the device? Without code being able to be updated. And yes, there are some arguably hacky solutions, at least at times for like hot deploy and hot hopping code. That is not something that Meta is using. I didn't ask why. I'm sure there's a variety of reasons. So it's not something a lot of our customers are using. So instead they have this thing called blocks where they can write in Python or php if I recall. ~Um,~ essentially what looks like J S X but turns into Jason and delivers to the vices Jason, and in the same way as builder, a component. ~Um,~ can read the Jason and dynamically render what they want. So this engineer was showing me this new promotion they added to the Instagram app and [00:14:00] they were like, this code doesn't exist in the phone. This was written in Python because, ~uh,~ Instagram's backend is Python, if I remember him correctly. And it's actually sent over and rendered dynamically, which is really cool. ~Uh,~ they have a ~format,~ format and we realized we needed one too. So we made a project called Mitosis where. The idea was very similar to what Meta realized. It's funny that we developed these things in parallel, ~um,~ without ha knowing, having any knowledge of each other, doing these things, and ~kind of~ learned about it and had some conversations with their engineers later. But basically we were like, okay, what if we made a J S X equivalent of this Jasons, because the Jasons does look a lot like the v om format of React, which really is what the J S X does. It's like it has a tag. Things have properties, things have children, ~blah, blah, blah.~ And so we made this thing called Mitsis where we can, ~um,~ Two way compile. We can turn the Jason to Jsx and J S X to Jason. So it looks like you're writing React component. It compiles to Jason. It really has the same React format except a couple additional constraints. There's some things that Jason can't represent that you can do and react like really~ kind of~ dynamic stuff.~ Um,~ And what was cool about that is we realized [00:15:00] that because we don't just support React like the builder, Jason can render, ~uh,~ identically to view and quick andel and solid js,~ and,~ and actually no framework. It could just produce HTML for, ~you know,~ your rails website, your LAAL website or whatever. ~Um,~ We were like, wait a second, we could use this to actually, ~you know,~ write to Jason's, J S X and then output components to all these things. And now Mitosis is its own project built on the same kind of tech, which allows people to, if you have a use case like us, ~like~ let's say you are a library offer, ~like~ let's say Log Rocket needs to provide UI components, but your customers use React and View and all these things, ~well,~ you could actually use Mitosis to write. Essentially react components, but compile them out to view components, et cetera.~ So you can MP install, you know, log rocket SDK view, and that was actually totally generated off of a React component or what looks like a React component without having to write. Components 10 times. That's how all of our SDKs work.~ Everything you install in builder is actually generated code from DYS Mitosis, which is from the Jasons, which is also the same thing you get over our APIs. I know it's a little bit weird and abstract and multi-layered ~and~ and trippy, but yeah, it's actually ~kind of~ fascinating. ~The properties you get when you can turn Jason to react and, and back.~ Paul: So when you're able to turn json into React, does this have anything to do with the way that Quick [00:16:00] operates~ and the way that Quick She'll laughing? Uh, ~I'd love to get into that. And, but before we do,~ uh, just~ I wanna remind our listeners that this podcast is brought to you by Log Rocket. Log. Rocket offers session replay. Issue tracking and product analytics for your full stack to help you quickly surface and solve impactful issues affecting your user experience. With Log Rocket, you can find and solve issues faster and improve conversion and adoption so you can spend more time building a better product and less time debugging. So head over to log rocket.com to try it for free today. ~So Steve, yeah, we're talking. I like this topic we're on here about JSON and. Universal data, serialization of objects, whether they be this or that. And I mean, we got a little, a little deep into that subject cuz ultimately our goal here is to talk about quick 1.0 and we're talking about the benefits it provides.~ We did have Mishko on the Log Rocket podcast. He was on Pod Rocket twice actually. And we've gone over a little bit about the point of quick, ~um,~ if you could really. ~I, ~I, I didn't mean to double say it here, but if you could really quickly summarize for us what is quick for people tuning in for the first time, and then why d Why is j s o N in in the conversation here streaming dynamically loading data?[00:17:00] Steve: Yes. Now these are all great questions. So let's start with quick. The goal of quick is to deliver, ~uh,~ instantly on applications. So as opposed to the. Current model today that we use, which we call hydration, which is you, ~uh,~ render an application or a page on the server, you then transfer that to the browser via hdml. But the HDML is actually just ~kind of a,~ a facade. It doesn't actually work. It doesn't do anything. It just gives you something to look at while your actual application downloads reruns and then binds to the html. Now it's actually usable html. So that's hydration. And that's where we've noticed, ~uh,~ particularly for, ~uh,~ people who initial page load matters a lot. ~And those are people like e-commerce marketing sites. Um, there's a lot of verticals that can also be travel and FinTech and SaaS.~ Basically, everybody wants a fast loading site. Everybody's customers want a fast loading site. I hate using slow websites on my phone, ~especially when, I mean,~ funny enough, I live in San Francisco. I live in a part of San Francisco that has. Terrible signal. I get like barely 3g, and most websites just don't even work at home. So if my wifi [00:18:00] isn't working or I step outside to walk my dog, which I do multiple times a day, most of the internet just doesn't work. And we often forget ~that~ that's the case for most of the worlds. I don't care if you're in San Francisco or if you are in Columbia or you are in Eastern Europe. ~Um,~ You may or may not have a fast connection all the time. You may be on a bus or on a subway or stuff like that, and every single time that, let's take e-commerce for an example. Every single time that a page takes more ~an~ an additional, I can't remember, it's like a hundred milliseconds to load. If I recall correctly, it was Amazon found that they were losing like 1% in profits. Forgive me for not remembering the exact stat. Here. We actually have it on our sites. There's so many people have done these stats, but basically you're losing major amount of money when you make these pages take too long to load. And the faster they load, the more your bounce goes down, the more your conversions go up. Which means just money goes up. So slow sight, less money, fast sight, more money, right? And that's quite important to businesses. And so with quick, the idea is, ~well,~ how do we skip that hydration step? And the [00:19:00] idea here, which was borrowed from a framework internally used at Google called Wiz, ~um,~ which powers Google search, ~uh,~ Gmail. I think Google Photos, I, I forget the exact list, but they ~kind of~ developed this technique that's really cool, which is you send HTML to the browser and in the html any. Dom events, any like points of interactivity actually have a serialized URL in the H T M L. So imagine you have a button and the button will have a property, I think it's ~like~ called ~like~ JS colon action, or I think they ~kind of~ mangle this to, to minify it. But the value of the attribute, so say it's called like Js action equals, and it'll be a path to a url. It'll be like to probably some funky hash js. And that Js never needs to actually fetch or run unless you actually click on that button. And so what they do is they actually have a bootloader or a loader on the page that the first thing it does is it looks, ~you know,~ in your Google search results. And it finds all those attributes. You could do one quick query selector all and find all the possible URLs [00:20:00] that may need to execute on this page. What they'll then do is they'll fetch those so they're in the cash, they're still not executing, which is the majority of the problem that we're trying to avoid is executing this js. And what they can do is as soon as you click, they can then execute that one file. What that means is, instead of. When you load, let's take, ~I mean,~ Google search, if Google search slowed down by a hundred milliseconds, I think they would lose billions of dollars or something like that. So these things are important at that scale, but they're important at any scale. It's just easier to quantify at really large scale when you're talking insane amounts of traffic and money. ~Um,~ But basically they discovered that this works extremely well to make your website just as fast as if it was pure html, but instantly interactive. And that's the point of quick. But the idea of quick is to do it in an open way. So fully open source. And second, with a modern developer experience. Wiz today, from what I understand, is not, ~you know,~ simple and easy to use. Like React and jsx uses a very different, a little bit more legacy format. The idea is, ~well,~ what if it you felt like you were writing React? But it actually loaded just absurdly fast, [00:21:00] both at the page load point and at the point of interactivity. And so quick wants you to have these instant on applications at any scale, ~uh,~ so that even if you're at the scale of Amazon, it doesn't matter, or the scale of Google, it doesn't matter like you may have. Notice that when you go to Google search results, they have ~uh, uh,~ a seemingly infinite number of interactive widgets. You search movies, there's a movies widget. You search something about a location, there's a map and there's business stuff. There's a million different widgets that could load on these pages because of this format. Doesn't matter. They could have infinite engineers making infinite widgets if it's not delivered on that page. It's not running, if it's not interacted with, it's not executed or even parsed. And that's how you achieve, ~uh,~ what we're looking for, which is essentially. Oh one scalability. So regardless of the complex of your site, the page loads just as fast. The amount of JavaScript that loads on that page, ~uh,~ and executes the minute it loads is literally just less than a kilobyte. It's just that loader. And as you interact, you're only loading tiny little pieces. ~And,~ and that's the idea of quick, ~um,~ where the Jason comes in is in a [00:22:00] couple areas. So number one builder supported a quick SDK out of the gates because. Of this Jason format we use in mitosis. It was as easy as just generating a quick sdk. ~We wrote a simple, um,~ in mitosis you write a, ~uh,~ a simple generator. These are often just one file and you write the generator once. And now anything we've ever written in builder supports quick. Awesome. So that took a minute. That was great. But the second thing that's interesting here is when you skip hydration, ~um,~ You could actually go deeper into creating extremely high speed and dynamic experiences. So a lot of things that we find start to get complicated and not performance for react at scale is things like delivering, ~um,~ personalized results and components or running ab tests. Traditionally, you're actually gonna have to deliver these in a way that's very hard to do, performantly. It could be simple when it's in a very simple use case. ~Like say you just have. You know,~ you use something like Versace or Netlify and you have two different branches and do you're ab testing a whole separate version of the site, one against the other. That's easy. But when it comes to, ~uh, I'll keep using e-commerce examples because that's, that's the majority of my background.~ E-commerce, that just doesn't work. ~Um, equity work is, somethings make a huge site change, but~ [00:23:00] generally speaking, the type of ab test you're running day to today is these two images against these two images or these two page layouts, ~uh,~ against these two, or let's also run, ~uh,~ personalized results. ~So, Uh,~ at shop style, it's very important that if you previously shopped men's wear products, when you get to the homepage, ~you see~ men's wear products, ~you see~ promotions for men's wear products, examples of menswear products, ~uh,~ because you're not buying women's wear so you shouldn't see it. It's a waste of money. It's a waste of screen real estate. ~Same with for women's wear, you should see women's wear if we don't know. You know, you don't know. Um,~ there's a lot of fancy tricks we can do to di deliver these dynamic bits from the edge, et cetera. ~Um,~ and Jason's what describes that. But when you can turn those things to pure H D M L, you can actually now run an infinite amount of personalized variations or AB tests without any. Cost. And if you didn't use Jason for this, you'd actually have to have developers, hard coding, all these variations, and nobody has time to write a hundred different versions of the same components, react quick or otherwise. But what we do have time to do is use a gooey, you go into builder and you hit duplicate and you now make the men's version hit publish and you hit duplicate and a few clicks. You've just made a thousand versions of a component. And that's easy delivered over to api. It ~kind of~ solves this problem where. [00:24:00] Developers just wanna write clean code that looks and feels like today's react, but delivers insanely fast, like quick does. And you want your other team members who need to make changes to all the stuff to just change it. You don't have to worry about it. Drag drop, change it. You put the rules in place, like you're only allowed to use the design system components or whatever. But otherwise, you sleep at night knowing your code's clean and your marketing team can just market. Everybody's happy, everything's fast, and everything's easy. ~That's, that's the dream and that's what we're pretty much seeing.~ Paul: Can you talk to me a little bit about. Speculative fetching or speculative loading of components. Cuz I think that's something a lot of people might look at and they go ~like, what,~ what if it speculates incorrectly and what's it speculating about? Is it speculating about what little bits to load when it slices and dices up my Java script And yeah, ~let's,~ let's get into that a little bit. Steve: ~Yeah, that's a good question. Yeah.~ Like any good engineer, everybody's a little bit wary of magic optimization, right? They're like, ah, I don't know about that. I wanna know exactly what's happening. ~Yeah, yeah.~ And so let me describe how this works ~and, and,~ and why it works. ~So, uh,~ going back to the example of ~like,~ okay, when a quick page loads, it's just pure [00:25:00] html. In the h t Hdml is all of these, ~um,~ Paths to JavaScript files and, ~um,~ the question now becomes so, ~well,~ first, our compiler already in a very deterministic way will shred your components into small files. ~So, ~um, I should point out an important part of this concept, which we callability compared to, ~uh,~ what we call hydration is like a replay or replayability. You're rerunning your entire. Page just to make it interactive. ~Uh,~ with quick, you're resuming, ~you, ~you serialized HT m l, you deliver it and then you just pick up where you left off. You could actually take a quick page and grab the H G M L, open up a new browser and paste it and continue where you left off regardless of what the state was like. You load up a counter app and you click the button a few times. Now it's at seven. Now you pace that to another browser window. It picks up on seven. It could continue. It's pretty interesting property. ~Um,~ But anyway, so what happens when you send this HTML with all the JavaScript URLs is, ~um,~ there's really three ways that you can optimize this. One is you just don't, you don't prefetch anything. And when you click a button at that time, it fetches the [00:26:00] JavaScript and runs it. ~And, um,~ That works okay. And it's shockingly fast because the JavaScript is very small, but you run into issues of what you don't want is, ~you know,~ you're on a bus, ~um,~ the bus goes under a tunnel and now the application just doesn't work because it can't fetch that piece. I forget there's a name for this, but basically you want to have this continuity. ~You,~ you do want things to continue to work, ~uh,~ and you don't. Want to always need a network at every moment. So you can actually have your network drop off for a minute and the application or the site still works. ~And so it's like, okay,~ the next thing you could do is ~what,~ what Google does. And they're adamant that it's the right way. And it is ~a,~ a really effective way is just prefetch everything because fetching JavaScript is not nearly as expensive as parsing and executing it. ~And so it's like, okay, you know, one image or one video on your site is gonna be, you know, Uh,~ take a video. It's gonna be probably 200 kilobytes at least, depending on ~the,~ the size and duration. ~Um,~ an image. Sure. 30 to a hundred based on size, et cetera. ~Um, JavaScripts,~ these little bits of JavaScript, you could probably prefetch everything for a pretty complex site in. Less than a hundred kilobytes. A simple site, you know what, 10 or something. ~Um, so it's like, okay,~ that's one way to do it. Just prefetch everything all at once. And now everything's already in memory. When you click [00:27:00] the button, it'll, ~it'll, uh,~ parse and execute immediately. There will be no delay. And if your network is unstable, doesn't matter. It's already there and it's cashed in. A service worker is what we use. But the question is, what if you want it to be faster than that? Like what if you actually could determine that it's an e-commerce page, and at the top of the page is an ad to cart button, and that button's really important. You want people to see it. And if they're trying to smash that button, that button should work right away, if at all possible. And down below, let's say you have a reviews widget. ~The re reviews widget has all kinds of functionality, creator review, uh, rate a review, you know, submit, blah, blah, blah, blah.~ What we ideally want is we want the fetching to be prioritized, so that add to cart button is fetched immediately. Page loads, add to carts ready. Right. And then all the other review stuff, the stuff lower on the fold, et cetera. So that's where we have, ~um,~ a couple different strategies here. What we wanna do is speculate what's more important than others. ~Uh,~ there's a few heuristics here and one that we have coming, I think is the most interesting. But one is just what type of event is it? ~You know,~ is a click more important than ~a~ a mouse center? Is a blur and focus event more important than a form submit. We have essentially an ordering of what events are probably most important. ~Um,~ after that we look at [00:28:00] positions. So yeah, things higher on the page generally should load fester than things in the footer. And so we will prioritize based on position. ~Um,~ there's a few other things in this, and then what we will do is we'll actually pass some important information to the bundler. So if we find that. Let's say every time you run, ~um,~ the button click, ~you know,~ the add to card button, click handler. It also has a dependency. We will bundle the dependencies and we'll do it in a smart way so we can see the whole graph, we can prioritize the graph and we can make smart bundles so you're not always loading tiny pieces of cross multiple files, but it's grouped like you optimally want. ~Um, but finally,~ and where we're going with this is what we really wanna do, and I think this is proven by a really cool project. By, ~uh, Minko,~ Minko, catch of the Angular team, ~uh,~ who made this project called Guest js, which the idea was let's hook into your Google Analytics and let's look at ~the, the, uh,~ the paths people take through your website and let's prefetch pages based on what they tend to go to next. So people land on your homepage and they all then go to the shop page. Then we know that from the data that's the best next page to Prefetch. So it's at a page level rather than a, ~you know,~ point of[00:29:00] Paul: That's amazing. Steve: Yeah, it's awesome. I think it's been in beta forever, but it works. I don't know why he has to take it outta beta or maybe I'm making that up and it's out, but that's what we want as well. And so with quick, the same idea is, and we're testing this on our own site and our own stuff now, is let's collect user analytics. And if we are. If it is the case that everybody tends to click the add to card button first upon, or most upon reaching the product page, let's prefetch that with the highest priority. Maybe the search bar is the next highest priority and we prioritize accordingly. That stuff can be done offline and fit your bundle bundler. And ~um, yeah,~ that's the idea of it. Paul: So between, let's say strategy A is like the OG way of maybe event and structure based, and strategy B is using, um, mink's new framework. He's developing ~in,~ in analytics based what in the diff between method A and method B, do you think has already been identified and will be continued to come to light and be identified that maybe we could look at and learn a little bit about. [00:30:00] How we structure the websites ~and,~ and what we think is important versus what actually is important. Steve: Ha ha. Yes. That's a good question. ~Um,~ the short answer is it's too early to tell definitively. So we need a little bit more time to collect the data and run the test to say, okay, let's test the, ~uh,~ the dumb way that completely ~like~ make a guesses way against the smart way, quote unquote, using real data. ~Um,~ the reality is the dumb way, again, I'm gonna put these in quotes because, ~you know,~ it's whatever the dumb way is gonna be lower lift. You don't need any analytics to run, you don't need any backend service going on. You don't need anything. So that's easy peasy. The big question is exactly what you asked is the smart way. How much better is it to make it worth have to have it? This like, Offline, this analytics to store, to query ends load into the bundling~ process ~process. ~Um,~ so far we found that process is actually not complicated. It's very simple. We might provide an API or something open source. It's not something we're trying to monetize. We just want people to be able to run their applications as fast as possible. But yeah, we're gonna try to make that as simple as possible, measure the difference, and then be able to recommend is the smart way, the better way. ~Um,~ and if [00:31:00] so, who is it for? Maybe it's the better way for Amazon, but for your personal blog that gets two visits ~a,~ a day, ~uh,~ maybe it doesn't matter. ~You know,~ it's up to you. Paul: Right now, this is a, a highly analytical and quantitative process. It sounds like you have ~a,~ a pathfinding. Method ~and,~ and quantifying ~these,~ these routes that you take. ~I mean, we, we,~ we don't have time to go into detail necessarily ~about,~ about all these methods, but, ~um,~ correct me if I'm wrong, but it does sound very quantitative and you're really defining a structure by which you can make these evaluations. Steve: Yeah. Yeah, it is. It's actually really interesting, the data format of what we save in the database and then use SQL to query it off of, and that's. ~You know,~ the biggest question is how do we make it as simple as possible so that people can host this anywhere? Right now we use BigQuery, cuz we use BigQuery for a lot of things internally. You can do really complicated analysis with BigQuery, which is awesome. ~Um,~ not everybody uses BigQuery. ~Uh,~ so how can we make it so that it's. It's as effective yet simple as possible. So just slots into their stack, or could we provide [00:32:00] something you can ~kind of~ spin up on your own aws, ~um,~ using things that are outta the box. ~So if you, for the details, you should have mono on sometime. Mono implemented the details here, it's, um, in, if you wanna go down to the weeds, it's over my head, uh, at this moment. But, um, for now, it's just mostly the way we store and query the data and yeah, it's a lot of, um, God, it's really hard to describe.~ ~I'll leave it as, yes, it's very~ Paul: ~It is, yeah, very quantitative, right? Um, in terms of non quantitative, sort of smart. Or we could call it AI driven development that you've been involved with. Steve. Um,~ you've recently had a, another post come out about using AI to generate pages from components. ~Uh,~ a little less quantitative, ~I guess,~ but could you talk us through a little bit about what you're working on with the team? Steve: ~Yes. Yeah, I,~ I love this one. And so this is something like, I just did a blog post comparing, ~um,~ types of visual editing. Like on one extreme, it's just edited buttons, ~um,~ that was recently announced ~by,~ by some big people. ~Uh,~ then you have like live previewing. Then you go deeper into like full dragon drop with your components. And then also full, ~like~ no code, ~like~ create anything from scratch. You don't need a component for everything to. Actually build and deploy something on your site like we talked about, ~you know,~ meta even does in a cool way as well with Instagram and Facebook and their other apps. ~Um,~ what's interesting is when you have this Jason format that can render out anything to any. Friend in any framework, native app, whatever. ~Um,~ and then you could train an AI on that. Then you can actually just start asking questions of the ai. So the first thing we released a while ago, or, ~um,~ not too long ago, a [00:33:00] few weeks ago, was just ask for anything you want and it'll be generated. ~So like,~ give me a homepage hero that has two buttons. One is a primary CTA or one's a secondary cta. ~Uh,~ it says this and then it, ~uh,~ it looks like it would be on jcrew.com. And then you hit it and just bam, it's generated, and you can hit publish and it's live on your next Js. ~You know, and ~a and a minute if you wanted. ~Um,~ but what's cool is then you could go in and tell it to edit things. ~Uh,~ a fun one to do is, ~uh, you know,~ click on the hero and, ~uh,~ we have a keyboard chart at Command O and just say, ~um,~ translate it all to Spanish, and then cool. It's all translated to Spanish. Or you can change things. You could say, this is too dark. Make it lighter. Or you could say, ~um, You know,~ add a third button and make this the most primary button. I have a whole video where it went to depth, but it's really cool. You can just generate whatever you want and then you can ask it to edit however you want. And the idea there is, you know, things that are hard when it comes to still building, even if visual one is designing still hard. Even if you have good components. Knowing how to compose those components into a good way. Make sure to use these props for this versus that. It's not easy, ~um,~ and if [00:34:00] AI could just do it for you. Fantastic. ~Um,~ and second, using a responsive editor. Has a learning curve. So if you wanna use builder in a super advanced way, it can be a lot easier to just say what you want and have the AI do it for you, or say what you want changed and have the AI do it for you. And then to actually learn how to use the nuances of the drag and drop editor, especially as you're just dipping your toes. So we're really excited about AI and how we can have this. This Jason intermediary that we can interface with the ai. ~Um,~ you can use that to create all new things, which you can either with builder hit, publish and deliver to your live site. Snape over an api. So no deploys, no code changes. It's just there in whatever region you decide or because of how, ~um,~ our code gen works. Or you can just generate code. So connect your components. Ask for the most awesome homepage ever. Tell AI to change it however you want. And then just export to code and pay. Send your code base, do whatever you want. ~It's,~ it's pretty cool. Paul: So I, I think one big takeaway I'm hearing from you, Steve, here, is ~like, um,~ your mitosis endeavors and using this j s o representation. We're coming back to it's full [00:35:00] circle, man. We're coming back to J S O again, it's a. A really strong representation to communicate a component sort of language to the ai. And when you say train, do you mean you're priming it with these statements, ~um,~ and getting it ready? Or do you work with fine tune models, ~uh,~ through a provider, or do you really train your own LLMs from scratch? Steve: Ha ha. That's a good question. ~So we,~ we've gone down all paths, ~uh,~ training, fine tuning and clever prompting. ~Um,~ and we use a mix of, ~uh,~ multiple things today, but actually with the latest developments of LLMs, where we're starting to go towards the most, which is actually the most, ~um,~ Simple way is through generating most of the stuff through prompts, passing to LLMs like G P T 3.5 turbo and G P T four. Those actually work shockingly well. And so if you just provide some examples, some background, some context, and ask it to output it, that works. And the other thing we found actually works as a huge advantage to these models that are pre-trained on massive code bases and reactors [00:36:00] everywhere is because mitosis ~can,~ can, ~um,~ parse, ~um,~ React Code JSX to Jason, we've actually now adopted just using React as the basis. So these days, the simplest ~and,~ and best models that we found to be impactful is we literally just asked the ai, ~you know,~ give us a React component for, ~you know,~ here's all the criteria. It generates React component, we parse that to the Jason and then it's imported into the build builder visual editor, which can then output to quick or whatever you want. ~Um,~ and then the way we found is to make the custom components, ~you know,~ designed with my components work is we just provide the type interface. So we convert what we know about the components to ~a~ a, a type script interface, and we basically say, here's the components you can use. And we add some med information so it ~kind of ~quote unquote understands what's available. And then blam, it'll generate new stuff off of it. ~It's,~ it's pretty cool. Paul: Very, very neat. And so if people wanted to get started, they could head over to Builder and check it out. Steve: Yeah, builder ao ~uh,~ you could sign up, ~uh,~ for free. You could check out our pages. We have ~like~ this interactive playground that I just built out that uses web containers. ~It's really cool, so you can actually,~ you don't even have to [00:37:00] download anything. You can just play with it all in the browser ~and,~ and, ~uh,~ see if you like it. Paul: Sweet. And Steve, if people wanted to keep up to date with you and things you're posting about and talking about, do you have a Twitter or blue sky? Steve: Yes, I have Twitter, blue Sky, YouTube, TikTok, Instagram, LinkedIn, all that stuff. And it's always the same. I have a very hard to remember username, but it's always available on every platform. It's Steve, 87, 0 8. ~You can find me,~ Paul: ~That's, that's great. Arguably much better when you just need to remember one~ Steve: ~Exactly.~ Paul: ~87 0 8. It has a ring to it that we're, we're, we're creatures of pattern. So I think you have one going for you there, ~Steve. It was a pleasure having you and talking about quick AI and ~you know,~ how you stepped into the field and the problems you identified. Steve: Yeah. Thanks so much for having me. I had a blast.