The State of Front-End Frameworks

[00:00:00]
>> We want fast websites because, well, that's a good developer experience. And this actually has been a problem for almost a decade. And it has been a problem for so long that Google has spent huge amounts of time and effort on building what Google calls either the Core Web Vitals or they call it the PageSpeed Insights.

[00:00:24]
So there's two parts in there, there's Core Web Vitals and there's Page Insights. Core Web Vitals is actual data collected by Chrome when you as a user visit a particular website on Chrome. And so that's actual field data. Page Insights is a laboratory test which tries to predict what your actual Core Web Vitals vitals will be, so those are two separate things.

[00:00:46]
So when most people talk about Page Insights, they are actually talking about the in-lab kind of simulated environment. Which, usually, is a predictor of Core Web Vitals but it doesn't actually have to be. And so the thing you want, is you wanna have a good score, a good performance score.

[00:01:04]
So this shows you the Core Web Vitals numbers on the top, right? This is how it is. And then on the bottom, it's gonna run it in the lab and try to show you what the predicted numbers should be. And the thing that Google cares about, which I think are good numbers is, how long does it take you to paint the screen?

[00:01:23]
How long before you can interact with the system? Are there any kind of shifts, meaning that you render one thing, and then an image shows up and the whole thing moves over? And a few other things. And what I find interesting is that there's this calculator in here, and you can actually see how this calculator influences your performance, right?

[00:01:42]
So how sensitive is the system to different parts in it? And the thing that is super sensitive is total blocking time, which kinda makes sense, right? If you navigate to a site and JavaScript is running, then as a user, you can't interact with it, right? So total blocking time is the biggest block of JavaScript that didn't allow the user to do an interaction.

[00:02:06]
So you could take ten seconds to boot up, so to speak, but if you break it up into one-second chunks, then your total blocking time will only be one second. And a time to interactive is basically a number that says, how long does it take before a user can do an action?

[00:02:24]
And if you think about it, it also makes sense, right? You navigate to a page, and you want to be able to go and interact with it, right? The reason I'm going to a page is because somebody sent me a link to a cool shoe and I'm gonna go and check it out.

[00:02:37]
I'm like, I love this shoe, let me add it to the shopping cart. And I'm like, I can't add it, that button does not work, right? And at some point, you're like, you know what, I really don't need that shoe, and you just leave, right? And so this is the reason why performance matters.

[00:02:51]
And so it turns out, getting a good score on a real website, what I mean by a real website is a website that has Google Analytics, has HubSpot, has all of the third party code in addition to your first party code. Getting a good number like this is extremely difficult.

[00:03:07]
And it really comes down to the amount of JavaScript that is being shipped to the client. So first of all, does it actually matter, is this and actually problem we're solving? And so Google has collected, on their web dev website, they've basically collected all kinds of statistics that is trying to convince the world that, look, this matters, right?

[00:03:26]
There are companies that tried to improve their performance. And in each case, basically, it's positively correlated, meaning the faster you become, the more money you make, the better the conversions are, or whatever thing that you care about, whether it's sign up conversion, sales, user retention, doesn't matter. Whatever thing you care about, gets improved if your site is faster.

[00:03:48]
And that makes total sense, right? You just want to have a nice, fun, website, good experience to kinda work with. So I think there's a huge amount of data that actually says, this matters. And so you would think, since this matters, that companies would try to get there.

[00:04:05]
But it turns out it's not so easy. And what I mean by that is, this is a graph from HTTP Archive. And it basically shows the amount of JavaScript being shipped to the browser over time. And what you can see here is that in 2012, or so, we started with relatively little amount of JavaScript.

[00:04:23]
And there's essentially just a progression that keeps going up, up, up, up up, right? And this progression doesn't look like it's gonna stop. And so you say, well, what's going on here? Are we just getting worse or something like that, right? But if you think about it, the sites today versus sites ten years ago, the site today is much nicer, a lot more interactivity, a lot more things I can do over there, right?

[00:04:49]
So it's not like we're just getting worse at not shaping JavaScript, but JavaScript has a purpose, it's doing something useful. It's giving us a better user experience that the users want, but it's coming at a cost of startup performance. Once the website is up and running, usually nobody's complaining about the performance of the site.

[00:05:08]
It's the getting it up and running, the boot up process, so to speak, that is the problem. And so my prediction here is, this trend is just gonna continue. We're not gonna stop in terms of the amount of JavaScript we're gonna ship to the client. And part of the reason is that it just becomes so easy to just type npm install and add a particular thing.

[00:05:28]
But if you think about it, we're in this world where whatever your problem happens to be, whether your problem is, I wanna add animation, or I wanna add localization, or internationalization, or analytics, or whatever you wanna add to the website. There is a solution out there in NPM somewhere, right?

[00:05:45]
The problem is, all of these solutions will just keep adding to the amount of JavaScript you have, right? And all these solutions just assume that they should be the first ones to get executed on boot up of the navigation of the website, right? So you come to a website and immediately all of your analytics code, all the animations code, everything is coming up and initializing and booting up, and this basically creates the problem, right?

[00:06:12]
So, what can we do about it? Well, right, so this is just kind of reiterating the point that this trend is gonna continue, we're not gonna stop, right? The website of the future will have even more JavaScript, right? And this isn't about going back in time and saying, hey, let's just go build the websites we built ten years ago.

[00:06:31]
First of all, the developer experience sucked ten years ago, nobody wants to do that. And second of all, the user experience also sucked, right? It wasn't as nice of a website ten years ago as they are today. So nobody wants to go back, but we do need to do something with the amount of JavaScript that we're shipping.

[00:06:48]
Okay, now, to kind of point out just how much of a problem that is, we built this site called Performance Insights. And what we do on this site is pretty straightforward. Take your website, you type in your URL, and it runs it through Google PageSpeed score, right, and it gives you back a number.

[00:07:06]
So in this particular case, it gave you a number of 36. And so what we're saying is, by default, this website that you built is just the same number that Google PageSpeed gives you. So then we do is, we run it through image optimization, right? Everybody says, please use the latest and greatest images, make sure they're correctly sized, etc.

[00:07:23]
So we optimize the images on your website and then we feed it back to the PageSpeed score and we get back 77. Meaning that if this website could have done a better job optimizing, they could have had a better score. We do the same thing for CSS, and we get an improvement again.

[00:07:38]
So this particular website did a bad job of optimizing images and CSS. And then we optimize JavaScript, which is a euphemism for we delete JavaScript. And we run it through the website, and, wow, look at that, you get 100th, right? So even without optimizing images or CSS, just by deleting the JavaScript, you will get an amazing score.

[00:07:58]
And then the last bit is what happens if we do all these things together. Now, this is not a typical e-commerce website. So, what we did is we did the same exact thing for top 50 e-commerce websites. This font over here is way too small for you to read, that's not the point.

[00:08:14]
The point is, these are top 50 e-commerce websites. And notice the first column, it is all red. So think about this for a second. We're talking about top 50 e-commerce websites that clearly can get the best possible developers that money can buy, cuz they're the biggest e-commerce websites.

[00:08:32]
They understand the value that a faster website gets more money. They're in the business of making money, they're e-commerce website. And, yet, they're all in the red. What is going on in here, right? You have highly motivated people, which have the resources to do it, and they still can't do it, right?

[00:08:53]
And so to go around and basically blame the developer, to say you just didn't hire the best developers. I'm like, yeah, but this is the top 50 e-commerce websites. If they can't hire the best developers, then who can, right? Now, I wanna point out a couple of anomalies here.

[00:09:09]
Again, the font is way too small for you to read, but this yellow one over here, that's Amazon. This yellow one over here is Staples. There's APMEX, which I've never actually heard of, and the yellow one over here is actually IKEA. So there are a few companies out there who are really, really trying hard, right?

[00:09:26]
And Amazon being one of them. And, yes, you navigate to Amazon, you'll get your response pretty quickly. And they fully understand this. And what's interesting about these companies is that, for example, Amazon, there's a tweet out there that basically says, at Amazon, we looked at using React and we realized it's just not fast enough for what we need, right?

[00:09:47]
And it totally makes sense because server-side rendering on React is a lot more expensive, and then client-side hydration will negatively impact. And so if you use something like React, and I'm not picking on React, the same is true for AngularJS and other technologies out there, as well. You'll kind of realize that, well, you can't.

[00:10:06]
And so what Amazon's actually doing is they have, probably, a PHP script on a backend, good old-fashioned way of doing it. And they have jQuery in the frontend to kind of add interactivity. And that's kinda how they get performance, right? Is that they basically do not do hydration because hydration would be a death.

[00:10:27]
Now, what this basically shows is that if I take the top 50 e-commerce websites and I try to optimize images, I will get a very little performance benefit. And that makes sense because the top 50 e-commerce websites, they already know what they're doing. And so, for the most part, they're doing the right thing with optimizing images.

[00:10:46]
Same thing is true for CSS, there's very little gain to be had optimizing images. But look at the huge job if we could just figure out how to get rid of the JavaScript. And actually this column right here, as you can see, optimized images, very little changes in this column.

[00:11:02]
Optimize CSS, very little changes in this column. Optimize JavaScript, meaning delete the JavaScript, look at that. All of a sudden everybody's in the yellow or green. And if you can put all three of these things together, pretty much any website can get pretty close to 100, can be in the green in terms of startup performance.

[00:11:21]
But we need to do something about this JavaScript problem, right? So let's look at existing frameworks. What I find amusing about existing frameworks is that they all claim that they're the fastest thing available. And their claim is basically set around the idea of, we do x really well.

[00:11:41]
And if you extrapolate x, then you think that x is everything that matters. And so one of the things I wanted to point out here is, websites are fast, not because the underlying framework is fast. Websites are fast because there is very little JavaScript to execute, right? This has nothing to do with framework, right?

[00:12:05]
SolidJS has superb benchmarks that show off how fast it is, and I believe it. It's probably one of the fastest frameworks out there. But it's irrelevant, because it's not the thing that is the problem. The problem is the amount of JavaScript that is downloaded on initial render. That's the problem, right?

[00:12:25]
And so the fact that SolidJS optimizes away all of these things, good for once the website is running. Doesn't help you with getting the application up and running. Now what this graph here shows is, as the amount of HTML templating, jsx, whatever you have, grows or number of components grows, how does the size, this should be probably in kilobytes, how does the size of the total amount of bundle grow, right?

[00:12:56]
And what you can see is that different frameworks have different slopes, and they have different intercepts, right? But they all kind of fall into this category of y=mx+b, right? We have the amount of content we wanna ship to the client. b is the initial kind of framework size that we have to ship.

[00:13:14]
And then there's the marginal size, which is how many bytes per each byte that you kind of type in in form of a templating JSX, whatever the templating system you have. And while there are certainly differences between frameworks, I'm gonna argue that they're pretty much the same, right?

[00:13:32]
They, for the most part, are about the same, there isn't really much of a difference. And so this is this line over here that's blue that's resumable, and that's supposed to be close to 0 but not negative, [LAUGH]. And this line basically shows what you want is you want a system where the amount of JavaScript is flat, right?

[00:13:54]
You wanna have a system where, yes, the amount of HTML I send across is the amount of HTML I need to render the page. But the initial amount of JavaScript should be constant. And that's not the case in the current world. In other words, sure, I will go build a simple Hello World, or a showcase movie app, or showcase store in your favorite technology.

[00:14:20]
And I'm gonna show you, look, it's 100 out of 100, and that's great. The problem is, once the real world requirements show up, once you need users, authentication, settings, preference pages, analytics and all the other things, that demo app that used to show 100 out of 100 on Google PageSpeed score is just gonna keep decreasing, right?

[00:14:43]
Because as the complexity of the app goes up, the thing decreases. And I find that very almost disingenuous that people show off all these demo apps, and then show off, look how amazing we can be, right? And yeah, you can build a demo app in any technology and get good scores.

[00:15:03]
But once this technology hits real-world complexities, it will just disintegrate. And that's kind of the point here, is that what you want is a framework that is 0 of 1, right? You wanna have a constant cost framework cuz you don't need to have it. If we do nothing, this train line is gonna continue.

[00:15:24]
And what we want instead to somehow break this correlation. We wanna say, can we do something to not having to continue it this particular way?