et il fait il denk que…
quoi, il Diego?
Tu ne s'est pas pani bumhovusa
Hello, welcome to the DevTools FM podcast. This podcast about developer tools and the people who make them. I'm Andrew and this is my co-host Justin.
Hey everyone, today our guest is Steve Sewell, who is the CEO and co-founder of builder.io. Steve, we're really excited to have you on. Is there anything you'd like to tell our guests about yourself?
No, nothing particular. I think we'll get into all the specific things. Or maybe the thing is, I care a ton about web performance. We're going to talk a lot about that today and empowering everybody in the world to be able to work with the same tools that developers use.
Great tools with developers. Put them in the hands of everybody and I think we'll touch on that plenty. So I'm thrilled to be here and chat about all this.
Yeah, awesome. Awesome. Well, maybe we can just dive right in. So you have started, helped start builder.io, which is sort of a WYSIWYG website builder. So can you can you kind of talk about the product and sort of your motivation for starting it and which else go?
Yeah, absolutely. So there's really two elements to this. Try and weave them well together and I'll try not to ramble too long. I could be long-winded. But it's really twofold. So I originally, way in the past, never actually set out to be a developer myself.
I was obsessed with software products. In fact, when I was going to college, the iPhone 3G had just come out, which when I had the app store, which was like, I had to make an iPhone app. Like, that was the crazy thing, except I don't know how to code.
So it was a big question of like, well, how do I learn that? And I learned best incrementally. I watched a good talk the other day where they called it just in time learning, like just in time compilers, like just learn as you need. I think that's better for many, especially me, than trying to learn everything before you start getting your hands on something.
And so I went the road of trying to learn design tools and I learned Photoshop and After Effects. And those are generally considered difficult tools on the design side, robust, but they're a lot easier to learn than the next thing I tried, which was coding.
So I remember at the time thinking like, you know, Photoshop, you can make amazing visual effects, After Effects, you can make amazing motion effects. I just needed the next app to make the interactive effects, so to speak, right?
Of course, you kind of find your region for thin air or you find tools like Dreamweaver or just like really janky old stuff and it's not doing what you need.
And so I was like, you know, arrogant, I guess, I'm like, I'll just teach myself to code. It can't be that hard.
Way harder than I expected. Way more esoteric than I expected. Everything was just not what I expected.
And I'm glad I have the skill set now. It's very, very valuable skill set to have now, but I've been obsessed with like, how can more people learn this stuff the way that I naturally learn?
What could happen if everybody could learn this in a natural way? It's a lot like way in the past. There's this old story that like Steve Wozniak made the Apple One, then realized that he worked for HP.
HP gets all rights to all intellectual property he made. He made one of the first like personal computers, becomes a massive company.
Obviously HP would say, yes, we want to own that. But like, the old fable is that he like went to their executives and they basically laughed at him and they're like, why would business machines make sense for consumers?
It's too hard. It's too complicated. It just makes no sense.
I think coding is very similar. I mean, it took them 30 years to go from the Apple One to, you know, a few years to the Apple Tube.
It's commercially successful, still very difficult. Macintosh came out, point clicked out, can drop wildly innovative, still pretty difficult.
And now we're about 30 years from that Macintosh and we have the iPhone.
It's an unheard of idea that a four year old could just pick up a computing machine and just figure out how to play games, make music, draw, make art, stuff like that.
It's a crazy idea. And I think we have a similar sort of trend going on with coding of like this crazy thing that's difficult to learn, it's becoming easier to learn.
There's boot camps and stuff, but we can potentially make it that next level more visual, more intuitive.
Now, where I actually realized there's an obvious sort of market opportunity here, like something that was being unfulfilled is I was doing a startup.
It got acquired by a company called Shop Style. We did a rebuild of their site. We built it on Angular.
We did, you know, as a headless site before people use the word headless, headless commerce of 2015.
It was early time for that.
We solved a lot of stuff on the open source side, round Angular performance and this and that.
And we realized though that there was a big missing piece. I didn't think about content management.
I thought about how the developers would build the site. I did not think about how the marketers would manage the site.
And I realized that e-commerce is a marketing machine.
It's like test of the thousand versions of the homepage every day to see the conversion impacts, throw up new landing pages for every new product, every new possible ad, social campaign, email campaign.
I mean, the needs are never ending.
And so we ran into this problem. We're like, wait a second, there's an infinite amount of needs the marketing team had.
And there's only so much time we can code things.
And there's only so much you can structure in a CMS. You make a template, you make a form.
But the next thing comes in, why need a new section? I need a product. I need a newsletter sign up.
I need all these things.
And we got to the point where we had this Angular site, but we had no good tools here.
And the marketing team would get frustrated to be like three months to get a new page.
Developers hated the work. I mean, it's pixel pushing.
I think nothing, a developer hates more than to build a page that lives for one day.
It's a one day sale and has a unique page just for it.
And then it goes in the trash, like developers like to build things that last that scale that add value over time, right?
And so constant tension.
And we realized something which is at one point they reached for Webflow and they said, hey, this page, we've been asking for four months.
We made it in like two days and Webflow, like just kind of copy pasted on to the Angular site.
And we had to have a lot of discussions like it doesn't work that way.
You don't just kind of copy pasta.
You don't kind of embed, not with good performance, not with the ability for our site analytics to actually work within the contents of the Webflow content.
It's just all this stuff.
So then they're clever.
They're like, well, why don't you put all the shop style stuff, the product catalog and search and stuff into Webflow?
And it was also like, that doesn't work either, right?
But it became obvious that this big company problem would be solved if they had a no code solution like Webflow.
But if it was composable like any other software, plug it into Angular and use Angular components, render out to Angular code, plug into shop styles, product catalog, which is a custom one.
You know, we use some various pieces of content management.
Like could you plug that in?
That'd be the ideal solution.
The question, though, is, you know, there's a lot of no code products, none of which are composable in this way.
They could solve this problem.
So I was losing my mind at this job.
Like, really, it was just becoming a tedious, awful job.
And so I quit.
I did a lot of research on, you know, could this problem be solvable?
And I came upon sort of understanding how compiler architectures work, like the LLVM compiler, that, you know, you can write,
does in different programming languages will compile to LLVM.
I think these days it's like C, C++, Object, C, Swift, Rust, it just goes on and on.
And as long as you compile to the LLVM format, they've already written sort of ways of writing code out to all the different machine sort of instructions,
all these assembler, assembler, whatever.
And so what was interesting about that was, I know there was a day in time, like maybe the 80s, where people would have said,
you have to, you can't just generate machine code.
You have to write the code.
You have to know the machine specs and how to move bits in an efficient way.
And they really realized, like, no, actually, there's a point where the compiler can be more optimal,
because there's only so much performance stuff that an engineer can keep in their head.
Versus the compiler, you can keep adding stuff, too.
So as long as you can compile anything to the IR, the IR can do optimizations on itself,
kind of like Babel, where it has multiple layers.
And then the final layer outputs other things.
The big question was, could you do this on the front end?
Could you make the top level, instead of it being a high level programming languages, make it UIs?
Could the middle layer be just a data representation that you can read and write in a visual form,
like as JSON, store in a database, query it and display it where needed?
But could that output, either ahead of time or just in time, as React, Angular, View, React Native, IOS, etc.,
could you do that?
And after a year or two of banging my head against a wall, the answer was, yes, you can do that.
It's very hard, and it's hard to get right, and there's a lot of gotchas and pitfalls,
but we did land on, yes, you can make composable no code,
you can make it so that the Nikes or whatever of the world don't have to have this problem
where you may start a small business on a tool like Webflow,
and it's amazing for the small companies, the individuals, etc.,
but at a certain scale, and I've seen startups do this all the time,
their needs become more bespoke, and they throw away all the no code, they build this React site,
and now they realize, wait, all the non-developers are like, wait, I don't have drag and drop,
I have forms, and the forms never have the fields that I need, and this sucks,
why can't I go back?
And anyway, we see that there's a way, we see that the technology works,
anyway, I'll stop rambling about it, but that's kind of where we are today,
on just plug and play no code that works with your React design system,
back and front end, and just publish, run tests, etc.,
without that interplay between teams, but never blocked, you never have to migrate off of it,
it works with your systems and components and whatever.
A lot there.
No, no, no, it's great, this is a really, really interesting domain,
I've worked with a lot of CMSs, and having to plug those into a production system,
and particularly this question of how do we give non-technical users of the system
who want to push content, customizable content especially,
in a way that is all the things you should have to perform it,
and sort of like other things, it's like, it works with the technology that you're using.
So this is specifically not hitting the webflow sort of like target,
you're trying to integrate it into an existing app, I'm assuming,
so is this like a richer sort of like, I don't want to say like iframe,
but to sort of like give people a conceptual model of like how this happens,
it's like you have a port or a portal or something inside of your app,
and this is where you're injecting sort of like content,
is that sort of the realm of like how you're trying to target it?
Yeah, that's spot on, we like to think of it in terms of pages and sections,
so you might have your homepage, everything between your header and footer,
like any other page, just build or powered.
Unlike an iframe, it will interface with your components,
you are using your design system, the same thing shared in your code base,
and you probably will pick sections of other pages.
A lot of, it's about 60% of our customers are e-commerce,
some of my examples are e-commerce,
but any e-commerce usually have collection pages and product pages.
Collection page, we don't tell people to put everything in builder,
like all that product cell and search logic, put that in your code,
developers keep it in code, but there's probably an area above
that's like, this is the organic t-shirts collection,
like that should be in builder, they should be able to put anything in there,
links, run A-B tests, conversions and stuff.
Or like product pages, you might have a section on the bottom,
like here's a product information, but here's all kinds of content,
the story of the shoes, 3D visuals of the shoes, stuff like that,
that the marketing team should just own,
kind of like your iframe analogy, this is just your box to do it.
Cool, so you guys have built a lot of things to support this,
just browsing your website, the three top ones seem to be
Quick.js, Mitosis and Partytown,
so we'll probably go through each one of those and ask what they are,
how they work and why you built them.
So the first one we'll talk about is Quick.
So why did you build it and how is it different than other web frameworks?
Yes, there's a great question, there's actually a number of reasons
why like everything settled on this one solution,
I'll give a couple of quick ones.
The first one is, you know, when a lot of people modernize
the front end of their website, a lot of it is for performance reasons,
their monolithic thing is getting slow, they want something fast,
they want jam stacked, delivered from the edge and it's flexible for the developers.
The problem is, when the goal is performance, and to be clear too,
you know, the people who manage websites at some scale, like you mentioned,
I think webflow is killer for individuals freelance or small businesses,
but for the mid-market and up, businesses that have multiple teams
and are doing sophisticated things, they don't have those tools.
What those teams absolutely need is they need conversions,
they're spending money on ads, they're doing social campaigns,
they're spending all this money and resources to get you to the website,
and the worst thing that can happen, and it happens all the time,
is the website loads so slowly, people get annoyed and they just go away, right?
And that kills your conversions, that kills your whole funnel.
And so, we always found that if you're looking at conversions,
performance is paramount and Google has a million studies on the direct impact, right?
Like Amazon did a study about every 100 milliseconds cost them 1% in sales.
So that's like 100 milliseconds, it's like millions of dollars, right?
And there's about at least six other studies we've listed on other websites
that all share the same thing, it's just slow site, people disappear,
which makes sense.
You're on a beautiful native app, you swipe up to some store,
if the store is super janky, you're just like, ah, I'm back to Instagram,
or whatever you're on, right, TikTok, etc.
And so, what you find though, is people start by having a pretty fast site.
Like, the thing about performance that some people,
like the non-development, non-development people don't understand is,
it's not like an engine where you add more horsepower and it gets faster,
it's the reverse, it's kind of like a zeppelin,
and when you add weight, it gets slower.
So any site's fast, you could go to example.com,
which is just a little bit of text, put that in Google page feed,
and it's 100 out of 100, perfect website.
It is, cause there's nothing on it.
And so, people will make a new website,
they'll use like, I'd love Next.js, we use Next.js like crazy,
they'll make a Next.js website,
they'll put a little bit of content on it,
and they'll be like 90 out of 100, I rock.
That is great, until you realize that you need a lot of additional tooling on it.
You need a lot of first party code,
you need all kinds of things,
the React components do all sorts of awesome crazy stuff,
pull the product catalog, render out interesting things.
Sometimes you need those to be personalized per visitor,
so people who shopped men's products see men's,
and women's see women's, you can't statically generate it all.
You start thinking about A.B. testing,
most A.B. testing tools out there,
they use blocking JavaScripts,
the script at the top of the page blocks it from rendering,
inject stuff in the DOM, React kind of goes crazy,
it creates a performance nightmare.
Then the marketing is a pop-up solution,
so you add more JavaScript that launches pop-ups when needed,
and this stuff adds and adds and adds until that beautiful fast site is just not.
We've seen this time and again,
and you can look at the Chrome real user experience dataset,
this giant dataset in BigQuery of web performance,
and you'll see the average website on mobile
in real world in the field takes an eternity to load.
I'm not talking about examples,
I'm talking about real production websites,
and the reason why is they have a lot of needs,
and every framework starts fast and then gets slow as you add things on,
and bundlers are not magic,
you add another import to another thing,
and that's consumed and run on every page all the time.
So, what's awesome about having this sort of like compiler infrastructure
where you can take a data representation of the entirety of a page,
and then output it to any front-end technology,
is you can start going,
oh, well what front-end technologies get us a good score,
because we know people, our customers care about performance,
they look at our website's performance,
and our site was getting like 60 out of 100,
that wasn't that good!
And I was kind of going crazy,
I was doing everything to optimize every bit of an image,
and every little CSS,
if the line wasn't needed, it wouldn't be included,
and then one day I'm losing my mind,
I cannot get the thing to work faster,
and so I'm like, you know what, I'm just going to start hacking and slashing.
What I did is I just commented out all the script tags,
so no scripts were imported,
I pushed that up to Versal or something,
or ran PageSpeed Insights on it,
and I was fighting for like one point,
I wanted to get from 60 to 61, that was it,
and that thing shot to 100,
and I was like, what the heck?
And I was like, wait, wait, this is obvious,
the typical React app with third-party scripts and all this stuff,
is downloading a ton of JavaScript,
it's parsing it, it's executing it,
and then it's getting to the,
I'm ready to be used state,
on a mobile network on a low-power device,
that actually is a very time-consuming process
that makes sites very slow.
And so that's what we're like, oh crap!
JavaScripts, this thing we love,
the J and Jamstack is the problem,
and that's kind of an issue.
And so the question became,
well, can you load JavaScript differently,
or can you defer the loading of the JavaScript,
or can you do weird tricks to make it so that you can just load
HTML?
Nothing's faster than HTML, HTML can just load instantly.
Assuming the images in the HTML are optimized
and the CSS is not bloated,
it's only styles that are needed,
or just something close,
if you could just deliver HTML, it's wicked fast.
So we were working on like this bespoke compiler technology
to compile it out to HTML on lazy load JavaScript.
And then I met Mishko,
the creator of Angular,
all this stuff,
and he was like, hey, I'm working on something new.
I call it, he called it Qt back then,
Q-O-O-T.
He's like, I was frame recall Qt,
that can deliver applications as pure HTML,
and you never need JavaScript until absolutely needed.
And what was funny is,
almost nobody understood how
important and how impactful that was.
He was actually almost frustrated that people didn't get
how amazing that was.
And it's inspired by technology
Google uses internally called Wizz.
So Google search and really core Google products
use a similar technique of just HTML.
The HTML has like paths
to where you can find JavaScript in the HTML.
And it has what Qt has as well,
which is we call a boot loader
or a Qt loader,
which is a little bit of JavaScript.
It's the only JavaScript you can load on the page.
It's like 500 bytes, it's nothing.
It just listens to events on the page.
And if the target of the event
has some special attribute that links to a JavaScript path,
it uses a dynamic import
and executes that JavaScript.
And that simple technique alone
makes it so that you can deliver pages
as pure HTML.
And as the user interacts,
it just pulls tiny bits of JavaScript.
Almost imagine like you were back
in the days of writing jQuery,
where you literally only wrote the minimal code
to manipulate that DOM node or whatever it was.
And so Qt was 100%
sort of Mishiko's creation, the earlier forms.
Early forms had wildly wacky
DX and stuff, because it's a heart set of problems.
People don't realize that this take
on front-end frameworks that are
very sort of HTML first,
they avoid any blocking JavaScript,
they avoid downloading hardly really any JavaScript,
and they require no hydration.
You don't have to
download the entire application in the browser
and then re-render the whole thing,
even though it's hydrating into the same DOM nodes,
you don't have to execute all that code again.
It ran statically on a server,
it doesn't need to re-run.
You should be able to pick up where it left off.
And so I know we have other sort of topics
around this, so I won't go super deep down the route
and hold just yet, but the point was just realizing
that pages need to load fast.
The only way is to reduce JavaScript
or delay the loading as much as possible.
And Qt was this wild solution that,
and we hooked it up, we proved it out.
We hooked Qt up to our compiler
and started running speed tests
on all of our customers' content
et tout était 100% de 100%.
Et nous étions comme, c'est impactif.
C'est comme ça qu'on a fini par arriver.
C'est génial.
La web a été en train de se passer
depuis les jours de jQuery,
en particulier.
Il used to be
que nous avons la moste de l'HTML,
et nous allons se couper sur des comportements.
Et c'est, à l'heure de, très vite,
je pense que la révolution
est arrivée quand nous avons un modèle component
qui nous a été introduit,
où nous pouvons commencer à penser
que les séquences de l'UI
sont comme cette fonctionnalité encapsulée.
Nous avons été expressant cela en JavaScript,
et si vous pensez
qu'il y a un signe de
un pire de succès,
nous avons un pire de fêlir,
où chaque petit piece de fonctionnalité
que nous voulons ajouter est plus en JavaScript,
et c'est comme la fin de la mort par 1000 coupes.
C'est comme, oh, on va juste utiliser
cette frameworks de component.
C'est comme, ok, peut-être que c'est bien,
mais nous allons utiliser cette autre chose,
et cette autre chose est de 250 kilobytes.
Donc, avant que vous le connaissiez,
vous avez 750 kilobytes de vendeurs
que vous avez pour le chiffre.
Et les séquences
ne peuvent pas être importantes,
mais la cost de l'exécution
est une vraie chose.
Il y a tout ce qui est vrai et valid,
et c'est quelque chose que l'on réacte.
Vous avez un spelt
qui vous donne
une fonctionnalité
sur les subventions














un titbit qui est mis en train d'avoir un peu de défi,
mais le DX est presque identique à réact.
C'est complètement component-driven.
Je crois avec vous 100% que la révolution de la compétence
était énorme et on ne va jamais retourner à ça.
C'est tellement impactant sur la construction de la web.
Et c'est impactant pour des outils de la construction,
car les équipes de marketing ou les non-developpages
et des modèles de la compétence ne réalisent pas
que les développeurs ont des blocs de la légion
dans leurs mains et qu'ils ne font pas de la page,
ils ne font pas de la pièce,
ils font des blocs en un petit,
les connectent avec les dots,
c'est une expérience incroyable.
Et donc les modèles de la compétence sont aussi importants
pour les marketers,
car ils peuvent ajouter le héros et le carousel
et le bruit et les bespokes et les bespokes,
c'est un requirement difficile.
Donc ce qui est fort, c'est que,
comme vous l'imaginez,
le fait que les exécutés sont très vite,
ne peuvent pas exécuter comme réact.
Donc la question est,
comment vous le faites,
vous le ressentez juste comme réact,
comme des compagnons, des JSX,
les capsules,
tout ce que vous avez dit,
on veut tout le propre de ça,
mais ça ne peut pas exécuter de cette façon.
Et donc c'est là que les choses
sont extraordinairement déchirées.
Et je me sens comme dans ce jour et à l'âge,
et en fait, ça a été historiquement
le cas dans les compétences de la compétence
depuis longtemps,
toutes les routes sont réconnées à les compilers,
quand vous réalisez que le développeur
doit penser et raisonner
et faire quelque chose de l'un de ces deux,
mais comment ça exécute
doit être de manière complètement différente.
Et donc c'est pourquoi
nous avons un spécial compiler pour...
En fait, nous essayons d'évoiler.
Nous avons déjà fait des compilers,
mais quand ils ont fait le changement de compiler IV,
c'était juste un énorme travail,
il a juste eu des barres de bâtissage,
il est comme, je ne veux pas faire ça encore,
mais ça a été clair que c'était besoin.
Donc, bien sûr, nous avons pu utiliser
beaucoup de ces études,
mettre les mêmes constraints en place.
Au bout du jour, exactement,
vous faites des compagnons comme réact,
nous compilons ça à un code
qui a un model de execution
où il ne s'agit que de la demande,
il n'y a rien de hydréne,
vous pouvez le faire avec
quelle stratégie vous voulez,
d'une manière intelligente,
en base de la visibilité,
comme quand les compagnons sont en vue,
peut-être que vous prévoissez le JavaScript
pour que, quand vous cliquez,
vous pouvez le modifier
dans le besoin,
mais plus ou moins,
quand les mutations actuales
sont sur le page, vous devez le faire.
Il y a un réact,
un réact,
où ça peut faire des différences
avec un peu de compilers,
un peu de temps de run,
mais la chose unique ici,
et comment ça s'exécute,
c'est que ça peut faire des rendements en ordre,
ce qui veut dire,
une des défis de la challenge,
je n'aime pas l'architecture d'un pays,
c'est un mouvement
en train de retirer le JavaScript,
mais vous devez enlever les sub-apps
qui ont le même problème.
Vous avez trois apps
qui ont besoin d'agressifement
de l'air,
peut-être parfois un peu différente,
mais c'est normalement tout à l'heure,
après ça.
Et ce qui est très unique,
c'est que vous pouvez avoir,
vous savez,
votre component de page,
votre component de héros,
votre component d'intérieur,
mais si votre héros est comme un carousel,
et vous cliquez sur le prochain slide,
vous allez enlever la code
pour votre héros,
rien d'intérieur et rien d'extérieur,
et vous allez enlever
les différences pour juste ça,
en déçant tout autre,
touché, déploité,
ce qui est un nouveau truc
qui a fait notre vie
très difficile,
parce que la façon dont les gens
espèrent que le DX
soit très comptable
pour comment
les nuances qu'on a besoin
pour ce temps de travail,
mais bon,
on a enfin terminé
ce que nous sommes
dans un état où vous avez
toutes ces propres
grandes, granulaires,
propres de performance
avec la compétition de la compétition
des gens comme.
Est-ce que la compétition de la compétition
s'est accomplie par la mitosis,
ou est-ce que tout est rapide?
C'est une bonne question,
on a presque passé la route,
mais non, la mitosis
toujours vit en un autre côté,
ce qui est intéressant
de la mitosis
et qui je pense
que ça va avoir une applicabilité rapide,
c'est une chose que tout le monde
trouve,
Rich Harris a été
dans la rhodium
des fois,
Ryan Carniata avec Solid.js,
qui est vraiment
mieux que réacte dans tout le monde,
objectifiquement, c'est mieux,
c'est plus rapide,
c'est plus rapide,
c'est plus facile, c'est juste mieux.
Ou Quick,
ce que nous pensons
est extrêmement mieux
pour les types de cas de utilisation
que c'est bien pour,
ce qui est vraiment un temps de load.
Le problème que tous ces fameux
ont, c'est
qu'on ne peut pas
faire tout ça
sans un écosystème,
on a besoin de la libraire UI,
ou on a besoin
de la chose de la management
de la grande state,
on a besoin de toutes ces choses,
et donc,
une façon
que nous pensons que la mitosis
va jouer dans les Quai
est,
nous travaillons avec les équipes
qui font ces différents libraries
de UI,
parce qu'ils ont cette challenge,
ils appuient à réact,
ou à vue,
ils appuient à l'aide d'un autre,
mais le sphèl est plus grand,
et ça commence à être plus grand,
et ça commence à croître,
et c'est comme,
comment vous appuyez à ces choses?
C'est là que la mitosis
peut aider un ton de
construire un système de design,
on peut le piler
sur les codes idiométriques
pour les fameux frameworks,
et maintenant,
tous les benefits de la libraire,
c'est plus de l'Ui,
les libraries component,
c'est tout comme ça,
c'est bien,
Quick,
c'est bien,
et puis,
vous aussi vous avez des providers
comme,
ah, donc,
la libraire nous a besoin,
parce que nous avons des rendeurs
qui doivent être renouvelés
à tous ces frameworks nativement,
et puis,
vous pouvez être quelque chose
comme Algolia,
qui donne des compagnies
pour les UIs de search,
et, en fait,
ils veulent supporter ces frameworks
et nous devons les faire,
donc, je pense que c'est ça,
que la mitosis est un peu plus rapide.
Juste pour nos listeners,
la mitosis est
ce,
ce,
comme notre label,
ce,
ce,
cette représentation intérieure,
donc vous avez votre,
votre,
des components de la libraire,
ce qui ressemble,
ça ressemble,
le JSX-E,
qui,
puis,
compiles à tous ces autres frameworks.
Donc,
c'est intéressant,
il semble que c'est un problème
d'un compiler,
donc,
une des choses que je me suis
toujours
fondée
avec Svelte & View,
c'est que,
dans un template,
vous pouvez constranger,
votre,
comme,
la code de la run-time
que vous avez,
vous pouvez faire des
meilleures déterminations
sur comment optimiser ça,
comme,
ce qui se passe
dans la hôte,
mais,
en pensant,
un JSX,
qui,
les gens,
aimeront dire,
c'est juste un JSX,
le JSX peut être un
très,
très difficile à optimiser,
et se faire dire,
qu'est-ce qu'il faut,
pour faire,
ce que vous voulez,
et si vous avez
de la run-time analysis,
ou de la code de la
execution path analysis,
sur,
votre,
les choses pour les optimisations,
ça se fait vraiment,
vraiment,
c'est super,
et je ne sais pas si on devrait
aller assez loin,
mais,
je suis vraiment inquiétant,
sur,
comment vous pouvez,
accomplir ces sortes
d'optimisation,
broadly ?
Oui,
non, je peux parler de ça,
c'est,
en fait,
une observation vraiment,
vous savez plus,
sur ce sujet,
que beaucoup de gens,
parce que je ne peux rarement
pas demander cette question,
et c'est l'une des
meilleures considerations,
en plus,
la hausse de la hôte,
est,
maitosis,
a des constraints,
de la même manière,
que les sphèltes,
et les vies,
vous devez,
ne pensez pas,
comme,
réacte un JSX,
et pensez,
comme,
un template statique,
vous devez,
quitter vos yeux,
et dire,
la raison pour laquelle nous avons choisi,
un JSX,
c'est pour ça nous n'avions pas voulu,
inventer un autre,
un système de template,
et ça,
il travaille avec les typescript,
et ça,
il travaille avec des tools,
mais vous ne peut pas,
réacte,
vous ne pouvez pas,
le JSX,
des éléments,
où vous voulez.
En fait,
quelqu'un a,
un issue,
de la dernière,
que je pensais,
être,
fric,
brillant,
où ils ont un peu de,
un peu,
ça fait plus de l'exfolte et ça fait plus clair que c'est plus de l'exfolte statique
mais en fin de compte, nous avons émulé le réact et nous avons ajouté beaucoup de
l'exfolte statique et de vous dire les constraints, vous ne pouvez pas juste ajouter un
variable random et vous ne pouvez pas juste éprouvoir, ce n'est pas juste JavaScript,
c'est une des lignes statiques qui est la plus stupide, donc vous devez avoir
de l'air un peu ou de râper votre tête autour de ça et pour le long de temps, je n'ai
peur de cette principe et j'ai vu un J.S. Ryan Carniato avoir des problèmes de
faire une analyse très stupide et il a construit certaines constraints comme
le component de la show, les 4 de chaque component, etc. et j'ai vu que c'était
travaillant, c'était élégant et les gens ont accepté, ils pouvaient changer leur
pensée et utiliser le même moyen et c'était le grand hommage, j'ai dit
ok, J.S.X. va travailler, on va faire ça et c'est ça.
Ça me rappelle beaucoup de ce que Rich a fait avec Svelte, donc pour leur
réactivité, il y a des syntaxes qui sont cooptés, c'est comme, hey, c'est
comment tu fais quelque chose interactif et en première place, les gens disent que c'est
vraiment bizarre, mais c'est juste une chose à apprendre, vous vous êtes
habitués à ça, ok, ça fait le sens. Mais ça répond à une des plus
grandes choses que je pensais, c'est que si vous avez
l'intention d'établir ce JavaScript pour les
dépendances et tout le logiciel, à un moment, vous avez
eu un problème de haltation où vous avez besoin de faire des optimisations,
vous avez dit, oh, je ne sais pas ce qu'il y a, on va juste le faire.
Exactement.
C'est assez cool, c'est assez cool, j'aime ça.
Ok, en revanche à Quick.js, pour un petit peu avant de
bouger à la part des villes, l'une des choses que Doc a rappelée
est que la réplayable est résumable, donc comment est-il
cela et comment effectue-t-il l'expérience de l'utilisateur?
Et probablement, la plus importante, comment effectue-t-il
comment j'ai écrit le code? Est-ce que le code est en Quick?
Est-ce que je dois penser à autre chose en racineant ou je vais juste
le faire?
C'est une question fantastique.
Oui, donc le plus court de cela, c'est que vous pouvez
pouvoir le trouver résumable versus réplayable.
Donc, réplayable est ce que vous êtes en train de
mettre en place un service de jamstock ou un rendering de statique.
Comme vous le savez, la histoire, tout ce qui a vraiment commencé
avec un focus browser qui va juste le rendre dans le browser,
et je pense que à un certain point, les gens ont réalisé
que le sending des pages avec un spinner,
le downloading de JavaScript et le rendring des pages
sont un peu longues, surtout quand votre app s'est rendu large.
Mais ce que vous pouvez faire, c'est que vous pouvez
envoyer l'initiel HTML.
Vous ne pouvez pas interagir avec ça, c'est un peu de la
HTML, mais les gens ont pris un moment pour procéder
à ce qu'ils sont en train de regarder.
Donc, vous faites ce magique de la sender HTML,
mais ensuite, vous faites tout ce que le JavaScript
peut faire et le rendez, et j'espère que vous n'avez pas
de l'intérêt de cliquer sur tout ce qui est important
dans le temps en meantime, ou quelque chose ne peut pas
fonctionner, les liens doivent fonctionner,
mais les menus de hamburger interactifs ne fonctionneront pas.
Et donc, ça a fonctionné pour un moment,
et quand les gens ont commencé à réaliser
que les applications sont en train de se faire
plus grandir, les dependencies de JavaScript se sont en train de
se faire, les bundles ne sont pas magiques,
si c'est importé, il doit être consommé,
downloadé, élevé, rendu.
Et donc, il a créé ce problème de la faute
que, en faisant une définition réplaîmable,
c'est que vous basicement vous faites
votre application sur un service
ou vous faites un processus statique,
il crée l'HTML, vous le vendez,
mais ce n'est pas fonctionnel de l'HTML,
vous devez répliquer l'application sur les browsers,
donc maintenant vous downloadez les JavaScripts,
vous vous abaissez tout le state,
vous faites des requêtes de réplique, en quelque cas,
et ensuite vous vous plaitez.
Si vous regardez à l'école ou à l'école,
comme un angular, priori à une certaine version,
ça serait juste de faire un clavier,
ou juste de faire couper, ou de replacer le dom,
et ça serait juste de faire le plus vite,
il n'y aurait pas de flicca,
généralement, vous allez juste voir le nouveau contenu.
Réacte va préserver les nodes dom,
mais il y a encore un renseignement
dans chaque ligne de la application de la technologie
et de l'application que votre service
ou votre build statique a déjà répliqué.
C'est déjà été récomputé,
il devrait être réutilisé
en tant que répliqueur de scratch,
comme si Mishko s'appelle Amnesia,
il s'est dit que je ne sais pas ce qui se passe,
je vais aller sur le code et je vais le faire,
et ça peut être plus lent
sur un appui mobile pour la netwerk,
ou un appui compliquant,
qui se dévouent tout le temps,
le défi de 1000 g,
ça toujours se passe tout le temps.
Donc, c'est résumable,
c'est cette idée de
si vous êtes statiquement sur un service,
vous vous rendez votre application
à un certain point,
le point que vous voulez délire HTML,
et vous ne vous avez pas besoin de
le rérunner dans le browser.
Tout ce qui a été récomputé
a été récomputé,
rien ne doit récomputé,
rien ne doit être récomputé.
Le browser peut s'en prendre
au state que le service
ou le build statique est resté,
et quand vous intervient,
vous pouvez continuer à travailler
avec le plus tard,
et que les choses ne sont qu'à rémodifier,
et modifier le DOM,
ou le downloader ou le hydrate
ou le exécuter quand il est besoin.
Et l'un des plus cool des demos de ça,
à laquelle j'ai eu,
vous savez,
le lock et le load,
comme un package,
et que vous pouvez le faire.
Mais l'un des plus cool des demos
est que vous pouvez prendre un appui rapide,
je vous ai mis ça sur la live stream
l'autre jour,
où c'est comme un liste de to-do,
ou je pense que vous avez fait un
commerce,
mais n'importe quel,
c'est juste d'en prendre un to-do.
Vous ajoutez des to-dos,
vous vérifiez des boxes,
et ce que vous pouvez faire
est que vous pouvez aller au DevTools
et vous pouvez copier le html de l'air,
vous pouvez le mettre dans un autre browser,
comme un browser empty,
le body.
Vous voyez le html,
mais les uns de nous sont utilisés,
html n'est pas une application,
c'est juste le bioproduct de l'application.
Donc, vous ne pouvez pas juste le mettre,
et puis interagir avec ça,
ce n'est pas possible,
mais en plus,
ça peut,
vous interagissez le html,
et vous vous interagissez,
et puis vous continuez de travailler
sur le state que vous avez fait.
Et c'est ce principle wild,
c'est extrêmement impactif
pour le rendition de l'edge,
le service statiquement,
et avoir une expérience très high performance,
à chaque scale,
n'importe comment votre app s'étend,
vous pouvez être macy.com,
et vous avez des lignes de code,
c'est encore plus facile de le mettre,
et ça ne va qu'un peu le faire,
c'est bien,
vous n'avez pas de problème
pour ajouter des imports dynamiques
et d'assins,
c'est vrai que le compiler quick
fait ça,
il ré-write tous les imports
et tout pour vous.
Mais il y a des principes
intéressants comme de débarquement,
le temps de tournage
est un processus simple
de snapshot du state html,
pour pouvoir replier,
et puis continuer.
Certaines outils
pour analyser l'espoir
est extrêmement lente,
dans ces contextes,
parce que de cette résumabilité,
c'est un principe bizarre
que Miesko a appris,
je me sens comme si il a
médité dans une cave,
il se rend avec ces idées d'inspirations,
et puis il a tous ces
intéressants effectuées,
qui sont évidemment très impacibles,
et qui sont, je pense,
qui continuent à explorer
les bénéfices de l'exploit.
Wild, Wild.
Donc en parlant de Wild,
Partietown est en fait
biscuit de la visite
devite l' zdrowé,
membre de l'king,
Wiол est en fait
turmois en morphologie,

inception de cette
junté dangle,
parle un peu plus scripts,
beaucoup de welche part moet les institution также pas
de moteur,
cartes,
저oid,
12 à 13 bezpieilles
de recording des milliers à la Destorable microorganciencenow distribué
enountain de photo est le restaurant de ses
cucumber ou cest à Dakar
Adam Bradley, créateur de Vionics, Tencil,
un whole lot of awesome projects,
kept reminding us, he's like,
you know we're gonna just get destroyed by third party scripts.
We're gonna optimize all of our code,
but all the code that's not in our control
is just gonna wipe us out.
And we're all like, yeah, I know,
but it's easier to not think about that.
I'll just finish quick and then we'll worry about it, you know?
And we kept having these ideas
and we were getting further with Quik
and eventually we got to the point
where like Quik is working great,
it's rendering out of site,
we gotta answer the third party problem.
And we really didn't know what to do.
All we know is we cannot have all that code
running on the main thread.
And we've learned from experience
like I think in your past experience you did,
just telling the marketing team,
no, you can't have marketing tools is not a solution at all.
Developers like I think it is,
they will fight it, they will try,
they'll never win.
And if you, I have experience of, you know,
working on the marketing end development side
of this company who has passed
company as a mostly on development side,
I fully understand why.
That yes, truly, genuinely, no marketing tools
means your business will not grow, it's not an option.
And as we know marketing tools, you know,
you could either blame the tool creators,
they write bad JavaScript
or you can just blame the functionality
that's required, requires JavaScript.
It really does, it needs to load,
it could be optimized more,
the incentives aren't always there,
but it's not a fully solvable problem
on the platform side too,
those who provide the functionality
can't fully solve it either.
And so we really were spending
around two different things.
So thing one was can you do this stuff
on a server somehow?
The problem is, and a lot of people have explored this,
can you do it at the edge, can you do it at the server?
The problem is those marketing scripts,
need DOM access,
they need to read the cookies and set the cookie,
they need to read the page,
they need to inject an additional script
and maybe need to inject an iframe or DOM,
the server doesn't work.
And so the only way it might work,
this is one of the paths we explored
is you run a fully emulated browser,
you run puppeteer on a server,
one per visitor,
and you have a web socket connection
where you're just posting stuff back and forth,
this is I need this cookie, I need this.
But even then the asynchronousity
makes the whole thing break down,
the JavaScript for these things
require the synchronous DOM access,
they would break all their code.
And probably security concerns
there too potentially.
Wild ones, so many problems with that.
But we were just obsessed
because we've identified how fast your site can be.
And I don't know if you've seen it,
one thing we noticed early on
is when we deleted all the marketing scripts
and we had the quick version of the page
versus the react version of the page,
that thing loaded crazy fast.
Like sometimes you don't realize it,
but we would just post links in Slack
and you would open up our old site
and it would load like a site does
and you'd open the quick site
and it's just like, what the heck?
The thing is just,
you don't realize how fast this stuff is
until you experience it.
And that's why we're losing our minds,
we're like, we're not gonna bog this down.
Once you hit that sort of peak performance level
of just like entire page load in milliseconds,
like it's just impossible to go back from.
And so we started playing with this idea of like,
what about the web worker?
We talked about it a lot
and we're like, well, I don't ever work this with DOM access.
But we're like, yeah, but the web worker would solve it.
It's wildly less expensive
than this idea of puppeteer and servers web sockets.
It is, I mean, it could be something that's just for free,
it's just open source, this and that.
The problem, of course, though,
is the window slash DOM access.
So the first thing we looked at is,
AMP had created this project.
Oh, I'm blanking on it now,
but they emulated the DOM in a web worker.
So they use something like JS DOM,
like a full pure JavaScript implementation
of the documents, DOM,
window, object API, some stuff to some functional.
And they did a lighter weight version.
Oh, I'm blanking on the name,
but we know the person who made that thing.
And he told us a lot about what went well,
what didn'ts, what to do, what not to do.
His main thing was don't run JS DOM with a worker.
But we ran an experiment.
We didn't experiment where we ran JS DOM with a worker
and we patched JS DOM to message the updates,
you know, to message back and forth.
The problem with that, though,
is JS DOM or any DOM emulation
is a massive amount of code.
And you still have problems of keeping the cookies fresh,
keeping the DOM state fresh.
Like if you're post messaging every DOM update back and forth,
it's still going to be wildly something.
And so that's where it was Adam's idea.
Can't remember where he came up with it,
but he was like, wait, wait, wait, wait, wait, wait.
Okay. And I can't remember when he did it.
We met up in person one time
and I think he was explaining it
and he's kind of like, hear me out.
If we can proxy those global variables,
so you run normal JavaScript on the web worker
and you use like the proxy API
to say anytime you're trying to access a variable
that's not there in the local scope,
at least we have a hook to say we could do something there.
The problem is we still have to do something asynchronous,
but we can intercept that and answer with something.
So next question is,
how do you make asynchronous to de synchronous?
And that's where we found two options.
One option we found first,
which is the ugliest thing in the world,
is it turns out that, you know, it's so funny.
I saw a video the other day that called XML HTTP request XHR,
this like, what do they call it?
They call it this like archaic thing.
And I'm like, I thought everybody was used to XHR.
Fetch is like the new shiny thing,
but XHR is how people have done it forever.
But what we realized is,
way back in the day,
there were facets to do synchronous stuff in web browsers.
People want to be easy, they want to be synchronous.
So XHR had a property to make it synchronous.
So everything on the page would freeze
while fetch some data and then rendered.
And obviously people realized
that's a very detrimental thing to do on the main thread.
They deprecated that.
But weirdly enough,
XHR, for whatever reason, exists on the worker thread
and synchronous XHR is allowed.
And with no, and we talked to people on the like Chrome teams,
the people and on the W3C,
and we're like, are you planning on getting rid of this?
They're like, no.
We're like, OK, we're going to use it.
We're going to use it for the ugliest thing imaginable,
but it actually ended up working.
I'll explain how it works a minute.
But yeah, so what we ended up doing is realizing, OK,
the combination of synchronous proxies
to hook into your trying to access global browser state,
plus synchronous XHR
is that lets us freeze the worker thread,
which is not nearly as bad as free as the main thread.
Because if you freeze the main thread,
you can't interact, the browser can't render those problems.
If you freeze the worker thread,
who cares in a certain sense, right?
And so you freeze the thread,
you trigger an HTTP request.
It goes to slash proxy town.
We load a service worker that intercepts that
and sends a command to the main thread
to evaluate whatever you're trying to do.
I was trying to get the document,
I was trying to run a method, whatever,
and then send the response all the way back
and let the web worker thread continue
as if nothing magical had ever happened.
It worked.
It worked really well.
And Adam came up with a lot of other clever tricks
to be able to do function,
and passing and referencing
and all this crazy stuff.
So Mexico, Scope and State all works.
So it was crazy thing upon crazy thing.
There's so many levels to the mad science
that he was able to implement for all of this.
Then to the day you actually have any JavaScript
to run in the web worker and it runs.
And we also verified with the lighthouse team
that when you're running code in the web worker,
as long as it's not,
when you're doing a performance test on a web page,
if you can download,
and we did a bunch of our own tests on this too,
but we checked with that team
to make sure they're not planning to change this,
you could download a gigabyte of JavaScript
in the worker thread.
As long as it's not like injecting big new things
into the main thread,
you're not penalized,
because it truly is out of the concerns
of the page loading.
The page loaded great.
And what most third party scripts are,
is just listening to events
and just firing off HTTP requests.
User click this, image loaded, whatever it is.
And so, the performance will be slightly degraded
in the worker,
that third party code will run an ounce slower
cause it has to do some thread hopping,
but your application runs lightning fast.
Every user interaction is lightning fast.
And you can finally go back to that point
that I made earlier about people being autonomous,
we can go to our marketing team and say,
hey, add whatever script you want in Google Tag Manager.
It's fine.
And everything runs great.
And the last thing I'll just leave you with is,
there's a new set of APIs called Atomics.
And we can use shared array buffers
to do this even faster,
where you don't need service workers,
you don't need synchronous XHR.
It's actually an API designs
to allow this type of synchronous access
across these threads.
And that's where we will move,
but there was this thing called the Spectre,
like security vulnerability that made it so that it's very,
it's difficult to use Atomics today,
but over time,
we will move from the XHR synchronous sort of hack
to Atomics and shared array buffers
and everything gets faster.
But at the end of the day,
even as things are today,
main thread is wicked fast all the time.
All your third parties are on another thread
and it's just seamless.
You write JavaScript.
And the last thing I'll add,
I know I keep saying the last thing,
last thing is we've been starting to write
first class party code lately,
party code.
I should keep using that, kind of like that.
We've been writing party code.
We've been writing JavaScript
that we know is meant to run in the web worker.
We do things like prefetching for quick,
client-side routing for quick, all in the worker.
We're even exploring running
all quick components of the web worker
because with Party Town, it makes the DX so seamless.
We're kind of like, wow, this is kind of nuts
and it's working really well
for performance, for load time,
for all that stuff.
It's fun.
Yeah, I was just about to ask that question
since the docs very clearly say
like third party, third party code
is first party on the horizon
because I myself have had the thought
like, oh man, if I could just run React
in a web worker and just let the main thread be idle,
that'd be awesome.
Yes.
No, it's exactly what we're exploring.
And what we find is the way the framework
is structured today,
there's so much sort of direct hopping
between the framework code and the DOM code
that the performance is not ideal
because there is a small price to pay on thread hopping.
So heavy DOM read and writes is not ideal.
But I mean, obviously, we're making a framework.
We're like, well, if we design the framework in mind,
the quick framework is unique
and then it can do every rendering asynchronous.
It's like, you can build,
you can run React through Party Town,
but it might not be the most optimal.
You can make a new framework, though,
that's optimized for this asynchronous world of Party Town.
Then it could be wildly fast.
Your application could be as big as you want
and get all these benefits.
And we're also exploring some things
that React Server components do,
where essentially a server,
something else, other than your application,
can return essentially vDom JSON that patches in.
We may be able to use the same facets of React 18
to actually allow this to work very performatively in React,
where it's like the web worker is actually
like your server for React Server components
and then returning the DOM for the main thread to patch in.
So there is really interesting stuff on the horizon here.
Oh, that's bonkers.
That's wild.
I, this really broke my brain when I first saw it.
I was just like, wait, wait.
So the synchronicity problem
was the first thing I thought about.
I was like, how can you do that?
The synchronous XHR is incredibly clever,
but there are all these problems.
It's like, you know, if you're serializing this object
that has like references or whatever,
you know, it can be like all this stuff
that you have to just basically call,
like web worker post message or whatever,
and get that over.
And it's, that's, I don't,
like it's hard to understate
how hairy of a problem this is.
And the fact that it works is nothing short
of just absolute blank magic.
Agree 100%.
And to be clear, there are many moments where we're like,
wait, this is probably just not going to work.
Even when we felt we were 80%, we're like,
that last 20% is going to kill the whole thing, probably.
And luckily, again, credit to Adam.
Adam solved everything.
The way he does the reference tracing
and everything is ridiculous.
Yeah, that's wild.
It does seem like there is,
I mean, there's still probably the potential
that things won't necessarily work as expected.
You pointed out earlier that, you know,
heavy DOM rights
or just a lot of message passing generally.
And especially if you're passing a lot of data,
it can be expensive and can kind of slow things down.
So if you have, you know,
some very poor performance analytics code,
which is not un heard of whatsoever,
that is like, I don't know, spamming either DOM access
or like accessing something,
like just over and over and over and over again on the window.
Like you could very easily get into the situation
where it performance for that, I guess, isn't great,
but maybe it's okay.
Like if it's mostly off the main thread.
Yeah, so there's two things we discovered
with Party Town that are cool here.
Thing one is the vast majority is analytics providers.
If they do anything slow,
it runs happily in the web worker.
They're not spamming the DOM much.
They're usually registering a few event listeners
and doing the rest on their own.
But the interesting thing is, you know,
when you going back to this idea of components,
composability of components, all that stuff,
like as a developer,
you just want to think about components.
You don't want other things touching your page.
Get off of my page, don't touch it.
So what's interesting about Party Town
is it creates this bridge that you can hook into
and you can actually say, ha, not allowed.
Like you can actually say within that worker
and you can put different scripts
and different workers by default,
they all fall into one.
You can actually say, no, you cannot touch the DOM,
no, you cannot read the cookies.
It actually sandboxes those things
for some increases to security privacy
and just sanity, so to speak, your own sanity
of being able to say like, no,
you're not allowed to read to this area of the DOM.
You're not allowed to write to the DOM.
I will handle DOM writing, you don't touch,
which is a nice property of it.
Fascinating.
Can you mop stuff going to the web worker?
So if it's like, hey, I want a cookie,
can you just like give it a whatever cookie you want?
So it uses the same API as Proxies
that says like, okay, worker's trying to do X.
How would you like to respond?
You could throw an error or you can return null.
You can turn a bogus string.
Another good example of this actually is like,
you may want the third parties
to have some level of user agent access.
You might want them to know
that it's a desktop versus mobile,
but you may not want them to know every detail
about the user agent, the version and everything.
They all use the same parsing,
regexes, the general strategies.
So you can actually provide a bogus user agent
that basically would allow most user agent parsers
to identify desktop versus mobile,
but nothing deeper than that.
So you can still be clear
about what I want these third parties to know
and what I don't.
That can help with GDPR and other things as well,
which is like you don't get access to certain things
until a certain time or never or in a limited way.
Magic.
Right.
Awesome.
So it looks like we got one question left.
This is a question we asked to a lot of our guests
that come on, but I think you'll have some unique opinions
about it, given all the stuff we've just talked about.
What do you think the future of the web will look like?
That's a great question.
Yeah, I could ramble about this forever,
but I really do think that one big change
is in the process of being made
and I'm very excited to see it
and we're contributing to it.
So we care a lot about it.
We don't be good about it,
which is really right now today performance,
like having a fast site and the flexibility,
the ability to update the site,
run tests on the site,
you build new things on the site
or at two ends of a linear spectrum.
So I've seen, in fact, I remember one time,
somebody sent me an example of one website
in e-commerce at decent scale
that reached 100 out of 100 on Google PagePay,
and sites mobile.
And I was like, I don't buy it, like no way.
And I loaded it up and like, it's true.
It actually did.
But I realized something.
I'm like, I've been through this rodeo before.
I guaranteed the way they did that
is by taking enormous amount of sacrifices.
And what they did as a key part of that
is they unplugged every possible tool
to customize that page.
That page is as hard coded as anything
that's ever existed
to make sure you constrain
every possible performance nuance.
And so as expected,
I checked back a month later to see
was that page still fast?
No, it wasn't.
It was down to like 20 out of 100
because you realize a website
is not a static thing.
It doesn't sit there un-changing,
especially e-commerce or similar industries.
It has to always change.
And that's where it's picked your poison
and businesses require change.
So that's why everybody ends up
start, even if they touch the side of the spectrum,
they just slide back to the side.
And that's where you find conflict
in between teams, the engineers fighting.
Stop doing things.
We need to lock down the performance
and the marketing, which is like,
stop being annoying.
We need to promote this business.
You only have a job
because we're selling a product
through this business.
Like, you know,
everybody needs to come to terms here.
And so I think what we're going to see
that I'm very, very excited about is
finally, I think the ecosystem
is cracking the code.
And we're not the only ones doing this.
Marko does some cool things.
Astrodis can cool things.
We think we take these things
the furthest, at the largest scale.
We focus on the largest scale,
a blog site, a hobby site, etc.
Can use those other tools
and get good performance without doubt.
But I think we're finally going to reach
that day and age where we see
the web is a much more fluid thing.
You can actually actually be set free.
And regardless of people's
background, technical or non-technical,
they can be making wild things.
The other day, atoms.com
made this landing page
that was a mix of code and no code.
And it was just ridiculous.
It had this canvas motion graphics
effects that the developers made,
but they registered it with Builder.
So they dropped it on the page
and they customized the details.
They put the shoe and the product information
on top of it and all these animations
and other things.
And the performance was killer.
And it was like, this doesn't happen.
You don't, A, build a wildly awesome,
crazy interactive page.
B, you don't do it without code.
You don't do it by just dragging and dropping,
hitting publish, it's live in a day.
And C, end up with a high performance
experience end to end.
Like those things don't exist.
And I think we're just starting there.
I think similar to the personal computer
where the aptitude was only the beginning.
It was just, you know,
people could do things without coding.
That's great.
But there's so much more to come
for the Macintosh, iMac, iPhone, all of that.
I think we're at a similar thing
where we've really found
scalable solutions to performance.
Just like, you know, the Apple,
I think always knew
it could run code performantly.
It's just what can you build
on top of that foundation
so that you can do interesting,
wild, 3D animated, you know,
iOS games, but still run
in a performable way under the hood.
And I think we're getting to that point for the web.
And we're getting to the point
where everybody can be
not just a content creator,
but an actual coder,
an interactive experience creator.
And I really do think that
the second order of effects
of democratizing something like this,
making it so that it's not the tiny population
who knows how to make interactive coding things,
but actually make it so that everybody can do
literally what anybody else
can do who can code.
Coding is not going away.
I think it'll get more specialized.
And I love code.
I still write code.
Though I'll do make anything
and builder that I can
because it saves me a lot of pixel pushing.
But I think we'll see this sort of second order
effects of everybody can make wild stuff.
And when people can make things,
people inspire others,
people jump on the bag and wagon.
And I do think we'll see
some level of renaissance,
just like personal computing,
the internet stuff like that
when it comes to the creativeness of the web.
And we're seeing fragments of that now today,
like it's just one final example.
If you look at any e-commerce website,
you'll find that it's generally a thin layer
of the database.
It's a homepage that shows a preview
of a couple of products.
And then every other page
is a collection page or a product page.
Collection page is a grid
with different pictures in the boxes.
And the product page is just a bigger box
with a different picture
and different price and different piece of text.
It's incredibly boring.
And what customers of ours,
like Everlane have started to do,
is actually reimagined every page.
So, like, as a quick aside,
as like a real world example,
is I tried to learn to surf recently.
It was partially successful,
partially a failure.
It's difficult.
And I realized I needed a wetsuit.
And so I went on Decathlon's website,
Decathlon.com,
and I'm like, I need a wetsuit.
I knew wetsuit was good for surfing,
it's good for cold weather,
because Pacifica is freezing.
I don't know if you ever surf Pacifica,
but it's so mind-numbingly cold.
I need a good wetsuit.
And I went online
and I saw these grid of wetsuits.
And I was in the deepest category,
I was in the wetsuits category,
there was no other filtering.
And I'm like,
which one do I get?
And I'm like clicking through each one,
trying to find where in each product page
there is some level of difference.
And eventually I gave up,
but my partner convinced me
to go to the Decathlon store.
And we walked into the store,
the store was better organized,
it had surfing sections.
So I went to that.
And then in the surfing section,
I had the wetsuits.
And it said, these are the beginner,
intermediate, advanced wetsuits.
This one's good for cold temperatures,
this one's good for warm temperatures.
I was like, that is intuitive.
I know which one I need now.
I would have never figured that out,
clicking through every product page on the website.
It's kind of slow too,
so it was kind of painful.
And I just bounced at a certain point,
which is what happens.
What Everlane's doing now is,
if you go to the denim page for Everlane,
it's not a grid.
It's actually these full page sort of explore
the different denim options,
drill down to what you actually need
and then see a slightly more hand selected
or computer selected set of products to explore.
And that's really exciting to me
because e-commerce websites
have not changed in decades yet.
And I know Everlane,
Everlane's founder CEO is an investor.
I remember last time I met up with him,
he was just so excited about
how awesome their latest storefront is
and how this new store,
the physical store was so different
than every other one.
And I'm like, wow,
that passion does not exist on the web
and e-commerce in a certain way.
It's really just grids on grids on grids,
boxes on boxes,
different data in the same boxes.
And it's exciting to see
now that they have the ability
to make the experience unique.
If you're shopping denim,
it's a different experience
than if you're shopping shoes, right?
They're sneakers of a very different look and feel.
Adam's a similar,
the shoes page and the mass page
is totally different.
It's different information.
There's a different way to lay it out.
And when it's easy for people to do,
you get these magical properties.
So I'll stop rambling,
but I think the web will get a lot more exciting.
That's what I'm trying to say.
Well, I'm excited.

Yeah.
We've had some guests that are like,
ah, everything's shit
and it's all going to trash,
but I'm excited to see the optimism.
I'm optimistic, yes.
Yeah.
I, even for Descript,
I could see so many different use cases of,
like it's a problem that we deal with too.
Like I spent weeks
trying to get our bundle sizes down
and then I come back three weeks later,
just look at it and I'm like,
oh my God, no.
So just to get away from that cycle
is going to be a huge revolution of the wheel.
Quick Automate's on a cool way, by the way.
It rewrites all your imports
and hopefully that's an archaic problem
of the past very soon
that nobody is wrestling with anymore.
Yeah, that's our hope.
Yeah, if I never have to open up
a bundle analyzer again,
I'd be a happy man.
Those are not fun.
I have one quick question.
Is it, does it require a server?
Is it like server-side, rendered?
That's a good question.
So no, it doesn't.
I mean, you can run it fully in the browser
if you want.
It's quite performant
in a lot of ways, just fully in the browser.
But in most cases,
you should probably static render.
It depends on your use case.
Basically, we support the same things
that Next.js does.
So a server, a static,
an incremental static
or just all in browser is all fair game.
Sweet, awesome.
Cool.
And yeah, with that,
we will move on to tool tips.
So my first
and maybe only tool tip of the week
is something I literally saw today.
It's from Matthew C.P.
He works at Astro, I think,
and produces a lot of different
interesting tools.
I think we talked about Lucy Lang
one time, like a DSL
for writing state machines.
This is a very different approach
on a JavaScript front end framework.
So it aims to like completely decouple
the interactivity you add to HTML
from the HTML altogether.
So what it looks like in the end
is a very weird take on CSS
where you like you target something
that's in the HTML
such as like a button or a counter
and then you have this CSS language
to make it interactive
so you can have like increments
the counter, you can affect the text.
You do all different weird sorts of things.
So if you're interested in on
a wildly different take
on front end development,
this would be a good place to start looking.
That's fascinating.
I did not get this on first look.
That's interesting.
Yeah, it's it's it's
it's a weird take.
I've never seen it before
and I'm interested to see a few
like larger examples
that show how you could use it.
Agreed.
Most of you do like repeats and stuff too.
I'm sure it's in there.
I'll take a look at my own time too.
Yeah, it's really interesting.
It's like, oh, you can tell
that they're like really like CSS.
Like, you know.
And of course, I forgot to say the name.
It is corset.dev.
And yeah, that's the name.
Let's move on to Justin.
So this is something that Andrew
actually shared with me
and I forgot and I reshared it with him
as it goes.
So there is this website
called block protocol.org
and it's I think it's by a company called HASH.
But they're sort of envisioning
this specification
for how to describe components
in a data format.
This is not a new
and or unique thing.
Anybody who's ever used a headless
CMS has like consumed
this sort of thing before.
Just another take on like trying to
to sort of like rough out
a standardized way to describe
certain sets of components
to give them specifications
and then to provide some components
out of the box and then
give you the ability to
to register your own components.
I thought the presentation of this
was really well done.
I'm really enamored with the idea
of just like generating components
from structure content
because in the same way that sort of
like quick takes this gives you
this component format
that is sort of an intermediate
representation of what, you know,
all these other framework components
could be a sort of
block protocol or like structure
data for a component
is is very much that in a simpler form.
It's like, you know,
we'll give you the data to express
the component and then you can just
sort of like generate it out.
But anyway, yeah, it's really cool
if you're interested in the sort of thing
or if you're, I don't know,
thinking about making your own
CMS or using
like a structure CMS
or something and then like
or thinking about
how to store the data
for your components.
This could be some good inspiration.
Awesome.
So this is a performance tool
that we put out
because we notice something
a learning we had
and looking at the performance
of websites is typically
and actually I'd encourage
you to just throw a website
in there. It takes a while
to load the performance scores.
So put like, I'll put
like target.com, Nike.com.
I don't know, some website
of decent scale
because it usually is more meaty.
And then, yeah,
I just say
definitely not the one I manage.
So don't want to put myself
on blast like that.
I feel bad.
I've been using target as examples
because I don't know anybody
target, but I'm waiting for
somebody to stop it.
To be fair, every commerce website
or most websites
a certain scale look look the same
in terms of performance scores.
But basically, here's what we found
and why this tool is kind of
interesting to us is
you can go to PageBit Insights
or Lighthouse
and it'll tell you fix all these things.
What it doesn't do is quantify
how much of an impact
each thing would make
and people get frustrated.
They start knocking out things
on the list,
takes a month to get the three items
and they don't see the performance score move.
So what we do is
and this is how we learned
the impact of different things
on people's site performance
is we will take your website
and we'll just run the normal Lighthouse.
We use Google PageBit Insights API
under the hood.
So it's doing a mobile score.
And then what we'll do
is we'll proxy your website.
We will grab your HTML
and we'll modify it.
So in one example,
on that middle one,
we're optimizing images.
So we're just making sure
the images use the lazy attribute
or loading equals lazy
if they're offscreen.
They're setting the decoding
to be async.
They're setting a width
and height attribute.
We basically add all the attributes
that you should be adding to images
and we'll rerun the score
and say, OK,
how much will changing
the way you load images
impact your Lighthouse score
or your performance score?
And the idea is
you can usually pinpoint
one or two things
that are actually
the most impactful.
Like PageBit Insights
will tell you change
a million things.
But in this case,
yeah, if you optimize
all those things,
it'll go up a lot
because everybody's question
is always how do I get to 90
plus out of 100?
It's like, well,
this will tell you.
In this case,
the original score,
I think said images
were not that much
of a problem for Target.
The score went up
like five points
like whatever.
That's fine.
CSS is pretty on part, too.
For CSS,
we remove any unused styles.
So we come through every style
if it's not on the page,
we remove it.
We run the performance
and we see that.
OK, your CSS
is pretty good.
You could remove some styles
and the score will go up a bit,
but nothing crazy.
And generally,
what we find is
JavaScript is the problem.
For the JavaScript test,
we literally just
delete all the script tags
and say, how fast
would it run if it just had
no scripts running?
And that's usually see,
like, oh,
just that one modification
would get you to like
an 80 out of 100
or whatever it is,
doing nothing else.
And so that lets you see,
like, OK, that's cool.
And if you have that tab
still open,
you could scroll down.
It'll recommend some tools
and it'll say, OK,
if you use Party Town,
we can run the same proxy
and instead put some
of the scripts behind Party Town
and look at the new
performance score
of the Party Town of Fide site.
And usually,
actually, we'll be able
to see it in a moment.
Usually, you can get from,
like, in this case,
it starts at a 28,
keeps going further,
further, it's a decent ways
down the page.
Yeah, quick wins, 95.
Just adding Party Town
to as many scripts as possible
could get you up to 95
from 28.
That's one of the things
that people are just like,
tell me how to improve the score.
It's like that's,
like, that's,
you should do that, right?
We will show with quick, quick.
The quick score
will simulate basically
all scripts removed.
So first party scripts
can be removed entirely
and only laid
loads needed.
And if you scroll up
a little bit,
we get some other tips.
So in this case,
we said CSS
is kind of optimized.
So if you click
into that,
you'll see some suggestions
on how to better
code split it.
JavaScript
will recommend various projects,
a couple of ours,
couple of others,
this and that.
And this,
people have been enjoying it
just as a way
to stop banging your head
against the wall
and like what's going to
move the needle
and actually realize,
you know,
maybe page,
but inside set you down
this rabbit hole of,
of something about images,
but JavaScript
or CSS
or something else
is your problem of the whole time.
So it's fun tool.
It's in beta.
If anybody watching
this as feedback,
please tweet at me,
Steve 8708.
We'd love to the feedback.
This looks awesome.
There,
I shared a few podcasts
back core web vitals,
I think.
And it's like
the same thing,
but this seems
a lot more approachable
and like a friendlier
to the eye.
That tool is just like
here's just everything
that's possibly wrong.
And it doesn't tell you
exactly if it would
make it all that much better.
So I really do like
having the the improvement
that you could get
because you can really
prioritize based on that.
Yeah, exactly.
No, I'm glad you liked that
and exactly with Google
rolling out core web vitals
as a requirement
for search ranking.
It's actually like life or death.
Like,
even if you don't believe
for whatever reason
that like poor performance
will lead to users
bouncing and poor conversions,
Google literally will say
you don't pass core web vitals.
We will derank you on search.
That's just your business
falling through your fingertips.
So yeah,
hopefully you can get this
and know how you can get
the score up and pass.
Sweet.
And this is the performance
insight tool.
So it's builder.io
slash c slash performance
hyphen insight.
Insights,
I guess.
Well,
we'll have a link
in the show notes
so you can you can
definitely find it there.
Yeah,
this is really awesome.
I am a bit of a performance nerd
and have used
a lot of tools over the years.
You know,
the classic web page test
is great.
And this is just.
Yeah,
team is awesome.
There's a lot of.
Yeah, yeah,
they're no, they're great.
And they've been doing it
for a while, you know,
and, you know,
so that's the shoulders
that.
Did you know sort of
build off of,
but yeah,
yeah,
web page test
used to be one guy
who had all those devices
in his garage,
like he had the phone
and the old laptop
and this and that.
You would be waiting
at a queue to run
in his garage.
The company,
I forget the name,
acquired it,
but I heard that story
from someone on the team.
I thought it was hilarious.
Yeah,
I mean,
I really love the
just the innovation
in this space.
So there's another tool
that I was using
at my last company
called caliber.
Caliber is great.
I'm just,
you know,
a lot of tools
in this space.
But yeah,
definitely giving actionable
insights.
This is the number one
thing you want to do
with any performance
insights.
Yeah,
what I I know it sucks.
Now what?
What I do is 5000
things you could do.
It's yeah,
go ahead,
I start.
Yeah.
Yeah.
OK.
And with that,
I think that wraps it up
for the episode.
Thanks for Steve
for coming on.
This was a wildly
interesting look
into the future of web pages
on or to the future
of web.
So thanks for coming on.
Yes,
it was awesome.
Honestly,
y'all done,
y'all done some magical,
magical work
and I'm I'm
definitely excited
to dig in more.
I appreciate that time.
Hit me up with any questions
you got.
I'm happy to respond.
I'm pretty accurate on Twitter.
Well, that's it
for this week's episode
of DevTools FM.
Be sure to follow us on YouTube
and wherever you consume
your podcasts.
Thanks for listening.