Partytown with Adam Bradley
Adam Bradley discusses Partytown's web worker approach to third-party scripts, Qwik City's meta-framework, and Mitosis's cross-framework component compilation.
Episode Description
Adam Bradley discusses Partytown's web worker approach to third-party scripts, Qwik City's meta framework development, and Mitosis's cross-framework component compilation.
Episode Summary
Adam Bradley, Director of Technology at Builder.io, joins the show to discuss his work on Partytown, Qwik, Qwik City, and Mitosis. The conversation begins with his background creating Ionic and Stencil JS before moving to Builder.io. The core discussion centers on Partytown, which offloads third-party scripts like Google Analytics and Tag Manager to a web worker, freeing the main thread for application code. Bradley explains how Partytown proxies DOM APIs within the worker environment, forwarding calls to the main thread since web workers lack access to window and document. The conversation then shifts to Qwik City, the meta framework built on Qwik, which draws inspiration from Next.js, SvelteKit, and Remix while leveraging Qwik's resumability to avoid hydration entirely—resulting in a runtime of roughly four kilobytes minified. Bradley contrasts Qwik's approach with Solid JS and traditional frameworks, arguing that rendering performance is largely a solved problem and that the real gains come from not executing JavaScript at startup at all. The episode also covers Mitosis, a compiler that translates a subset of JSX into components for React, Vue, Angular, Svelte, and other frameworks, enabling Builder.io's visual editor to work across any stack. Bradley closes with thoughts on the JavaScript ecosystem's maturity and why no single framework will ever dominate.
Chapters
00:00:00 - Introductions and the Mobile Web
Adam Bradley introduces himself as Director of Technology at Builder.io, outlining his history creating Ionic, Stencil JS, and now working on Qwik and Partytown. He explains that his day-to-day work has always centered on performance optimization for low-end devices, whether mobile or web.
The hosts discuss the overlap between mobile and web development, and Bradley clarifies that his mobile work was always web-based rather than native. Christopher Burns shares his university experience with Cordova and React Native, prompting Bradley to recommend Capacitor as Cordova's modern successor, built around ES modules and TypeScript for bridging native APIs and the web.
00:04:34 - Partytown: Offloading Third-Party Scripts
Bradley explains Partytown's core mission: dedicating the main UI thread to application code while moving third-party scripts like Google Analytics and ads into a web worker. He describes the common frustration developers face when carefully optimized sites are slowed down by business-required marketing scripts, noting that the median website loads ten third-party scripts.
The discussion covers Partytown's framework-agnostic design, which works by simply adding a type attribute to script elements regardless of whether the site runs WordPress, React, or Angular. The hosts highlight integrations with Next.js, Gatsby, Astro, and VuePress, and discuss a potential WordPress plugin that could impact the majority of the internet.
00:09:35 - How Partytown Proxies the DOM
Christopher Burns asks how Google Tag Manager works within Partytown, since it dynamically installs additional scripts. Bradley explains that Partytown proxies global APIs like window and document inside the web worker, forwarding calls to the main thread for real responses rather than reimplementing the entire DOM like jsdom would.
When scripts inside the worker attempt to add new script elements, Partytown intercepts those and keeps them within the worker environment, while non-script DOM modifications pass through normally. Bradley discusses the project's beta status, emphasizing that data loss is possible if scripts don't work correctly and encouraging community testing and minimal reproduction cases to help identify issues.
00:13:44 - No JavaScript and the Builder.io Ecosystem
Bradley shares that the ideal scenario is shipping zero JavaScript, but HTTP Archive data shows most real-world sites add numerous third-party scripts regardless. The conversation transitions to how Partytown fits alongside Qwik, which skips the traditional hydration process by serializing state directly into the HTML and only executing JavaScript when interactions demand it.
Bradley introduces Qwik City as the meta framework for Qwik, analogous to Next.js for React or SvelteKit for Svelte. He explains that Qwik City's runtime is approximately four kilobytes minified and that it draws heavily from existing meta frameworks while sidestepping their reliance on hydration, making it conceptually distinct in that it has no single entry script.
00:19:28 - Qwik City Details and Framework Migration
The hosts explore whether migrating from Next.js to Qwik City would be feasible, and Bradley confirms that similar routing conventions, file naming, and JSX-based components should ease the transition. He introduces Qwik React, which allows importing React components into Qwik apps using an island-like pattern where JavaScript only downloads when needed.
Discussion turns to Qwik City's deployment story through Vite, with middleware available for Cloudflare Pages and Netlify. Bradley describes the excitement around edge SSR and personalization as a key challenge, where rendering personalized e-commerce content at the edge as quickly as possible represents the next frontier for framework performance.
00:27:26 - Framework Competition and Comparisons
Bradley reflects on how frameworks borrow ideas from one another, tracing inspiration chains from PHP and Jekyll through to modern meta frameworks. He argues that while Qwik City's developer experience is comparable to Next.js or Remix, the fundamental difference lies in Qwik's runtime behavior—eliminating hydration entirely—which competing frameworks cannot adopt without essentially becoming a different framework.
The conversation compares Solid JS and Qwik, with Bradley noting that Solid dramatically improves on React's internals but still relies on hydration, while Qwik avoids startup altogether by serializing everything into the DOM. He contends that rendering performance is essentially a solved problem and that the meaningful innovation is in not running JavaScript at all during initial load.
00:30:41 - Mitosis: A Cross-Framework Component Compiler
Anthony introduces Mitosis, another Builder.io project that compiles a subset of JSX into components for React, Vue, Angular, Svelte, and other frameworks. Bradley explains that this enables Builder's visual editor to let marketers and designers drag and drop custom components with real business logic into any framework's application without developer intervention for every content change.
The hosts compare Mitosis to Babel but for framework translation, and Bradley describes how it frees organizations to maintain their existing infrastructure while still using Builder's drag-and-drop tools. He defers deeper technical details to teammates Steve and Sammy, noting that Mitosis can even output React Native components.
00:37:23 - The Education Gap and Scaling Challenges
Anthony observes that while framework insiders understand the benefits of Qwik and Solid, the vast majority of developers have never heard of them, creating a significant education gap. Bradley acknowledges that small React apps work perfectly fine and that the real pain points emerge at scale—when hundreds of components cause startup bloat and slow conversion rates on e-commerce sites.
He explains that with Qwik, startup time remains constant regardless of how many components exist on a page, making it particularly valuable for large-scale applications. The discussion touches on studies linking faster load times to improved conversion rates, reinforcing why performance-focused frameworks matter most for businesses where milliseconds translate directly to revenue.
00:40:09 - The Future of JavaScript Frameworks
Christopher asks whether a single dominant JavaScript framework will ever emerge, and Bradley returns to his automobile analogy: after a hundred years, there are still dozens of car companies making different vehicles for different needs. He predicts the ecosystem will narrow to a practical handful rather than converge on one winner.
The episode wraps with Bradley reflecting on JavaScript's maturity since ES modules, async/await, and native fetch in Node 18, noting he's been content with the language's capabilities since around 2017. He shares his origin story of learning to code on GeoCities with Notepad, and the hosts close by thanking Builder.io for its open-source contributions and directing listeners to Adam's Twitter and Builder's GitHub.
Transcript
00:00:00 - Anthony Campolo
I love that job. Adam Bradley, welcome to the show.
00:00:13 - Adam Bradley
Thanks for having me.
00:00:14 - Anthony Campolo
You are the director of technology at Builder.io. Why don't you give us a little intro to who you are and what you do?
00:00:22 - Adam Bradley
I'm the director of technology at Builder.io. Previously, I was with the Ionic framework and helped create that. While I was at Ionic, I also created Stencil JS, which is what powers Ionic and all the components. Since then, I've been working with Misko at Builder.io on Qwik, which is a next-generation framework for resumability and things like that. Misko has already talked about that in a previous episode, so I'll defer to his knowledge, or that episode, for more information on that. I'm also working on Partytown for Builder. Partytown is a way to offload third-party scripts onto a web worker. That's what I've been working on.
00:00:57 - Anthony Campolo
Awesome. Yeah, we already got the Qwik pitch from Misko, so we don't need to talk about that too much. I would be curious to get, later on in the episode, your definition of resumability, because it's a difficult term and you guys seem to have kind of invented it. A couple different definitions will probably be useful. But before we get into all that and Partytown, I'd be curious: do you miss mobile?
00:01:18 - Adam Bradley
Do I miss mobile? I don't know, to be honest. I don't think there's much of a difference. In my day-to-day development, it needs to perform on a low-end device, so it was easier for that to stand out in mobile, for sure. My work with Stencil and Ionic was definitely focused on low-end Android phones. How can we make these still perform fast?
What I'm doing today is somewhat the same: trying to make stuff run fast on slow devices. That's the best way to test it. So my personal day-to-day is largely the same: studying flame graphs and performance tooling and seeing how fast things are performing. So I would say it's about the same. Mobile, website, and web app development is a wide spectrum for developers, depending on exactly what they're working on. To answer your question, I do miss building mobile apps a little bit, but I enjoy more of the performance side of things and trying to eke out more performance.
00:02:13 - Anthony Campolo
Yeah, I find it interesting how the two are separate worlds, but they influence each other quite frequently. You see this with GraphQL. It was invented for mobile, but the vast majority of people doing GraphQL right now are doing it for the web, at least it seems like that from my vantage. So it's always kind of cool to see people who've worked in both those worlds. I still have not really touched the mobile world at all, but one day.
00:02:35 - Adam Bradley
I also should say that I wasn't building native mobile apps, so I was still doing pure web development: CSS, HTML, and JavaScript. That's also why it's not really too big of an adjustment for me. I've still been web 100% of the time.
00:02:48 - Christopher Burns
I built mobile apps before, and I jumped from Cordova to React Native and cursed Cordova to the point that I never looked at Ionic, so maybe it's grown a lot since my cursed days of PhoneGap and Cordova?
00:03:02 - Adam Bradley
Yes, and actually, while we're on the subject, I would encourage you to test out Capacitor, which is also something that I helped start at Ionic and is widely used now. It's taken over Cordova, but it's kind of the next generation. Cordova was built in 2009, so it had a very 2009 way of doing JavaScript and modules and trying to replace, what was the phrase, where they would add all the APIs on the navigator and things like that. Capacitor is kind of the next generation: just using ES modules, TypeScript, and being able to bridge the gap between native APIs and the web. So for those of you who had issues with Cordova, I definitely encourage you to take a look at Capacitor.
00:03:41 - Christopher Burns
This is an interesting subject. I can just say one more thing. Cordova was one of my modules at university. It was called Mobile App Design. They had an art lecturer teaching it because he knew how to make websites and put websites on phones. And I was like, this makes no sense. Why don't you use a proper system, something abstracted like React Native? I literally fought with the lecturer. I was like, if you want to build a mobile app, build it properly, or if you're going to go halfway, use React Native. I was naive at the time and forced my way in to the point where they allowed us to use other frameworks, and I was the only one that chose React Native. I still, to this day, think that mobile app I made was pretty good compared to most of the uni apps at the time.
00:04:24 - Adam Bradley
Yes, this could easily be a multiple-month-long discussion of which framework to use for building a mobile application.
00:04:30 - Christopher Burns
For sure. And it's still not over. I would say it's still even in its infancy.
00:04:34 - Anthony Campolo
Let's get into Partytown. So Partytown is probably one of my favorite projects of all time, and I can give a really short pitch because I've heard you give a couple podcast interviews about it. When you have a website, you have your website and you have all the other stuff like marketing scripts and analytics and things that are going on that involve third-party code or widgets, or things that me and Chris talked about on an episode with the two of us. When you have all of that, it slows your website way down. And so Partytown is the idea of taking all of that, taking that party and moving it somewhere else, and moving it off the main thread because you're using a web worker, I believe. So can you talk a little bit about what Partytown is, how it works, and what benefits come along with it?
00:05:23 - Adam Bradley
Yeah, really, the whole idea behind Partytown is we want to dedicate the main UI thread to your code, to whatever application JavaScript you're running: React, Angular, Vue, it really doesn't matter. No JavaScript at all. We want to free up that main thread's resources to just your code and then all of the other code, basically third-party scripts, so things like Google Tag Manager, Google Analytics, ads, stuff that will slow down your site, offload that to a web worker and let it all run there. So it's not blocking the main thread at all.
The idea of this is not to put your application, your main code, into a web worker, but rather just anything that can run a little bit slower. Anything that can be asynchronous, basically in a background thread or background task, is ideal for Partytown. We've actually seen that it drastically improves performance. I think most developers have been there where they've spent a lot of time getting that site to run fast and scoring 100 out of 100 in Lighthouse, and are pretty happy with it, run it in production, and all of a sudden all the analytics kick in and it kills that performance.
[00:06:26] And then the very same people that tell you to speed up the website are the ones who also added all the scripts. Kind of a frustrating position that developers are often put in is that, well, we can't really do anything about these scripts. We need them for business reasons. I can't say no to adding Google Analytics. That's kind of an organizational decision. It's out of the developer's hands what can and cannot be run on your website. And also, to be fair, that's perfectly fine. A lot of these scripts are needed for business reasons, so that's why it's kind of restricted, like, well, we have to run these. But when you have to run them, you can't improve them. You can't make them better, and you can't do something different with them. They just basically eat up all the resources. And that's kind of where Partytown comes in. It's basically, all right, our hands are tied. We've done everything we can to make our JavaScript as fast as possible.
[00:07:11] And now when we add in this one megabyte, five megabytes of someone else's scripts, it just destroys the performance and there's nothing we can do about it. That's really the source of it. That's why Partytown was created. It all comes from working on Qwik, which again, you know, Misko and I and Manu are working on for Builder, that we can make your website as fast as possible. Basically HTML, CSS, you can't get faster than that, but you're still going to add all these scripts to it. You still need to add all these scripts, and they're still going to slow down your site and you're back to kind of where you started from. And so that's the whole idea behind it. It's like, how can we offload this to somewhere else to keep that site fast?
00:07:44 - Christopher Burns
Partytown is a really interesting thing. One of the biggest places that Partytown could be a big benefit for is WordPress. There was a PR, I don't know if it got merged, to put Partytown into a WordPress enhancement plugin.
00:08:00 - Adam Bradley
Was there? I didn't see that.
00:08:02 - Anthony Campolo
Yeah, I got it right here. I'll drop it in the chat and put it in the show notes for anyone who wants to check that out.
00:08:06 - Adam Bradley
That would be awesome. We did not make it framework-specific, like it needs to have a webpack loader or use React something or another, right? It's entirely just basically somehow you need to make a script element, and however that script element is added, you could also add this type attribute to it. Whether it's WordPress, Drupal, React, Angular, it really doesn't matter. But any of these things can make elements. And so however you were making your script elements before, you can continue to do it the same way, but then add in this certain attribute to change it, to move it to a different thread.
00:08:37 - Christopher Burns
Yeah. And literally, if it got merged into something like WordPress by default, it would speed up like 70% of the internet.
00:08:44 - Adam Bradley
Yeah, that's no joke.
00:08:46 - Christopher Burns
Literally. But there's other frameworks that have been experimenting with Partytown as well. And Next.js is one of them, isn't it?
00:08:54 - Adam Bradley
Yes, Next.js has had it. Last I knew, it's still in Canary. I don't know where it is now. They have their own script component where you can decide how to load that script. One of the options is worker strategy, which is basically Partytown. That's been getting some good success.
Gatsby just added roughly the same thing. They also have a script element or script component. I forget the name. Worker implementation, I think, is what it is. It's the same idea. But again, that's what I'm happy about with how to enable it. Partytown isn't required for a certain framework, so therefore any framework can enable it. I know VuePress has a good plugin. There's quite a few. On our website, we've got quite a few integrations. I think Astro has already made one.
00:09:35 - Christopher Burns
I do want to ask one question, and if you don't know this stuff, it gets pretty complicated really fast. How do things like Google Tag Manager work with Partytown? Because Google Tag Manager downloads and installs its own scripts based upon the scripts you put into its website. So how does that work with Partytown?
00:09:53 - Adam Bradley
Because we run that script inside of the web worker. In the web worker, we basically have to proxy the DOM, proxy window and document, because they actually don't exist, right? They don't exist whatsoever inside of a web worker. And if you try document.title, the web worker is like, I have no idea what you're talking about. Crash. And so that's really the problem, is that all of these scripts, the entire world, the last three decades of scripts, are written on window and document. So you can't just throw something into a different environment that doesn't recognize this.
That's where Partytown comes in. It proxies all of these different global APIs. And so when they're called, the web worker is like, no idea what you're talking about, but I do have a proxy for this. So let's forward this over to the main thread, get the real answer, and come back to the web worker with the answer of what document.title means.
[00:10:38] We're basically not re-implementing all of the DOM. Something like jsdom for Node.js, if we were to do that in the web worker, that's at least two megabytes of JavaScript, which would be counterintuitive to trying to speed up the site. Instead, Partytown is a huge fancy proxy of like, I don't recognize this global. Let's ship it over to the main thread. Maybe they know what to do with it, and then get the response to that.
If we run all of Google Analytics inside of there, it's going to add new scripts to the DOM. Just like what would have normally happened is going to happen inside of the web worker too, but with the caveat that, like, oh, you're adding a script. I know what you're about to do with this. So let's just stay inside the web worker and add that script inside the web worker too. But if you were to call document.createElement and add a div or a button, that's going to get added just how it normally would have.
[00:11:23] But if you add a script, it's just like, nope, you're inside the web worker. We're going to keep you inside the web worker.
00:11:28 - Christopher Burns
When it comes to marketing scripts, I still believe it's like the black magic of the internet. Every company seems to make one. Is it open source? Is it closed source? Is it versioned? Is it not versioned? And the biggest thing is when you have to bring in things like GDPR and have a banner block scripts from loading depending on their preferences. Nobody has this fully figured out and it's still a pain today. If you know one of these cookie policy banner things that has it sorted out, I would love to know.
00:11:58 - Adam Bradley
As far as cookie banners go, it's been a request to make sure that they work, because I think we get asked a lot, like, does it work? And I don't know. There's a lot of code out there in the world. Partytown is an open-source, MIT-licensed project. The more help we can get testing this and finding something like why that script didn't work, and writing a minimal test case to help out, like if we fix this one little thing then the script would work. Because again, we're not trying to reinvent the DOM. We just want to make sure that all of what would have happened in the DOM gets replayed correctly with the proxy. So there are a few little things that sometimes don't work, and that's where we need help. I get asked that a lot. I'm just like, well, does this script work? And it's like, I don't know, find out, let me know, and let's find out why it doesn't work in there.
[00:12:37] That's where I usually ask the community to help out with that.
00:12:40 - Christopher Burns
Would you say that Partytown as a project is very feature-complete at this point? Is there a massive roadmap of things you want to add, or is it just that very poignant, move-things-to-the-web-worker, and that's it?
00:12:54 - Adam Bradley
I would say there is no roadmap for the most part other than just work. If a script just works inside of the main thread, it should just work inside of Partytown too. That's why I still label it as beta, and I wouldn't encourage Amazon to just flip the switch and have all their analytics run through Partytown tonight, because you can opt in. It's definitely a slow migration, per script, and definitely stay in contact with the analytics team that's helping out with your site so that you can make sure that no data loss is happening. That's kind of why I'm still keeping it at beta. There could be data loss if something isn't working correctly. If you went a month without knowing that, I'm sure your business would be quite upset to not have any analytics for a while.
So again, yeah, beta. If you find an issue, please help narrow down why, and we'll get that fixed and published again.
00:13:44 - Christopher Burns
What's Partytown's opinion of shipping no JavaScript to the browser?
00:13:49 - Adam Bradley
Partytown's opinion is absolutely don't ship any JavaScript at all if you don't have to. That's kind of also where Partytown fits in nicely. In a perfect world, on your personal blog site, it's easy to say, well, I've got no JavaScript on here. It's as fast as it could ever be. But in a realistic organization, I think the median of the internet, as of HTTP Archive, is that there are ten third-party scripts on the average site, and the 90th percentile has got 34 third-party scripts on their site. So even if you build a site with no JavaScript, more than likely you're going to add a lot of JavaScript regardless. Again, that's kind of where Partytown came about. It's going to happen. So ideally no JavaScript, but realistically it's going to be there.
00:14:32 - Anthony Campolo
I'd like to talk a little bit about how Partytown fits into this larger suite of tools that Builder is working on, and what are some of those other projects that you're working on?
00:14:42 - Adam Bradley
You guys already talked with Misko and Qwik. So it's server-side render first. The framework first decides to build this application, build the HTML, just like React render-to-string, kind of the same concept there. And then that HTML is passed down from the server. And then traditionally, basically all the traditional frameworks at this point will replay and catch back up to what just happened on the server. That process is called hydration. Regardless of what you do, you can have a fast React site. It needs to catch back up to what it already did before. It needs to scan through all those nodes, hydrate basically to what it used to be. And so that work is a huge hit to performance.
If you go to any site that's doing hydration, if you look at that flame chart of that first second, you're going to see a huge spike. And that's the part that really is hurting a lot of the page scores because of that.
[00:15:28] So what's different with Qwik is that we're able to basically skip that entire hydration process. We can go straight to HTML, keep it HTML, and the state is serialized inside of the DOM so that when you need to use something, it's already there. And that's kind of the high-level difference. We call it resumability because the server pauses the state, pauses it inside of the HTML, ships the HTML, and then when you want to pick back up is when it continues, rather than like, oh, let's download all the JavaScript, let's rerun the same thing that just ran inside of the server, and let's continue. Or let's replay what has already happened on the server and let's pick up from there. And that hydration process is really what a performance killer is. We've been working on Qwik as this project to avoid that whole process and go as fast as possible, avoid as much JavaScript as possible. Yeah, it's been working great.
The next project is Qwik City, which is what we're labeling the meta framework.
[00:16:24] So basically the Next.js to React, or the Gatsby to React, or SvelteKit to Svelte, Qwik City is to Qwik. That's actually been a lot of fun project, where it's being able to integrate the server-side stuff pretty tight with Qwik and it's working really, really well because it already kind of is an SSR-first framework. So being able to provide that experience out of the box has been a lot of fun.
00:16:46 - Anthony Campolo
Yeah, I'm definitely curious to get into Qwik City. That's also the first time I've heard Qwik pitched as predominantly like an SSR kind of framework. And I think that is a little easier for people to latch on to and wrap their minds around than trying to present them with this new term that you have to define to them. So I think resumability is great, and I look forward to it becoming kind of a more well-known topic in web dev. But I think leading with this as an SSR framework that does SSR a little differently might make a little more sense to people. That's just kind of my advice to you, but something that I've heard people mention is, we have so many frameworks, we have so many meta frameworks. Qwik sounds cool, Qwik sounds revolutionary. But why do we need to build a meta framework on Qwik instead of maybe taking some of our other meta frameworks and swapping out the front end for Qwik? So would that be possible, or is Qwik just so new that you have to build a new framework also?
00:17:41 - Adam Bradley
Well, what's actually kind of cool about Qwik City is I was just looking yesterday. The runtime of it is about four kilobytes when minified, so there really isn't much to Qwik City at all to begin with. The majority of it is just leveraging what Qwik provides. So if we were to somehow use Remix or SvelteKit or any one of them where it's kind of the core concept of how to build routes but use some other framework, that would be quite difficult to pull off because it's still kind of having to use the core concept of hydration and having to rerun all of this JavaScript to execute, whereas Qwik City's JavaScript really doesn't. Again, four kilobytes when minified, really. And that's even if you were to download some of the parts of it. So more than likely you're not going to get any parts of the runtime of Qwik City.
I think the core concepts are absolutely inspired by SvelteKit, Remix, and Next.js. Next.js has a new proposal for how they're going to do layouts and pages. I kind of feel like it's taking a lot of the good ideas from a lot of the existing popular meta frameworks, but it's able to avoid or sidestep a lot of the traditional issues that they have to handle, even basically having to run JavaScript at all, whereas we don't have an entry script. That's one thing that's kind of weird with, you know, we use Vite for our development, and Vite has one entry script to start with. Inside your index.html you have the entry source file. That's the one thing that doesn't fit well with how Vite and Qwik City works. There's actually not an entry script, so we still make it work. Vite works amazing with Qwik. It actually works very, very well. But that's the one weird thing. It's conceptually quite different. There is no one entry. There could be potentially hundreds, thousands of entries. But that's something that Qwik's optimizer handles and is able to not have to require any of that JavaScript.
00:19:28 - Christopher Burns
When it comes to Qwik City, you mentioned things like Next.js being an inspiration. Would it be possible in the future to migrate from, say, Next.js and React over to Qwik and Qwik City?
00:19:40 - Adam Bradley
Absolutely, I hope so. It uses a lot of the same concepts, like the routes directory and the file naming conventions and even the components. So if you start using some Qwik components, you see that it's really just a React component. It's really just JSX. The only difference is that there is a wrapper to that JSX called component. So for the most part, I would like to think that migrating should be quite easy. But the larger the site, the more issues you might have.
The other project we have is called Qwik React, where basically you could import any React component and it quickly ties it into building a component that would render. You might never download its JavaScript, so it's kind of able to use Qwik to provide an Astro type of concept where Astro will only download stuff. There are little islands as you see them, or as they're visible, things like that. So our Qwik React function kind of does the same concept.
[00:20:37] And so that idea would be that there is no UI library for Qwik yet, but there are millions of them for React. So you can start using them now. Or even if you have a React app, you can slowly start migrating one component at a time.
00:20:49 - Christopher Burns
I'm very excited about the future of Qwik. I have a project that I would love to convert from Next.js over to it. And Anthony laughs because that seems to be my job, converting one thing to the other. But Qwik feels like the ultimate destination, because we've seen a lot of fire going around the internet right now about here's one hack you can do that will get 100% Lighthouse scores. And it's like, is that really doing anything, or is that just pushing the can down the road? I think it's really good to see all of these different frameworks compete and show new techniques of raising the bar. And yeah, I'm just waiting for the day I can use XState and TanStack on Qwik, and I'll be quick to move over. That is all I can say.
00:21:34 - Adam Bradley
Nice. Well done. Yeah, I would definitely give a huge shout-out to Sally, Jess, and Ryan. Ryan's been a good friend, been helping us out a lot with Qwik and how things work, and a huge inspiration with everything that he's done with Solid and the performance that he's added to Solid. He's been a lot of fun to work with. When you say how the frameworks are kind of improving each other, I'd say a huge shout-out to him and what he's been able to do with all the different frameworks and, you know, to judge them all.
00:21:56 - Anthony Campolo
Yeah. Ryan's the one who actually put us in touch with Misko in the first place to get the first Qwik interview going. So yeah, Ryan has been a big friend of the show for sure.
00:22:04 - Adam Bradley
Great.
00:22:05 - Christopher Burns
It is literally that thing of like, when we look at the market share of React, there's enough market share to go around by just looking at React alone. I'm doing a talk in the next week about what is the One True framework, and the answer is there isn't one. You should look at what your project needs and pick the framework from there, not just go, Next.js is perfect for a marketing website. Next.js is perfect for a dashboard. You could use something like Astro, something so much smaller.
00:22:31 - Anthony Campolo
So you're arguing against Chris from three years ago?
00:22:35 - Christopher Burns
Yeah. Well, you could say I've matured as a person, and my tech preferences are still, I like the bleeding edge, but less React now.
00:22:44 - Adam Bradley
Yeah, I like to compare it to automobiles. Automobiles have been around for over 100 years. We've had plenty of time to refine it and make the perfect one. But there's still, what, 20 or 30 different car companies, and each one of them makes trucks and big trucks, small trucks, race cars. There is no one perfect automobile that can solve all problems. Some need to be a dump truck, some need to be a race car. You kind of have to pick the right one for whatever your use case is.
00:23:06 - Christopher Burns
What currently is the time schedule for Qwik City? It's already launched in like an alpha state, by the looks of it. But when do you hope that you can confidently say to somebody, you can use this in a production app?
00:23:18 - Adam Bradley
So right now the doc site is built on an older version of Qwik City. After this call, I'm going to go back to getting the doc site updated to the latest version of Qwik City. Once that's smoothed out, we're hoping to then call it beta, so basically get more people using it.
What's fun is that we've got quite a few people on Discord, quite a few people that are helping out with it now. We're getting plenty of feedback, so we're adjusting things. We don't want to quite open the floodgates of having too many people using it with issues and having a fire hose of things to try to handle. So right now we have a pretty good set of features we're trying to add. Once we go into beta, which I hate to give a timeline for, but in the next week or next few weeks or so, get that released, then we'll definitely have an announcement and get more people using it.
00:24:01 - Christopher Burns
Yeah, you should really delay that beta status for Bun support. It's the hot thing of the moment and it's really worth adding.
00:24:08 - Adam Bradley
I haven't used it. It looks really, really cool, but the only reason I think it looks cool is because I saw that it's super fast, but then it's not fast for async, so I don't know what to think.
00:24:17 - Christopher Burns
I've not used it as well, but it very much does seem like everyone's like, this is the future, and we're still waiting to see because Deno is the known alternative right now.
00:24:27 - Adam Bradley
Yep. Deno. A huge fan of Deno. We've made sure that Qwik is working on Deno for both building and on the edge and things like that. So that's what's kind of cool about Qwik and the output that it creates. We made a lot of effort to make sure we're not using Node APIs. It's just building JavaScript. JavaScript should be able to run on the edge inside of Deno, inside of Bun. It really doesn't matter. And so that's been fun, making sure that the whole build process and the whole output is just JavaScript. I'd like to think that it would just work on Bun, but I haven't personally tried it.
00:24:57 - Christopher Burns
Really interesting here. And what does deployment look like for Qwik and Qwik City? Because I'm not sure we ever spoke about that one.
00:25:04 - Adam Bradley
Deployment. Well, it uses Vite. The other thing that we did a big effort on is making sure that we didn't create another CLI, another special way of building, a new plugin system, or a new way to do styles and pre-process CSS. So basically Vite does an amazing job at that, and so we just use that. However you would deploy your traditional Vite app, you would just add the Qwik City plugin and the Qwik plugin, and then it's going to output to whatever directory you output it to, and you deploy that. And then Qwik City itself has middleware for Cloudflare Pages and Netlify. And we're still adding in Vercel and things like that. But those ones are all built too. So the doc site is using Cloudflare at the moment. It builds the whole middleware for Cloudflare Pages and we just deploy that. Pretty simple, actually.
00:25:49 - Anthony Campolo
Brittany Postma has a blog post on the Netlify blog for deploying a Qwik app. Not Qwik City, I think. Just Qwik. And then Cloudflare Pages has a dedicated deploy-a-Qwik-site link. So those are probably the two best resources right now for anyone who wants to play around with this.
00:26:06 - Christopher Burns
So it does deploy just like a regular Node framework. What I really want to see is that you're targeting, you know, Deno, Node, Cloudflare Workers, serverless, to find out which is truly the best option in this current moment. Because it's very much, I would say, up in the air. Like, will Deno actually bring us all this performance we're looking for? Will Cloudflare Workers beat Deno? These are still open questions. And the biggest thing that I always think of is, what's the point of all this? How much faster is it going to get? And I guess that's the only thing we all really care about, right? We'll code it in the hardest way possible if it truly is faster.
00:26:45 - Adam Bradley
Yeah. And that's what's fun about kind of this next generation of edge and SSR and, you know, basically people like the R&D of React. But then there are issues with that, with SSR and especially the personalization side of things. Let's imagine that you're an e-commerce site and, you know, for a certain group of people you want to show a certain T-shirt, and another group you want to show a certain color or something like that. Being able to personalize that on the edge and render that extremely fast is kind of the next big challenge right now. I think everyone's doing a good job of it. I think we're set up to do a great job of that, and that's kind of what we're aiming at. We want to be able to do all this personalization on the edge and render as fast as possible, respond as fast as possible. And that's kind of what we're working toward right now with Qwik.
00:27:26 - Christopher Burns
I guess one of my final questions about Qwik and Qwik City is, how would you feel if Next.js ripped off every feature shamelessly?
00:27:34 - Adam Bradley
Good luck. To be fair, like how they're doing routes and layouts and nested layouts and things like that, we took a lot of inspiration from that. Their most recent RFP of how they're doing layouts took a lot of inspiration from SvelteKit. And Remix has taken a lot from, you know, so it's a little bit of everyone. And then all of them took it all from, you know, Jekyll and all of them took it from PHP.
00:27:56 - Anthony Campolo
I've heard ColdFusion is the only framework that has ever mattered. They're all just reinventing ColdFusion, according to Rob Cameron.
00:28:03 - Adam Bradley
Everything that we've used in computer science was invented in the 70s. We're just rediscovering it over and over again. Now, as far as Next.js goes, I think Next.js versus Qwik City, if you were to compare the DX of the two, it would be a tough sell of just like, well, this one's so much better than this one. It's really when you compare React to Qwik that the actual differences are made. Whereas Next.js is extremely tied to React. They couldn't just switch out how hydration works and how React works and Suspense and all that stuff. That just can't be done simply. And so to basically try to take the features of Qwik, you'd have to use Qwik or you'd have to completely refactor React. And at that point it wouldn't be React anymore. It would be an entirely different framework, and you might as well just call it Qwik. So as far as the meta framework goes, I think they're very, all of them are kind of one for one right now.
[00:28:51] You know, Remix is just a slightly nicer version of Next.js, and that's my opinion. They're all pretty much the same for the most part. It's the underlying frameworks is really what we need to compare. And you can see that right in the startup, like which ones are using JavaScript and which ones aren't.
00:29:07 - Anthony Campolo
Do you think there would be a world where Qwik is on something aside from JSX?
00:29:12 - Adam Bradley
Yeah. So the renderer itself, the renderer of Qwik, is just a traditional VDOM. There are plenty of renderers out there that are plenty fast. I think, in my opinion, that rendering performance is a solved problem. It's been a solved problem for quite a while now. The metrics of rendering 10,000 nodes and who can run that fastest kind of doesn't really make a difference anymore. Like in IE8, that made a difference. But rendering performance, again, it's solved. React is well known to be one of the slowest renderers, yet it's widely used. No one even comes close to the usage of React. So the performance that it has is pretty darn good, even though it shows it's slower than other frameworks today. It kind of doesn't matter, in my opinion, at this point. So I guess what I'm saying with Qwik is we have a run-of-the-mill renderer that's going to perform just as well as any other VDOM framework out there.
[00:30:04] The big difference is that it doesn't have to render. The old adage of the fastest database call is the one you don't have to make. That's kind of like Qwik when it comes to rendering. There's a huge chunk of Qwik that will never have to render. You're not even going to download the code to re-render. The performance metrics of like, how fast did it render, kind of doesn't matter to Qwik because, well, we didn't do it at all. We didn't have to hydrate the whole app to see what we need to do to optimize it. You don't have to use useMemo. To use useMemo, you need to run the JavaScript to then decide how to make it faster. We just don't run JavaScript. It's kind of the big difference because we already know from the compiler, from the optimizer, what's possible to render and what's not.
00:30:41 - Anthony Campolo
One other thing I'd be curious to get your take on. There's an entirely separate framework, has nothing to do with any of this, that Builder is also working on called Mitosis. What is the deal with Mitosis?
00:30:52 - Adam Bradley
Mitosis. So that is a way for us to have a subset of JSX to build a component. And so you can write your normal component how you want it to work. You know, a fancy button. When you click the button, it adds to your fancy cart. However that would work, and you can add your styles to it. But then Mitosis would output that same component into any of the frameworks. We just recently got Svelte done. Even JS is done. We're working on a Qwik version, but React, Vue, Angular, they would all be able to output that.
00:31:17 - Anthony Campolo
Is it a compiler?
00:31:19 - Adam Bradley
Yeah. So basically it takes a subset of a React component and outputs it to all the different frameworks. The benefit of that is like, if you're using Builder's product, you're able to build an actual component, like one that has your own business logic, one that does very special custom things that you can create for your marketers and designers, and then your marketers and designers can drag that component wherever they want. The benefit of that is that now you can have this component run inside of your Next.js app or your Gatsby app or your Astro app. It really doesn't matter. It's able to take these custom components and actually put them in your real app rather than building, let's say, like Wix. Wix has a drag-and-drop interface builder, but it's very difficult to take a very large organization and migrate it over to use Wix. It's great up to a certain point.
00:32:05 - Anthony Campolo
All right. This is so interesting. I haven't heard anyone even talk about Mitosis yet. I think I only discovered it because I was just looking at the Builder GitHub or something, but I can't think of anything else in the space that's even similar to this. Because it sounds like what you're doing is you're trying to build almost Babel, but instead of Babel, that translates things to like the right JavaScript language, like ES 2015, 2016, 2017, it's instead Babel, but for components being understood across different frameworks.
00:32:31 - Adam Bradley
Yeah. Which basically kind of frees you up so that you can run it on your existing infrastructure. So again, say you have a Next.js app and it's a huge Next.js app and it's got many, you know, product pages, marketing pages, and all these different things, and you want to add in a page that marketers and designers can edit. There are certain tools that can do that today. But when you want to actually add your own logic to that, so let's again say a marketer wants to have A/B testing on their landing page, and they want to change the text and they want to move the add-to-cart button somewhere else, they can do that without having to contact a developer. The developer made that component, completed it, put it inside Builder, and then the developer did their job where they made the website, they maintained the component. But then as the marketer and designer, they can change the content, change it around, A/B test colors, fonts, all that stuff.
[00:33:18] And so it kind of frees up both sides to work on what they're more concerned about. And the big underpinning of all this is Mitosis, being able to generate the components for the different frameworks that whatever that site is using.
00:33:30 - Anthony Campolo
How do you know how to do that? Did that require writing like a specific plugin for each framework, or does it all compile to vanilla JS? You got that to work in every framework. How do you actually achieve that? Because I would imagine that there's so many differences between all these frameworks and different front-end UI libraries. I'd be curious, how challenging was it to build something that could do that?
00:33:52 - Adam Bradley
That starts to get a little over my head. I'm just aware of Mitosis and what it can do. You know, Steve and Sammy. Sammy's been working on it most recently on the team, and he can probably talk in depth about how it works. I mean, he can even output React Native.
00:34:06 - Anthony Campolo
But can't do React Native Web.
00:34:08 - Adam Bradley
I'm sure it could. Would it be the same thing?
00:34:11 - Anthony Campolo
That's a question for Chris.
00:34:12 - Christopher Burns
No. Ish. Yes. It depends on the elements. Similar.
00:34:18 - Adam Bradley
I would just say just use Ionic.
00:34:21 - Christopher Burns
In your opinion, what is the main difference between Solid and Qwik? And where do their futures lie, considering that Ryan is quite a big ally of Qwik?
00:34:31 - Adam Bradley
Yeah. Actually, Ryan did somewhat recently mention that he'd like to add resumability into Solid. So there's that. If he did that, that would certainly make them more comparable in that sense. And he also did a lot of work on Marko. And Marko does have resumability from what I understand.
00:34:47 - Anthony Campolo
Marko 6, I believe.
00:34:48 - Adam Bradley
Marko 6.
00:34:49 - Anthony Campolo
Which isn't out and no one has any idea when it's going to come out.
00:34:52 - Adam Bradley
So as far as I know about that, I've never used it. I've just been told this. So there's certainly that. But in the traditional sense, Solid JS is an extremely improved React, but it still has the hydration process. It has much faster rendering, things like that. But at a certain point, it's kind of apples to oranges as far as how they kick in and how they work. A lot of the traditional frameworks, like Svelte, Angular, Vue, all of them are kind of competing to see who can start up the fastest. And they all have the same somewhat process. They have a different DX, they have a different look, but for the most part they're largely the same. And we've all been competing about like, yeah, but this component looks nicer than this way of writing it. And that's kind of what we've been arguing about for the last 20 years, like, I like the look of this JavaScript, and I like the look of this JavaScript.
[00:35:32] But to be honest, the core concepts are the same. That's where we feel Qwik is actually different. It's not about how fast we can start it, because there is no startup. And we're able to do that by serializing everything inside of the DOM and only kicking in a listener when you use it. It truly is different compared to the other frameworks. But what they are doing right, and I think React is doing right, is the R&D of all of it and how the component works and how the JSX works. JSX is really just a syntax for how to build components with JavaScript. The underlying of it, whether it's DOM, whether it's something that Solid does where it boils down to faster optimization, that's internals. We can certainly do the same thing that Solid is doing right now. But on the surface of it, it's JSX, that's how to translate this component, and that's what I think.
[00:36:16] What Qwik is able to bring is the niceness of React, but actually something drastically different in how it starts up.
00:36:24 - Christopher Burns
This is like my biggest question. It's like React, but completely different. Solid is like React but better. What is better, like React but better or like React but completely different?
00:36:37 - Adam Bradley
Yeah, that's a great question. React is like the components, how you write it, how it looks, the JSX, how you would do a for loop. Everything like that is very familiar. There wasn't a reinventing of anything in that world. So that's where I think Solid is right there too. It's very, very similar to React, uses signals instead of stores, and its reactivity is much, much better, built right into it. So on the surface, the DX is the same. Under the hood, it's entirely different because it can choose not to. It doesn't even choose. It doesn't run until you use something. Now there is prefetching and all that, so it's able to get all the modules that you probably use, and we're able to track which ones you're probably going to use. But for the most part, JavaScript isn't needed.
00:37:20 - Christopher Burns
I think it's a really interesting moment for sure.
00:37:23 - Anthony Campolo
Yeah, the entire Solid and Qwik world. It's like I talk to people who I'm friends with, a handful of people who are now working on both of these frameworks, and people who are very into the frameworks, and people who are very deep into them. And Solid's been around for like four years now. So there are people who get it and just obviously get why it's like the future and get why it's a huge improvement and why it's so much more performant and all this stuff.
But then I talk to like 99% of other developers. They've never even heard of these things and they don't even have a clue about them. So there's such a huge education gap with these frameworks and explaining to people how they work and why they're better. But I've really enjoyed getting to learn about them because they've helped me just understand what is a framework even doing. Because, you know, you learn React these days and you use React and it's just a black box and it works and it does the thing you want it to do.
But the fact that there are now frameworks that are offering similar benefits to the DX of React while also saying, hey, we've completely reworked the internals, so it's going to be better for XYZ reasons, that's really great. But I think people have a hard time wrapping their minds around why this is actually better, because they never really thought about the internals of these frameworks before.
00:38:36 - Adam Bradley
Yeah, and I think that's totally fair because, you know, a lot of people do start up their computers, start up React, and the app is just great, loads really fast on their computer, really fast when they do it on their phone. And so that's an honest question. It's like, what's the problem really? The problem we're trying to solve is the larger the app, the more components you add, the less it scales.
So there are certainly tricks you can do, you know, lazy loading and all the different things. Use useMemo. There's no shortage of tricks on the internet of how to make your React app a little bit faster. But as you add, let's say you've got 100 components on that page, it's going to be slow. It's going to have to load all of that component. It's going to have to re-render the entire tree at some point, no matter what you do. And I think the larger the app, the quicker you're going to see the issues, especially for someone like e-commerce where it really affects the bottom line. It affects the conversion rates quite a bit, especially if you know the faster the site.
[00:39:27] There's plenty of studies out there that show every 100 milliseconds, every whatever milliseconds you shave, the more your conversion rates go up. So that's kind of what we're trying to go towards, is really the people that do see this issue. Like if you use Create React App and create a blog, you're not going to see the problem. React is just fine. And to be honest, it is just fine at that point. But as it scales, everything you add to it is going to keep adding bloat to it. Whereas with Qwik, every component you add, no matter if you have one, zero, or 100, the startup time is going to be identical. And I think that's the big difference here for massive sites. You're going to see the difference, and that's when it's really going to matter, especially for e-commerce or product pages and things like that.
00:40:09 - Christopher Burns
I have really one final question to close this out on. It is what I would describe as Utopia PHP. It's Laravel that's like the final framework. Do you think we will arrive at that sometime soon with JavaScript and meta frameworks?
00:40:27 - short split/interjection
Yeah, we didn't even talk about.
00:40:28 - Anthony Campolo
Databases at all in this episode.
00:40:30 - Adam Bradley
Well, yeah. I mean, honestly, no, I go back to that car analogy. We've had car companies for a hundred years now and there are still Ford, Chevy, Toyota. And each of those companies, they have a whole spectrum of SUVs, trucks, big trucks, race cars, four doors.
00:40:47 - short split/interjection
I thought.
00:40:47 - Anthony Campolo
Tesla won. You told me Tesla didn't win.
00:40:50 - Adam Bradley
Right? Right. Tesla still has, you know, 1% of car sales. So yeah, I don't think there really ever will be one true winner in that aspect. And I think that's fine, to have those different flavors, because they're each going to be good at something. And I think that's fine. It would probably narrow down. There are certainly a thousand different frameworks out there, but there's really, you know, four or five that are practical that you would bring to your boss and your boss would say, yes, let's use that one. So I think that's kind of more of the line that it would be in. There's going to be a handful of ones that have, I guess, won.
00:41:20 - Christopher Burns
And do we have all of the tools in JavaScript today to get these frameworks to maturity, or do they still need more work?
00:41:30 - Adam Bradley
That's a great question. I remember saying two or three years ago that since 2017 I've been very happy. Since async/await and promises working awesome and ES modules, ES modules is a huge step forward. I'm actually quite happy. You know, everyone's just like, it'd be nice to have a certain trim feature or something like that, but they're all kind of there. We can argue for years about what other features we should add, but it's also kind of nice where we're at, even since Node 10. We've done actually quite well.
And I guess maybe it's just starting to make me sound like an old man, you know, yelling at the clouds, like, I think we're good. But, you know, since Node 10, it's supported classes. It's actually been a lot faster since Node 7.5. It's got ES modules natively. So I think that's going to be, it was behind a feature flag, I think, in 14. No, 14/18 is when ES modules kick in.
[00:42:23] What's the other big thing I'm waiting for? Fetch. Fetch inside of Node.
00:42:28 - Anthony Campolo
Yeah. Fetch is 18.18.
00:42:30 - Adam Bradley
That's the big, big one I'm waiting on. But really, I don't know. I'm pretty happy with where we're at compared to, you know, I've been developing since the late 90s. It's a huge difference.
00:42:41 - Anthony Campolo
Yeah. We didn't get your how-you-learned-to-code story. Actually, do you want to give that in like 30 seconds?
00:42:46 - Adam Bradley
How I learned to code: GeoCities and using HTML tags. That's how far back I go.
00:42:52 - Anthony Campolo
GeoCities. Yeah. You're not the first one to say that. You're probably the second or third person to say that.
00:42:56 - Adam Bradley
GeoCities, Notepad, viewing other people's source code and seeing how it works. Then I did CSS quite a bit. I actually did Photoshop. I was a designer before I did any sort of development, so I did Photoshop work for quite a while. College, got a job doing designer work, then got into websites and then slowly started learning JavaScript. And it's been all fun since then. Ever since jQuery, it's been all JavaScript.
00:43:19 - Christopher Burns
It's a fun time, and hopefully we'll get to the point where we don't need to compile TypeScript anymore. That's just native.
00:43:25 - Adam Bradley
Yeah, that's a thing now, right?
00:43:27 - Anthony Campolo
Does Qwik support TypeScript?
00:43:29 - Adam Bradley
Absolutely. Yes.
00:43:30 - Anthony Campolo
If not, Chris is not using it.
00:43:32 - Adam Bradley
So it's not tied to TypeScript. But all of our examples are TypeScript.
00:43:36 - Christopher Burns
There you go. Hey, all of my examples are TypeScript and [unclear]. Now, Anthony, it's the perfect combination.
00:43:42 - Anthony Campolo
Pretty good. It's pretty good. All right. Well, thank you so much, Adam. This is a really awesome episode. It has so many cool things to talk about. I know we've got some other people on your team that are on our schedule as well. So thank you to Builder for really putting their money where their mouth is and contributing to open source. The stuff you're all building is just incredible. So please let our listeners know where they can find you, where they can find these projects, and Builder.io online.
00:44:07 - Adam Bradley
Yeah. Thanks for having me. Basically, I'm on Twitter quite a bit, Adam D. Bradley on Twitter, and continuing to work on our GitHub projects at Builder.io.
00:44:17 - Christopher Burns
Very nice. I think that's about it for today's episode.
00:44:20 - Adam Bradley
Thanks for having me, guys. It's fun.
00:44:22 - Anthony Campolo
Yeah. Thank you.
00:44:52 - Christopher Burns
I would say it's still in its infancy.