Stuart Thomson

Stuart Thomson

The principal engineer of my team and I had a discussion, and the conversation ended up on the topic of Javascript being a bad language. Ultimately, I think it has some deep flaws that every frontend developer just learns to work around to the point that those workarounds are now second nature.

He then asked me a question: “Do you think anything will replace Javascript?”


Gary Bernhard’s talk The Birth and Death of Javascript (30 minutes, presented in 2014) is a wonderful work of fiction adjacent to this topic. I have not been able to forget this talk since first watching it. It’s well worth watching, and this post is not going to run away while you watch it.

Present day

We currently have languages that augment the Javascript environment, but require compilation. Typescript and JSX are popular examples of this today, but we’ve also seen languages like Dart, Elm, Reason, and Coffeescript. Each of these are carving out their niche of the ecosystem, but can’t escape from the reality that they’re all Javascript under-the-hood.


Typescript is a flavour of Javascript that adds type annotations and a compiler that spits errors out when types don’t match. According to the 2021 State of JS survey, static typing is one of the biggest pain points for Javascript developers. Typescript seems to be filling that gap, with a nice 69% of respondents saying they use Typescript.

The most obvious way to replace Javascript would be to make a new language mostly compatible with it, but fixes all its flaws. Typescript does not do that. While it does address one complaint (and rather well in my opinion), it does not intend to change core features of the language. The quirks of the prototype still exist, there are still two values that mean “nothing”, primitives can be coerced at runtime leading to two equality operators (and only one of them being what you want).

Besides, the Typescript project has expressed that they do no intend to replace Javascript. Typescript has been in a position, much like Babel, where proposed features could be implemented in Typescript to test the waters before they are fully standardised in Javascript. If Typescript had to go through the same committee processes that Javascript does, then it would lose that ability to move faster. This has been advantageous for the project, as developers were able to write modern Javascript (with types!) well before it was supported in any browsers.

Type annotations proposal

A more recent development is the Typescript team putting in a proposal to add a type syntax to Javascript, almost a direct copy of the style Typescript uses. These type annotations wouldn’t cause errors at runtime, meaning you could pass invalid types to functions that are annotated. They’re effectively treated as comments, allowing editors to provide hints and squiggly lines without adding a runtime overhead to browsers.

function getWords(str: string): string[] {
return str.split(/\s+/);
// Invalid Typescript, but valid Javascript in the proposal (since types are ignored at runtime)

Currently all Javascript is valid Typescript, but this proposal leads towards a future where (almost) all Typescript is valid Javascript. What’s particularly interesting is how this proposal doesn’t remove the need for Typescript in the first place: the type annotations are completely ignored by the JS engine. If you want to take advantage of the annotations then you will still need a type checker, such as the Typescript compiler.

With this, the role of the Typescript compiler would likely change. Currently the Typescript project is able to provide editor actions and hints through the language server, as well as transforming Typescript code into various versions of Javascript. If this proposal were to be accepted and made part of the Javascript language then Typescript would continue to be both, since constructs like enums and visibility modifiers would not be included and must be compiled out. However I think that Typescript will be added to new projects just for linting, rather than for its compilation. This change in how it gets used would also change the priorities of the project.

As an aside, I’m interested to see what this would do to Facebook’s Flow, and whether adopting Typescript’s syntax will change the goals of the project. Would we see alternative type checkers, would Typescript completely take over, or will Flow fall to the wayside completely?


Dart is a language developed by Google for cross platform mobile development. Unlike Typescript, it is actually intended to replace Javascript… kind of. Initially, the Chrome team wanted to include a separate Dart VM in Chrome, but this was heavily criticised due to the effect of fragmenting the web. This was scrapped in 2015, with the Dart project opting to compile code to Javascript instead.

ECMA International, who are also in charge of Javascript, have formed TC52 to standardise Dart. The TC has not published any documents since 2015, though development on Dart has been actively continued by Google with the most recent release (as of writing) in 2021. Now that Dart isn’t meaning to replace Javascript in the browser, I suspect this committee is no longer active.


Today we also have web assembly (WASM), which — as a compilation target of a few compilers — allows completely unrelated languages to be compiled to a format that can be run in web browsers. This is often used for high performance code, such as processing images in a Web Worker thread or using cryptographic functions in-browser.

If WASM were to get access to the DOM, then maybe we’d see a slow change towards WASM for full-scale applications. It would have to come with better tooling for web projects in other languages, followed by the creation of new libraries (since the web is a completely different platform to anything else). All the while, Google is pushing browsers to expose more native APIs to web apps. Already on mobile you can install web apps for an experience close to native apps, including their inclusion on the home screen and abuse of push notifications.

I don’t believe WASM will fully replace Javascript. A large scale adoption of WASM would lead to a reduction in Javascript usage, but the higher barrier to entry and tooling investment makes WASM less appealing as a tool for minor enhancements to the web. The project itself states it is not intended to replace Javascript, citing that Javascript will likely be glue holding an application together or a bridge between separate parts of an application.

The future

The title of this post doesn’t ask if anything is currently replacing Javascript, but whether anything could.

Javascript continues to evolve

Since the release of ES2015, Javascript has seen continual improvements through various proposals and committees. Already in this post I’ve mentioned the type annotations proposal, but there are other proposals active for common pain points. As of writing this post, the decorators proposal has reached stage 3 and has been implemented in Babel, with the Typescript project expressing interest in implementing this new version. The Temporal proposal, which will add proper date and time objects to the language, is also in stage 3 and is being implemented in Chrome (though likely behind a flag before it reaches stage 4).

This process will continue as long as Javascript is a popular language. The same has happened to Java, where steady releases have added new features to the language. If I had to guess what’s in store for the future of web development, this would be my bet. Javascript will continue to evolve and grow. Pain points will either be addressed with additions, or we’ll have stricter subsets of Javascript that people actually use for everyday development (such as everyone ignoring the existence of the == operator).

Crafting a theoretical Javascript killer

So what would it take to create a new language to fully replace Javascript?

  1. It would need to be adopted by the W3C

  2. It would need to be implemented in the major browsers

  3. It would need to be widely used by developers

  4. It would need to be able to do everything that Javascript can do

  5. All existing websites would need to continue to work (i.e. Javascript would still be around)

Even if you ignored point 5, you would be left with a major hurdle: the fragmentation of the web. This is the issue that Google came up against when they announced their intention to include a Dart VM in Chrome. The only players large enough to propose and implement a new language for the web are the same ones that will be hit with criticism and antitrust claims, which makes it both a waste of time and money.

The nuclear option

There is one way to ensure that Javascript is replaced: replace the whole web in its entirety (we’re definitely too late to do this). Replacing Javascript would involve the DOM, its APIs, its libraries. It would mean replacing all websites, related services, companies, industries. It would mean replacing all of its users.

This may be a goal of larger tech companies, such as Facebook’s split into Meta. While VR already has spaces to meet and play, like VRChat or standalone video games, Meta’s focus is on convincing businesses that it’s a good idea to do your work in digital spaces. These spaces, of course, would be the property of Meta — subject to rent licensing and require the purchase of special hardware, made available on the cheap through Meta themselves. Through this, Meta would have created an entirely new platform: one without Javascript (well, it’ll probably have a web browser). Here, there is opportunity for a fresh start, as the client side of VR applications would be built with game engines instead of web tech. Without a web application to share code between, it’s unlikely new projects in this space would use Javascript for their backends. A brand new world, untainted by Javascript. This world, however, should be avoided. Let’s keep science fiction fictional.

There are attempts at replacing web technologies at a smaller scale, founded on similar political ideals to the web. The Gemini project replaces HTTP and HTML with a format much closer to Markdown and plain text than anything more structured, removing scripting (and even images) in favour of an early-tech aesthetic built upon modern knowledge and technology. Protocols such as XMPP and Matrix have been trying to do what the web did but with messaging.

To take the heading of this section more literally, Gary Bernhard’s speculative talk about a world after nuclear war, The Birth and Death of Javascript, paints a picture of a world where the common compilation target of WASM (asm.js in the talk, as hadn’t been announced at the time) is how all code is run, with no need for operating system kernels or hardware isolation. In this alternate reality, Javascript is dead because nobody in their right mind would choose this language when we have the option to start over. It would take a momentum-stopping event in order for Javascript to be replaced.

What’s next?

Not much. Javascript can evolve, but can’t re-invent itself. New languages may come, but they’ll either be left behind or have their core features stolen and included in Javascript directly. We could throw the entire ecosystem away, but why bother when what we have is good enough.

Will anything end up replacing Javascript? Not in the near future. I’d guess we’ve got it for another decade at least. I’m interested in what my thoughts would be then, but there’s no way to predict what happens in this industry.