Today we talk with Steve Sewell, co-founder and CEO of Builder.io, about their visual editor and designer which connects to many open source systems.  Running within a website wysiwyg, it integrates with most modern front end frameworks, such as React, Due and Svelte.  We discuss how it functions and connects to various systems.  We also dive into the backstory of how and why builder.io created their framework called Qwik.

CHARLES MAX_WOOD: Hey everybody and welcome back to another episode of JavaScript Jabber. This week on our panel, we have Dan Shapir. 

 

DAN_SHAPPIR: Hey, from Tel Aviv. 

 

CHARLES MAX_WOOD: Steve Edwards. 

 

STEVE_EDWARDS: Hello from a finally, finally sunny Portland. It's been raining like nonstop for months. 

 

CHARLES MAX_WOOD: I'm Charles Max Wood from Top End Devs. We've got a lot of exciting stuff coming up, including a JavaScript remote conference that's going to be held in September. So if you're interested in that, go to topendevs.com slash conferences and you can find it there. 

 

DAN_SHAPPIR: Cool. 

 

CHARLES MAX_WOOD: Yeah, we have a special guest and that is Steve Sewell. I hope I said that right. Steve, do you want to introduce yourself and tell us why you're famous and important? 

 

STEVE_SEWELL: Yes, of course. So I'm co-founder and CEO of a company called Builder.io. We're kind of getting some solid traction lately. I think our name is getting some better recognition lately, but in short, we make sure... 

 

DAN_SHAPPIR: You're on the bonus.

 

STEVE_SEWELL: I hope so. I mean, I love to hear any sign of people like what we're doing, but we effectively make a visual editor. You can connect to whatever site or app stack you have. So the short answer use case is, you know, you've got a next JS site, got a marketing team that needs to rip out a bunch of new pages or A-B tests on pages all the time. You'd like it to be within your next JS site using react components, design system, whatever plug builder in markers, get a drag and drop editor. You get a clean kind of component driven API driven workflow and sky split. 

 

DAN_SHAPPIR: And I already have a million questions. 

 

STEVE_SEWELL: Perfect. 

 

Hey folks, this is Charles Max Wood from Top End Devs. And lately I've been working on actually building out Top End Devs. If you're interested you can go to topendevs.com slash podcast. And you can actually hear a little bit more about my story about why I'm doing what I'm doing with top end devs, why I changed it from a dev chat.tv to top end devs, but what I really want to get into is that I have decided that I'm going to build the platform that I always wished I had with dev chat.tv and I renamed it to top end devs because I want to give you the resources that are going to help you to build the career that you want, right? So whether you want to be an influencer in tech whether you want to go and just max out your salary and then go live a lifestyle with your family, your friends, or just traveling the world or whatever, I want to give you the resources that are going to help you do that. We're going to have career and leadership resources in there, and we're going to be giving you content on a regular basis to help you level up and max out your career. So go check it out at topvendevs.com. If you sign up before my birthday, that's December 14th, if you sign up before my birthday, you can get 50% off the lifetime of your subscription. Once again, that's topendevs.com. 

 

CHARLES MAX_WOOD: Right, so we are going to be talking about builder.io, but we're also going to be talking about Quik. Where do you want to start? 

 

STEVE_SEWELL: This is for me, I'm game with either, honestly. In fact, actually our platform kind of preceded everything which led to the open source projects. Maybe we start that way, and as we go into why the platform exists, it might explain and transition well into why the open source projects exist too. 

 

CHARLES MAX_WOOD: Sounds good, all right. 

 

DAN_SHAPPIR: So you were saying that the platform is like a pluggable. Wiziwig type environment for designing user interfaces, but that it's not like a self-contained system, rather it plugs into open source systems like Next.js. Which other, by the way, open source systems does it plug into? 

 

STEVE_SEWELL: Yeah, so technically anything. At its lowest level, we have an API that can just give you HTML. And so if your use case is simple, you just want something like a wissy way, a kind of Wix style, but you need to plug it into whatever website. This could just be a Ruby on Rails website. We have an API to just pull the HTML and inject it wherever you want. The way the visual editing works is it actually does run within your website. So what's interesting is even in that simple use case that works regardless of tech stock and Well, web tech, we support native apps as well, but we can get back to that. But in that HTML editing scenario, you actually do still edit on your website. So any CSS classes that you have in global styles or whatever, your tech styling stuff like that all is there in the sort of wissy wig, that kind of real-time editor. And then if you connect to other things, so we have a deeper integration with most modern front-end frameworks like react, which of course gives us good quality support for next JS remix Gatsby, you know, everything else built on react and then view. And then we have spell to install the JS. We have a bunch of going to forget quick is actually about to ship in the next couple of days, but basically those lower level integrations are the more powerful ones admittedly depends on your use case, but those are the ones where the entire system is there within your code base. Meaning if you install a React SDK, you get React components for images, columns, and some basics. And then you can, those building blocks, like what you drag into the editor, are all things you can replace or augment with your own. So if you have your own carousel, your own products grid, all that stuff, those become registered in your code base and used in that drag and drop editor. So basically, I like to say we're the only sort of no or low code you should never outgrow. I've never seen people outgrow regardless of size. You need customization. Make new components. Those are building blocks and those are wildly flexible. Everything that's built into the system, all the responsiveness, columns, and children and slots is exposed to you too. So you can make any type of thing that you drop in the editor with any rich functionality connected to data and it's, uh, loaded within your site infrastructure. You know, people ask, how do you host it? It's like wherever you're hosting now is just where it lives because connected to your website, it's just sent over an API. And then that gives you other advantages, like if you want to do things like AAB testing and personalization, you don't have to do weird sort of injected JavaScript hacks like in legacy systems. It actually can be delivered through your framework, you know, statically generated from the edge. So kind of get this trade off of flexibility and performance and I'll stop there because that was a lot. 

 

DAN_SHAPPIR: So, you know, what you, one of the things you said kind of amused me what you said at the very beginning that it can be just an NPI endpoint that provides the static HTML and that amused me because that's kind of called a web server. 

 

STEVE_SEWELL: Yes, 

 

CHARLES MAX_WOOD: kind of. 

 

DAN_SHAPPIR: So I tried to understand fully the architecture that you're describing. So when I install your or integrate, I guess the more appropriate term, your service or your solution into whatever development environment that I'm using Is everything running within my environment, or am I connecting to a service that is hosted on your own servers somewhere at development time, at runtime, both? How does it actually work? 

 

STEVE_SEWELL: Yeah, so that's a great question. So it actually works under the hood. It's identical to any other headless CMS. So if you're familiar with a Contentful or whatever else, you make models for your data like schemas. Those schemas can have fields. So common way in Contentful to make like a page schema is add a few fields. One's called the URL, like freeform decide what the URL slug is. There might be just a freeform rich text editor, right? So it's not drag and drop and all this stuff, but there's a way to add, you know, heading paragraph, you know, like maybe basic, basic blog content and maybe some other fields, like who's the, like, let's say it's a blog post. Who's the blog author could be a reference to something else in Contentful or whatever else. So that's just JSON data and you will pull it from their API. So maybe a next JS as part of get static props, you're going to fetch the data and say, Hey, Give me the blog post for this slug. You get all that structured data and you print the author and this and that. And then just a chunk of HTML for that rich text that was entered and builder actually works identically. It's just when you get the response. So same way you can have custom fields and schemas to structure your data, however you want. So a blog post and builder would be structured the same. What's the URL slug, a field for the author, a field for any other data you want to render yourself. But then if you want the blog post to have more than just basic text, you want it to actually be really, really interesting stuff. It's got text and widgets and all sorts of stuff that becomes a sort of tree of Jason that describes the layout. So it'll say, okay, there should be a hero here and products there and some texts there, and then if you're rendering via react, you manually handle all the fields. So how the slug is handled, where you display the author, but then we provide the unique bit as we provide this rendering component in past SDKs, we called it the builder content now in the newer generation ones, we just call it the render content component that can take in that arbitrary Jason that our visual editor can construct and that can render it out. So that can loop over the Jason's like, okay, hero here with props, you know, text here with these props, any custom components or whatever else. But in terms of integration and workflow, it's identical to any other headless CMS or really any other API. It's just that unique pit that we can dynamically render whatever the API provides Any structure, any components, et cetera, is the unique bit. 

STEVE_EDWARDS: Was one of those rich tech fields. And I, this is really interesting because I've been wrestling with doing something similar with another headless CMS that Shagoa named. But if I'm understanding you correctly, what you can do as a headless CMS is provide just everything's in JSON format, right? 

 

STEVE_SEWELL: Yeah. 

 

STEVE_EDWARDS: Okay. We all understand JSON. He's a nice guy, popular guy. But so you can provide just text strings that allows us to form out what we want to form out in our templates, but you, but if it's a complex field with in builder and then you send everything completely rendered. All we got to do is pop it on the page. Is that right? 

 

STEVE_SEWELL: Exactly. So in the format of the HTML API, and that's the difference between web servers is, you know, it's a fully queryable API returns JSON. Yeah. One of the fields is just a blob of HTML. You just stick wherever you want. But in the case of like a reactor view, I mean, it really is cool. One of the really biggest aha moments of using builder is you've got components in your code. It could be simple, like presentational design system components, you know, your card, your columns or carousel, or they can be very rich ones, like a big old giant whole search page in a component or whatever. When those become the pieces in the drag and drop editor, that's when it unlocks a lot of that aha, like, oh, wow, we could do anything like we can lock this down to require the design system everywhere. So all design is perfectly standardized, or we can loosen it up and say, hey, mix and match. Most customers go that road. Like if you look at everlane.com, shops.com, Zapier.com, all these homepages are just made in builder, some mix of totally drag and drop from scratch made by their design team or whatever, as some of these sort of building blocks they use, kind of re-use as templates. And then code components, because one of the limitations with, I mean, the whole reason this exists is I think most people should be using some combination of a Wissy wig. It's very tedious to hand code CSS for every new marketing landing page or whatever it is you're doing. Most teams have this dynamic where marketing has this massive backlog of tests, personalization, new pages. The engineering team really would rather not work on that. They'd like to do interesting, hard stuff, not move the color of the button or whatever else. The idea is how do you do this kind of collaborative process where engineers can make components just in the ones already in their code, they just register them and build during their usable. And to be clear too, it's used the same way. So the component has two props, you know, a title, which is some text. and URL, which is a link or maybe an image too, when you registered in builder, those become UI fields. So you're just dropping in your components or bespoke stuff. So the format where we don't send HTML, we actually send JSON and the JSON then is provided to the rendering component that we have that you just, you know, type out in your next JS code, basically say, hey, render the free form builder content here between my head and footer in the blog post content area, wherever, that's where you get the really big power, where that can have anything you want. So you're never like, you're never like, oh, we have to move off this WYSIWYG system because we need more event stuff. It just doesn't happen. You just add new components, add new customization, whatever you need, if that makes sense. 

 

DAN_SHAPPIR: Yeah, so- 

 

STEVE_EDWARDS: Okay, so my head's still spinning here, turning it into grass. So if I have, let's start with something really simple, for instance. So let's say I'm creating, and this is something I'm actually working on. I'm creating like a brochure site for a very small business for a friend of mine, okay? And I'm gonna use Astro, okay? To build the site because it's static. I don't need a whole bunch of JavaScript on the front end, I wanna render it. So, you know, I've got my different content types that I need, I've got like a front page with all the various items that go on there. And then I've got a page of services. We do this and this and this. I got a page of customers that we've had with all their logos and a description of the customer, you know, on a content page and stuff like that. So I'm gonna go into Builder and set up my content model, you know, as you normally would. I guess what I'm trying to get my head around is, so I have like a theme or a template that I've designed in my application on the front end and I'm saying I'm using Tailwind for the CSS portion of that. Am I understanding that you're going to take all that and somehow get that into Builder and the Builder is going to give me everything back all nice and pretty and I just got to show it? Or am I still doing some coding in my front end, my Astro templates, as well as some coding within Builder? 

 

STEVE_SEWELL: Yeah, I actually have an Astro example. Does it make sense for me to screen share? Is that a good use of the real estate or is that a bad idea? Words is better. 

 

STEVE_EDWARDS: For this, considering we're audio words is. 

 

CHARLES MAX_WOOD: Yeah. Yeah. We don't post videos, so. 

 

STEVE_SEWELL: It's called mouth coding. So, yeah. Yeah. So let me do the mouth coding format. So I'll tell you exactly what your Astro. So the big key about Builder is it's still your site structured the way you want. So you're still going to have Astro files for that homepage. Maybe you'll have a dynamic root file for generating landing pages. And so let's take a simple example. Let's take the example of the homepage, right? So maybe you make a model for your homepage. Usually we recommend being a little more dynamic, but let's simple example, homepage. And you're like, okay, in Astro, I have my index.Astro and I've got my header in there all in the code and footer. And I might have some custom fields. Like I want to have like the structured data. Like what are the title, description, SEO image, you know, all that stuff is just fields like any CMS uploaded you do in Builder. And then you're like, okay, but between the header and footer, whoever's managing this website, I don't want them knocking on my door every time they want a new button or a new image or whatever else. So I'm going to allow them to just freeform edit with the WYSIWYG. And you can hook it up so that you actually can see your Astro header and footer and then the editable area in between. That's a little added integration because that makes sure truly what you publish is what you'll see live. You actually want to be editing within your actual CSS. And If you want to utilize Tailwind components, you'd use templates and builder. So what that means is as a developer, you're like, okay, like say we, uh, we have some standard ways we use Tailwind. We have like a button which uses these Tailwind classes and a few other things. You actually can go in and make some, just drag in a box and builder, add something inside, and then there's a little bar to add classes or add the classes and save it as a template. You build up this little library of templates and that'll have sort of all your basic components and then that non-developer can go in and just drop in and mix and match and change things anytime. When they hit publish, that entry is saved in the database. And so what your index.Astro looks like is besides, you know, hard coding the header and the footer at the top of the file, you're just going to hit our API and say, Hey, give me the content for the homepage. It'll be a JSON object. And this is using the HTML API format. So nothing fancy that'll give you a JSON object, which is here's your custom field key value pairs. So render them like any CMS data. And one of the fields is just called HTML. And that's what you're just going to have. Uh, I think Astro has like an at HTML or something, but you're going to use Astros format to say, Hey, but 200 footer dump that HTML field in here. I'll pause there. Does that explain it maybe better? 

 

DAN_SHAPPIR: Yes, it does. And, but it still brings me back to, to some of my questions that I've had. So I gather that the headless CMS itself is a hosted solution. It's not something that I would ever run on premises. It's always going to, I'm always going to be hitting your servers in order to get that data, be it the headless part, the field value, the key value pairs, or be it actual, the actual HTML. The big difference of where you kind of differ from other headless CMSs, as far as I can figure and correct me if I'm wrong, is that while first that, you know, you won't just put in values or data, you would effectively put in HTML and styling. Now you could do that with other headless CMSs. It's just that you would need to build that, you'd have two problems. First of all, you would need to build that HTML and CSS by hand and then stick it as a value into that headless CMS, which would be a royal pain, but I know that some people actually do it, but it's a huge pain and very difficult maintenance issue. And the other problem is that how do I actually integrate it with a more sophisticated environment? I mean, if you look at the Astro example, that's fairly straightforward because I just take the HTML as is and then, like you said, just dump it in. But if I'm looking at the more sophisticated environment, like a React or a Vue, then I'm actually, like you said, I'm integrating it with my own components. So you literally... So again, unlike...other headless CMSs, which just expose an API to the application, be it RESTful API or be it a GraphQL or whatever. You also give me components that I integrate into my, my environment. I install them, I NPMI them, and those components can talk, I guess, either directly or indirectly to your CMS, but then they take care of the rendering of the HTML and I can even embed my own components within them. Am I correct so far? 

 

STEVE_SWELL: Yes. No, that's spot on and worth just emphasizing that yeah, it's simplest, most probably straightforward to understand level. Imagine we're just Contentful or Sanity or any other CMS, except we have a special field type that essentially launches a Webflow or Wix editor, right? Some full on WixieWik editor. That's just a field in the data model And it returns to you as such either pre-generated as HTML or like you said, the JSON. And yeah, if we were to take that in case this is helpful as well, because you brought up React, if we took that same exact Astro example, which said, okay, we're using React this time. The only difference is let's say we're using Next.js. So we'll do get static props and we get the API response from builder. One of those fields, instead of providing HTML provides a tree of JSON. So literally it actually looks a lot like you'd expect. We have some docs that shows what the raw data looks like, but it literally is just like component. Components colon hero props colon key value for props, right? And then component colon it's an array. So component colon products, props is like maybe the category or collection of products to show, you know, whatever. And so in your code, you know, get sack props, get speed data, and then the page template will render all the meta information, anything else that you like manually, but instead of like a normal CMS where you have this huge hard coded layout with like, you know, it's like hero and it's like title equals CMS data Subtitle equals CMS data.subtitle and image equals CMS data.image. And you do that a thousand times over and it gets kind of complicated and maintenance is a challenging on the developer side of the marketing teams, change things a lot. Instead, that whole swath of stuff is just builder component, content equals and the JSON that the API gave you. And that will render the hero with the props and whatever else. And that knows how to look up from, we have a basic way to say register component hero and give us a little more information on the props, like, you know, it takes an image prop, but that should be a file picker that supports PNG or JPEG, a little more annotation so we can guide the user to what to upload or whatever. And yeah, you get a lot of that hard coded stuff out of your code. And instead of the dump HTML here like Astro, it's just here's the renderer component with a prop for that JSON content and similar ideas. 

 

DAN_SHAPPIR: So when I, where I have a little bit of a challenge with that is for example, let's go back to the most sophisticated example of a React-like environment, where I actually want to embed some of my own React components within your component, as it were. Now, if my components are really simple, all they need is some JSON input, then I understand how that works. But what happens if they need more sophistication? I mean, what happens if, for example, they need to bubble up events like you're supposed to pass in some callback function that they then invoke when the user interacts with them. What happens if this event kind of needs to bubble through your component to the whatever you're contained within? How does that kind of work? 

 

STEVE_SEWELL: Yeah, these are great questions. So the solutions to all of that. So as a surprise, when you didn't bring up, I'll touch on a minute too, is like, what if my component based on the props needs to fetch data, right? Because React doesn't make that easy. I mean, suspense is solving it. But today, there's a solution for that too. The short answer is the majority of our customers from the earliest to now are pretty big companies. So we've hit all this stuff. And mostly, like given reacts constructs, the majority of things are just solved by React itself. So if you want to be sharing data to your children components, like just make a new react context, context, so make react context of anything the children will need and have the children read the context as needed, right? So you can do some level of sharing and communication between the surrounding components and the inner components. But there's also, there's even more there. And also for what it's worth too, it's important to know we don't do any type of encapsulation intentionally. There's no shadow DOM boundaries. There's certainly no iframes. This is actually meant to be just like a developer would have had in the code. You know, if you set in builder, put the hero here and the products there, it should operate fundamentally the same as if you had hard-coded in the template layout products here, you know, hero there. And so the same way you do any communication works the same, like an event listener will naturally bubble up. So you can listen to the surrounding component for clicks or whatever else. But the really cool thing is we also have a way to pass data and methods down to builder. So there's this data prop, where you can data equals and add anything. It can be methods, it can be complex product data, anything you pass to that builder rendering component actually becomes accessible to everything inside in a very natural way and in the visual editor. So we have this whole system for like actually visualizing what data was provided, like a list of products. And you can visually, much like you would do in like a web floor Wix, like design a grid and then say, Hey, each image come from, you know, the product image and the product title and the product link and just design things totally bespoke. So there's a lot of these sort of ways to pass anything in and out. So it's kind of very transparent, these boundaries. 

 

DAN_SHAPPIR: A conceptual similarity, probably not a technical one and certainly not the one of intent, but a conceptual similarity between the way that you kind of manage these things and the way that they're managed now with the React Server Components, where the React Server Component can contain a client-side component, but it can only really pass in a JSON because it needs to be serialized across the wire. And in a sort of a way, you also kind of have a sort of a serialization because everything is based on data coming in from your...from your headless CMS. So that's really interesting, something I need to think about. Yeah, when I first saw React Server components, I was like, oh, I'm very familiar with this and the trade-offs and all of that, yeah. And another thing that kind of comes to my mind is the whole thing of versioning. Because to an extent, you look at everything as data, but in a lot of ways, you're pushing into the data things that otherwise would have been part of the code. And I would, you know, in a lot of cases, I would assume that they'd be versioned alongside the rest of the code, but now they are within your CMS. So for example, if I want to create a new, a PR, for example, that changes some design aspects and potentially some of the, some props of my own components. How do I do that? If those components need to be contained within your meta component.

 

STEVE_SEWELL: Yes, no, this is a great, you asked really good questions, by the way. I could tell like you're, you're definitely, I mean, maybe it's the Wix background, but like you're familiar with these types of systems and sort of like what you would imagine would happen used in these ways. This is fun. So yeah, these are really, really good questions. So the first piece that's important to know is anything, because this actually worked really well. I'll be honest too, I should make this clear upfront. Nothing about Builder was really designed in advance. I didn't sit around thinking of all the constraints or ways people want to use the product. Literally everything was trial and error, like brute force trial and error. 

 

DAN_SHAPPIR: It was just like, everybody does that. Anybody who says a liar. 

 

STEVE_SEWELL: I agree with you. And so where I'm going with that is I completely didn't anticipate what the right decisions would be, but turns out there is a very right decision for what you're describing. And there still is one sort of occasional pain point with it So the right decision became to be everything that can be in your code should be in your code, meaning the components you register are there in your code. Obviously you're not like copying, pasting React component code to some weird system of bars. It's right there. You call register component in your code. The schemas for the components, the name and the inputs is there in your code and diversions. So I'll give a quick example of versioning of your code and how it impacts builder. Let's say for example, you push to a staging branch some new things. Maybe you rethemed all of your components, assuming they still take generally the same props, but they might look and feel wildly different. That's okay. You push that to staging and the builder, Jason, that just says, you know, hero with props, you know, whatever the same content displays fine, just with a new look and feel. And so you can push that to staging and builder. You can select, point your preview at staging and say, okay, everything was going staging. We're great. You can also push to staging or, or develop locally to there's a config to say, Hey, points at my local posted, you know, my local preview and edit off that and you can register 100 new components. And then when that goes to production, your marketing team starts dropping in the new components or any changes work as expected. The boundaries are kind of clear. The one thing you'd need, and you only need one thing, is your components need to have a basic contract with Builder of like, this is the schema we support and we're going to try and be forwards and backwards compatible with that. So there's two ways people deal with what if we just decide, you know what, our hero component we wanted to have a wildly different set of props. Well, builders already got saved in the database, a title and a subtitle prop, and now you just want to rename them or remove some or something. You decide how that changes. Now, all builder data is read and writable with APIs, like any other CMS. And we also provide utilities to like traverse the tree and make updates. So one thing is you can migrate the builder data. You can say, actually, okay, title is now called big text, you know, whatever. You can change all the names and just comb through it. Synchronizing that with your deploy can be a trick, but there's ways. We have environment support, you know, there's ways to do it. Or second, you provide things like higher order components so that your component can deviate, but you still can register something that maps the old way, the standardized way that you've been using a builder to date to the new way. So I'll pause there. Does that explain some of it or did I miss some of what you were asking? 

 

DAN_SHAPPIR: No, no, it totally explains it. My two cents would be that you probably are, but you should also be thinking about some sort of integration with GitHub or something. 

 

STEVE_SEWELL: Yeah, no, I agree with that. What do you think that should look like? We've been playing with these ideas. 

 

DAN_SHAPPIR: It's a great idea. I know that Wix was thinking about that a whole lot when I was leaving for very similar reasons. Unlike your Wix kind of reverses the approach that you have where you're embedding the WixieWig within the development environment and Wix is looking to embed the development environment within their WixieWig, their Velo. And they were, and they're certainly also looking at how to version that as well, because at the end of the day, when you're dealing with code, developers like to have version control and, you know, it stands to reason and the defaxo standard for version control these days is Git. But to be honest, that was not part of my purview. So I didn't really think about that so much. But I know that they're thinking about it a lot and I know that you're talking with them. So maybe you can come to similar conclusions. I don't know. I do think it's potentially beneficial for headless CMSs in general. I mean, this whole distinction of data versus code is kind of arbitrary as you show with Builder. And I think that a lot of these new kind of database as a service type solution are also looking at versioning. We had Tejas on our show. Are you familiar with Tejas? 

 

STEVE_SEWELL: I'm not, no. 

 

DAN_SHAPPIR: So he works, I forget their name, is at Zeta, I think. And they're like this database as a service. And they're, one of the things that they're introducing is versioning. So I definitely think that all the various solutions that do these sort of things need to have a versioning type solution in place. And what most developers are used to is Git because Git is good. Yeah. 

 

STEVE_SEWELL: Yeah, do you think, so here's a funny experiment we've been running. I'm curious your thoughts on. So as a brief aside, so Builder does have a versioning system built in to have your new old whatever versions and environments and stuff, but that's semi-standard CMSs. I'm actually not sure what the others do. I think we have some unique elements but basically the gist of like you want to make a new version of the home page, edit it separately, deploy that to staging while you still maintain and spot fix your live one, you know, stuff like that is built in and GUI based. But I agree with you. Git has a whole bunch of its own sort of beneficial unique properties. One thing we started is we started exploring that and we found that, you know, the raw data, if you save it to Git, it's looks like it sounds, it looks like raw data, it doesn't look very human friendly. And so the first thing, and you might find this interesting, we're like, you know, the builder data really, actually, if you're familiar with what template ASTs look like, like Angular's template AST or view template, it's really just data that says, you know, this component, these props, this component, it looks identical to the builder data. In fact, it was the builder data format was very much inspired by looking at those template, those parse template ASTs. And so I was like, hmm, what if we actually were able to serialize this to something more human readable? And that's actually what inspired this project we have called mitosis, which it's interesting when you add the ability to serialize the raw data to, we chose JSX because we didn't want to invent a new templating system and I have to have types of support. 

 

DAN_SHAPPIR: I was scared that you were going to say YAML. 

 

STEVE_SEWELL: No, yeah, I would have the same issues. Now what we really want is, what I really want is TypeScript, right? I just, I cannot use anything that's not Types these days, like TypeScripts. It's just, uh, don't want to deal with like a typo breaking production and writing a unit test for every single code path every time. So the question was, can we turn the builder JSON to TypeScripts like TSX some standard way? So I made this project called Mitosis that does that. It, it's a subset of my, of JSX. So it's inspired a lot by SolidJS. I saw JS add some unique constraints to JSX. So the longest time I was like on the fence doing this or not, or I was like, well, people not understand this idea of JSX, but it has additional constraints, you know, mysterious ones. And when I saw Ryan was solo JS, I was like, okay, it's possible. I'm doing it. And, uh, we made an ESLint plugin or actually an amazing contributor to mitosis made the ESLint plugin. But basically, so yes, like we'll catch, you know, all the rules you're not allowed to do, but basically you could turn anything in builder to JSX. And that makes it much more friendly to synchronize to your code base. And of course the reverse works to modify the JSX goes back to builder, but that's where things got really crazy. And that's where we started exploring, like having the builder ID, like pull out code on one side and drag or drop on the other, and you can drag and drop on the left and see the JSX on the right edit. You can go edit the code or we use like VS codes embedded editor Monaco. So you can do multi-select and do big sweeping changes to the code in the UIs update. And that was the really cool part. And that's where we took it one level further because Builder needs to output to pretty idiomatic performance, high quality code for views, fell, solid, just quick, all those frameworks. So we made Mitosis even a standalone project where you can write components with JSX or TSX and output them as pretty surprisingly good quality code for the other frameworks. And actually that's how we build our SDKs, those renderers. And that's how others are exploring building things like design systems where web components is an awesome idea, but I get on trouble on Twitter. I have issues with web components. And the Chrome team is not happy about my comments on web components. So I have to tame it a bit, 

 

DAN_SHAPPIR: but this idea of one Alex Russell to debate. 

 

STEVE_SEWELL: Oh, I actually was a fan of Alex Russell though. We do have a difference of opinion on web components. He's anti JavaScript, which I, we are, but he's pro web components. And it doesn't compute with me because that's a pure browser runtime JavaScript system. I would love to hash things out with Alex sometime because I, yeah, there's something I must be missing there. 

 

DAN_SHAPPIR: Oh, you know, 

 

CHARLES MAX_WOOD: let's have them come cross swords. 

 

DAN_SHAPPIR: I'll try to organize it. Let's see if it works out. Bring either, you know what, you can make it even a total free for all and bring Rich Harris on board as well. I know he has some strong opinions about web components as well. 

 

STEVE_SEWELL: That'd be a blast. 

 

DAN_SHAPPIR: Look, I'm totally geeking out on what you're describing because literally what you're saying is that you've kind of created this wizzy wig coding environment, like code generation from drag and drop, which is not just creating some weird internal use JSON files, but literally, totally human editable TSX files that are resulting from just dragging and dropping stuff around. Now, obviously there's no reason why not, but because, you know, it's text, but it's so, so yeah, but it still sounds really, really, really cool. And obviously it could also be like, I guess you're hinting a sort of a solution to the versioning issue because once it's code, we know how to version control code. The flip side though, and that will be one of your challenges is that at the end of the day, one of the goals is that the people doing the whizzy wigging aren't coders and then they probably shouldn't have to deal with Git merges. 

 

STEVE_SEWELL: Yeah. Yeah. It's interesting. 

 

DAN_SHAPPIR: You know, it's good for you to have these challenging problems is all I can say.

 

STEVE_SEWELL: It's definitely fun. And yeah, it's not obvious. We do a lot of exploration. And then when we're like, this is intriguing, but questionable, we go back to the core product. And yeah, so it's kind of one of those things where like, okay, the core workflows are working well. But at a certain time, you know, a lot of also what we do is we do a lot of waiting and watching in the ecosystem. Like one of these days, someone might solve a way to do visual get merge conflict resolutions. Like that's your point. That's the big issue is the marketer somehow things have gotten out of sync and the marketer needs to do a merge conflict resolution and they're like, what the heck is happening? So really if that piece can be solved or there's interesting research in the ecosystem, we can use, borrow, emulate, whatever that may open up some new stuff. So it's just fun to be on the on in an area where we're able to explore new stuff and know that it's so net new that things will evolve over time, we'll kind of be after it, it's fun. 

 

DAN_SHAPPIR: Now I have to bring up a video that I watched that you did with Jason Langsdorf, I hope I'm pronouncing his name correctly. I think it's starting to get a bit dated I guess, it's over a year old, but it was an excellent description and a visual representation of what you're doing. And I think it's worthwhile watching, first of all, obviously to see what your product is although I assume it's come a long way since then. But beyond that, basically just to understand this huge or really important use case for you, which in that case was the integration with Shopify, where you're using Shopify as the data source rather than for the e-commerce data, rather than having it within your headless CMS. But using your WYSIWYG to build a Shopify store or a sophisticated Shopify store using drag and drop, which is awesome because Shopify's built-in or inherent drag and drop capabilities are currently fairly limited. You can customize their themes, but their themes are mostly kind of preset. Now, we actually, in the previous episode, had people from Shopify talking about their hydrogen environment and this is, was especially cool for me in the con in that, you know, again, when watching your video, because in that video, like I was joking with you before we started recording that like half the video was you configuring the next JS environment to properly integrate with Shopify. And that's, I guess, kind of one of the things that they're really looking to solve with hydrogen, that it's kind of integrated out of the box. So I'm thinking if I'm able to easily drop. Builder IO into Hydrogen, then I automatically get WizzyWig for Shopify, which I guess is awesome? 

 

STEVE_SEWELL: No, that's spot on. That's actually two comments on this. So one is that's exactly what you get. So we have a demo example of using Builder with Hydrogen and it's easy as expected. You just need a Builder key and drop that Builder rendering component anywhere you want. A lot of people make a special catch all route to build create landing pages on the fly and the URL just plug it in. And then sections like maybe the bulk of the homepage between that header and footer. And maybe another common use case is like people usually have promotional content on collection pages like at the top, like, you know, this is why our dresses are amazing, you know, whatever. Or more particular, more common is on the product pages. They will usually have a whole region dedicated to marketing content, you know, below the basic product information is the whole story of the shoes and who grew the materials where the shoes are, why the quality is so good or why they make, I don't know, why they're just amazing products in general. And that's where the Wissy Week is handy because the marketing can experiment like crazy. We do have built-in conversion analytics too, so they can run split tests. We do it in this interesting performance way. So they can say, okay, let's test talking about the shoe material versus the shoe construct or whatever. Let's see what converts more. And we can generate a heat map and do all that. But the gist of what you're saying is spot on, is one of the biggest challenges with Shopify, in my experience, especially for upmarket, is a small business, you could spin up their basic gaming system and you're fine. You don't need to go super bespoke. A larger business needs to get in there, they need to run tests. They also often want to personalize a lot. If you're a return visitor, you should see different content than a brand new visitor. A brand new visitor doesn't know anything about you. You should show them something that explains who you are return visitor may not know your latest product release. So maybe you should prioritize that or another common use case as well. And this works great with the API driven approach, modern, more edge oriented platforms like Hydrogen's oxygen. You'll frequently like Everlane, one of our customers that many do various similar use cases. The homepage of Everlane will look completely different if you previously have visited the sites and shopped men's products versus women's products. Cause as you can imagine, if you're just there to shop menswear any screen real estate focused to women's wear is a waste of space. And that makes a big difference on if you're going to buy things, if you're going to find something you like, or if you even just feel like this website, this brand is the right brand for you. Right? And so, and if they've never seen you, they just show you a mix of both. It's really cool. And when you have a visual system like Builder, that's just a click, click, click, you know, click, click, click, menswear, you know, targeted at men's click, click, click, women's wear plan. Their marketing team last holidays, they made a hundred versions of their homepage because it was just personalized, AB tested, scheduled, and it's not hard. It's a wissy wig. It's just edit the blocks, enter the props, that type of stuff. And so with Hydrogen, with Shopify's default platform, you start to outgrow it. So you want to change up the front end and use a next chance or whatever. The huge problem people find is, like you said, Shopify's sort of visual editing is limited. But it's actually more than you get in headless worlds like Jamstack. There's kind of nothing. And so that's actually been a pain point for Shopify merchants as they go to a custom stack and even those basic things in Shopify kind of are non-existent. And maybe your website gets set up with this giant, you know, theme data model in CMS and you really are kind of blindly plugging in options and I'm being generous most of the time that's just sitting in code that's nowhere to be edited by the marketing team. A system like Builder kind of gives you a more modern approach and works for the new tech stacks and for performance and stuff. So it definitely makes a very, very interesting and compelling offering. I'm excited to see more people adopt hydrogen. I think it's still probably early. I think it's in beta. I think React server components have a couple clunky areas, but I'm hoping we'll start seeing a wave of people adopting the more modern setup because admittedly Builder works nicer in those setups. Working with their liquid environment is very constraining. React is much more conducive to how we'd like to work. 

 

DAN_SHAPPIR: So to summarize, when is Shopify buying you? 

 

STEVE_SEWELL: They have, surprisingly actually, they've never knocked on our door. We've had others, but not them. Ideally, they don't. We like to be platform agnostic. We like to be this sort of modern visual developments, not bucket into one category. But hey, you never know. We're friendly with that team. We like them. 

 

Hi, this is Charles Max Wood from Top End Devs. And lately I've been coaching some people on starting some podcasts and in some cases, just taking their career to the next level. You know, whether you're beginner going to intermediate and intermediate going to advanced, whether you're trying to get noticed in the community or go freelance, I've been helping these folks figure out how to get in front of people, how to build relationships and how to build their careers and max out and just go to the next level. So if you're interested in talking to me and having me help you go to the next level, go to topendevs.com slash coaching. I will give you a one hour free session where we can figure out what you're trying to do, where you're trying to go, and figure out what the next steps are. And then from there, we can figure out how to get you to the place you want to go. So once again, that's topendevs.com slash coaching. 

 

DAN_SHAPPIR: I'm hogging the conversation. I'm just having so much fun. I'm just a little curious. 

 

CHARLES MAX_WOOD: No, no, it's totally good. I mean, I'm imagining, because you're talking about Shopify, but there are other areas that you kind of mentioned that that this can go to, right? And you've talked a bit about sort of the website generators like Next and stuff like that. But you also mentioned like Rails or, you know, some of these other systems. And so I'm a little curious, you know, how do you pull it together in there? I mean, do you just take advantage of their front end stack and NPM install stuff and it just kind of works? Or how are you going off into those areas and making it available there? 

 

STEVE_SEWELL: Yeah, that's a good question. That's where basically the catch all solution is that HTML API. So the Rails example would be like the Astro example on your, in fact, we have a little read me that somebody made one time. A common use case on like a Rails is to create, is essentially to override your 404 page. And the 404 page, instead of being like, you know, not found, instead that catch all page, and forgive me, I'm not a Rails developer, so I can't speak to the details. Basically that catch all route will actually, every time it does not find a page, you know, within the Rails environment for a URL, they're actually ping builder and they use the JSON API to be like, hey, do you have a page for this URL? If so, we give you that JSON with a field for the HTML and you just pop that in, change the status back to 200 and serve the page, usually within a template like between your header and footer. 

 

CHARLES MAX_WOOD: Okay. 

 

DAN_SHAPPIR: Now you were talking about the fact that your framework or platform agnostic, which kind of leads me to one another thing that we wanted to discuss, that I wanted to discuss. Although You have a gun bar ahead of this podcast and you have, who was also a guest here a couple of episodes back really, you really wanted me to talk with you about it. So it'd be really angry if I don't. And that's the fact that you have your own framework, which is called quick. And the one of, uh, and your CTO, I think is Mishko, which who has from angular of angular fame. 

 

CHARLES MAX_WOOD: I love Mishko. He's a cool guy.

 

STEVE_SEWELL: He's awesome. 

 

DAN_SHAPPIR: And I guess he kind of owns this new framework, I guess quote unquote. And so a few words about what it is and how it fits into the Builder IO vision. 

 

STEVE_SEWELL: Yeah, yeah, let me explain that backstory. I think it's pretty interesting. So one of the things we're most proud of with Builder is whatever you make inside a Builder, we go through a painstaking effort to make it performance. Wissy Wig site builders, if you go back all the way to like Dreamweaver and Microsoft front page, they have a very well-earned stigma for making, generating awful code. Buggy, clunky, poor performing, bad code, right? So generally speaking, people don't expect to drag and drop and create the world's fastest website. You usually expect it's not as fast. And when we started with Builder, speed was a concern. Like we wanted to make sure it outputted fast. Everything was fast. It would load quickly, images were optimized, whatever. But I actually found that when we started acquiring our first customers, which were on the larger company side, That was a hardcore requirement. So we went pretty all out on the performance aspects of Builder. In fact, we had one in general, one company who would drive me crazy because if they ever handwrote anything in their code that performed better than what Builder generated, they would complain. And it was like, well, a automated system ever outperforms a paste stinkingly handwritten code base. And after a thousand cycles of this, I actually came to the conclusion that maybe. And what I mean by that is, and I'll get to quick, I promise, it's a little bit of lead in the backstory. And one thing I learned is before, like I've been like tweeting out performance tips and stuff though I've actually paused that because some of them were debatable and people get really angry if they disagree. So I'm like, you know, maybe I'll just stick to the CSS tutorials and stuff like that and some occasional hot takes. But one thing I did learn seating out performance tips, especially those that were generally considered people agreed on, people just don't know them. I mean, performance is something that's always changing, like the best practices with the browser support 

 

DAN_SHAPPIR: and something that is performance all the time i don't know people take it fairly well 

 

STEVE_SEWELL: i just did something wrong then actually i know what it is i used to tweet bite-size tidbits and people would take them wrong and i realized that Twitter, a single image is too, for me, for the content I was doing, was too limiting. I thought people would understand. There's only so much you can fit in 140 characters and small image. 

 

DAN_SHAPPIR: Oh, for sure. I'm kidding. Although, and you know, people on Twitter though never take things the wrong way, I think, you know. 

 

CHARLES MAX_WOOD: Oh, no, never. 

 

DAN_SHAPPIR: And they're almost as friendly as the people on Reddit. That's what I've found. 

 

STEVE_SEWELL: You are so funny. Almost. I've made I've made a list Reddit, Hacker News I would say is the, the harshest followed by Reddit followed by like Twitter than like LinkedIn, TikTok, YouTube. Anyway, I have the same hierarchy in mind, but you know, I started doing is I started doing videos because when people don't watch the video and they complain, you're wrong about X other people reply and they're like, you clearly didn't finish the video. So it gives you more room to make sure you're like, if you're hearing me this way, this is actually like what I'm saying. Anyway, sorry. Back to the topic of performance. I've definitely learned that Unless you're studying performance all day, every day, you're not going to know every trick out there. In fact, people would argue at this one company, they would argue that a certain way of generating a source set is better than we were doing. I would have to grab data and prove that they were wrong. But it's one of those things that you know, it's nuanced and complicated. I really learned, we take a lot of inspiration from the LLVM compiler, like high level, just that idea that they can compile so many, what they call them frontends and backends, but like the input languages like C, Rust, C++, Swift, whatever, and then generate lots of machine architecture code for all the different outputs. And in that compiler, the nice thing about a compiler, actually the pro and con of a compiler, is you can make them infinitely complex. So if anybody's like, oh, there's some optimization you can do by hand for a certain set of conditions for really optimal code, you can just build into the compiler. You can build a system to detect the conditions and to generate it And you can make the compiler infinitely complex, almost infinitely knowledgeable of all the incredibly nuanced performance best practices. What we started learning with Builder is we were able to just bake all those into the Builder generators or compilers. And so on average, we tend to find that just an average of your hand coding stuff is not including as many performance best practices as what we're generating. So we were feeling really good about that. We're saying, hey, not only is this a great way to generate content that just all the best practices are just built in there for you, there's still areas to improve, don't get me wrong, so I'll say many best practices, but it's always been better. 

 

DAN_SHAPPIR: I have to add on what you're saying. First of all, I totally agree with everything you're saying, but I think you're kind of being generous to an extent because you're saying, I'm comparing myself and I want to be better than the best developer with the most, the developer that's most knowledgeable about performance best practices whatever percent of web developers are not that knowledgeable about web performance. 

 

STEVE_SEWELL: Exactly. 

 

DAN_SHAPPIR: Like a case in point that I like to give is that if we compare the performance of Wix, which is totally wheezy week, but build actually on top of react to the performance of react in general, then the ratio of Wix websites with good performance is 50% higher than the ratio of react websites in general. So a person building a website using Wix drag and drop, which ultimately generates a React website, is 50% more likely to generate a fast loading website than a React developer doing it by hand. It may not be nice to hear, but that's the truth. Now, if you're able to take it a step further, like you're describing and generate websites that are better performing than those created by people who are actually performance experts then you know more power to you. I mean, it'll be amazing if we can automate that. If we can also then automate accessibility, for example, and automate other stuff like that. I mean, you know, we fixed the web, but please go on. 

 

STEVE_SEWELL: No, I mean, that's precisely the goal. And you're right. I mean, that's the interesting thing about WissyWig is you can build it in to be more intuitively semantic. So if you're an HTML developer, have you memorized every HTML tag and ARIA attribute? No, Jesus, there's a lot. But in actuality, like when you're using a Wistewig and you're just grabbing templates and components, a columns component, a button component, it's just going to do the best practices by default to the extent that it can. But usually you're building kind of less low level pieces and more kind of off the shelf pieces, which allows us to do some more of these best practices across the board, which is nice versus very granular. I mean, there's a lot of developers who are still using divs for everything. Div on click, like it's, it's ugly, but in builder you'll grab a button, right? The button component, uh, does a styling reset as you expect. It's got all of these sort of correct ARIA behavior. I mean, stuff like that, you know, really makes a difference. 

 

STEVE_EDWARDS: So that brings up, that brings a point I was wanting to jump in here and make, you know, having come from, I started out in Drupal world, if you familiar with Drupal. And there's a lot of, of modules that people had built that were very highly used. And, you know, in looking at those and some of the discussions that rage, I can, can't even comprehend the difficulty in trying to come up with something that somebody can drag and drop and have it build good HTML that's going to suffice for all of the different use cases in which it's used. You know, I think of panels, which was a drag and drop API that allowed you to break your page into different sections, right? Or views or stuff like that. And one of the common complaints that used to drive the creators just nuts was what we call divitis. You know, a div on top of a div on top of a div on top of a div on top of a div. The other day, I was looking at a page that Astro said that I'm talking about we just did a proof of concept inside of Wix. And so I was looking at the source code, the page code for the Wix website. And it was divitis. It was crazy. With Wix, it's definitely 

 

DAN_SHAPPIR: divs all the way down. 

 

STEVE_EDWARDS: Yeah, divs all the way down. 42 of them, to be precise. I do that too, so. Let me give myself a rim shot there, thank you. So the question is, and then in terms of Symantec HTML, you talked about Symantec HTML And we've had, if you look back at the JavaScript Jabber archives, we've had people come on to talk about all the different HTML elements and what's best in terms of accessibility, right? Accommodating your blind users or the people that are used between, you know, whatever. Dan, I don't remember who your friend was. 

 

DAN_SHAPPIR: Bruce Lawson. It was an amazing episode. One of our best, I think. 

 

STEVE_EDWARDS: Right. Right. It was really great. So here's my All of that to ask my question for you from a builder standpoint. If I'm going to go, you know, generally if I'm building an application, I'm using view, I'm using Astro, something with a template, even going back to Drupal. Okay. You want to use header. You want to use nav. You want to use main, you want to use section. You want to use all these different semantic elements that are going to help with your accessibility issue. How does builder handle that? Is that something you can tweak or, you know, cause basically as you've described it. In Builder, we're building our whole rich, you know, Prismet calls it a rich text field. You can call it whatever you want HTML. And then all we do is plop in the render component, which tells me I have no control over how that JSON is rendered. So how do you tackle a task like that where you're trying to be all things to all people who are building complex UIs in your Builder, but at the same time, doing it in a way that's somewhat clean? 

 

STEVE_SEWELL: Yes. No, this is a great question. And I have, I have two answers. I have the like tactical technical answer and like the broader answer. I'll give the broader answer first because this is the interesting thing. Like businesses or technologies are born from a set of conditions and constraints. So as you might know, Wix, Squarespace, there's been some wissy Wig builders out for a while. They pioneered this initial generation of like, and SMBs all the way up to some decent sized companies can build out some pretty fascinating stuff. Wix with a deeper control Webflow came in with their take, you know, this first generation of Wixie Wig builders. Actually, that's not fair to say. I mean, there was like Dreamweaver and whatever generation. I'll say the first generation are really caught on. Like there's a really good reason to use Wix for a ton of businesses, right? Dreamweaver is questionable. Who should use that or when or why? Or it might be deprecated. 

 

STEVE_EDWARDS: Okay. For that, go back to front page 98. That's where I started. 

 

STEVE_SEWELL: Exactly. I mean, so that's not to discredit the front page was awesome in its own ways. 

 

CHARLES MAX_WOOD: Yeah. Oh yeah. 

 

STEVE_SEWELL: But I think what we've seen is at the time those tools were created, it was just hard to make a witty wig in general. It was always a complicated task to build one of those dang things from scratch. So just like any engineering project, you have to pick what is critical to deliver and what is nice to have. And always in these cases, especially when you're talking tools for these sort of more SMB or small or occasionally in these use cases, high quality code output, high quality performance was not a critical factor. It was just like solve the drag and drop in general, try and make it mildly intuitive, right? That was the critical and everything else had to be pushed back so you don't spend time on things that are low value to your users, any business, any engineering project. And so, as those things took on, I think what we saw with Builder specifically is there's no reason not to use a WistiWig Builder if you're a small business freelancer, etc. I mean, unless you're a developer and you just want to make an Astro site for fun, for the most part, like a WistiWig for an SMB or smaller is a no brainer option for the mid market, especially enterprise companies in the world. It's like Nike dot com will probably never be powered by one of the witty wigs of the current generation, right? Nike has too many customization needs. They want to choose every element of their stack. The witty wig has to be the most minimal part that makes almost no designer architecture decisions for their code. And so that's what where builder came into the market. And we found immediately is what our customers care about the most is the code output, the performance. Is it semantic? Is it ADA compliance? Because a lot of our customers are in e-commerce. E-commerce companies get sued like crazy for not being ADA compliant compatible. I think we're using the wrong term here, but like, if you are not, you can easily get sued in the United States if you have an e-commerce website that is not proper on the ADA side. 

 

STEVE_EDWARDS: Tell me more about that. 

 

STEVE_SEWELL: Yeah. So this is something that, well, this was one of the first asks we started getting is, so forgive me, I'm not an expert on the legal details and stuff like that, but basically in the last, I'm not even sure the time range. I'll tell you the pieces I do know so I don't over extrapolate. Basically our initial customers came to us and they're like, I'm in e-commerce. I keep hearing core stories of e-commerce websites sued because the websites are not ADA compliance. I need to know with your tool, like, will you be ADA compliant? And the short answer was like, Yes, we care deeply about that. We care deeply about the performance, the ability for screen readers to use it, to be as semantic as possible. I'm going to raise my hand and say, we're not a magic wand. We don't do perfect semantic output, but we sure as heck try. And we can talk about that in a minute, how we implement those things. But yeah, these things were top concerns. I don't think in the earliest days of Wix, their customers were saying that. They were scrutinizing the code output. They're just like, does my website work or not? Can I make what I want? Whereas when you're talking enterprise, they're like... The code outputs got to be at par with what our engineers are producing. And I'll be honest, that was mildly annoying at first because even today it's still hard to make a witty wig. But we realized that that was a key area of focus for our company and eventually a key strength of our product. And that's where we made sure to build in from the start a ton of static analysis of the content. So we modeled, we think of us almost like a visual IDE because if, for example, you do bad things. box that has a link, you know, it links to some external page and inside is text with links inside. You can't have links in a links. We'll actually give you a warning with a clear error message like you need to choose link on the outside or link on the inside, one or the other. And stuff like that will be built into the system. And the other really key part here is that all of the components you use in the drag and drop editor are just regard, if you're a view site, they'll just be view components, react, react, and they're all built with accessibility and everything in mind. But not only that is you can replace or customize them. So you can override the components. You can say, actually, our image component should, you know, be powered by Cloudinary. And so that's just there. Or if you want to make your own, like you have your own design system, you use Chakra URI or something, awesome. People are dragging and dropping with those accessible design system of components. You could even lock it down to only allow those. So you make it really strict and really required. Or you use our built-in templates. And our built-in templates, we're very mindful of those things. So the combination of the pieces being ADA compliant and performance, the static analysis, and a little bit of generation side, we can analyze as we're generating, like, oh, I'm seeing some things, let me clean up and make this a little more semantic. We're able to do those things with a caveat within reason. We're always trying to get better. So don't expect the world's perfect website generated by Builder. But I would say expect better than average and getting better than 

 

DAN_SHAPPIR: So we are starting to run out of time and I guess we will need to postpone our quick discussions to the future podcast, maybe with you, maybe with Mishko, but I do have an important question that I still need to feel the need to, to push in and that's what about locking? I mean, if I'm building my website with builder, how tied am I to your platform to your headless CMS if tomorrow you go bust or whatever because you know these challenging financial times or whatever and you're unable to raise another round or I don't know what, how screwed am I? 

 

STEVE_SEWELL: That's a great question. So short answer is surprisingly not screwed, but I'll explain in more detail. So the short answer is all of the data in Builder can be read and written with APIs and observed and synchronized to other systems with web hooks. So if you want to really set yourself up for like What do they call it when people like create motes around their house and survivalist? If you want to be a survivalist, what you can do is from the get-go, use webhooks to synchronize all data and builder in real time to some other database system. And luckily huge swaths of the product are open source, not the visual editor itself and not the APIs, but like all those components for rendering the content. So if you have your own copy of all the JSON data and you need and builder just were to disappear overnight, which would never happen. There would be all sorts of ceremony and heads up and whatever, but say some nuclear weapon hits, you know, whatever it just poof, it's gone. You could continue to take the data out of your database, pass it into the rendering components, which are open source and your site's still live. It's fine. If you're like, okay, next step is, but I need to actually edit this stuff. You're right. The visual editor could in theory be gone. I mean, I always have dreams up in worst case scenario, open source it or whatever, do something with it. But worst case, say the visual editor is gone. The nice thing is the data format of builder is also open source. So you can make your own lightweight editor on top of it. But more importantly, because of our code generation and our mitosis project that open source is the majority of that, you can just transform all that builder content to react or view or quit code and just pop it in the code base. And now your engineers maintain it from then on. And we try really hard to make the code very, very idiomatic. So, uh, it should not look like generated code from tools in the past. It may not always look exactly the same way a developer would have written it, but it should be pretty dang close and be maintainable in all of that. We go to a lot of lengths for that. So that's the short answer is you can still have the data. You can load the data. You can render the data. You can export out to code. Everything can be exported into your own systems. You can even make your own visual editor on top of it. I always imagine in hypothetical worst-case scenarios, I could at minimum get people instructions like here's how our visual editor works. If you want to make a new one, do this or run and make an open source, you know, lightweight version that then the community can take on and take from there. But does that answer your question? 

 

DAN_SHAPPIR: Yes it does. Thank you. Totally. 

 

STEVE_SEWELL: Does it make sense to if we have time, I can without explaining deeply what QUIC is, I can finish the bit on why we made it. I think we went on a couple of tangents, but at least I can mention the necessity of it. Do you think that makes sense? 

 

DAN_SHAPPIR: I think so.

 

STEVE_SEWELL: Let me give that it's brief. I mean, the gist was we made the system to create performance code. We felt very proud of it. We also made it so that if you wanted to do dynamic things like personalization and AB testing, traditionally you'd use like blocking JavaScript that injects content very bad for performance, it could make your website buggy. And so we felt really good about all of this. We started selling builder as builders great for performance, AB testing personalization, the content generated. Great. So people would hook it up to their website, they'd have a React website. I thought the website would be faster. It's still 20 out of a hundred. And that's where we realized we had to explain to people that performance is not like you put a bigger engine and the car goes faster. It's more like a hang glider, right? The more weight you add, the more it kind of slows down. And so if you're adding Builder, Builder is generally speaking, a zero-cost edition, which is great. Most tools that do anything that we do ads performance cost, but we're big on this whole idea that like C++ and Rust champion of every abstraction is zero cost. But in order to improve performance, you have to remove something. And so we started being like, well, wait a second, we had our, the builder.io like marketing website was all powered by builder and it was rendered via React and Next.js. And we were like, let's make one website that's perfectly fast. And so we were getting like 60 out of 100 and I was losing my mind. I could not get it faster. And because we have this ability to take the page and generate code of any format, optimize things in any which way, or change frameworks entirely. I started messing with is view faster as felt faster as solid faster, sometimes a little bit like solid, but like I was really not getting past about a 65 no matter what I did. Eventually I was like, I can't figure it out. I'm going through everything that page beat insights and lighthouse was suggesting. And so I just did a hack and I'm like, you know what, let's just hack and slash. Let me remove big chunks of the page and see what I can remove to make it go up. And I was really trying to get to 70 or something. And I really could not move the needle until what I did is I did a hack and I regexed out all the JavaScript tags and that thing shot to a hundred out of a hundred. And I was like, Oh, and then I had back the JavaScript and things flow way down. And I remember being like surprised, but then not as like, that actually makes sense. The amount of JavaScript that's downloaded, parsed and executed for any basic page in most frameworks, where the Andy framework of today is significant. And that's a significant amount of time and resources on a imperfect mobile device, on an imperfect network. And it became crystal clear, like, crap, I mean, some of these pages don't even do much. Like, why am I having to flush through and hydrate the whole page for a largely static, like, here's what the product looks like type page. And so that's where I started experimenting with, can we compile the builder content to just play in HTML? And that's easy at first until you start thinking you have dependencies and shared components. And that's why I ran to Mishko and he's like, hey, I have this new approach to frameworks where it's pure HTML that's delivered and you don't need any JavaScript unless it's absolutely needed and it's not even executed until it's absolutely required. And that was like, boom, that's what we need. And so long story short, we can go into the framework details another time. We hooked up quick to the builder output and bam, 100 out of 100 every single time until and this was the last piece we had to add our third party scripts like Google Analytics. That dinged us back down again. And that's where we ended up making just to spoil everything, this project called party town, because we needed those third party scripts to run off the main thread because that's what is hindering performance. So we made party towns, allow them to run in a web worker without erroring out because they actually will have using a clever trick access to the a window object and other things. And with those pieces combined quick for the main content party town for third party scripts, cause we can't change those. We just need them run them somewhere else that won't bog down the UI. And then builder generating the content or assume a developer that's half decent writing the content, you actually can have this ideal state of fast website, regardless of complexity. 

 

DAN_SHAPPIR: And now I suddenly remember that originally, I think I invited you over to talk about Party Town. 

 

STEVE_SEWELL: Ha ha ha. That would not surprise me. 

 

DAN_SHAPPIR: So now I need to invite you over again to talk about Party Town. 

 

STEVE_SEWELL: Yeah. I love talking about Party Town. 

 

CHARLES MAX_WOOD: I think we should just get you scheduled for another episode. 

 

DAN_SHAPPIR: At least one. We have two more. 

 

CHARLES MAX_WOOD: Right? Yeah, but then we can dive in. Yeah, 

 

DAN_SHAPPIR: we have two more topics that we want to talk about. 

 

CHARLES MAX_WOOD: Yeah, but we can dive into those and just see where we end up there. 

 

STEVE_SEWELL: That sounds great. 

 

Hey folks, if you love this podcast and would like to support the show or if you wish you could listen without the sponsorship messages, then you're in luck. We're setting up new premium podcast feeds where you can get all of the episodes released after Christmas 2020 without the ads. Signing up will help us pay for editing and production, and you can go sign up at devchat.tv slash premium. 

 

DAN_SHAPPIR: So, Chuck, are you moving us on to pics or what? 

 

CHARLES MAX_WOOD: I am. I think we'll let Steve give us his growners first and then we'll go from there. 

 

STEVE_SEWELL: Yeah, so I have one and this might be a little unconventional. 

 

DAN_SHAPPIR: No, the wrong Steve. 

 

STEVE_SEWELL: Sorry. 

 

CHARLES MAX_WOOD: No, the other Steve. 

 

STEVE_EDWARDS: Oh, I'm sorry. I'm the Steve with the growners. You're the Steve with the good content. I have the growners. 

 

AJ: What does a growner mean? 

 

STEVE_EDWARDS: A joke that makes you groan because it's so bad. Perfect. Actually, before I get into the what I call the high point of every episode, a quick pick. As of today, GitHub Copilot is available to everybody as a post on the GitHub blog. I just happened to see it on Hacker News. 

 

AJ: They released it for them? 

 

STEVE_EDWARDS: I don't know. I'm just looking at the blog post that you can get it. Now the caveat is that unless you are a prolific open source developer, it's 10 bucks a month, but it is available. It was previously on a beta and you had to be invited. That is available now for those who like it and want to give it a shot. You can get a free trial too. I didn't notice how long it was. So you can try it out and decide if you like it, but then it's 10 bucks a month. 

 

AJ: Remember it's always easier to have bad code generated and debug it than to write good code the first time. 

 

STEVE_EDWARDS: Absolutely. I totally agree with that. Okay. So for the jokes, does anybody know the difference between Ironman and aluminum man?

 

DAN_SHAPPIR: No, what is the difference between Iron Man and Aluminum Man? 

 

STEVE_EDWARDS: Iron Man stops the bad guys, Aluminum Man just foils their plans. 

CHARLES MAX_WOOD: That was not terrible. 

 

DAN_SHAPPIR: Yeah, I agree. 

 

AJ: Also, Aluminum Man can be totally destroyed by gallium. 

 

STEVE_EDWARDS: Oh wait, was that supposed to be funny? Or is that chemical? 

 

AJ: Oh, I guess, yeah, you'd have to understand what gallium does to... Gallium, if you expose... So gallium is like mercury in that it's liquid at room temperature. If you expose gallium to fresh aluminum, so if you scrub it a little bit to get the oxidization, aka rust off, and you expose gallium to aluminum, it will amalg, meaning that the gallium will soak into the aluminum and change its chemical structure to just basically become brittle and fall apart. It's not, it's not, I guess it's not a joke. 

 

STEVE_EDWARDS: I was going to give you a, what's such a complimentary...

 

AJ: No, it doesn't. It doesn't deserve it. It's just yeah, if you didn't, sorry. 

 

STEVE_EDWARDS: And then, you know, the one of my favorite lists of jokes are cow jokes. And so I came across an edition the other day. So what are the chances of a cow standing in a field getting struck by lightning? 

 

STEVE_SEWELL: Medium rare. 

 

STEVE_EDWARDS: Thank you. 

 

AJ: I liked it. I liked it. 

 

STEVE_EDWARDS: Yeah, see, that's where I really need like a cow sound effect. That'd be awesome. And then getting back to chemistry You got to think a little bit this one, but it is gettable. Whisk fish is made out of two sodium atoms. 

 

DAN_SHAPPIR: I don't know. 

 

STEVE_EDWARDS: Nobody? Tuna. Since the sodium symbol is NA to NA. 

 

AJ: Yeah. Yeah. Anyway, that was a little easier to grasp than what I was saying about gallium. Still a little technical, but workable. 

 

STEVE_EDWARDS: Yes. It's, it's, it's, you got to think about it, but it's, it's, it's gettable much more than some of the other ones. So those are my picks. 

 

CHARLES MAX_WOOD: All right. AJ, did you have some pictures you wanted to throw out?

 

AJ: Hmm. Let me think if I've been listening to any good books lately, I started listening to Sapiens and that's, that's an interesting book. It's about the history of the human races, not just Homo sapiens, but other Homo's as well, Homo erectus and Homo neanderthalus and another three or four of them, it's only a couple hours in, but it's pretty good would recommend also. I finally got my very own copy of JavaScript, the good parts and oh my railroad diagrams looks pretty cool. 

 

DAN_SHAPPIR: Yeah, that book is a bit dated though, isn't it? 

 

AJ: I don't think it's dated at all, Dan. I think there's no relevant information in this. 

 

DAN_SHAPPIR: Oh, let's put it differently. You think that nothing that has been added to JavaScript since that book came out actually belongs in the good parts.

 

AJ: I think it's a little bit dated because if you watch his the better parts talks, you realize that there's a number of things that he put in the good parts that don't belong there. There could be a few pages of this omitted and it would be a better book. 

 

DAN_SHAPPIR: I think that even you agreed that the sync await can be pretty good, at least in some cases. So I... 

 

AJ: Yeah, yeah. No, I've never seen anyone else use async await properly. But if used properly, async await is actually quite great.

 

CHARLES MAX_WOOD: All right, well, we're awaiting Dan's picks. 

 

DAN_SHAPPIR: Okay, so Steve brought up Copilot. So I'll mention that maybe some of our listeners may recall we had Kyle Simpson, Getify, a while back talking about a company called Tab9, which actually has a sort of a similar offering and turns out that they are still around. And their CEO, Dol Weiss, actually wrote this excellent Twitter thread that kind of compares co-pilots to tab 9 and very upfront about what are the relative benefits and limitations of each one of them and why they end the fact that they actually have a very different approach in architecture and the consequences of that. Now, unfortunately, I won't link to that because this whole thread is in Hebrew. So I guess I will just need to reach out to Doron and basically ask him to translate it. And then we'll be able to link to it. But it's still a fairly, it's very interesting. And yeah, it's cool that we have these two different solutions that actually can be used in tandem. So that would be a mention rather than a pick. An actual pick will be another book by Naomi Novik. So I picked her book Uprooted a while back, it's a fantasy book, a standalone fantasy book, which in my mind is a big advantage. I'm kind of, I sometimes get tired of all these huge sprawling, multi-volume type series that never end. And having a standalone book is like a breath of fresh air sometimes. And I really enjoyed Uprooted. And at the recent conference, I actually had someone come up to me and said that he read it on my, as you know, as a result of my pick and really liked it a lot and actually thanked me for it. So I'm gonna pick another one of our books. It's called Spinning Silver. It's also a standalone book. It's funnily enough, kind of based on the story of Rumpelstiltskin, but it actually is a book for adults and I enjoyed it quite a bit. So I'm recommending that. And I'm reading another one of our books now. So I'll have a pick for another future episode. And my final pick is that same pick I pick each and every time, which is the ongoing war in Ukraine, which I'm really seeing people kind of start to not to think about it so much anymore because it's like, it's like just there and just like ongoing never-ending. And that's really sad because it turns out that hundreds of people are dying literally every day. And I don't know what will bring it the to an end. It doesn't look like it's going to end anytime soon. And that's really sad and unfortunate, but I think it still needs to be in our mind. So those would be my picks for today. 

 

CHARLES MAX_WOOD: Awesome. All right. I'm going to throw in some of my picks now. I'm going to do a repeat pick on the board game just because I had played it a bunch, but I didn't own it. And now I own it. 

 

DAN_SHAPPIR: Just because you can, Chuck. 

 

CHARLES MAX_WOOD: That's right. So I'm picking Lost Ruins of Arnak. I think I mentioned, I think I picked it February-ish cause that's when I got introduced to it and it's, it's a bit complicated game. There are several ways to win and several tracks to follow or maximize. And essentially you're trying to collect treasure and who collects the most treasure wins, but you can collect it by researching, you can collect it by exploring, you can collect it by doing a number of different things and on board game geek, it's got a reading of 2.88, which puts it kind of, in my opinion, uh, slightly higher than the casual gamer. So if you're the kind of person that likes a good game of Monopoly, but don't get too much more complicated than that. This is not a game for you. But if you kind of like one that you have to think about, prioritize what you're working on and explore how to play the game and you like a bit of a challenge with other people, it plays up to four players and it's super fun. So I tend to think that our audience are more the latter than the former, but I know some people, you know, board games to start their cup of tea, they'll, they'll play UNO or Skippo and Don't don't get much deeper than that. This one will drive you nuts if you're that one, that kind of person. So anyway, so I'm going to shout out about that. And then there was another website I was going to pick, but I can't remember what it, what it is right off the top of my head. So I'm going to, I'm not going to pick it. I do want to shout out again about JavaScript remote comp. If you want to speak, just click on the conferences tab on top end devs.com or just go to top end devs.com slash conferences. And you can click it and I'll have a link in there for the CFP. I'm working that out here within the next day or two. You'll have that link up and we're going to be reaching out to pretty much all of our past guests, hosts, et cetera, and just see who can make it on that week. And we'll see how that all goes. So I'm going to pick that. And then the last pick I have is, so I've been doing this school board campaign and I've been working on setting up a way to collect donations because you can donate to the campaign and I'm using a system called Anadot is the one that I'm, I'm a hooking up and you can set different levels of donation and things like that. And it's pretty convenient, real easy to run with. So I'm going to pick them and yeah, those are my picks. Steve, Steve, the guests, Steve, you want to shout out your stuff now? 

 

STEVE_SEWELL: Yeah, I have, um, you know, I don't think I have anything more to self-promote. That's top of mind. I actually think the one thing that I think people are developers in particular are sleeping on, but shouldn't, this might sound weird to make me lose credibility with half your audience, but. Do any of you use TikTok? Oh, you do. So in, in my experience, a lot of developers don't use TikTok. I've always liked the app. I, again, I had to give it a couple of tries. First one I was like, ah, there's people dancing. Get me out of here. Second or third time came back around. Maybe second time I thought it was too much of a waste of time. Third time actually put in a little more time and my sort of feed on it became a little more curated. And I started discovering some things. I found that it actually could be amazing learning resource with a caveat of decide what's a good credible source or not. I've learned some random misinformation about random stuff. One thing that was going viral on TikTok was people describing what, when it says it's a 50% chance of rain, what it actually means, and they were 100% wrong. I know it was embarrassing because I believed them. I believed them. I said it to someone in real life. They proved me wrong. I was quite embarrassed. So be careful with that. But here's one example. 

 

STEVE_EDWARDS: If it's on the internet, it's true. Didn't you know that? 

 

STEVE_SEWELL: Exactly. I mean, he was the same judgment. And maybe the shorter form can make misinformation spread more rapidly. You know, if you're making an hour long YouTube video, maybe it's better researched. I mean, maybe debatable, but here's one example I really like. There's this guy goes by the handle designer, Tom, he will give you, he will do it this or that for UX stuff. For instance, should table headers be left aligned or right aligned? Basic stuff or like should the icon. Oh, sorry. Actually, I think he discussed that one briefly. What are other good examples? 

 

DAN_SHAPPIR: But can you center in CSS, Chuck? 

 

STEVE_SEWELL: That's true, but CSS, just do whatever is easier. 

 

CHARLES MAX_WOOD: Nobody said anything about CSS. They just said table headers. 

 

STEVE_SEWELL: Yeah, it's UX designs. They're not worrying about the platform specific. Other examples are like, should you use your brand colors for buttons? Should the button be the color of your brand or should the button be some other color dedicated to buttons? He'll take these simple things that you may or may not have thought about. And in literally 30 seconds, do a surprisingly good and well researched and sophisticated breakdown of here's the arguments for each, but you know, the evidence lands here, use this. And I find them wildly entertaining and informative and they dictate my decisions on a day to day basis. I started producing TikToks in part because I found Twitter to be such a brutal environment for posting content, especially if you're new to it. Like if you're new and just kind of learning, like I learned by making mistakes, just how I am. Like people will, they are ready to come get you. I shipped it to TikTok because at a certain point it just got brutal and I was like, should I just stop doing this or should I try something new? So I went to TikTok. My goodness, people are so much nicer and encouraging and would say nice things. Like if somebody saw the video and thought to themselves, this is a nice video, I learned something, they'll say it and it'll make you feel way better because Twitter, they'll rarely tell you that, you know, I liked what you posted. Sure, there's the hard button, but the people who are actually giving words are usually there to want to prove you wrong or counter argue or straight up insult, you know, depends on what the content is. So I started spending more time creating content on TikTok. And I just found it to be a very, very, very good experience. And I started meeting other people and I've been trying to do the similar like, let me take something you've wanted to know. Like let's take something cool on the website you've probably seen, explain how to do it in a simple performant way. Try and end it in 30, 30, 60 seconds. The reception has been good. And I've enjoyed it immensely. And so developers who think TikTok is just for people dancing, it's come a long way since then. They're very good at personalization. In fact, that's its own fun game to try and reverse engineer how they're deciding what content to show you, separate topic entirely. But I like it. And there's, there's more and more good engineering, like front end development content. So it's worth giving another look if you either have dismissed it in the past or never tried it. I like it a lot. 

 

CHARLES MAX_WOOD: Yeah. I'm so I've gotten into it. Some, uh, what I found is, yeah, they. when you get in, they immediately hit you with the people dancing and stuff like that. Yeah. And the trick is, is you go in and you find, you find the other content and you can search for all kinds of stuff. You can search for the hashtags and so whatever you're interested in, there's probably content for it. There's, there are programmers, there's programmer TikTok talk to be sure. And so I'm just getting into putting content on there. And so I'm probably going to be putting stuff on there and on Instagram reels. Both of those are going to be at a top end devs and yeah, we'll be talking careers, we'll be talking tech, we'll be talking all kinds of stuff, but yeah, it's definitely an interesting platform. They tend to want you to put some music behind it and, you know, make it a little bit more of a thing with your content. But you know, if I can inspire somebody to do something, do better in their career to, you know, believe in themselves to try out a new technology that's going to move the needle for them. Any of those things, I consider that a complete win. Anyway, I didn't mean to hijack your pick, but it's a growing platform within the tech space and it's definitely worth checking out. 

 

STEVE_SEWELL: Yeah, the growth is, someone showed me the data. The growth on TikTok is insane. It is definitely growing at a faster rate than anything else. Surprisingly, number two is Reddit. I did not realize Reddit is actually still growing at a pretty wild pace compared to the others, but yeah, I'm a big fan of TikTok. 

 

STEVE_EDWARDS: I will. played a little bit of devil's advocate there. And I saw an article about this yesterday is who owns TikTok and what they do with user data. I mean, it's basically an arm in the Chinese government. 

 

DAN_SHAPPIR: Oh yeah, but that's kind of true for every Chinese company more or less, you know, unfortunately, unfortunately, but you know, it is what it is. Yeah. 

 

STEVE_EDWARDS: Anyway, I'm just putting that out there. That's, that's. that's the reason i don't have it on my phone i'm my 

 

DANl what the yeah but what that's right on that you actually have on your phone and and is your phone from itself from china 

 

CHARLES MAX_WOOD: i was gonna say 

 

AJ: the latest most up-to-date beyond the science mental health guides where are you gonna find that 

 

STEVE_EDWARDS: my phone is iphone so it's made here in the u.s so i'm not worried about that are you not worried about mental health 

 

DAN_SHAPPIR: i'm just waiting for the drum for the drum roll steve 

 

STEVE_EDWARDS: after that one

 

CHARLES MAX_WOOD: Yeah, I was gonna say Yeah, the iPhone on my iPhone was made in China. Anyway, any other pics you had there, Steve? 

 

STEVE_SEWELL: Nothing crazy. Did I forget anything important? 

 

CHARLES MAX_WOOD: The only other thing I would ask is, how do people find you? So give us your TikTok handle and your other stuff, GitHub. 

 

STEVE_SEWELL: Great question. I have the same handle everywhere because it's awful. It's Steve8708, but wherever you find me, Twitter, where am I these days? Twitter, Instagram, TikTok, YouTube, Reddit. There's something else. I'm on all of those. 

 

DAN_SHAPPIR: How do you find time to run a company? 

 

STEVE_SEWELL: I am wildly efficient. And generally speaking, I post the same content everywhere. Usually the same exact format. So that's how I'm doing it. 

 

CHARLES MAX_WOOD: Cool. All right. Well, we're going to wrap it up. Thanks for coming, Steve. 

 

STEVE_SEWELL: Thanks for having me. This was a blast. 

 

CHARLES MAX_WOOD: All right, folks. Till next time, Max out. Bye. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit. c-a-c-h-e-f-l-y dot com to learn more.