Black holes will be all that remains before the universe enters heat death.

Finally — the end of JavaScript!

William J Edney
Sep 7 · 5 min read

It’s been almost 25 years since I wrote my first line of JavaScript. And in those 25 years, I’ve seen a variety of technologies that were supposed to kill JavaScript.

So why isn’t it dead yet?

Sit right back and you’re hear a tale, the tale of a fateful trip…

#1 — Java applets

“Let me tell you, just as soon as applets take off, that’s going to be the end of JavaScript…”

In the beginning was Java — and it was… well, not good. We’re talking Java applets to be precise. In fact, JavaScript was originally called LiveScript all those years ago because it was intended to “script up” those applets in your web page into full blown apps. I’ve always thought that LiveScript was a cooler name, anyway. I once asked Brendan Eich over dinner “Why the name JavaScript?” and he muttered something about “marketers” :-D.

(And that renaming birthed one of the greatest points of confusion in tech recruiting history. If I had a nickel every time I tried to explain to a recruiter that “no, JavaScript isn’t Java — they’re wildly different technologies…”)

Yes, Java was “the way, the truth and the light” for a number of years, but the light turned to darkness and the truth became not-so-much and Java’s “way” became servers, not clients.

A valiant attempt, but as a boisterous Texan once told me: “that dog don’t hunt”.

#2 — Java… again… once more… with feeling!

“Let me tell you, just as soon as we have Java-based browsers, that’s going to be the end of JavaScript…”

Whole browsers built out of Java! That was the promise.

At the point that applets started to fail, the Java crowd started to wind up the “ok, we’ll just build whole applications out of Java!” narrative. For a while Netscape even had a project, “JavaGator”, that was an attempt to build a complete web browser in Java.

Java-based browsers defined the term “failure to launch” and didn’t even achieve the same level of resounding success that Java applets did.

#3 — Flash… in the pan

“Let me tell you, just as soon as we have a million Flash runtimes deployed, that’s going to be the end of JavaScript…”

Around 2002-ish, Flash was ascendant. Adobe had bought Macromedia for some wild amount of $$$ and was going to spread Flash far and wide. In fact, Flash actually contained a brain-damaged version of JavaScript (ActionScript 2, soon to be supplanted by the much more capable ActionScript 3 — although eval() was still badly broken).

I have to say, Flash had Flash Studio going for it which was a nice tool and was ahead of its time.

But Flash was proprietary, slow, very buggy, a memory hog, a binary format and a never ending source of security problems. Adobe even tried to kill SVG on the desktop — a format they had a hand in inventing — because they saw it as an open standard Flash competitor. Oh, and Flash required a plugin. Oh, and it was meant to really do fancy graphics, not to build apps (how do you build apps using the abstraction of ‘timelines’ anyway? People tried…)

Thank you Steve (RIP) for putting a stake through the heart of this one.

And so Flash went… right down the pan.

#4 — Have you seen the light? The Silverlight?

“Let me tell you, just as soon as we get Silverlight into every browser, that’s going to be the end of JavaScript…”

Not to be outdone by Adobe, Microsoft (at that time, playing the role of Galactic Empire with Steve “no one’s gonna buy an iPhone!” Ballmer as Palpatine) decided to make a run at their own version of the “use our proprietary plugin/runtime” game.

The promise Microsoft made was “we won’t make you choose a language — as long as it’s made by us”. So, yes, any of the .NET languages could theoretically compile down and be used by the Silverlight runtime. As long as you were a C# or VB.NET fan, or for a while an IronRuby or IronPython fan, you could theoretically deploy your app to a web browser without having to deal with that nasty JavaScript!

Except it was still a plugin… and proprietary… and a binary format… and a memory hog. It was, admittedly, more secure and less buggy than Flash.

To their credit, Microsoft killed this one themselves.

As soon as they “saw the [not Silver] light” (about the same time that Palpatine was unceremoniously ejected for failing to predict that actually hundreds of millions of people wanted to buy iPhones), organizational moves were made to deprecate Silverlight and focus on the Web.

One result of this change was, ironically, was to finally give IE a real JavaScript engine with a garbage collector that wasn’t written by a summer intern — I’m looking at you JScript engine, my old nemesis.

Goodbye Silverlight — we hardly knew ye.

#5 — (Web)Assemble the forces!

“Let me tell you, just as soon as WebAssembly takes off, that’s going to be the end of JavaScript…”

Since proprietary efforts weren’t doing the job of killing off JavaScript, the anti-JavaScript forces tried a different strategy — take an evolving Web standard, hijack it, and start positioning it as a JavaScript killer.

The authors of the WebAssembly specification never said this was a goal. In fact, the origins of WebAssembly are rooted in making JavaScript faster.

This effort to position WebAssembly as a JavaScript killer was a variation on the Silverlight theme of “once we have a common multi-language runtime, we can get rid of that nasty JavaScript!”.

WebAssembly never really got off the ground.

WebAssembly, despite its name, was not intended to be a “common assembly language for the Web”, but a way to write performant compute-intensive web applications, such as games.

As it turned out, initial versions of WebAssembly didn’t do well with garbage collected languages. And the performance still isn’t what was originally promised by having a binary-ish format (which, to be honest, surprises me).

In any case, sorry anti-JS crowd, that “nasty JavaScript” is still with us.

Nice try, though.

So why isn’t JavaScript dead yet?

It has shocked me how many body blows this language has taken over the years and still it stands, like a bruised boxer in the ring.

But as my friend and business partner Scott Shattuck says, one reason is “Location, location, location”.

JavaScript’s position as the only language built into the web browser ensures it’s longevity. With billions of web pages depending on it, JavaScript will likely outlive everyone reading this article.

Also, JavaScript is surprisingly powerful. It has its Good Parts.

Ironically, its usage outside of the web browser is only increasing.

In addition, for those who can’t deal with the regular JS syntax, there are plenty of languages that will compile down to JavaScript. As Douglas Crockford told me over barbecue back in 2010, “I’m amazed at how many languages are starting to use JavaScript as a compilation target.”

But you said it will die.

Yes, everything does, sooner or later. I started this article saying that the end is coming for JavaScript and it is.

So, when will JavaScript finally die?

About 10 minutes after COBOL does.

Bill Edney has been writing JavaScript since June of 1997 when Nav 4 ruled the world (and crashed a lot). His latest project is here.

CodeRats LLC

CodeRats LLC

From graphical DBA and data flow tools like DBCommander™, Dataspace™, and LiquidData™ to our low-code TIBET™ web platform, our focus is bringing great tools to life. Check out Sherpa: The Cloud Programmer’s Workbench at

William J Edney

Written by

CodeRats LLC

From graphical DBA and data flow tools like DBCommander™, Dataspace™, and LiquidData™ to our low-code TIBET™ web platform, our focus is bringing great tools to life. Check out Sherpa: The Cloud Programmer’s Workbench at