JavaScript's Journey to the Edge by Ashley Williams | JSConf EU 2019

Subtitles section Play video

>> Hello, everyone, welcome to my awesome talk.
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.
That's pretty sweet.
But, this kind of looks a lot like server-side rendering, a little bit, right?
Like, it's just one.
But the real trick is, remember, we don't just have one basket, we have a lot of baskets.
So, at any point in time, these chefs can be making pizza and sending them to people
all over the world so everybody can have pizza that is nice and fresh without someone messing
up their kitchen.
That's what the Edge is.
You might be asking this is a talk about performance.
How fast are you?
Right?
So benchmarks are done and I'm going to show you some.
Your mileage may vary.
These were done yesterday in who knows what will happen tomorrow?
These are good representative benchmarks of what we have.
There is something called serverlessbenchmark.com, but these are competitive numbers.
I don't want to do a product talk where I compete against other products.
I want to skip over that one and do what I call big numbers are big, small numbers are
small, all numbers on small.
These are numbers for response times, in Cape Town, and, so worker are respond in about
143 milliseconds, and a GitHub pages is going to respond in 591.
In Doha, worker will respond in 44 milliseconds, in GitHub pages, 497 milliseconds.
What about Australia?
A worker, 208 milliseconds, GitHub pages 624.
Those are some big numbers.
Remember, these are people accessing the internet.
Maybe you'll call me a millennial, but if I don't have access to the internet, I actually
get nervous.
Emotional health.
Also, it's all of this information.
All of the ability to prosper currently on earth is largely driven by the internet, and
so this axis matters.
Could you imagine having to wait that much more time just to get, I don't know, you probably
read Reddit.
You would have to wait so long, it'll be terrible.
Reykjavik Iceland, 170 milliseconds.
Now you're probably asking me how do you do that?
That is very interesting, or hopefully you think it's interesting.
Let's talk a little bit about it.
We have all of these baskets, and it turns out that trying to cook pizza on these baskets
actually has a lot of fascinating constraints, and so the first thing we can think about
is scaleability.
So, for Cloudflare, scaleability, traffic, or requests, they're super easy, never gets
huge.
I think it can take over 30 terabytes of traffic over it.
It's a lot, and it's continuing to grow.
However, for this model to work, this idea of tenants, or how many apps we can put in
the basket is super hard.
Every app needs to be in some location, and some places are very small.
We are looking at a need for 100 times efficiency than what you usually see on a server-side
offering.
We came one a set of constraints.
The first was for the code footprint, the base amount of what the app needs to be, a
VM requires ten gigabytes, a container around 100 and then what we needed was less than
one.
Less than one.
That's a pretty big deal.
All right?
And then from memory usage, a VM is going to require at least one gig a container, again,
around the same that had for the footprint but we needed to do under five.
All right?
And this is fundamentally because the Edge is not a large place, or like here, the kids
call it, the Edge is not thick at all.
It's very small.
We have to get everyone's apps on here because we want everyone to be super fast, all right?
Additionally, because of the needs that we have, context-switching is very interesting
thing.
For a VM, very low context-switching is needed.
Maybe for a container, a little bit more.
We need context switching because the apps only run local to it.
We don't need to be running that app all the time.
We need to be able to switch back and forth between apps incredibly quickly, like to the
point where switching processes would be too much overhead.
That's a pretty big constraint, all right?
Start-up time is a fascinating constraint.
A VM is going to take around ten seconds, a container 500 milliseconds.
We need it to be less than someone will notice - around one 50th of the blink of an eye.
Why do we need that?
If people start using too many resources on our Edge, we need to be able to kick them
out quick.
But, if they get another request in, we need to be able to start them back up quickly again
in a way that the user never would notice, all right?
These are some pretty serious constraints, right?
But, there's other things that also have these same constraints.
For example, certain APIs, particularly APIs that speak to our APIs may need to run client
code directly on the server, because it needs to be more efficient.
Similar with big-data processing.
With big data, you can't bring the data to the app, you bring the app to the data.
It's similar constraints to what we have.
Also, web browsers also have the exact same constraints.
They need to be constantly running all of that code from all of those websites that
you go to that all of you are writing.
This is where I say web browsers are freaking awesome.
We have actually already solved this that is namespacing server-side need with a client-side
technology.
Like server technology is actually too slow, and building out server-side technology, have
we overlooked the fact that we have this beautiful technology that is our client for the web?
Browsers are optimised for exactly the types of things that we need in a type of serverless
properly.
They've got fast start-ups, someone is literally there waiting for it.
They're going to be moving quick.
Remember, we talked about computation in the browser and how optimising rates has been
getting, all right?
I don't know about you, but I usually have around 100 tabs open at once, and that's a
lot of processes.
You also have to remember that a single page is not always a single website.
There are plenty of iFrames.
That like button is its own context and the browser is orchestrating all of that.
Additionally, and I know people will fight me on this, browsers are optimised for secure
isolation.
When you go to a website, if it was able to leak all that stuff out to your other websites,
we would be in a big, big problem.
So, the architect of this run time said web browsers has been the most hostile security
environment for quite some time.
And I'm inclined to agree with him on this.
I think this makes sense.
So, with deciding what we were going to do for a serverless run time, we picked V8.
Come on!
We chose to run the serverless run time on V8 using this class of V8 isolate.
You could traditionally think of this more like a VM but the word "VM" has kind of changed
so this is more of a JVM which is not the same.
You can understand it as a light weight context sandbox, so why is this better an VMs or containers?
It is basically because you get to share more.
It's like a little bit more communist, right?
VMs, you get the hardware virtualised, and then you've not to bring everything else on
your own.
Containers, all right, you get the operating system, but again, bringing everything else
on your own.
With isolates, you get web platform APIs, the JS run time, and operating system, hardware,
and you just show up with your application and maybe a couple of weird libraries you
wrote, and that's freaking awesome, and, because we can share so much, we can very efficiently
use resources.
And so just to take a kind of look at what this is, in a virtual machine you can see
that the process overhead is one-to-one with the user code, whereas with the isolate model,
you can see that it is definitely many to one.
This is how we are getting those benchmarks that we are talking about.
So, in addition to using V8, we have built a coding environment for you that uses the
Fetch API and the service worker API.
You can build it out in a UI that looks a little bit like this.
You literally just have to have something for fetch events, and then you write a function
that can handle requests.
You can do plenty of other things but this is the bare minimum worker in what is looks
like.
Because we're using V8, we get ... for free.
If JavaScript is not your jam, feel free to use a target for WebAssembly and we can use
that.
You might be thinking this looks like a lot like an operating system, and, man, I would
like to talk about how that is true but I have literally no time left.
I would recommend that you check this out if you want to learn about how we've tried
to tame the um killer, that's really fun.
Before I finish up, I do want to say, is this a good idea?
Right, like, oh, cool, you can do it, but like should you?
So a lot people will be like, yes, there is a spectre haunting this architecture.
Right?
Wrong talk, sorry!
This one!
Spectre!
It's a fascinating memory bug.
I don't have time to go into explaining it.
What I will tell you is that we've made some mitigations to attempt to avoid it.
Spectre is a bug that goes all the way down to the depths of the stack, and many of us
are just trying to cope as you pop up it.
This is it what we've been doing so far.. primarily, we are letting you avoiding the
any sort of timer.
If you use date.now in a worker, it will tell you the same time every time.
We don't allow local concurrency because that's a timer in disguise.
But one of the things that we are also able to do is we have the freedom to reschedule.
We can take the look at someone who is kind of looking a little weird, a worker that is
behaving funny, and we can say, "Hey, let's kick you out, keep an eye on you, stick you
in your own little box."
Hopefully, I have encouraged you to think that is it a somewhat cool technology, and
that it's fast, and maybe you want to use it because you want to get fresh pizza to
everybody in the world.
But, let's talk about how you can actually use it, because, accessible isn't just about
receiving content, it's about building content that other people can receive.
I joined Cloudflare two months ago and it was like oh, shoot, we've got to make this
developer experience way better.
People do not like curl commands and API keys in them.
That's not cool, all right?
So, you may have seen me on a couch yesterday, but I've been working on this tool called
Wrangler.
It was originally released for building Rust WebAssembly workers in Cloudflare but now
a fully fledged CLI for loading any type of worker you like.
I found this picture of a crab with a cowboy hat on it.
You can npm install it, and it will just work for you.
It looks a little bit like this.
I couldn't speed this gif up.
Boom.
So, if you like emojis, there are a lot of them.
If your terminal doesn't support them, we have fallback.
We've set up a template gallery because maybe you don't note what you want to build with
something like this, so you can just generate one of these templates and get going with
it.
Each one will create a functional work I don't remember er for you, and so that is pretty
awesome.
So you can run this, command, and just publish, and it will be successfully published at this
fascinating URL.
How many people here signed up for workers.dev subdomain?
We've got three.
Here's the thing: remember that fucking DNS tweet?
I hate setting up DNS.
Maybe you too.
To get started playing with this kind of thing, you do not need to set up any sort of DNS.
We will give you a free subdomain on workers.dev you can get it by running the wranglers subdomain
command, snag that for you, and you can put the apps and workers you would like on it.
Finally, we've got cool new docs.
They are also written as a worker.
So, that is good.
And the big announcement here is you probably like why do I care about this?
This is a company, corporate product announcement, but today we are making it free.
[Cheering and applause].
I'm really excited because Cloudflare workers are actually the first free Edge serverless
platform.
You cannot put something on the Edge, be it our Edge or someone else's Edge without paying
money.
I'm excited to get people playing in this awesome spot because I think it will change
how we think about applications, particularly as a more distributed thing across the world,
and not having to think about server and client.
So we have a free tier, this is some stuff about it.
Again, go forth and build, but I have one final message for you, because I'm not done,
and I am almost certainly over time, but, it's an Ashley talk, so we are going to go
over.
I want us to do some thinking, like, it's cool, this Edge thing.
It's free, and I want you to go and use it and build awesome accessibility apps, but,
the real point of this talk is that I want people to think more radically, and, with
more people who don't look like us about how the internet works, and how it could work.
Right?
When we encounter trade-offs like the client and the server, I think a lot of people think
that's how it is.
That's what we've to do, right?
We have the client server, we can't change that.
What I want to encourage you to find oppositions like that and challenge them because those
oppositions are opportunities for making strides in accessibility for the web, like what we
are doing today.
And so, again, we've talked about journeys, we've talked about performance, we've talked
about accessibility, the web is the primary place that new developers go to learn, so
let's make sure we can get there fast.
The future with the .just community which is representative of the whole world literally
cannot come soon enough.
Thanks!
[Cheering and applause].