All language subtitles for 1-the-state-of-front-end-frameworks

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.

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.

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.

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?

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?

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.

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?

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.

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.

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.

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?

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.

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.

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.

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?

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.

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.

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?

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?

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

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?

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?

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.

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.

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.

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.

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.

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.

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?

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?

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?

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.

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?

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?

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.

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?

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.

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.

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?