Steve Sewell is the CEO and co-founder of Builder, a next-generation visual design and collaboration tool for web content creators and developers. Builder includes a WYSIWYG designer for the marketing folks, and it has a great deal to offer the developers too. Basically, Builder is a system that allows for fully customized components to be laid out in the UI, then connected with APIs and data stores, all without losing the ability to still modify the underlying components. At the same time it streamlines engineering and business stakeholder interactions in the development process.
I recently spoke with Sewell about Builder, the envelope-pushing technology stack that makes it go, the crazy level of innovation in the JavaScript space right now, and more.
Matthew Tyson: Glad to have a chance to talk!
Builder is a drag-and-drop designer but also much more. You must spend a lot of time pushing back against people’s impulse to pigeonhole it as a WYSIWYG editor?
Steve Sewell: A new product category requires a lot of educating of the market, right? People see “drag-and-drop from my tech stack” and they can be loaded with confusion right there.
Like, how do they integrate? They think we must be a site builder. But we’re not.
We just build up pieces connected to you. It is API-driven because our whole goal is to make sure that you can have a good end-to-end workflow. Marketing on your team can jump in, make a new page, configure an A/B test and run it and then see the conversion metrics without going through code deploys and stuff like that.
And people wonder, how do you do that? That sounds like witchcraft. Then we have to explain all this stuff.
Tyson: What are some of the misconceptions you encounter?
Sewell: We need to dispel a lot of myths people immediately have in their heads. People generally think, “Oh, drag and drop. I’ve worked with a tool like that before… five, 10 years ago, and it’s going to be poor performing. It’s going to be buggy. It’s going to be limited.”
And we say, no, actually, this is an extremely unique approach to something that might seem familiar, but it’s wildly different. It has good performance and it has such amazing flexibility and compatibility with your entire code stack.
We’re a friend of choice. We’re backing up choice. All your services, your custom code and logic, they all plug in nicely.
Tyson: One challenge we’re all dealing with is the proliferation of front-end JavaScript frameworks. I mean, it’s kind of crazy. I’m not sure there’s ever been quite such a situation, in that there are so many contenders and so many of them are promising.
What do you attribute that to?
Sewell: This is a great question. Why so many front-end frameworks? I think a lot of this stems from the digitization of the world, right? Everyone needs to go digital. Everybody needs to sell, transact, communicate, convert online.
My prior experience was leading the web engineering team at a company called ShopStyle. They were crawling all of the merchants online, providing a shopping experience all in one place.
We were originally on a very legacy technology stack and we moved to a more modern one (AngularJS) that allowed the developers to move much more quickly. Because they no longer had to worry about, you know, the parts from the server to the client. All the state was in one place. All the logic was in one place. And the DX was quite nice compared to an older sort of Java monolithic stack and jQuery, which was hard to maintain. It was a cleaner, better structure.
But then you find the next set of problems, which is when everything’s happening online, the conversion rate matters a lot online. And when everything’s shifting to mobile, you find that two things are critical. One is that the initial page must load very, very quickly for the end user. So that means small amounts of content to download: as little JavaScript as possible, as little HTML as possible, optimized images. Everything has to be the tiniest thing that’s necessary. And second it has to respond to the touch quickly. It needs to render the updates quickly.
You have these three very difficult needs, and it’s hard to get all three. It’s kind of pick and choose which one you want to optimize for… maybe two, but definitely not all three. Between developer flexibility, moving quickly, testing new features, new content, fast initial load time. So it’s tiny payloads, very optimized, almost no JavaScript, and then fast interactions. The next page should load pretty much immediately as well. We’re seeing there is extreme pressure to get those things right. And it’s extremely hard to do that, right?
So we in the JavaScript community have reacted by striking a pretty good balance of pre-rendering it on the server. It does involve downloading a lot, generally speaking, for a real-world application to hydrate that app. And then you can navigate fairly quickly. But I think some things, like SolidJS, show the navigation could be a lot quicker. We can just jump right to DOM mutation. We can keep that good DX. There could be wins there and there are people chasing that goal. And this is starting to create a whole new wave. People are asking, how can we load the application with less JavaScript or no JavaScript?
That’s where you have people like Astro trying to do islands, trying to be HTML by default, islands that lazy load when needed. There are pros and cons to that, in terms of the communication and how much needs to be hydrated. Then you have approaches like React Server Components, which say, hey, we can also produce mostly pure HTML and remove a lot of the DOM runtime.
Then you have the most extreme, in our opinion, which is Qwik, which basically says a page can initialize with no JavaScript at all. Realistically, it’s less than five kilobytes of JavaScript to have a bootloader. But anyway, we’re seeing these competing trade-offs and these very difficult circumstances yet this huge economic pressure. Pressure to be faster, lighter, simpler.
Tyson: Do you have any sense of where things are headed? What will the scene look like in a few years?
Sewell: Where things are headed is super interesting.
Let me tell you the part that we’re focused on. That is that initial page load. That’s something that the latest Jamstack movements, in our opinion, are really falling behind on. It’s very hard to find the e-commerce website or website in general of decent scale that’s got a decent number of engineers contributing to it, the engineers it needs to run an A/B test and personalize and stuff like that. You know, it’s hard to find one of those with a very good Google PageSpeed Insights or Lighthouse score. And I mean a real-world score like Google PageSpeed Mobile, where it’s testing on a 4G connection and a low-powered, emulated device, not on your gigabit-ethernet MacBook Pro M1, right?
That’s not what we’re optimizing for. We’re optimizing for real-world use cases. That’s really hard because all of the current frameworks require downloading a lot of JavaScript to become interactive. You’ll see some HTML, but there’s a lot to download and execute in the mobile device before you can start interacting. That’s where we’re seeing a big movement to pure HTML.
What’s the tiniest amount of JavaScript we can deliver yet somehow wake up and continue to be interactive? That’s the goal.
Tyson: That’s a good one-liner that highlights one of the chief approaches to moving forward with JavaScript: What’s the minimum over the wire to arrive at an interactive starting point?
Sewell: And that’s where you see frameworks like Marko, which has been leading the way in a lot of ways. You see frameworks like Astro trying to do this islands architecture, which has pros and cons.
And that’s where you see Qwik pushing this to an extreme, which is being able to initialize a page with less than five kilobytes of JavaScript, but then to be immediately interactive. And it’s really, really crazy technology inspired by many, many different places, but that’s the golden end result people are looking for – that your page is downloaded with just a tiny bit of HTML and you’re not downloading a bunch of JavaScript.
When you start interacting, then a little JavaScript comes in and then the interaction behaves as expected. All this but still maintaining the DX of using components.
We structure a kind of declarative view of what the app should look like, and then the updates and the reactivity should just work. The bundling should be optimized automatically. We shouldn’t have to be wrestling with these things by hand. They should just work. So that’s where we see this stuff headed. How do we deliver the tiniest payload as fast as possible, but still be rich and instantly interactive, which is really quite difficult. And there are a lot of approaches and that’s where Qwik is interesting – in that battleground with the others.
We have pretty good DOM rendering performance, and we have libraries like SolidJS that push it further and a few others, but we’re definitely seeing more focus on the initial load time, more pure HTML, less JavaScript. I think there are those out there who have been using service frameworks, still to this day, and aren’t adopting the heavy JavaScript front-end frameworks like the Reacts because they just don’t feel comfortable. They want pure HTML and a little bit of jQuery. We’re finally breaking ground on ways that we can do this and satisfy the needs of everybody in clever ways that were very hard to figure out.
Just to be clear, Misko [Hevery] on the Qwik side is the one who figured out all the really key, important pieces there. There’s a lot of great research by other teams going on too.
Tyson: I have to say, when I looked at Qwik (the Stackblitz example) I thought, wow, lazy loading boundaries at the state, resource, and events. What is possible with this?
Sewell: Totally agree. The Qwik stuff is amazing, and we’re only scratching the surface.
We talk a lot about pure HTML on first load, but you’re talking about the fact that it has these very granular boundaries, so the performance potential you get is crazy. And with Partytown, things are fetched in the background completely. We did a lot of research and found that even things like link prefetching are actually consuming the main thread. But when you’re off in the web worker (as with Partytown) it’s kind of free territory. It’s very isolated doing its own thing. It’s not influencing anything.
Also, with Partytown, you can just say “body inner HTML equals blah,” meaning the code can remain as is, and there you go, it’s running in a worker thread. You’re clicking around a page and the transitions and state changes are literally instant, which is nuts. I mean like one millisecond, it’s just immediately live.
With Qwik it’s also all automated. I don’t know if you’ve seen the demo of the optimizer, but it’s all completely automated. You don’t have to do any wrangling to make it work. A lot of people go in thinking a React app with Webpack is bundling smartly and they don’t realize how not smart it is until later down the road. They have to manually write these async imports, and it becomes a big mess.
Tyson: Yeah, I think a lot of us can relate to that.
Sewell: With the Qwik optimizer, it will automatically divide up your code into the right sized bundles and essentially rewrite it all to be super thin and granular. So when you’re interacting, for instance, child components never hydrate when parents do. It’s really crazy how extremely optimized and thin it is. And we’re just scratching the surface of the implications of that. And it can distribute as plain HTML and it can just wake up and then sort of freeze-dry again, change state.
Tyson: This is the “resumability” of Qwik.
Sewell: Yes, and it could give you things like really granular back-and-forth behavior, like time traveling. The implications and possibilities are crazy, and it’s such a new and unique approach. We’re exploring new possibilities and exciting applications every day, which is amazing.
Tyson: Do you have any advice for folks who are looking at creating a startup, someone with a burning idea?
Sewell: I do have a lot of opinions on this. The primary one from my learnings is: Be religiously obsessed with customers. So you can read The Lean Startup. You can go through any YC program or read any YC literature and it will reinforce the same idea. But I think it’s such a powerful idea that people need to not only understand it, they have to be obsessed with it.
I can give you a tiny back story, about the very first year I spent where I left my job and started working on Builder. I put a whole year into it and I had built various versions of Builder since like 2012. I talked to a lot of people about what they needed for this and that. I spent a year building something and I worked really hard that whole year. And it was only at the end of the year – December, literally – I picked my head up in December and I started showing it to a couple of potential customers. And I realized within about 10 minutes of demoing it to them that I had missed the mark on it in a couple of huge ways. Foundational decisions that I made so early on that this was not going to work. This was going to be a non-starter, they’re not going to adopt the product. It’s not what they need.