Miško Hevery, creator of Angular and longtime Googler, tells Ben about building the future of web applications in his new role as CTO of Builder.io.
Angular is an open-source web framework used by millions of developers. Explore the Angular community.
Miško is currently CTO at Builder, an API-driven, drag-and-drop headless CMS with a visual editor. Explore their docs or see what they’re up to on their blog.
Builder’s full-stack web framework is Qwik, which just reached 1.0.
Let Miško walk you through why Hydration is Pure Overhead.
ICYMI, listen to our episode with Builder CEO Steve Stewell.
Connect with Miško on LinkedIn, Twitter, or GitHub. You can also check out his website.
This week’s Lifeboat badge is awarded to ORION for their answer to Unicode symbol that represents "download".
[intro music plays]
Ben Popper If you know the Logitech MX series, well get excited. Something new is cooking on both the hardware and the software side. MX Master Series's mission is to help all developers stay in the flow, and they're looking forward to seeing what you have on the horizon. Follow Logitech on social to find out more.
BP Hello, everybody. Welcome back to the Stack Overflow Podcast. I'm your host, Ben Popper, Director of Content here at Stack Overflow, joined today by a very special guest, someone who has created software and ideas that a lot of people have used to help build the web, who has answered a question or two on Stack Overflow and built up a nice chunk of reputation, and who now is working to build sort of the next phase of the web and headless CMSs and things of that nature. So, Misko Hevery, please welcome to the show. You are the CTO at Builder.io, creator of AngularJS, and we're glad to have you here on the Stack Overflow Podcast.
Misko Hevery Thank you for having me, Ben. I really appreciate it.
BP So before we get started, you were trying to tell me a story, funny in some ways, I think. You came on Stack Overflow, you've got a nice chunk of reputation– 50K, but you only answered really one question you'd say that got you all that, and of course you were answering your own question. That's the classic way to game Stack Overflow.
MH Yeah, so when AngularJS was just starting to happen, I made a question. It was, “How does AngularJS work? How does the change detection work in AngularJS?” And so I asked that question to myself and then I was nice enough to answer it, and that one question seems to keep paying dividends 10 years later.
BP Well that's good, either because AngularJS is very confusing or because people continue to see value in it and seek it out, and so they want to know how it works. So I think probably a little bit of both. We do that all the time. We have our own internal Stack Overflow for all of our questions, so I say, “I want to get something up on the blog.” I post the question and the answer so people know where to go and they don't have to ask me that same question over and over again. Misko, for people who don't know, tell them a little about yourself, how you got into the world of software and how it is you came to create something like Angular.
MH It depends how far you want to go back. It's funny enough, I started as a computer engineer, which means I designed hardware, not software. I joke that I'm the JavaScript engineer who knows how a transistor works. And so over the years, I started in back end systems and databases and then slowly I kind of migrated to the front end. And then about 13-14 years ago, I started this project called AngularJS that kind of became popular. I kind of surprised myself on that one. And then we did this other follow up thing called Angular, and about two years ago, I was at Google for 16 years and so I was like, “16 years is long enough. I'm either going to become institutionalized or I have to move on,” and so I decided to move on and I went and joined Builder IO as a CTO. And one thing I didn't specifically want to do was start another framework, but somehow here we are. I started another framework called Qwik. I think it's significantly different than the other frameworks, and I think one of my requirements back when I started something else was that it can't be a marginal DX improvement. It has to be a fundamental rethink of how things work.
BP So let's travel back in time a little bit. 13 years ago you were at Google. I don't know what you were working on, but maybe Angular wasn't sort of the project you were assigned. What was the problem you had personally, the itch or the pain point that made you want to create this, and how did that become sort of your central focus? Was this a 20% time project that turned into something or were you building something internally that then got open sourced and put out to the world?
MH So back in the day, you had multi-page applications. Everything was rendered on a server. And if you think about it, all of these apps are really a standard round tripping. You go from the database to the UI and from a UI back to the database so it's just a big marshaling problem which you have in front of you. And every web app you would build, it's the same thing and at some point you're like, “I'm just kind of tired of doing this. Is there a better way?” And so I started Angular on the side. It was not really meant to do anything. And the goal of Angular was actually very different. It was to extend the HTML vocabulary so that non-developers, a web designer who understands HTML, can build simple applications. It wasn't even meant to be complicated stuff. It was meant to be simple stuff like, “Make a guestbook on my page.” I don't remember if you remember those days when guestbooks were a thing.
BP Sure. You've got to log in so folks know where you belong in the blog rankings.
MH That's right. And so I started working on this kind of on the side, and then at Google we were building an app using Google Web Toolkit. And Google Web Toolkit really has a really bad round trip. From the moment I change a piece of code until I get to see it, it would take two minutes. It was really painful. And so I kind of jokingly came to my manager. I said, “This is ridiculous. I could do this in two weeks with the side project.” And he kind of called my bluff and said, “Okay, show me.” And so I kind of rewrote this whole GUID app in the side thing which was called Angular, and people kind of noticed, “Hey, this is kind of crazy that you can be so much more productive.” But it wasn't really a framework, and so it was only at that point where we kind of said, “Hey, could we make this into something that others can use as well?” And so it kind of grew from there.
BP It's interesting to hear you say that you wanted it to be something that was accessible. I was reviewing the Builder.IO site today and checking out a few of the other headless shops, and one of the things that I see a lot is the idea of removing the bottlenecks. So instead of having product and engineering and marketing and design all kind of stuck together in a queue, let's give people the ability, even if they're kind of low-coders or no-coders, to be able to work with some of this stuff. So it sounds like that's a problem along with DX that has kind of been at your core for a long time.
MH Yeah, so Builder has a headless visual CMS, and I think the key word over there is visual. So the headless thing basically means that you are hosting your own infrastructure. So if you go to Wix, Wix will host it for you, but if you're Target.com, it's kind of hard to use Wix. So you really want to host it, and the downfall of all the hosting, or what's known as ‘headless CMSs’ in the industry, is that they're essentially glorified spreadsheets where you have keys and values, and as an engineer, you decide what the keys are like, “Oh, you get to change the image. You get to change the text, you get to change whatever.” And then the marketing really only lives inside of that forum, but they can't really go outside of it. And if they want to go outside of it, like, “Oh, I want to have two images,” well, let me talk to the engineer, and the engineer can go and change it.
BP Yeah. I'll put in the pull request for that and wait a few weeks.
MH Yeah. So the visual part really means that, as a marketing person, you have full freedom to do anything you want. You have a drag and drop editor and you can create anything you want, including dragging existing components that the engineers have written. And then when you drag those existing components, you might have to do some data binding or something like that, but then you can just reuse the power of the engineering. So the engineer can focus on what they like to do– create new stuff, and then marketing can focus on what they like to do, which is make it look pretty and interesting and do A/B testing and get people's attention kind of things. And so it really improves things. So I like to say that the old headless CMSs, they have a strong schema and the marketing has to follow that schema, whereas visual CSS is schema-less. You can do whatever you want inside of that box that the engineering has given you.
BP And so did you come to Builder IO at the beginning or did you come sort of after the founding? Were you a CTO who was part of its creation and developing its tech stack or did you kind of come after?
MH I came after. So Builder IO has been around for about five years, and it really has hit a stride recently. I think we have done some fabulous growth recently. I think the first three years or so was really the product development. And I came in about two years ago and my thing was, “Hey, I want to make the web faster. I think the way the web works today is kind of not the best thing.” And so I kind of chatted with Steve about this a little bit, and interestingly enough, Steve was like, “Hey, I have the same problem. We build these landing pages and they're just not fast enough and the customers always complain.” And the thing is, it doesn't matter whether you build them in React, Vue, Svelte, whatever your latest, greatest, solid framework you want. They're all about the same in terms of performance even though they're all claiming that they're the fastest. And so he's like, “Well, the only thing that kind of works is just sending HTML. Everything else, the moment you have JavaScript in there the performance just goes down the drain.” And then you say, “Well yeah, but if you don't send JavaScript, you don't have interactivity and that's kind of important.” And so this is where Qwik comes in. Qwik has this trick where we don't send any JavaScript at the beginning. It's all just HTML and so it's super fast, but then we know how to cleverly attach the JavaScript as you're using the application.
BP I think I met Steve. We were at the Next.js conference with Guillermo Rauch and talking about Vercel. Vercel made some news, I believe it was earlier this week, talking all about new edge functions. And when I think about Qwik, that's what I think about as well– delivering instant apps, using some of those tricks where, as you said, the less JavaScript you're moving around the better. Obviously you need it for interactivity, but HTML is where you want to be at. And then caching things and streaming things and trying, as you said, let's go back to the start, not to make these round trips every time on every click or every refresh.
MH Yeah. But I think Qwik is in a bit of a category of its own. It does things very differently. I think people are recognizing that there's too much JavaScript, but there are limited options with the current approaches because the current approaches all have this thing called hydration. And hydration is basically one of those bugs that we turned into a feature. But what hydration basically is is that the framework needs to recover information about the application, and this information it needs is, where are the listeners, where the click mouse moves or whatever, what is the state of the application, and what is the componentry? If I change the state, which component do I have to rerender? And the problem is that all frameworks that are currently out there, the way they do this is by re-executing the application from the root component. So you go to the root component and you start to recursively visit every single component underneath it, and that means that if a component is visible in your current page, then it has to be downloaded and executed before any interactivity can happen. And that basically is kind of the problem we're facing– that this hydration, this process of recovering this information, is very expensive. It causes you to download huge amounts of JavaScript. And not only is it downloading the problem, but you have to then execute all the JavaScript, and so all of that is slowness that the user experiences.
BP And so when you talk about slowness, the clients that I see on the builder side, a lot of them are in the world of e-commerce. Slowness doesn't mean what you said before– two minutes. It means a few seconds of stuttering when I'm browsing and that then translates back overall to 10-20% difference in sales. I mean when you talk about slowness, what are you talking about?
MH We're talking about startup performance. And specifically what that means is when you're browsing your social media, whatever your favorite thing is, and you see this ad or somebody is promoting this amazing shoe that’s going to make you jump higher or whatever. And you click on that link and you get to a page and you're like, “Oh, I want this shoe! This is great. Let me push the buy button.” And the buy button doesn't work. You click on it, nothing happens, and you wait. “Okay, so did I not click right, or did you not register the click? Let me try clicking later.” And then finally the thing wakes up and now you have two items in the shopping cart instead of one, and at some point you're like, “Screw it, I don't really need those shoes.”
BP Right, right. Now I've already gone back to the social media app. You've lost my attention.
MH You lost my attention. And so that results in less sales, obviously, because people just get frustrated. And this is especially true on mobile devices and on spotty networks. You're clicking something and the network is not really delivering, and it's like, “Wait, okay.” And so that's the problem that we are talking about in terms of startup performance. And so this is called sometimes ‘time to interactivity’. And Google has this thing called a lighthouse, which is kind of a way of measuring this, and so it measures that on slow networks and slow devices, and it is not uncommon for the lighthouse to basically say that it takes 30 seconds before the page becomes interactive. And so that means that you come to a page on a slow network, and you want to purchase a thing and you can't do it for 30 seconds or so before the page kind of starts working.
BP That's an eternity in web time.
MH That's an eternity. And so this is specifically what we're trying to solve.
BP So you mentioned hydration and how some of the stuff that is out there for React, for example, is using this client side JavaScript at an application state, talk to the server rendered HTML. What is sort of the thing about Qwik that is different when you talk about its sort of ability to avoid hydration? How does it do that? And if I was a web developer listening to that, would this be something that I could intuitively understand? Would I have to relearn things, pick up new tools? Or if I understand React, I understand this.
MH I think you would, it's pretty intuitive. Let's kind of talk about what it is and then we talk about how things change for you. So I think the best way to kind of understand it is to contrast the two approaches. So the way existing applications work is that you need to server-side pre-render it, and so you have to execute the application on a server. And so we all agree that the application has to run on a server in order to pre-render it. That in itself is not surprising. And then what you get back out of it is you get HTML that you show to the user, and the HTML looks like an application but it's not interactive. And so you need to do something in a client to make it interactive. And what you do is, if you think about it, you re-execute the same exact code that the server just ran on the client. And as you're re-executing the same exact code, the client is learning about where the listeners are, where the component boundaries are, what's the state of the system, and all of these things. And this re-execution is causing the slowness. Now let's compare this to reasonability. So the best way to think about reasonability is virtual machines. I know when virtual machines first came out they kind of blew my mind. Imagine you're sitting on your Mac and you open up a virtual machine inside of your Mac and inside of it you start booting Linux. What you actually see in the window is you see the bios come up, you see the boot up, the kernel process, you see the login screen, and you type in your username and password. Now you're logged in and you open up, let's say, a word processor and you start typing a letter, and halfway down typing the letter you save the virtual machine. You can pause it. And it saves it to a file, and the crazy thing about this file is that you can take this file and you can mail it– well, it's big– but you can send it to your friends, and they can all open the file on their virtual machines, and they're literally where you left off. When the file opens, their cursor is blinking at the next character of your letter. They don't watch the bios, they don't watch the kernel booting up, they don't watch the login screen, they don't watch the application running. They literally see the cursor blinking at the next character that you came to.
BP Right, you're mailing them that state and they can just pick up where you left off. Yeah.
MH That's right. And so this is essentially what reasonability is. Your application was running on a server, you froze it by serializing all the state, and then you moved it to a different physical virtual machine, in this case, in the client, and you say, “Continue running,” and the application just continues without having to redo all of this work. And not having to redo all this work is important because it means two things. First of all, you don't have to download a huge amount of JavaScript, so you have a lot less JavaScript to download. And two, you don't have to execute all of these things. And specifically, even if you have an application, a lot of components on your applications are really not interactive. They're really just for the purposes of the layout. And those components still have to re-execute on the client during hydration, but in case of reasonability, well, they already ran once, so there's no need to run them again in the client. And so you basically don't even download the huge amount of code in it. And so Qwik is kind of different in that sense, and what I really talk about is this idea that existing frameworks are replayable, meaning that when you go to the client, you rewind the world or the tape or whatever to the beginning and you replay it so that you end up in the same exact location. And this replaying is expensive in terms of time, and also in terms of bytes on the wire that you send. Whereas in Qwik, the application runs on a server, you pause it, you move all the bytes to the client, and you just continue where you left off. And this is where we get the performance boost in terms of startup.
BP And so do you have to make any sort of guesses or sort of presumptions about what the user wants in order to deliver them, as you said, sort of this pre-prepared state where they can hit the ground running, and if so, how do you do that?
MH So we're super proud of the DX because the amount of crazy hoops we have to jump through in order to get here was insane. And many times we were like, “This is never going to work,” and we were ready to give up, but somehow somebody always had a good idea to kind of push it through. So in Qwik, the whole thing is actually broken down to this very simple idea, which is that in order to make an application resumable on a client, you need to be able to serialize closures. If you have to think about it, the web browser is all event-based, and so it's really just about knowing which event to execute next when the browser executes an event like a click listener, and the click listener needs to be able to execute the closure that at some point you created in the past. And these closures were created as part of a server rendering, maybe they were delivered to a CDN and cached, and now you have to kind of resume the execution of these closures. And so Qwik’s thing is that it knows how to serialize closures, and the way this is done is that you mark the closures using a ‘$’. I know that people have very strong opinions about the dollar sign, but there needs to be a way of marking it. And so we looked at all the possible choices and the dollar sign was the least of all the evils out there. So as much as you have your visceral reaction to a $, it's really the best choice we have out there. And it's part of the API of Qwik itself, so it's not like you can forget to put $ somewhere. You don't even have a choice. As you're using Qwik, the TypeScript is going to scream at you if you don't use it. But what this $ means, is it tells both the developer and the optimizer that something has to happen. And specifically what it says is, “Hey, look. Whatever is behind the $ is going to be a function or a closure, and I want you to extract this closure into a separate file so that the browser can load this closure and continue executing it.” So that's step one of this extraction that has to happen. Step two is the closure closes over a state of the application, and so the thing we need to be able to do is to kind of recover the state on a server and serialize it and then use it on the client. And so the $ really also tells the developer, “Hey, whatever you're going to close over or whatever you're going to capture inside of your closure, make sure that these things are serializable,” and there is all kinds of runtime checks and linters to kind of help you along with this so that you don't accidentally serialize something you're not allowed to, but this is kind of the idea. So as long as you understand how this $ works, it turns out everything else is essentially the same as the other popular frameworks, whether it's Solid or React, et cetera. And so you really only have to kind of understand this fact that whatever I put in a state needs to be serializable, and Qwik is pretty good about being able to serialize just about all the common things, whether it's dates, timestamps, sets, maps, and obviously the JSON stuff. But it can't put certain things streams in there– streams won't serialize, classes won't serialize, and things of that sort.
BP Yeah, I think you said all you need to do is understand the $, so my marketing brain is going to cash runs everything around me. I got it. You understand that, you can serialize listeners, data structures, application state, you put it into HTML, don't have to move all that JavaScript around. Just pick up the execution where the server left off. That's an interesting approach and I guess it seems to be working for you. I want to ask you just a few more questions before we go. Let's move off of some of what you're working on. Just look a little broader. What's been your experience? You've obviously been a software developer for a long time. You've created stuff that lots of other developers have gone on to use to build. What's your experience been like with this latest wave of generative AI tools? Do they excite you? Do they scare you? Are you playing around with them? And what do you hope, I guess, will be the end result of chatbots that can talk to us, code for us, debug for us, or generally be involved in the process of writing your code?
MH Yes, yes. I love this question. Actually, I am both excited and scared, but not for the reasons you think. First of all, I am super excited because, wow, the ChatGPT is amazing. I'm sad because it's so good that you realize, “Is that what humans are? We're just these predicting machines that know how to statistically predict the next word in a sentence? Is that really all we are?”
BP That really is my only ability. It's just to say things that sound good when they're coming out of my mouth. They don't really make a lot of sense if you stop to listen.
MH Well yeah, but how do you get good at speaking? Well, you do a whole bunch of speaking.
BP Exactly. Never shut up.
MH And so I read this awesome book that I really, really enjoy. It's called Thinking Fast and Slow, and I really recommend everybody read that. I'm not sure if you read it or not.
BP Yeah, Daniel Kahneman. It's a good one.
MH Daniel Kahneman. It's so good. I joke that that's basically your brain's operating manual. It will tell you how your brain works. You should read it. If you have a brain, you should read it because you should know how to operate that thing.
BP It’s good to read the user manual every once in a while, yeah. Check it out.
MH And Daniel Kahneman makes a very interesting point. By the way, the guy got a Nobel Prize for his work, so this is serious stuff. And he makes a good point that there is really two brains: what he calls System 1 and System 2. And maybe I get the 1 and 2 reversed, but System 1 is literally ChatGPT. It's the predictor. And you look at System 1 the way Daniel Kahneman describes it, and he's not a computer science person. He's a psychiatrist, psychologist, I don't know. And you look at it from a computer's point of view and you go, “Oh my gosh, these two things are literally the same exact thing.” Now, humans also have this thing called System 2, and we don't really have anything for System 2 in terms of AI. And so this is why I'm not scared of ChatGPT, because without System 2, it can generate really good sentences, but it can't do anything useful with it. I like to kind of point to people, a System 1 question would be like, “Hey, ChatGPT. What is a recipe for yogurt?” And it gives you steps– this is how you make yogurt. And then you say, “Great, can you give it to me in half the size?” And for the most part, it gets this correct, and now you say, “Great, I want it in 1/7th the size.” Garbage comes out. The reason for that is because people on the web talk about yogurt recipes and they maybe talk about what the half size yogurt recipe is, but nobody talks about what a 1/7th recipe is. That's just not a thing. But if you had System 2, then you can say, “Oh, no problem. I can just take System 1's answer, which is, ‘this is what a recipe is,’ and I can divide it by seven and I will get the answer that you're looking for.” But ChatGPT can't do that. And so, Wolfram– I'm not sure you're familiar with it, there's this company called Wolfram Alpha.
BP The plug in, yeah.
MH So they're actually working with ChatGPT to kind of add the computational stuff. And the person actually wrote a very nice article about how ChatGPT works, and in there he's basically saying, “You could really have systems that are good at predicting things, or you could have systems that are good at computational stuff like math, but you can't have both. Those are two separate things.” ChatGPT can get better at prediction, but it can't get better at computation, whereas computational systems can get better at computing, but they can't get better at predicting, and they are fundamentally different things that you need to figure out a way to have two systems and have them talk to each other rather than assume that somehow ChatGPT will learn this over time, which it's not going to.
BP Yeah, I mean, I think there clearly are strengths and limitations to sort of the large language model on top of the generalized pre-trained transformer and we're starting to see what it's like if you give it tools. “Here's a calculator, here's a web browser,” or another interesting piece of the puzzle, “You're not just a large language model that does text to text, you also do text to image.” And one of the fascinating things that I've heard, and I'm not a deep learning scientist, is that if you make it multimodal, it gains a sort of better understanding of some of what you're talking about– the ability to have sort of a better sense of world and work through some of those puzzles, like 1/7th the size yogurt recipe, as it gains a little bit more depth in kind of its modes of thinking, its modality. So brave new world we're entering.
[music plays]
BP I want to say thanks so much for coming on. It was a real pleasure to chat with you, to hear about what you've built and what you're building. I know that you had mentioned at the beginning you are a Stack Overflow contributor, so at the end of the show, we always like to shout out somebody from the community who came on and helped spread a little knowledge. Today, we'll shout out ORION, awarded a Lifeboat Badge on May 4th for supplying an answer. “What is the Unicode symbol that represents “download”?” Thank you, ORION. You've helped over 57,000 people over the years with your little bit of knowledge. I am Ben Popper. I'm the Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper. You can email us questions or suggestions, podcast@stackoverflow.com. And if you like the show, leave us a rating and a review. It really helps.
MH So thanks for having me again. So I'm Misko. I am the CTO at Builder.IO. That's one place you can find me. I’m usually on Twitter @MHevery. And of course you can find us on GitHub, same exact login name. And check out Qwik. You’ve got to misspell things to be interesting.
BP Awesome. All right, everybody. Thanks for listening, and we will talk to you soon.
[outro music plays]