Builder.io Interview | Craft of Open Source Podcast

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.

---

I have with me a piece of JavaScript royalty here, Misko Hevery is joining us. I don't know where to start in terms of introducing you. You've got a very interesting career. Maybe you introduce yourself and give us a little bit of background on Builder.io.

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.”

The thing that Builder has that's unique is that he knows how to generate output for any framework you have. It generates output for Angular, Qwik, Reacts, or whatever you have. It's very trivial for the Builder to generate different outputs. What we found is no matter what output you generated, some were better than others, but they all didn't perform that well. The only way to get the site to perform amazingly well is to generate pure HTML. If you generate HTML, the site performs amazingly. If you generate any JavaScript, and it doesn't matter which framework you use, the site doesn't perform that well. No matter what you do, it's really hard to get a good score.

This is the dilemma that Steve was in when he met me. We chatted about it and I said, “I'm working on this crazy idea in my free time. How about we don't ship JavaScript until it's actually needed?” All the other Frameworks basically ship JavaScript up front, execute the JavaScript up front, and then the page becomes interactive. The idea behind Qwik was like, “How about we don't ship any JavaScript? It's only when you go and try to interact with the page. Only then, we download the JavaScript and make it interactive.” There are all kinds of tricks to make sure that when you download the JavaScript, there's no network delay, etc. so it's a bit more complicated.

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.

This is where we are with frameworks. It is so easy to end up failing in our product. This is where we came in with Steve and we said, “Can we do something here in this area?” We joined forces and started working on this thing and the idea is that a lot of people need to build landing pages, home pages, etc. This is where Builder CMS comes in as a unique differentiator because it's visual and a drag-and-drop tool that is unique in a headless space. On top of that, the other difference would be we can do amazingly good output because we can use this delayed execution of JavaScript rather than eager execution like everybody else is using. That was a lot.

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.

In terms of the history and the widespread adoption of Angular, I remember quite clearly that there was Backbone.js in the jQuery days. It’s those days when Gmail had been released and people were trying to release it. We, as an agency, are trying to build an interactive single-page application. The tooling was terrible. I remember every project we built in Backbone, which is probably partly our fault, eventually became completely unmaintainable. There was what we call a second or third wave of frameworks, which Angular is one where the size of the application wasn't a strong correlation of how likely it was to all end in disaster. What were the things that influenced you and that were in your mind when you sat down and thought, “I'm going to write a JavaScript framework?”

I didn't originally start to write a JavaScript framework for the developers. The original idea was to make it for people who do not necessarily know how to code like a web designer but know a sufficient amount of HTML. Could we extend the vocabulary of HTML to give them the ability to build trivial applications? The fact that I came at it from this angle was part of the success. Since I came from this angle of not necessarily a programmer, there was a strong need to simplify the complexity of the framework. The goal was always like, “This thing has to be simple for somebody who's not a developer.” When you come at it from this mindset, you don't build a complex thing such as Backbone.

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.

My background was server-side programming and then server-based webpages. Even a discussion about developing sites in React is crazy how many paradigms you need to have in your head. Whereas when I'm building little toy things for myself because I don't have the time to learn all that stuff. It used to be what is now called HTMX, which couldn't be any simpler. Most of the time, you write no JavaScript whatsoever. It's amazing to me how two things that are doing pretty much the same thing can be so radically different in their levels of complexity and approach. The derivative is interesting to me that React is an Angular to a degree as well. It’s well-adapted and popular. Was that a surprise to you when that started to happen?

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?

My app is what I had in mind. At that time, there was Gmail, and Gmail was certainly built with JavaScript but there was no framework. They had what was called the Closure Compiler and the Closure Library. I know that's the same name for two different things. It's confusing but the library was mainly a set of rigid rather than a framework or anything of that. Gmail was built so that the developer would literally manipulate the DOM elements individually to get the desired outcome.

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.

Since you have two different languages, you have to have two different experts. You now have a split between a back-end and a front-end person. The worst thing is that oftentimes, you have to implement the same thing twice. This is a form that validates the user. They have to generate the form on a server. On the client, if you add another contact to your list, then we want to render it on a client. Now you have to do the same thing on the client using JavaScript and a different language.

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.

This is why Qwik is so different because Qwik fundamentally says, “I think this isn't the right thing. The mental model of pre-generating the HTML on a server and then only adding interactivity where it was needed on the client was correct. The issue was that the mental model had two different languages. They didn't enjoy it.” It's not that PHP in any way is a problem. It's a great language, a great tool, great everything. The issue is that PHP is not on the browser. If the PHP were on a browser, then the world would be great, but it isn't. The browser has JavaScript. How do you bridge this difference between the back end and the client when you have two different languages?

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.

Was there ever talk within Google about potentially having different language runtimes as part of Chrome or anything? How JavaScript ended up in the browser is crazy. It's completely nuts. The language was designed in four weeks or something.

It was an intern at Netscape or whatever it was in Mozilla. Google did make many efforts to replace JavaScript with a different, better one. The most notable effort was Dart. Before that, there was a Google Web toolkit, if you remember that, which is in Java. You could make a very good argument that Java is a better language than JavaScript because JavaScript has lots of words. You can make a very good argument that Dart is a better language than JavaScript. The problem is that JavaScript has words and we all like to make fun of different weirdnesses of JavaScript. This is not the reason why you're having trouble building an app.

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.

Google, over the years, had many attempts to replace it. As I said, Google Web Toolkit, and then the latest was Dart. They all fundamentally failed because they didn’t create a sufficiently better experience. It's marginally better, but the real problem is that it's a semantic difference between the way the previous language and the current language works. Semantic differences are extremely difficult to bridge using some kind of transpiler. This is why TypeScript is so amazing because the TypeScript team says, “JavaScript is what it is. It has its words. We love it the way it is. We want to add the missing part, which is the types.”

They didn't try to change JavaScript or make it into something else. They said, “We're adding types and we're at taking and loving the language for what it is.” That was the big difference why TypeScript fundamentally succeeded, whereas Dart and Google Web Toolkit did not because they came out of it from the angle of, “JavaScript sucks and it needs to be replaced.” That’s not a good way to come at the problem. At the end of the day, I don't think it matters that much. The problem is somewhere else. A better language would be nice. Is it worth the trouble of replacing it? Probably not.

I find that interesting. JavaScript is a language that is very flexible, and you can do some crazy things with it. Whether that's by design or by accident or what have you. Let's say, in a different version of reality, that the Netscape intern sat down and implemented Java as the browser runtime. Maybe that would've been replaced. TypeScript can be written on top of a transpile or compiled down or whatever trick you use to do that with JavaScript. The language lends itself to that tooling. I wonder if it had been a less flexible language.

I don't think so. Fundamentally, you can build anything in any language you want. The difference between a well-fitted language and not a well-fitted language is how much you are going to enjoy yourself as a developer and how hard is it going to be for you. It isn't going to be ever a limitation of, “You can't do that. You can't build this app in that language.” The thing that JavaScript has going for it is it's a standard because it's in all browsers.

‍

The effort to replace JavaScript with something else is so monumental that whatever comes on the other side better be an amazing improvement over what it is. The problem is all languages are the same. Some are better than others and some are more enjoyable to read than others. Are they so much better to justify this monumental task of replacing it on the web? That I don't think is the case. There isn't any one language that is sufficiently better to justify this effort.

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.

With Meta frameworks, we expanded the scope a lot but it's the right thing. These problems need to be solved somehow. The fact that Meta framework solved them is good. The way I look at all existing frameworks is that they're fundamentally the same in the sense that they're all client-side rendered. They have a particular mental model associated with them. Since they have the same mental model, the only differentiation between them is the syntax. Do you like JSX or Svelte file that is HTML first versus JavaScript first? Those are trade-offs that a developer makes but it doesn't change the capabilities of what you can build, how you build it, or your mental model of how the thing works.

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.

The difference is that the UX is not the same. What the user gets is vastly different. We don't ship all the JavaScript all at once, so it's worth exploring this space. Qwik is one of the first ones who look at it from the lowest level and say, “Is this the right mental model or should we look at it differently?” Qwik, with its resumability, says it's a different way of looking at it. We think it's a preferred and better and has nicer properties.

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.

Misko, thanks for your time. That's been super interesting. I feel like I've gone back through a museum of JavaScript. Thank you so much.

Thank you for having me.

‍

Important Links

• Builder.io
• Angular
• Qwik
• React
• The Design of Everyday Things
• AngularJS
• Vercel