HomeVideos

The End of JS

Now Playing

The End of JS

Transcript

256 segments

0:00

One of my favorite conference talks of

0:02

all time is the birth and death of

0:04

JavaScript. Now, you're probably

0:05

thinking, "Okay, the death of

0:07

JavaScript, you you have my attention.

0:09

What are we talking about here?" Well,

0:10

before you get too excited, it's

0:12

actually a talk from 2014 by Gary

0:14

Burnernhard while he was at Destroy All

0:17

Software. By the way, great name. In

0:19

today's day and age, I mean, I guess in

0:21

some sense, we've really lived up to

0:23

that name of destroying all software by

0:27

producing unceasing amounts of it. What

0:29

makes this talk so good is that he

0:31

attempts to predict the future 20 years

0:34

in advance. A lot of it was a lot of

0:35

good jokes. It's one of the best

0:37

conference talks ever created, but it

0:39

also has some pretty interesting ideas

0:41

in it. And one of the best parts is our

0:44

year right now 2026 is actually one of

0:47

the pivotal moments inside the

0:49

prediction. The beginning of the

0:50

conference talks does go through some of

0:52

the old lore of JavaScript, the 10day

0:54

creation that Brendan Ike was able to

0:57

somehow birth this language into the

0:59

world, the pain of actually using it,

1:01

you know, some of the classic fun ones.

1:02

So his entire prediction actually relies

1:04

on a technology called Azam.js. Now this

1:08

may be a technology before your time,

1:10

maybe you were before its time, but

1:12

effectively it is supposed to be the

1:14

assembly for the web. Now this should

1:17

sound familiar because this is actually

1:18

what Wom is based off of. Effectively

1:21

Azom is just JavaScript except for every

1:23

single kind of operation you need to

1:26

enforce its type. So right here you can

1:28

see that square this function square

1:30

takes in X. X equals the plus sign then

1:34

X. That is a prefix operator that

1:36

converts whatever X is into a number.

1:39

And then you return X * X and then you

1:41

reconvert that into a number. diagonal.

1:43

Same thing. X equals number of X. Y

1:46

equals number of Y. We're going to

1:48

square X, square Y, which again renumbs

1:50

X and renumbers Y. And then we're going

1:52

to squirt it out with a number at the

1:55

end. That's right. Squirt it out, baby.

1:57

You're probably thinking, okay, why

1:58

would we do this? This looks horribly

1:59

inefficient. Well, the idea is that the

2:02

JIT should be able to read all this

2:04

stuff in and go, okay, we are doing a

2:06

number operation. So square can simply

2:08

become a mole operation, right? That

2:10

means it can just just be a single

2:12

instruction like mole register whatever

2:15

it and itself and boom you got a number

2:17

back out or at least that's the idea.

2:19

Now I do actually remember this time I

2:21

was in the valley during this kind of

2:23

big era of AOM and I actually

2:25

specifically remember Epic Games and

2:29

Unreal Tournament. This is the Unreal

2:31

Engine 3 game engine which was used for

2:33

high-end games in the early to mid

2:35

teens. And this is a a short screencast

2:38

of it running inside of Firefox. Uh the

2:41

last demo, the Python demo is running

2:43

inside of Chrome, which does not support

2:44

AOM natively. That was actually running

2:46

as pure Java uh JavaScript. And uh here

2:49

you see a a video game engine running at

2:53

a perfectly playable frame rate. Not 60

2:55

frames per second, but playable. First

2:56

off, a couple things. Perfectly

2:58

playable, not 60. I mean, even 60 frames

3:00

per second. Like, are we even are we

3:02

even doing that these days?

3:04

Ridiculous. Can you believe what people

3:06

put up with in like 2013? This is what

3:10

big tech did to tech. Okay, this is what

3:12

they did. They took something that could

3:15

run better and then made it objectively

3:18

worse and been like, dude, this this is

3:20

the future. This is what you get to look

3:22

forward to. But it was exciting.

3:24

Honestly, it was exciting because this

3:26

meant there is a possibility of us not

3:29

having to write JavaScript. You could

3:32

write any language you want and you

3:34

could compile it down and actually

3:36

target it and run it in the browser. Now

3:38

granted, what came out of these things

3:41

were literally three megabyte bundles.

3:43

And you know, 15 years ago, the internet

3:46

was certainly not that great to be able

3:48

to have every single website delivering

3:50

you many, many megabytes of just

3:52

JavaScript. Let alone were the computers

3:54

able to run that. The, you know, the VMs

3:56

inside of V8 were not that good as they

3:58

are today. There were a lot of problems

4:00

but nonetheless it worked. It made

4:02

people very very excited. So this is

4:04

kind of like the crux of Gary's talk

4:07

which is okay there's this technology

4:09

which you don't have to write JavaScript

4:11

anymore but it's powered by JavaScript.

4:13

JavaScript will kill JavaScript via AOM.

4:17

Obvious side note there was no such

4:19

thing as WOM at this point. So he he

4:21

based it purely off of AOM. And just

4:23

kind of prove the point Gary does flex

4:25

on us a little bit. So here's uh the

4:27

running inside Chrome with Chrome

4:28

inside Firefox.

4:33

It's just compilers. Once you have a

4:35

compiler, all you need is the the the

4:38

libraries being used. Uh so here what we

4:40

have is the running against Wine

4:42

running against an X Windows shim all

4:44

compiled from C into AOM. That AOM is

4:47

running on Chrome. And now we have

4:50

another wine-like problem, which is that

4:52

was the Mac version of Chrome running

4:54

inside the Mac version of Firefox, but

4:56

the Mac windowing stuff is all closed

4:58

source. So we had to do what we did in

4:59

the '90s and reimplement it. And because

5:02

we like confusing names, the open-

5:03

source reimplementation of Coco is

5:06

called Cacao.

5:09

And then uh Cacao and Chrome are both

5:12

compiled from C into Azim. And all of

5:14

that is running inside of Firefox. now.

5:18

And so really he just proved you can run

5:20

anything. If it compiles in C, baby, you

5:23

can run it in the browser. And this is

5:25

kind of his fundamental idea that he has

5:28

for our future, which is that everything

5:31

can just simply be compiled into this

5:33

Azim and it can just run in the browser.

5:36

But he actually ends up making a

5:37

significantly bigger prediction cuz this

5:39

in itself shouldn't really kill

5:41

JavaScript. So this is where it actually

5:42

gets interesting cuz this is where he

5:44

makes his first big prediction that is

5:46

during our time period which is the

5:49

first major adoption of AOM.

5:52

>> So uh that takes us to 2025 when you

5:54

start to see thick extremely large

5:56

applications ported uh into AOM.

5:59

>> Now now is this prediction correct?

6:01

Well, I think one thing that probably

6:03

threw off Gary's old prediction was AI,

6:05

right? Because during 2020 to 2025 in

6:09

his chart, uh, there was just a massive

6:11

war. You know, kind of funny. We had CO

6:13

during that time. He predicted massive

6:14

war. He was just wrong. You know,

6:15

pandemic, not war. But either way, his

6:18

prediction did not include this idea of

6:20

AI and generating code. And so, he

6:22

thought that people would just get so

6:24

frustrated with JavaScript that

6:26

everybody would just want to use AOM.

6:28

And he's not completely wrong because

6:29

the successor to Azom Wom is now in 3.0

6:33

stage which does happen to have garbage

6:36

collection, better exception handling,

6:38

JavaScript string built-ins, custom text

6:40

format annotation, deterministic

6:41

profiling, like a bunch of stuff that is

6:44

actually making it pretty good to use.

6:45

Now, my last time I used WOM, I I could

6:48

easily say I did not like it that much,

6:50

but now, okay, this is looking a bit

6:54

more interesting. Is there a world in

6:56

which you could you could use WOM? Well,

6:58

it actually turns out that Wom is

7:00

actually making inroads into the old web

7:03

development. Cloudflare workers can use

7:05

Wom and that means you could develop

7:07

workers using Rust or C++ or Go or

7:11

Python. Not really sure about that last

7:13

one, but you could you could use any of

7:14

them because they all can compile down

7:17

to Wom. So, it's actually kind of

7:19

happening. There is this small world

7:21

where WOM has seen a small uptick in

7:24

adoption. There's been a couple notable

7:26

apps that have used WOM. Figma being one

7:28

of them. So though this prediction is

7:31

really I mean ultimately I think we can

7:32

all agree is wrong. It it's not like

7:35

crazy far off. But it's his next

7:37

prediction that it feels unbelievable.

7:40

So his final stage prediction is

7:42

actually called metal where instead of

7:44

having like your operating system and

7:46

these calls between ring zero and ring 3

7:48

and having to have a bunch of overhead

7:50

from having indirection of memory

7:52

instead you just put a JavaScript VM in

7:56

the kernel and everything just has VM

7:58

isolation and everything runs AOM. Every

8:01

program you compile it's AOM. Every

8:04

dream you ever had, Azam. That girl you

8:06

were talking to earlier, that's Azam.

8:09

Now, he does claim that it it's hard to

8:11

sell this idea in 2014. While probably

8:13

still kind of hard to sell this idea in

8:16

2026, but hey, there's hosting companies

8:19

out there that are fully bought into

8:20

this. It does seem like WOM is making

8:23

some forward step. Maybe Gary isn't that

8:27

wrong. Maybe, I know this sounds crazy,

8:30

maybe he could actually be right. And if

8:33

this doesn't happen, I'm just going to

8:35

have to blame AI. You know what I mean?

8:37

Like they they ruined it. We could have

8:39

had we could have had JavaScript in the

8:41

kernel if it wasn't for AI. Thanks AI

8:44

for ruining everybody's ability to

8:46

innovate. Anyways, I I wanted to go over

8:48

this talk because this is this was one

8:50

of the most legendary talks of all time.

8:53

I highly recommend going and watching

8:55

it. I'll link it in the description.

8:57

Hey, the name is Let me show you my ASOM

9:00

face, baby. A jen. I forgot the Ajet at

9:04

the end, so it kind of kind of ruins it.

9:06

That That might have just simply been

9:07

harassment again. Hey, do you want to

9:10

learn how to code? Do you want to become

9:12

a better back-end engineer? Well, you

9:14

got to check out boot.dev. Now, I

9:15

personally have made a couple courses

9:17

from them. I have live walkthroughs free

9:19

available on YouTube of the whole

9:21

course. Everything on boot.dev you can

9:23

go through for free. But if you want the

9:25

gamified experience, the tracking of

9:27

your learning and all that, then you got

9:28

to pay up the money. But hey, go check

9:30

them out. It's awesome. Many content

9:32

creators you know and you like make

9:34

courses there. boot.dev/prime for 25%

9:37

off.

Interactive Summary

The video discusses Gary Bernhard's 2014 conference talk, "The Birth and Death of JavaScript," which attempted to predict the future of web development 20 years in advance. Bernhard's core prediction revolved around Azam.js (a precursor to WebAssembly or Wasm) enabling any language to compile and run in the browser, thereby diminishing the direct use of JavaScript. The speaker reviews these predictions, noting that while the first major adoption prediction for 2025 wasn't entirely accurate, partly due to the rise of AI, Wasm is indeed gaining traction in areas like Cloudflare workers and applications like Figma. The talk also touches on Bernhard's more radical "metal" prediction of a JavaScript VM in the OS kernel. The speaker concludes that despite its bold nature, Bernhard's vision might not be entirely wrong, humorously blaming AI if it doesn't fully materialize.

Suggested questions

9 ready-made prompts