If you’re familiar with building websites, you know teams must walk a tightrope between performance and user experience. While JavaScript adds rich interactivity to a page, it often comes at the expense of speed. Miško Hevery, the creator of Angular and now CTO of Builder.io, is providing tools to change that.
Broadcasting from All Things Open, Hevery joins us on the Open at Intel podcast to talk about Builder.io and the open source project Qwik. Together, these initiatives are making it easy to deliver websites that are both beautiful and performant—and they’re helping marketing and developer teams get along in the process.
Listen to the full episode here. This conversation has been edited and condensed for brevity and clarity.
Balancing Performance and Speed
Katherine Druckman: Most people probably know you as the creator of Angular, but you’re currently the CTO of Builder.io. Will you tell us about Builder.io?
Miško Hevery: Builder.io is a headless, visual content management system (CMS). What’s unique about Builder.io is that it’s a drag-and-drop editor, like Wix. Wix is awesome—you can build whatever you want, but you have to host it on Wix. If you have an existing system that you want to add drag-and-drop capability to, you’re out of luck. Builder.io adds drag-and-drop capability on top of your existing application, such as a React, Angular, or Vue project. You can designate areas that marketing teams have the power to change, so they can go wild. This allows the creative folks to do what they do, such as A/B testing or scheduling changes, and engineers to focus on what they do. Engineers can also create a design system, which the creative folks can drag and drop as well. So, it’s a mixed environment, which is different from traditional headless CMSs where you can only control the text or a field.
Katherine Druckman: I’d love to dive into Qwik. Can you tell us how that came about?
Miško Hevery: When I built Angular, it was one of the first component-based, front-end frameworks for building web applications. Angular spawned many derivatives, but I’d argue they all fundamentally work the same way, in that they’re client-side-rendered first, and the server-side rendering is an afterthought. Because of that, they all suffer from hydration. Hydration means that, on the initial page load, the application has to reinitialize the client to become interactive—so the more complicated your page, the slower and the more expensive hydration becomes. That affects startup performance. Qwik looks just like other frameworks, so you don’t have to learn anything new to use it, but underneath it works very differently. Specifically, Qwik doesn’t have hydration. No matter how complicated your landing page is, the start-up cost is always the same, which is about one kilobyte of minified bootstrap up front, and everything else is lazy loading.
Everybody says if your application is big, you should use lazy load, but it turns out lazy load is much harder than it seems. Qwik says lazy loading shouldn’t be a problem for the developer—it should be a problem for the framework. In Qwik, you don’t need to think about lazy loading or how to break up your application. The framework does this out of the box. It shreds your application into tiny pieces and observes how people actually use it. Based on that, the framework generates the correct bundles—so users have the least amount of code to download—and then prioritizes the correct order to download them. For example, high-priority bundles like a “buy” button download first, while a “contact us” button that few people click on downloads last.
Katherine Druckman: I want to drill down on the performance angle. Back when I ran a website for Linux Journal, a substantial portion of the audience would disable JavaScript in the browser to increase site speed. In today’s world, most people want a fancy website with a lot of great features, interactivity, and all the things that JavaScript frameworks provide. But just like security, performance is something you want to address early on in your project—it shouldn’t be something you apply a Band-Aid to later. How do you approach this conversation?
Miško Hevery: You nailed it. Your site will be faster without JavaScript, but it’s not going to be very interesting. The problem is that, with hydration, we’re in this world of all or nothing—either all of a page’s JavaScript shows up or none of it. Qwik focuses on downloading only the JavaScript that is going to be executed immediately. There’s a thousand ways you can interact with the page, but as a user, you can only do one thing at a time. So why are these other 999 things being downloaded and prepared? Qwik provides a fully automatic way to fix this. You write your application the same way you always do, and Qwik breaks it all up and keeps statistics on which parts you actually need and which parts can be delayed. All of that works out of the box. There’s nothing that you, as a developer, have to do.
Katherine Druckman: Did you have a use case in mind when you created Qwik?
Miško Hevery: The primary use case for Qwik was e-commerce websites. When a user lands on a page—especially when they’re on a mobile device or their network’s slow—if they try to click on a button but it takes seconds before they can click on it, they may click it multiple times and end up with multiple items in their shopping cart. It’s just a bad experience. Qwik was designed to simplify this and make it fast. And by the way, Google cares about this. Google Core Web Vitals measures and ranks your site based on performance. If there are two identical websites, the one that has better performance will be ranked higher by Google. So there’s a business incentive to make sure your website is fast.
Bringing Engineers and Marketers Together
Katherine Druckman: What else are you really excited about in the open source world?
Miško Hevery: Let’s talk about AI. One of the big problems we see is that creative folks create beautiful websites in Figma or another tool, and they hand it over to the engineer to convert it into something that works in the browser. That means the engineer must spend a lot of time with things like CSS and groupings. Builder.io has created this new thing called Visual Copilot that allows you take a Figma design and click a button, and AI figures out things like groupings and CSS styles to transform it into our internal format called Mitosis. Mitosis can then spit out whatever framework or output you want. Not only that, but the output is responsive. So, you can create a fixed design in Figma and push a button, and on the other side is actual code you can use inside your CMS or projects, and it’s responsive with all styles applied to it. And because it’s AI, it also takes a good stab at giving things correct semantic meaning, such as identifying hero, header, and footer components.
Katherine Druckman: That sounds like magic. If we can allow the creative people to focus on the creative and the engineers to focus on engineering, that eliminates some of the misery between them.
Miško Hevery: Qwik and Builder.io are all about bringing the creative and engineering folks together. In the past, there was some friction between them. As an engineer, you want to build cool things. As a marketing or creative person, you want to optimize the heck out of it. Wouldn’t it be better if each group had the correct set of tools to be productive?
To hear more of this conversation and others, subscribe to the Open at Intel podcast:
- openatintel.podbean.com
- Google Podcasts
- Apple Podcasts
- Spotify
- Amazon Music
- Your favorite podcast player (RSS)
About the Author
Katherine Druckman, Open Source Evangelist, Intel
Katherine Druckman, an Intel open source evangelist, hosts the podcasts Open at Intel, Reality 2.0, and FLOSS Weekly. A security and privacy advocate, software engineer, and former digital director of Linux Journal, she’s a longtime champion of open source and open standards.