Misko Hevery is the CTO of Builder, the online visual site designer. He is also the creator of Qwik, a next-generation JavaScript framework. Before his Builder and Qwik days, Hevery created Angular, one of the flagship JavaScript frameworks, and Karma, the popular JavaScript test runner.
Clearly Hevery has a long history of involvement in the JavaScript world. I had a chance to talk with him about Qwik, Builder, reactivity challenges, speeding up web apps, helping content creators and engineers coexist, and more.
Matthew Tyson: I’m excited to talk to you. I discovered Qwik, and that led me to Builder and your bio. You have a really interesting history, including the creation of both Karma and Angular, so I’m eager to hear what you think about some of the latest JavaScript trends.
Let’s start with reactivity. Reactivity is one of the most significant developments in front-end code, but it is not a perfect world.
Misko Hevery: It is complicated. Reactivity has many great properties, but also many problems. The basic issue with reactivity is that it requires a lot of compute resources to set up and then to tear down. This negatively affects the performance and memory utilization. The implication of all of this is that a framework must download all of the application before reactivity works.
Qwik needs to be reactive, because we want to be lazy, but at the same time we need an approach to reactivity which allows the framework to reason about the application without loading it. Qwik does this by storing reactive subscription information in the DOM.
I would love to know more about how you discovered Qwik so that more people can do the same.
Tyson: I became aware of Qwik by watching Rich Harris’s recent Jamstack Conf presentation. He describes how several projects attempt to address the shortcomings of reactive frameworks.
Hevery: Thank you, Rich!
Tyson: Qwik is a rethinking of reactivity from first principles. It’s really interesting how you have kind of enabled app construction with built-in lazy-loading boundaries. How did you become motivated to do this and arrive at this approach?
Hevery: So the idea actually came from my talk at ng-conf a few years back. There I basically described what today is Qwik. I kept seeing other frameworks basically rehashing the same old problems, and none of the frameworks seem to address the elephant in the room. They all seem to treat lazy loading as an afterthought, and I wanted to change that.
I set a goal of having a fully lazy-loadable system and worked backward to see what kind of framework I could build which would satisfy these constraints. Most frameworks care about framework size, but not application size. Application size is not “their problem.” I wanted a framework which specifically addresses the application size problem. Any real-world application is orders of magnitude bigger than the framework, so that is what we should be focusing on.
Tyson: Interesting!
So you are the CTO of Builder as well as the creator of Qwik. Builder is an impressive WYSIWYG editor. Does it use Qwik under the hood?
Hevery: We are about to release our new home page which will showcase all of the latest which Qwik has to offer. It will only load HTML above the fold, lazy load interactivity, and run all of the third-party scripts in the web worker. Our goal is to get 100/100 on Google PageSpeed and show that e-commerce sites can be fast.
Our home page is being built on top of Qwik, and as soon as we release it we will be able to offer the same capability to our customers. So we will be providing Qwik as both an open source project and as a service for making blazing fast e-commerce sites.
Tyson: Builder allows you to pick a variety of frameworks for output from the visual designer (React, Vue, etc.). I imagine Qwik will be another output option in the future?
Hevery: Yes, we already have Qwik working with Builder and soon it will be available to all of our customers.
Tyson: Is having multiple export targets as tough a technical challenge as it sounds?
Hevery: That is solved by Mitosis. Mitosis is a project which allows you to write a component once and then export it to all of the common web frameworks. This gives you “write once run anywhere” capabilities.
Tyson: Qwik allows you to build an app with boundaries at resource, state, and event handlers. This means the app can achieve fine-grained control of what is loaded. Is that a fair description?
Hevery: Yes! Qwik needed to solve several hard technical challenges which other frameworks simply ignore.
First, how do you break up large applications into many small lazy-loadable chunks? This is harder than it sounds, because at the time of writing the application you don’t know where the best lazy-loaded boundaries are. Only after running the application and observing real-world usage can you determine which features are used the most.
Second, the framework must not require that all of the visible components on the page be downloaded and executed. This is what all existing frameworks require: If you see a component, then you must download and execute all of its code before you can make it interactive.
Third, the framework must serialize all of the event listeners into HTML. Without this all of the application’s templates need to be downloaded eagerly.
Fourth, the framework must serialize data relationships between components (reactivity). Without this any mutation of state would require that the whole application be downloaded and executed.
Tyson: That is really a helpful breakdown. It captures where much of the action in the world of JavaScript is happening right now.
Can you describe a bit about what you mean by Qwik being “resumable”?
Hevery: Perhaps this demo can better explain it? But the basic idea is that the state of the application is serialized into HTML and therefore the framework can continue execution where the server left off. The big advantage of this is that the client does not have to redo all of the work which the server just did. This makes client startup instantaneous and greatly adds to the user experience of the application. Because Qwik only loads code for the component when the component needs to be mutated, the static section of the site will never have their code downloaded.
Tyson: Qwik is in early releases (although it is able to demonstrate all the core ideas). What areas are you most focused on advancing to arrive at a 1.0 drop?
Hevery: We are intentionally trying to keep the first release minimal. The key feature is the optimizer that enables Qwik to break up your application into a lot of fine-grained lazy-loading chunks. As you can imagine, the optimizer design is quite tricky, but it is the thing that enables all of the Qwik magic. So for 1.0 we just want to have a way to build an end-to-end app and show fine-grained lazy loading as never seen before.
Tyson: What is the relationship between Qwik’s take on app construction and the builder/bundler?
Hevery: We want to be able to create the fastest possible sites for our customers, and Qwik is the way to get there. Because most of our customers are in the e-commerce space, speed is something which directly impacts conversion and hence revenue.
Tyson: Is there anything else you want to touch on?
Hevery: A key part of the Qwik strategy is Partytown. Qwik can make your application fast, but it turns out third-party scripts can completely destroy all of the performance which Qwik worked so hard to create.
For this reason Qwik not only needs to make your app start up fast, but it also needs to offload all of the third-party scripts to web workers to maintain fast performance. Partytown does just that. It allows you to have your cake and eat it too, by creating an environment in the web worker which can execute the scripts, leaving the main thread for the user.
Tyson: Wow, interesting, I wasn’t aware of Partytown. A framework to run expensive scripts in a worker thread... It sounds like it could make a huge impact across all kinds of apps. It kind of reminds me of the ability in Astro to hydrate a component once the thread is idle.
Are you guys using Partytown in Builder?
Hevery: Yes, Partytown is a key piece of the strategy. Without Partytown it would not be possible to showcase 100/100 on Google PageSpeed for our sites.
Tyson: Builder is useful for marketing folks, to enable them to build sites without tech knowledge, but you also feature a lot of support for developers. Would you talk a bit about what makes Builder compelling for the coders out there?
Hevery: Actually, Builder is useful for both content creators as well as software engineers. Content creators want to constantly tweak things, and engineering just wants to build new features. The two groups have different release schedules. Marketing wants things to go live at midnight on Black Friday, and engineering just wants to release things (not on Fridays so that any surprises will not destroy their weekend). So the tool really allows for the two groups of people to coexist in a more complementary way.
Tyson: Hah! Those are some funny and true-to-life observations about software development.
Besides improved tooling like Builder, how do you try to balance the demands of the business side and the engineering side from the CTO seat?
Hevery: Haha, not sure I balance! But yes I try to break my week into three days focusing on business and two days focusing on coding. You need to have clear separation otherwise you get sucked into a black hole and you never come out.
Tyson: Is there a way to take an export from Builder and modify the code by hand, then import it into Builder and edit it again with the designer?
Hevery: Yes, we have both importers and exporters. HTML is just one of many formats we support. For example, one can create a design in Figma, and then import it into Builder. Similarly, we can take an HTML site and push it to Figma for creative folks to improve it, so there are quite a few import/export choices available.
Tyson: Fair enough!
I noticed there are several data integration options in Builder, for consuming data stores and APIs. Can you tell folks a bit about them?
Hevery: People think of Builder as a drag-and-drop UI editor. But in reality, it is a lot more. The key aha moment with Builder is when developers and content creators realize that they can drag their own components into the page.
The components have inputs/props and so Builder also understands data binding. Where does the data come from? Well, the integrations listed there show you all of the places where you can get data from. For example, your catalog comes from Shopify but you feed it into your custom components.
Tyson: Would you say that Builder is moving towards becoming a full-blown web IDE? I noticed you have introduced inline code editing as a beta feature.
Hevery: I don’t think that is accurate. IDEs require a lot of things that Builder does not have, nor does it need, so I don’t think that is a correct characterization.
I would say that Builder only does as much as is needed by creative folks to do their job in a way that fits well with the engineering development lifecycle. For that you don’t need a full IDE.
Tyson: I am looking forward to seeing where you and the Builder team take the editor. And as a coder, I can’t wait to get my hands on Qwik 1.0.
Thanks again for your time, Misko.