In this episode , we welcome Adam Bradley, co-creator of Ionic Framework and Stencil , currently Director of Technology at Builder.io . We chat about Ionic and Stencil, Adam’s new projects Qwik and Partytown as well as how Builder.io works and how is it different from other drag and drop website builders.
Key takeaways:
What is Ionic?
How Stencil was born
Making fast websites with Builder.io
The challenges in e-commerce and how Qwik solves them
How Partytown runs third party scripts from a web worker
Edited Transcript
Darko Fabijan: Hello, and welcome to Semaphore Uncut, the podcast for developers about building great products. Today, I’m excited to welcome Adam Bradley. Adam, thank you so much for joining us.
Adam Bradley: I’m Adam Bradley, Director of Technology at Builder.io. Previously, I helped to create Ionic Framework, which is a UI library for mobile applications. I also created StencilJS, which is a framework to help build web components. And currently, I’m at Builder.io helping to build Qwik with Misko Hevery of the Angular fame.
As of today, I’m going to be releasing another library called Partytown, which is dedicated to running third-party scripts inside of a web worker.
Darko Fabijan: Over the past decade, you have been busy with a lot of stuff! Let’s first go through Ionic and all the libraries that you mentioned and then dive deeper into technical details?
What Is Ionic?
Adam Bradley: Ionic is a UI library to help build mobile applications for iOS and Android. It’s built using traditional web development tools like CSS, JavaScript, HTML, etc. Max, Ben and I started with Ionic back in 2013.
With Ionic, we thought, “Could we use CSS, JavaScript and HTML to build something that’s for mobile apps so that we can enable web developers to become native application developers?” 9 years later, and it’s running great.
We worked on another project called Capacitor that has been replacing Cordova. Between Capacitor and Ionic, it’s been a great fun project to be a part of.
Darko Fabijan: Let’s dive a little deeper. If I want to have a UI framework for our whole product or company that would include web UI, desktop app, Android and iOS apps, Ionic would help us distribute, maintain and integrate that UI framework across all of these different technologies?
Adam Bradley: Absolutely. Especially when you get into PWAs (progressive web applications). When you want to be able to have your app running inside of its normal web browser, that’s when Ionic shines. Ionic is a web page to start with. That’s why it makes it a lot easier for web development teams to be able to build applications that work both in iOS and Android AND a normal browser, too.
It’s so much easier and cost-effective to build with web development than to have native application developers and the constrained resources they have. I think that’s been a big part of Ionic’s success – how many more web developers in the world are able to build quality applications.
How Stencil Was Born
The first versions of Ionic were in AngularJS. But then, Angular moved to Angular 2, and we went through a lot of work to transition Ionic to run in Angular 2. Because Angular changed so much, Ionic went through significant changes, too. It was a difficult experience for many developers because they had to rewrite all their applications.
At that time, all the different technologies like React, Vue, and Svelte became popular. We were worried about Ionic not being able to adjust to all these different frameworks. So we created Stencil.
Stencil helps build custom elements that are really just elements. Think of it this way: a div element can have an ID and inner HTML, you can add styles to it, etc. That’s an API that will continue to work forever.
That’s the same idea I like to think of as custom elements. A custom element is something you’ll find in the MDN docs, the API inside of the browser. Stencil is using the custom elements PI so that we can create an element that can be used by any framework, whether you’re on React or Vue. Stencil’s components are going to work inside of that.
The issue that we found is that people don’t want to use custom elements inside of React or Vue. They want to use a Vue component and a React component. So instead of rewriting all of Ionic, we decided to write Ionic in custom elements and then create wrappers around each of these custom elements. This way, you can use it in the traditional framework sense.
Despite minor differences, what gets rendered in the end is identical. Stencil allowed Ionic to work in all of these different frameworks and be more future-friendly. The idea behind creating Stencil was to be able to let the compiler make the adjustments to the different frameworks so that Ionic core developers won’t have to rewrite anything.
The idea behind creating Stencil was to be able to let the compiler make the adjustments to the different frameworks so that Ionic core developers won’t have to rewrite anything.
-Adam Bradley
Darko Fabijan: It sounds like you managed to find a very elegant solution. Can you talk a bit more about Stencil and how happy you are with the final product?
Adam Bradley: I am really happy with Stencil. We wanted the computers to do a lot of the boring stuff for us. All of us can write minified code but that’s just dumb and useless. As developers, we should be able to read the code that is easy to understand, and then some other machine makes it tiny so that it’s faster.
That’s how I think about what the Stencil compiler is doing. It allows you to be able to adjust to different packaging systems. There are systems like JS, UDM, commonJS, ESM that are all doing the same thing. Stencil handles all that stuff for you. It speaks to the power of the compiler that we didn’t have to rewrite any Stencil or Ionic components as the module systems have adjusted. We’ve been able to say, “Use this output target instead”, and then Stencil knew how to rebundle it.
That’s why Stencil was created: let the machine do all of the hard work and do something creative instead.
Making fast websites with Builder.io
Darko Fabijan: That’s great! Moving forward, in your initial introduction, it seems that Builder.io is the next step in your career. Can you please introduce us to that change?
Adam Bradley: Even before Ionic, my career was largely in e-commerce. When I came across Builder.io, I saw an opportunity there; it was something that I was interested in. Builder.io is a visual editor for building landing pages, which is commonly used in e-commerce.
The challenges in e-commerce and how Qwik solves it
When it comes to e-commerce, the faster the website is, the better. If you have a slow site that takes 10 seconds to load, it doesn’t bring up any images and is too janky, you’re going to lose customers. Being able to make those sites snappy and fast is what’s interesting to me. I did a lot of work with Ionic trying to make sure that that was fast on low-end devices, especially Android. That’s why I joined Builder.io.
Together with Misko Hevery who’s the creator of Angular and who’s also now in Builder, we’re working on a new framework called Qwik . Qwik’s purpose is to make those landing pages extremely fast.
The developers that are using Builder.io don’t have to learn Qwik or transition how they’re doing things. Eventually, we’ll be able to switch to Qwik and let them know – hey, now your websites are extremely fast. Now they’re using HTML and CSS. As you interact with it, it will be using the lazy load of JavaScript that you need. Conceptually, it’s very similar to Stencil.
How is Builder.io different from other drag and drop website builders?
In web development, you can hand-code everything in Notepad or you can use a drag and drop interface builder. But there’s always this balance of how much control you do or don’t have. If you use something like Wix, you’re basically using their service on their servers. You can point it to your domain but regardless, you can’t really integrate Wix inside of your server.
With Builder.io, the difference with something like Wix is that you’re able to then integrate this drag and drop interface builder into your existing site. What that allows developers to do is to let marketers, designers and anyone else in the company be in charge of building these landing pages, A/B testing, all these different features that marketers would love to do themselves.
I was shocked to realize that this isn’t a common thing. There’s web flow where the developer has to do a lot of work. And there’s stuff like Wix where you can do all this drag and drop interface but you really can’t push it onto your own service.
Builder.io has that sweet spot where marketers and designers can go in and build great landing pages, change around whatever they need, hit publish and get the page to go live immediately – but inside of their existing sites. It’s the concept of a headless CMS, except also with the UI and a visual editor similar to Contentful, Prismic and the like.
Builder.io has that sweet spot where marketers and designers can go and build great landing pages, chnage around whatever they need, hit publish and get the page to go live immediately – but inside of their existing sites.
-Adam Bradley
Darko Fabijan: Drag and drop is providing the visual side of things. There are also those headless components that are supporting the interface. Are they a part of Builder.io?
Adam Bradley: Yes. Developers still have the power to build complicated custom components and add them to their Builder.io pages. Then they can render it inside their site, and anyone else on the team can use that component on any landing page. It’s the balance of letting a lot more control without the necessity of developer resources for any landing page or any change that you make.
Darko Fabijan: This value proposition resonates very well with me. Makins things easy for developers and marketers and solving what marketing people can do on their own is not a simple task.
The challenge with drag and drop interfaces and how Builder.io solves them
Adam Bradley: The early part of my career was building landing pages for the marketing teams and things like that, and this idea absolutely resonates with me. If you need to make a landing page real quick, as a developer, you have to drop everything and make that work. There’s always a struggle for resources and gettings things done. When Steve, the creator of Builder.io, explainer this all to me for the first time, I was like, this actually would solve a lot of the problems. This could save a lot of time both for marketers and developers.
Developers don’t have to worry about publishing the page and pasting the code. They can go back to building the next big thing, new features and all that. At the same time, marketers can build the landing page that they want. It enables both parties to work faster and work on the areas that they’re more interested in.
With Builder.io, developers don’t have to worry about publishing the page and pasting the code. They can go back to building the next big thing, new features and all that.
-Adam Bradley
Darko Fabijan: Would you say that this is kind of Dreamweaver, only 20 years later?
Adam Bradley: Yeah. When a traditional developer hears about Dreamweaver and FrontPage, they think of all of the challenges that they had. Those things made really junky HTML and weren’t easy to deploy. With Builder.io, we are trying to explain that – no, this is not Dreamweaver. Think of it more like Webflow, except that you’re not requiring a developer to do Webflow. It’s more like Webflow for marketers; that’s how I would describe it.
Darko Fabijan: In our industry, I’m always surprised by how many young people are there. It’s possible that the majority of our listeners don’t even know about those tools that existed 20 years ago.
Adam Bradley: I really started learning HTML in 1994. That was the first year of the internet, so I’ve kind of been doing this from the beginning. It’s fun to look back at all the different eras like Ajax, jQuery, Framework Wars. I had heard a quote about everything in computer science was invented in the 70s. We just keep relearning it.
The Partytown library
Darko Fabijan: To get back to the present day, you also mentioned an open-source library, Partytown.
Adam Bradley: Yeah, Partytown. The quick backstory to that. We’re building Qwik, and it’s really fast because it’s building just HTML and CSS, and you can’t get faster than that. The problem is that any site needs to have third-party scripts, like Google Analytics, Google Tag Manager, HubSpot, Intercom, you name it. We can’t just say that we don’t do third-party scripts. So we have Qwik running and see it being extremely fast. But then we see that we’re still getting bad scores, why is that? It always comes down to, well, it’s Google Tag Manager is 500 kilobytes and it’s doing a lot of stuff that’s really tasking the main thread.
And then you add Intercom, and it’s another 800 kilobytes. Not far from that, you’ve got 2 Mb of someone else’s code running on your main thread and eating up your resources. We got to thinking, how can we move 3rd party scripts off of the main thread and into a web worker because the main thread is for your code? The main thread is to be as fast as possible for the user. That’s where Partytown comes in. It makes it easy to put a Google Tag Manager into a web worker to not take away resources from your site.
The challenge is someone who’s used web workers in the past you’ll say like, but that’s asynchronous, you can’t access the DOM, you can’t access window or local storage, things like that. And if you do, you have to have asynchronous calls to that because to go to use post message between the window and the web worker has to use a call back.
What Partytown is solving is that it’s able to make those calls synchronously. If you can do synchronous calls between the web worker and the main thread, that means you can do
document.Element
document that gets computed style, things like that. Those blocking calls will actually work.
If you have actual blocking calls working off main thread access, then you can run the entire third-party library into a different thread. The third party itself has no idea that it’s actually not inside of the main thread, because everything is working as expected, everything is coming back synchronously. But then to your code, you basically freed up that of those megabytes of JavaScript usage and memory for just your site.
It’s extremely experimental. We just got the alpha version out; I’m going to release a blog about it. We’re running it on a couple of pages inside Builder.io to collect the data. Since it’s still in alpha, we’d love to have people test it out, use it, give us feedback, try to make it work within your services, your use cases, probably don’t put it on your homepage today.
Image: dev.to
Making asynchronous work synchronously
Darko Fabijan: During the whole time you were presenting this, I’m wondering if I should ask or not ask how you have managed something which was by design manage to be very asynchronous and then you moved it to be synchronous, how deep did you have to go?
Adam Bradley: That’s the biggest challenge. The big trick is that it’s using a service worker under a different scope under a Partytown directory. With a service worker, you can intercept a request locally and you can respond asynchronously.
Inside of the actual web worker, there’s one weird trick that just web workers can do. That is to have synchronous this import scripts and synchronous XHR requests, right? It’s basically the combination of those two in that when you do document.getElement, or let’s do an easier one that you know, body.getwith that’s a synchronous call, it’s to a getter, we need to get in immediately, we can’t have a call back or a promise on that.
What’s happening is that there’s a communication layer that has a proxy around document. It creates this proxy object. And when you make a call to .clientwith, it then goes to the import scripts, which is a synchronous call to a URL, which then actually goes to the service worker. The service worker then becomes an asynchronous call and then it can asynchronously access the main window, read document.body.clientwith, respond its value, respond to the request and then import script as far as it knows was synchronous. That’s the big trick. Making it work everywhere: in Safari, Firefox, you name it – that’s the big trick. The future is really using Atomics.
Using Atomics is the only correct way
Adam Bradley: Atomics would be the correct way to do all of this. Atomics is only working in Chromium right now. Safari had it working at some point and then they removed it. Ideally, they would move it back and Atomics is part of the JavaScript standard.
The way we want to move forward with it is that we have these blocking calls and converting what was asynchronous to be synchronous. Let the blocking happen inside of the web worker and don’t bother the main thread with any of this.
It’s able to emulate the entire DOM in six kilobytes of code. We didn’t recreate the DOM like JS DOM which runs out of Node.js where it’s recreating every single thing. We just have a JS proxy that says, hey, I’m a document. When you call a getter, I’m going to forward this getter onto the main thread and the getter will retrieve that information, send it back. So it doesn’t really have to know about the document, it just has to have proxies.
Darko Fabijan: I think that you explained this very well. It’s always fascinating how much hardcore technology has to put into place to do something as I want to have a quick website, I want to have a quick landing page and then I need to create this thermonuclear reactor in order to be able to deliver that.
Adam Bradley: Yeah, right. It was important to me to make it extremely small so it’s written so it minifies extremely well. And it’s also written where it’s like, we care about the performance on the main thread, but we really don’t care about the performance on the worker threat because really when it comes down to it, third party scripts are asynchronous. Really Google Tag Manager is asynchronously sending beacons back to Google on its own time, right? And so it doesn’t have to be extremely fast on that end.
That’s also part of its design and that’s kind of the opposite of something like worker DOM. Worker DOM is a well-known, cool project that the AMP team created to kind of put your application inside of a worker. Well, this is kind of the opposite of that. Partytown is really saying like, no, the main thread is for your application, do everything you want, use all the resources you want and throw all these other guys into the web worker so they can take their time over there.
Darko Fabijan: Yeah, humanize the priority. Great. It was very, very interesting. We went over a number of technologies in depth. I hope the listeners will also enjoy going in depth around these technologies. Again, thank you so much. And we’ll be sure to include links to Partytown and all the other things that you can mention. Thank you so much.
Adam Bradley: Well, thanks for having me. This was a blast.