My name is Ashley Williams.

You may know me as AB.Dubs from the internet, I'm sorry!

What is this talk about?

This talk is about a couple of things.

The first thing is it about is performance.

More importantly, performance that makes things more accessible, and, unlike a lot of the

talks that we've seen at this conference, this talk is also about infrastructure.

Can I get a shout out from any of the ops people in the room?

Come on!

Who is on pager duty right now!

Someone, I'm so sorry.

That sucks!

I want this talk to be a little bit about how the internet works, and potentially, how

the internet could work.

And so this talk is called "JavaScript's journey to the edge" and so there's a little bit of

journeying.

Perhaps you're more familiar with these journeys if you're from the United States, but I just

wanted to say a small thing, as this is JSConf about how important this conference has been

to me.

I spoke at the last Reject JS in 2015, and I was the second-to-last reject only to Marika

who was the last reject.

It was one of the most amazing conferences.

The next day I went to JSConf EU and saw someone wearing a shirt with my face on it which was

a fascinating surprise.

This was from a musical number they had done using quotes from a previous talks of mine,

and they did that again in 2017, or 2016, with the classic "people got mad" which was

an auto tune of my voice talking about how people get mad if you put all of your code

in one file!

They do get mad!

But then I spoke at JSConf EU in 2017 and I wore an Antifa shirt.

It was a super fun talk.

Man, I have so many friends at this conference.

The last time I was here was last year where I did an impromptu Rust and WebAssembly workshop

for 100 people from the Mozilla booth, and it's cool.

This conference is super awesome, so can we give it a round of applause?

I love this place.

But this talk is obviously not about my journey, this talk is about JavaScript's journey, so

I'm about to show you some very scientific timelines that I made using Wikipedia and

Keynote.

JavaScript has had a fascinating history, and people talk about history, about this

one being the tenth one, and Node being announced in 2009.

We've seen a lot of development from JavaScript, and we've seen it develop really, really quickly,

and I think it's kind of developed in one particular way, so here we see the first website

in 1991, and then we end with Wasm up in 2017.

Wasm was only born in 2017?

Amazing.

But, we saw the appearance of a fair number of things, including a lot of browser engines,

and a lot of frameworks.

And I think one of the most pivotal things in this timeline that people don't usually

see is the emergence much Google Maps in 2004 really motivated people to see what you could

do inside of a website, and made it so that we started developing all of these things

that you could do browser computations so much faster.

So if we put these graphs together and take a look at this, what is happening is that

the speed of computation in the browser is just exponentially growing, and that is so

awesome, and I'm a big WebAssembly fan, I'm super here for this.

However, because the browser has become such a computationally awesome agent, we've run

into some costs.

How much does doing this cost?

And fundamentally, this comes back to the idea of accessibility, and it's spelled wrong

here, but it really comes down to the fact that what we are talking about is the ability

for people even to access content.

Mani in his talk the Cost of JavaScript in 2018 said the web is bloated by user experience.

And he's genuinely completely right.

So how many people here have ever checked out HTTP Archive?

If you haven't, it's amazing, and you could loan at these numbers.

This is just one of the graphs.

What this graph is showing is the median size of desktop and mobile applications with the

JavaScript bytes that are being downloaded to the device, and we have seen a 353 per

cent increase for desktop, and it's worse for mobile - 577 per cent growth in how much

here sending to the browser.

It's cool because the browser can take that stuff and use it really fast.

Moving those bytes over the wire takes a lot of time.

So, on average, remember, this is on average, there are people who are on the really bad

end of this, mobile loading time for an average website takes nine seconds.

All right?

That's unacceptable.

So this is going to be part of the problem we are going to solve in my talk today.

So, my intro did not entirely say this but I'm a systems engineer for a big orange cloud,

not to be confused with a big orange website which I'm not a fan of, or SoundCloud which

has a surprisingly spectacular logo.

I work for Cloudflare, I know it doesn't look super big here.

What does it do?

Cloudflare is an infrastructure company.

Cloudflare is not super good at actually defining what it does, but the thing you definitely

don't call it is a DNS company, because also, I mean, no-one likes DNS.

I can't figure that out.

I work at a DNS now.

But we call ourselves an infrastructure company, and sometimes, I describe Cloudflare as a

hardware company, and that is because our primary asset is this, and this is a map of

180 data centres and growing all over the world.

And so, this set of data centres contains something which is called "the Edge", and

this is a terrible name.

It doesn't make any sense to most people.

Someone said there's a wrestler called the Edge.

I don't know who that is, whatever.

To talk to you about what the Edge is, we will talk about the classic dichotomies in

web programming: client and server.

To do so, let's talk about pizza.

Who likes pizza?

All right, there we go!

I'm originally from New York, so pizza is cool, right?

We are going to talk about pizza delivery, and I want you to view that in the eyes of

pizza accessibility, because it would be terrible to deny people pizza, right?

Especially, warm, fresh pizza.

So obviously, you guys smoosh them together for pizza accessibility, all one word.

Here is animation mere HP your JavaScript programmer will be represented by this lovely

chef.

The JavaScript's generated output is a pizza.

Your end using is a super hero because this is how we should think about our users, and

we are going to have this interesting thing that is a basket, and so there you can think

of that as a data centre, a point of presence, or a cache node.

Let's take a look at what client-side rendering looks like.

With client-side rendering, what we do is we have our chef in New York, and we have

our person who wants to eat pizza in Australia.

When we render on the client, we send the chef to Australia.

That's a lot, right?

And then, what the chef has to do is then the chef has to cook.

And then, at that point, you have delivered your pizza in Australia.

But that's a little concerning, right?

Like, maybe the person in Australia doesn't have like a whole room with an oven for a

Like maybe they have a flip phone that literally can't do that.

This is a little bit after complicated situation.

So, of course be what do we do?

Let's throw a cache on it.

That should make it better, right?

Instead, with our cache, we send our chef to a basket, you know, and the Pacific Ocean,

South Pacific.

We send the whole chef and then we still have to send the whole chef to Australia where

they cook and they make their pizza.

Again, we still have this situation, even with the cache, where the chef is travelling

for maybe a closer location, but these still have to go into that person's house and make

that pizza.

That's pretty invasive be think.

All right?

So we can keep sending those chefs, but, yes.

Again, we have another option, right?

We have server-side rendering, and of course as everyone said, ten years ago at JSConf

you, Ryan Dahl announced node.js and it was cool because it promised to unify web development

on the client side and the server.

It's like why do it in two languages?

Let's do it in one.

That made the server accessible to JavaScript developers.

Maybe not for the first time, but for the first time for fin who didn't want to learn

a new language.

So let's take a look at what server-side rendering looks like.

We got our chef in New York and our super hero in Australia.

They're going to cook in New York.

No more moving into the house to make pizza.

They're going to send that right on over.

Not bad, but that's a pretty long trip for some pizza, right?

I'm not sure that's going to hold up.

Fresh pizza's very important, right?

So maybe that's not the freshest of pizzas.

Let's throw a cache on it, right?

Cool, we will throw a cache on it.

So cool.

The chef can still make their pizza in New York, and now they can just send it on over

to that cache and the pizza can hang out there, and then our Australia person can happily

eat all the pizza they would like.

But that pizza maybe, it's a little old.

I don't know.

What if they wanted an extra topping on something?

They would have to go all the way back, and that's really not efficient.

So, when we talk about the client and server, and we've heard other people talk about this

at this conference already, is that we are seeing frameworks realise they have to negotiate

this boundary better.

But that's really only just starting, and we are still genuinely talking about these

trade-offs between the client and the server, and they're tricky trade-offs.

Now, it wouldn't be an Ashley Williams talk if, when I said "trade doc" I didn't immediately

start talking about dialectics.

Who here knows what a dialectics is?

Dia what?

It is super foreign.

There's an idea of formal logic where you say A equals A. This is a thing, and then

that thing is always equal to this thing.

We use this a lot in science.

We say when we reach a contradiction, maybe where A doesn't equal A, we are wrong, right?

A does not equal A. However, I think that this is completely backwards.

In fact, the dialectical method, in contrast of formal logic, challenges to contradictions.

Fundamentally, the idea of dialectics is that the motor of history is these oppositions,

and that resolving those oppositions and pushing them forward as the synthesis of the oppositions

is what makes things happen, and I get so excited about this because I am a giant philosophy

nerd, so this is the philosophy nerd version of the diagram but this one will go over a

little bit better.

Just wait for it.

This will explain everything.

There we go!

Dialectics, right?

I want to see here we've been kind of assuming this trade-off between client and server for

a very long time, and then maybe dichotomy is the problem.

All right, so, we've got this problem, stuff is slow, we've got the client, we've got the

server, they seem to be in opposition, we have no way to resolve them.

What is to be done?

As I told you, I work to of a big orange cloud, and this big orange cloud has a ton of baskets

all over the earth.

One day, they were like what should we do with all these bassets?

We've been storing static assets in them but maybe we could do something cooler.

This is a direct quote.

Just kidding, it's not a direct quote at all!

What this became was like we have the client and the server, let's kind of take those oppositions,

synthesise them, and create the Edge.

So let's take a look at what that looks like.

We are back to pizza, all.

I hope you're into it.

So with Edge-side rendering, we have the basket and the chef.

The chef lives in the basket.

In our previous examples, no-one could cook in the basket.

But with Edge-side rendering, you can cook in the basket!

And so, now the chef doesn't have to move into your house and make pizza, they can hang

out in the basket that's near your house, make you pizza, and then deliver it to you.