The End of JS

One of my favorite conference talks of

all time is the birth and death of

JavaScript. Now, you're probably

thinking, "Okay, the death of

JavaScript, you you have my attention.

What are we talking about here?" Well,

before you get too excited, it's

actually a talk from 2014 by Gary

Burnernhard while he was at Destroy All

Software. By the way, great name. In

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

some sense, we've really lived up to

that name of destroying all software by

producing unceasing amounts of it. What

makes this talk so good is that he

attempts to predict the future 20 years

in advance. A lot of it was a lot of

good jokes. It's one of the best

conference talks ever created, but it

also has some pretty interesting ideas

in it. And one of the best parts is our

year right now 2026 is actually one of

the pivotal moments inside the

prediction. The beginning of the

conference talks does go through some of

the old lore of JavaScript, the 10day

creation that Brendan Ike was able to

somehow birth this language into the

world, the pain of actually using it,

you know, some of the classic fun ones.

So his entire prediction actually relies

on a technology called Azam.js. Now this

may be a technology before your time,

maybe you were before its time, but

effectively it is supposed to be the

assembly for the web. Now this should

sound familiar because this is actually

what Wom is based off of. Effectively

Azom is just JavaScript except for every

single kind of operation you need to

enforce its type. So right here you can

see that square this function square

takes in X. X equals the plus sign then

X. That is a prefix operator that

converts whatever X is into a number.

And then you return X * X and then you

reconvert that into a number. diagonal.

Same thing. X equals number of X. Y

equals number of Y. We're going to

square X, square Y, which again renumbs

X and renumbers Y. And then we're going

to squirt it out with a number at the

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

You're probably thinking, okay, why

would we do this? This looks horribly

inefficient. Well, the idea is that the

JIT should be able to read all this

stuff in and go, okay, we are doing a

number operation. So square can simply

become a mole operation, right? That

means it can just just be a single

instruction like mole register whatever

it and itself and boom you got a number

back out or at least that's the idea.

Now I do actually remember this time I

was in the valley during this kind of

big era of AOM and I actually

specifically remember Epic Games and

Unreal Tournament. This is the Unreal

Engine 3 game engine which was used for

high-end games in the early to mid

teens. And this is a a short screencast

of it running inside of Firefox. Uh the

last demo, the Python demo is running

inside of Chrome, which does not support

AOM natively. That was actually running

as pure Java uh JavaScript. And uh here

you see a a video game engine running at

a perfectly playable frame rate. Not 60

frames per second, but playable. First

off, a couple things. Perfectly

playable, not 60. I mean, even 60 frames

per second. Like, are we even are we

even doing that these days?

Ridiculous. Can you believe what people

put up with in like 2013? This is what

big tech did to tech. Okay, this is what

they did. They took something that could

run better and then made it objectively

worse and been like, dude, this this is

the future. This is what you get to look

forward to. But it was exciting.

Honestly, it was exciting because this

meant there is a possibility of us not

having to write JavaScript. You could

write any language you want and you

could compile it down and actually

target it and run it in the browser. Now

granted, what came out of these things

were literally three megabyte bundles.

And you know, 15 years ago, the internet

was certainly not that great to be able

to have every single website delivering

you many, many megabytes of just

JavaScript. Let alone were the computers

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

inside of V8 were not that good as they

are today. There were a lot of problems

but nonetheless it worked. It made

people very very excited. So this is

kind of like the crux of Gary's talk

which is okay there's this technology

which you don't have to write JavaScript

anymore but it's powered by JavaScript.

JavaScript will kill JavaScript via AOM.

Obvious side note there was no such

thing as WOM at this point. So he he

based it purely off of AOM. And just

kind of prove the point Gary does flex

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

running inside Chrome with Chrome

inside Firefox.

It's just compilers. Once you have a

compiler, all you need is the the the

libraries being used. Uh so here what we

have is the running against Wine

running against an X Windows shim all

compiled from C into AOM. That AOM is

running on Chrome. And now we have

another wine-like problem, which is that

was the Mac version of Chrome running

inside the Mac version of Firefox, but

the Mac windowing stuff is all closed

source. So we had to do what we did in

the '90s and reimplement it. And because

we like confusing names, the open-

source reimplementation of Coco is

called Cacao.

And then uh Cacao and Chrome are both

compiled from C into Azim. And all of

that is running inside of Firefox. now.

And so really he just proved you can run

anything. If it compiles in C, baby, you

can run it in the browser. And this is

kind of his fundamental idea that he has

for our future, which is that everything

can just simply be compiled into this

Azim and it can just run in the browser.

But he actually ends up making a

significantly bigger prediction cuz this

in itself shouldn't really kill

JavaScript. So this is where it actually

gets interesting cuz this is where he

makes his first big prediction that is

during our time period which is the

first major adoption of AOM.

>> So uh that takes us to 2025 when you

start to see thick extremely large

applications ported uh into AOM.

>> Now now is this prediction correct?

Well, I think one thing that probably

threw off Gary's old prediction was AI,

right? Because during 2020 to 2025 in

his chart, uh, there was just a massive

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

during that time. He predicted massive

war. He was just wrong. You know,

pandemic, not war. But either way, his

prediction did not include this idea of

AI and generating code. And so, he

thought that people would just get so

frustrated with JavaScript that

everybody would just want to use AOM.

And he's not completely wrong because

the successor to Azom Wom is now in 3.0

stage which does happen to have garbage

collection, better exception handling,

JavaScript string built-ins, custom text

format annotation, deterministic

profiling, like a bunch of stuff that is

actually making it pretty good to use.

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

easily say I did not like it that much,

but now, okay, this is looking a bit

more interesting. Is there a world in

which you could you could use WOM? Well,

it actually turns out that Wom is

actually making inroads into the old web

development. Cloudflare workers can use

Wom and that means you could develop

workers using Rust or C++ or Go or

Python. Not really sure about that last

one, but you could you could use any of

them because they all can compile down

to Wom. So, it's actually kind of

happening. There is this small world

where WOM has seen a small uptick in

adoption. There's been a couple notable

apps that have used WOM. Figma being one

of them. So though this prediction is