When you make simple things simple, complex things become possible. When simple things are hard, complicated things become impossible.
In web development, we're not just crafting code; we're shaping the digital world's future. In this episode, we interview Misko Hevery, co-founder of Builder.io, about the landscape of web development and the cutting-edge Qwik framework. Misko starts by diving into Builder.io. Discover how it aims to bridge the gap between visual web content creation and developers' expertise, creating a win-win situation for both parties.
Moving on to the world of Qwik, Misko expounds on its unique approach of delivering components rather than JSON data, resulting in unparalleled user experiences. Explore how Qwik challenges the conventions of existing frameworks and offers a fresh perspective on web development. Throughout the episode, Misko also explores many topics, such as the sustainability of open source materials, what’s next for Builder.io, and more.
First of all, I'm laughing here because I have never been described as royalty. That is such brilliant stuff to say. I am Misko. I'm known for this thing called Angular and now for this thing called Qwik. I'm a CTO at Builder. Builder is a headless visual CMS. That's a lot of words so I like to break it out because when I first joined Builder, I didn’t know what these words meant either.
The headless part means that it's hosted on your infrastructure. If you think about Wix, it is hosted on their infrastructure, so you can't host it with yourself. The headless mean is hosted with you. The visual part means that it's a drag-and-drop. That's a rarity in the headless world. Most headless things are not drag and drop. You can think of a Builder like Wix, but it's hosted by you. It's an NPM install you do on your project.
We were laughing before we started this about old companies you work for. You were at Sun many years ago. It must have been an interesting place to be, like Adobe, Google, and Builder. The question I want to ask you is, why is Angular so popular in the .NET world?
I originally came from a Java background. I was a Java developer and a back-end developer. It’s a very C++ class-based object-oriented way. A lot of .NET people feel the same. For them, Angular was very OO-oriented and had dependence injection on all the things we’re familiar with, so this is why it became popular. The flip side of that is the React. The React world is very functional in its nature. Those are two different approaches to doing it.
Do you think that the language paradigms and things map more naturally? It's amazing. When we're talking to folk who are interested in Flagsmith, if they're running a .NET back end, 97% of them have an Angular single-page application. It's crazy.
It maps. What people are used to from their back end, they're like, “That's the same concepts, different syntax, or whatever,” but maps are well for them.
Full disclosure. I wrote a CMS in 1999. Me and my friend Matt are still long-time business partners who started selling in London. I've got a lot of background and history of content management systems and their design. It's been fascinating for me to see where they've almost ended up with headless being such a game-changing paradigm in that industry. How did you end up at Builder, and what's the story there?
I was in Google for a very long time. I like to joke that after sixteen years, if you decide you'll leave a company, you don't need to justify to anybody why you’re leaving. You either leave or you become institutionalized and you never leave. I enjoyed my time at Google a lot. I enjoyed the company and the people. It’s just that after sixteen years, you're like, “I need to try something else. Maybe this is the pinnacle of awesomeness but I need to know,” so I left.
I started talking to a lot of different people and exploring a lot of different options. The last thing I wanted to do was build another framework. In the process of exploring, I came across Steve, the CEO of Builder.io. He had this headless visual CMS, which is the Builder.io. He had a particular problem, and the problem he had was people build sites with Builder and they would say, “This site isn't performing very well.” Of course, they would place the blame on Builder. Builder was like, “It's actually not us. We do supercenter rendering a little stuff. This isn't us that's causing the cause.” People will say, “Show me a site built with Builder that performs.”
I pitched that to him and I had a prototype. Since Builder was able to easily generate any output, he easily switched it over to generate Qwik output. What he found was that this page performed just as well as HTML. He was hooked on it. We were chit-chatting about it for a while and said, “What would it take to make this a reality?” We think the world needs this. We think that the way we build sites is not scalable. We are essentially blaming the developer for a slow site. When the site is slow, we blame the developer, except that if you look around, they're all slow. It's a consistent output of all of our processes. I'm reading a book right now called The Design of Everyday Things.
It is probably one of the most important books in design.
The book makes a very good point. If there is a failure, you can blame a particular person for failing, but you’re failing to understand that that person is human and errors happen. Therefore, why is your system designed in a way that such an error results in a failure of the output? You should design your system in a way where people can make mistakes and it's still okay. The book makes a good point, which is that the failure of the system is a failure of a design, not blaming the person. If you have an airline pilot and he makes a mistake and the plane crashes, it's easy to say, “It's a human error.” Maybe you shouldn't have designed the plane the way where a single mistake would cause a catastrophic failure.
You should design your system in a way where people can make mistakes and it's still okay.
That’s an interesting answer. How many frameworks have you started in your career?
Too many. There are two that are well-known. There's AngularJS and Angular. Now there's Qwik. I guess it's a third one. There were a few others in before which nobody has ever heard of. There was this thing called Pagelet that was an internal project. For some reason, I can't stop doing this.
What Backbone was trying to achieve was an excellent goal. They were on the right track in terms of what they wanted to do. They, unfortunately, made it too complex in terms of what the developer had to do to get there. What Angular did well is it focused on making it super simple. When you make simple things simple, then complex things become possible. It's when the simple things are hard that complicated things become impossible.
When you make simple things simple, complex things become possible.
A little bit, especially with AngularJS. I wasn't trying to build something so popular. I mainly built something because I thought that the way we were building websites was too complex. I was like, “Can we simplify this?” We put this into AngularJS and we released it. It took off mainly because at that time, there were not much in terms of alternatives. The alternative was, as you pointed out, Backbone and AngularJS certainly predates React. In terms of alternatives, there was nothing else. It hit the spot and it made complicated apps possible. It took off for that reason.
How was Google building web applications at that time? Were Google Teams target users of the platform? Who did you have in mind when you were designing it?
There was no real templating system, etc. Over time, they added things like a templating system but originally, it wasn't designed this particular way. These were the early days when we didn't have frameworks. Even Google solved it by throwing a lot of people at the problem rather than trying to come up with scalable solutions. Angular was unique in that sense. It came out at the right time in the development of the web when there was a need. There wasn't an alternate solution, so it took off.
In terms of the governance of open source projects within Google at that time, the organization and you, was that something they were learning, or was it fairly well understood and used playbooks?
There were no playbooks. We open-sourced it. The open-source office at Google was formed after we open-source our stuff. There was a lot of learning going on. Now, Google has a lot of processes around what is open source and how to get it. Back in the day, it was a Wild West. A lot of the open-source office at Google these days was influenced by what Angular did in the early days.
Moving on to builder, how do you see the landscape at the moment? The single-page application frameworks seem to have coalesced down into a handful. Now, the thing that's gone back into this Cambrean explosion where the runtime is. I find the next framework interesting in that is constantly reinventing this idea of what the runtime is for your application. There was a pre-compiled step, a server-ended step potentially, and a client-side step, and now they've introduced edge workers and things like that. Is that a problem or an opportunity for an organization like Builder?
It's an opportunity. It's useful to look at the history of how we got here. If you look at the history, originally we were generating HTML using some back-end technology whether it was a Perl Script through CGI, PHP, or Java, it doesn't matter. Fundamentally, we were generating some HTML and sending it to the client and we had a round-trip application. The problem was we didn't have good interactivity. Things like jQuery came up to give us interactivity with the client and that created a problem. The problem was that you have two different languages. You have a language in the back end and front end.
There was this going back and forth, and the reason why most of these frameworks took off is because they offered a single language end to end. You could have a single language on the server, concatenate strings using one technology, and then another on the client render in another technology. You had one mental model or one code base. This is the reason why the world's took off. Fundamentally, what you're now doing is you're building fully client-side rendered applications. Everything is happening in a client. There's this huge delay from the moment you see the wide screen to the moment you can interact.
Over the years, we've been trying to fix this wide delay by saying, “Let's pre-render an image on a server and do service-side pre-rendering.” Those are all different workarounds for this particular problem. It didn't change the mental model, which is that the app runs fully on the client. If you look at these days’ frameworks, they all fall into this category, they're fully client-side rendered systems with a sprinkle of server-side pre-rendering.
What Qwik does is, “Let's go back to this mental model of rendering things on a server, and then only adding reactivity or interactivity on the client where it's needed. If there is something that is needed, don't ship it.” You essentially go back to the PHP days in that sense. The big difference is it's a single unified mental model. It's the same language and the same way to think about it. You don't think about it as this is the front end and this is the back end. It's my app that happens to begin its life on a server and then finish its life on the client.
This is why we oftentimes talk about this idea of a unified execution model. We are trying to unify the back-end virtual machine and the front-end virtual machine. As a developer, you shouldn't think about it. It's a straight execution for you. You build your app the way you would normally build, thinking that it's a single virtual machine where it executes but the framework does the magic underneath and moves things around as needed.
That is an ugly thing over there. It’s like, “Don't touch it. It's fine. Move on with your life.” That is not the reason why you are having a hard time building an app. The people who are constantly trying to replace the language in the browser have this idea that, “If we only had a better language, we would have an easier time building an app.” There's the other set of people that is in my category who say, “The issue isn't the language. The issue is the abstractions that we put on the language.” We don't have a good mental model of what a web app should be and how it should be built. This problem sits way above the language so the language is irrelevant to this.
Also, the tooling has come along so far. Thinking back to what you mentioned, Google Web Toolkit, which I haven't thought about for quite some time. There are colleagues of mine who write React native applications or Next.JS applications and you look at the developer experience when you're writing those applications now is completely amazing. The ITs and the debuggers and things like that compared to what people are used to in the Backbone or jQuery days. It's quite a different experience now.
Over time, we have “use strict” that you can place on top of the file to tell the VM that certain things are not allowed. We're going to have more tags like that, which will further constrain the language and slowly take away the words. I don't think the words are the problem. They're fun to make. They make good videos and easy threads on Twitter to make fun of. In real day-to-day life, it's not the reason why you are having trouble with your app.
The asynchronous nature of it, which for me, is someone old enough to have been brought up on synchronous languages. That’s always the bullet that I shoot my foot with. Those are hard problems when you have to write for an interactive platform as well.
We got better over time. In the beginning, there was the Callback Hell. I don't know if you remember those days. We created Promises and added Async/Await, and now we are writing a synchronous code. It is nice. Here's an Async and Await. You don't have to think about it, and it works. The language is evolving and it's getting better.
The programming language is evolving and getting better.
There are two fairly large open-source projects related to Builder. There's Qwik and Builder itself. What are you spending your time working on at the moment?
I don't think Builder is an open-source. Builder is definitely closed-sourced and it is the thing we sell and makes money. There are two ideas. One is we want to make the world a better place. The world needs a better framework. This is what Qwik is and this is what we are working on, also what Party Town is. Also, we're using it as a form of marketing. We're using it to create awareness for people to say, “This is who Builder.io is.” Maybe one day you'll need a visual, a headless CMS, in which case, we want you to think about Builder.io.
How do we do that? We want to make sure that Builder is always top of mind. We offer, have blog posts, and talk about all the things for making the web faster because that's what everybody needs. It's actually what we are passionate about when we want to do it. We're not just talking about making the web faster but actively working on creating technologies to make the web faster. We are creating awareness around developers. I like to joke that the Qwik open-source thing is a form of marketing. It is marketing in the sense that it is needed. We're doing it genuinely out of our passion for making the web a better place. We think that is a better way of building web apps.
Were you influenced in any way by the success of what was ZEIT that is now Vercel because they seem to have quite a similar paradigm in that regard?
They have a similar paradigm. They give away Next.js for free. At some point, you have to host it and you say, “Who do I host it with?” You might as well go with Vercel. You don't have to, but you might as well. It's an important paradigm because open source has a lot of trouble monetizing itself. A lot of times, people look at the monetization of open source as it's horrible and it's not free. Somebody's got to pay me at the end of the day so that I can put food on the table and put my kids through college. It can't be all free. The money has to come from somewhere.
The open source in this regard has come a little too far and it's a little problematic because we don't have a good way of monetizing it and paying for all its development. It's the goodwill of people but that can only go so far. Let's say you’re Google and you're like, “This is an amazing open-source project, and I want to support this.” Who do you pay? How do you even do this? We need this idea of open source like, “I'm passionate about something. I would like to work on it.” At the same time, if you're a corporation and you are getting a lot of value out of this particular thing, there should be a way for you to contribute back to some big bucket. Distribute it around the world to people who put the time and effort into doing it. As of right now, there isn't that a mechanism.
I like what Vercel is doing because it shows you can have both worlds. You can have a way where you're building useful stuff in an open way that people can use, but at the same time, you're building in a way where it's sustainable and they have a way to pay and justify paying people to work on it. Open source would be a lot further along if we were able to pay for the people who are working on it.
I do agree, especially, where frameworks are concerned, which historically has been very hard to monetize. If you look at Angular, React, or Next, they've all got either monster-sized companies behind them or very successful well-funded scale-ups. Did Google ever spend any time trying to figure out ways to solve that problem? I would never expect a college student or something to start paying $0.03 a month to Qwik or whatever. As I said, a huge number of our customers use Angular and .NET. That problem seems stubbornly unsolved up until now.
It continues to be unsolved and I think it's a problem. Google doesn't have any effort to do this. There are a lot of people who don't see the value of open source, and that was at Google. I don't think Google internally supported Angular as much as it should have. If anything, you can make an argument that the Angular team has made huge progress even though they weren't supported as much as they should have been. It comes down to the fact that the passion of the people that made Angular successful, and these people just happened to be working at Google and Google was like, “You're building this product and we're using it internally, so I guess we might as well pay you because 2/3 of internal apps at Google are running Angular.”
There's an incentive to develop this. If anything, people at Google looked at it. Most people, not everybody, but some people got it. Many people looked at it as, “You can throw it over the wall and make it open source, but you're working on this because we need it to support all these apps.” I don't think that's the right way of looking at it. Unfortunately, we don't have a better system now. Part of it is self-inflicted because developers are so stubborn about paying for things. I get it. It's fine, but at the same time, this stubbornness can translate to corporations.
As a developer, you don't need me to pay you anything for using whatever. That's fine. I don't have an issue. If you become a corporation and you are now making billions of dollars out of this thing, maybe you should consider, “We should support this because we're getting a huge amount of value out of this.” The fact that the person on the other end is doing it purely out of passion is not fair because they have to put kids through school at some point. Open source could benefit from a more structured way. The problem right now is there isn't even a way. As I said, if Google decided they wanted to contribute back, what exactly would they do? Who exactly would they make a check to?
The thing is, they like writing checks for $100,000. If it’s like, “We need $500 for this guy.”
If there were a foundation, it would say, “You're using a lot of our software. I think you should contribute back whatever you think is fair. I'm not telling you how much to give. You give whatever.” I see Google being like, “We get lots of values. Let me send a couple of millions your way.” The foundation can look at all this stuff and say, “We need to invest whatever.” That is relatively straightforward because of the single transaction that Google would have to do, and therefore, the accounting systems would work, except there is no such thing now. Who exactly would Google make out this big check to? I'm not picking up Google, but any company like Facebook, Microsoft, or wherever you want.
It does seem a shame because it’s evident that these tools, Frameworks, and languages require huge sums of money for the sponsor company, which makes it very hard for them to flourish outside of those entities.
Builder is paying for four engineers to work on open source only and we have to justify this to our VCs. Our justification right now is, “This open-source work is creating awareness, which is turning into signups.” There should be a better way to do this. You shouldn't have to go through these convoluted steps to justify and creating value for the world and paying people for the hard work that they're putting in.
Let's come back onto Qwik. Where do you see things going in the world of Qwik and Next and stuff? I'm an outsider looking in and haven't ever been a front-end engineer. I wouldn't call it an explosion of complexity, but you seem to need to hold in your head these frameworks. Do you think they're going to carry on moving in that direction, or there's going to be more of a move back to simplifying things down?
Interestingly, you're saying that you have to keep a lot in your head because the reason we use frameworks is to simplify our mental model of the world. The alternative to not using a framework is to talk directly to the browser. That's so much more effort that everybody sees the value of a framework. It's interesting that you're framing it that way because I look at it the exact opposite. The job of the framework is to simplify the mental model for the developer. Originally, frameworks were used for templating. Over time, the frameworks can do CSS, animations, and state management. They've got more problems that they are solving. They've expanded their scope. Certainly, with that comes complexity, but I wouldn't say that they're getting more complicated.
The reason we use frameworks is to simplify our mental model of the world.
You’re right. If you deploy a Next application on Vercel and you're running on this global edge network with replicated caching and all this stuff.
It's certainly more complicated than deploying a CGI script but look what you're getting in return.
We've got edge computing. CloudFlare and Vercel are providing edge data storage, edge caching, and things like that. I'm wondering if there doesn't need to be too much moral delivered on that infrastructure side. There's probably not a huge amount that you'd need.
This is where we reached a limit. If you look at all the frameworks that are out there, whether it's Angular, React, Svelte, Vue, or Solid, they certainly bring incremental innovations with them, but they all fundamentally work the same way, and therefore they have the same set of limitations. This is where Qwik is different. It’s like, “Can we reexamine the fundamental ideas of how a framework should work and then try it from this angle?” If you look at it from the DX, a Qwik looks extremely similar to React or Solid. You might argue, “If it's similar to DX, why bother?” It's the same output.
Coming back to Builder, what's next for Builder?
Builder is in its growth phase. We have a product. We find that there's a really good market fit. Once we find a customer, the customers usually buy so we have a high conversion rate. That all says that there's a problem that needs to be solved. We have a product that solves the problem and customers like the problem we solve. Builder is at the stage where we have to scale it. We have this product that solves this customer's problem. We need to get awareness. Most people say, “I need headless CMS.” They don't think of Builder or they don't even realize that there's a visual option.
They know there's a visual option in the hosted space but they know that they can't have hosted. They assume that they have to choose from this non-visual selection that exists. For Builder to come in and say, “You can have visual, you can have drag and drop, and you can use the existing components that the developers create inside of the marketing campaigns.” That also reimagines how the CMS system works at the lowest level. If you look at all the other headless visual systems, the way they work is that the CMS system hands over a JSON to your application and then your application is responsible for data binding that JSON into the correct locations.
Of course, every company adds its own value on top of it, etc. That's the fundamental model of how it works. Builder.io is different. Builder doesn't work this particular way because what Builder gives you doesn't give you JSON. You can get JSON if you want, but what you get back out of Builder with a set of components that you insert into your application. Everybody else is giving you a JSON that you’re responsible for inserting the application using your own data. Builder is coming out and it's like, “No. You have a React app. Let me give you a React component representing this UI. If you have a Qwik app, let me give you a Qwik component representing this thing.” It's a very different mental model, and it has huge implications for what you can build.
That's super interesting. I'm trying to figure out how you manage such a large broad spread of frameworks.
This is why Mitosis exists. Mitosis is a code generator. Into the Mitosis, you input something, either a JSON or a Mitosis, which is the semi-framework key thing. The output of Mitosis is an Angular app, React app, Vue app, Svelte app, Solid app, Qwik app, Pure HTML, web components, whatever you want. This is the only way to do this. If Builder wants to be in the business of, “We don't give you JSON, we give you components,” then we have to give you components for whatever framework technology you happen to have. If we only were able to give you a React component, we could only really work with React applications.
We need a way of saying like, “Whatever technology you happen to be using, we can give you whatever you want.” That's achieved through Mitosis. Mitosis is a code generator which you input what you want and your output of it is canonical. If you look at what comes out of Mitosis, it's what a human would write. It's indistinguishable. At any point, you can say eject. Take whatever the output is and that's going to become our source code. You could always leave. It's not tightly bound, which is a nice property.
Misko, where's the best place for people who want to contribute, get involved in Qwik, join that community, or find out more about you? Where's the best place for them to go?
The place to start is on our homepage, which is Qwik.builder.io. In the upper right corner, you can have links to take you to GitHub, Discord, and Twitter. Discord is the primary place where the community hangs out and answers each other questions. To get into it, Discord is the place.
Thank you for having me.
Hello, I am the creator of Angular (http://angular.io) Open source web framework used and loved by millions of developers. I am also known for zone.js, and I help co-create karma (https://karma-runner.github.io/)