Is JavaScript eating the world or is it dying?

JavaScript (JS) was invented back in 1995 to add interactions to the web. Famously known as a language designed in only two weeks, it started as a “toy-ish” script language, but has quickly developed into the most popular language on the earth we know today (according to RedMonk language ranking 2020).

Why is JS so popular? Simply the fact that JS is the only non-markup language browsers speak would be an answer. As a website developer, if you want to do computation on the client side (browser), you use JS, period.

But that’s not the whole story.

In the past decade or so, more and more websites are relying heavily on JS because of the popularity of Ajax and SPA. Forget about the idea of “progressive enhancement” and “graceful degeneration”, browser is not limited to rendering HTTP documents now, but has become a comprehensive application platform. Users are almost forced to adopt newest version of their web browser to access web applications with rich features implemented in JS.

The increasing popularity of cloud computation has also helped. For example, Netlify is one of the leading advocates for the serverless website architecture (for a good commercial reason). They have been spreading the idea of JAM stack (as a comparison to the traditional LAMP stack), where ‘J’ represents JS… You may have noticed that there’s no server side technology in JAM, only ‘A’ for APIs provided by cloud service provider.

Even if you do need to write your own backend code, there is NodeJS and Deno…

In fact, JS has been so dominant on web that it’s taking over other platforms, where native applications used to be mainstream: Electrons on PC/Mac/Linux and React Native on iOS/Android has become the first choice for many developers pursuing cross-platform nowadays.

So it’s safe to claim that JS is devouring a large portion of the programming world.

But not everyone is happy about it. Even its father, Brendan Eich, joked that a lot of his job today is to make up for some mistakes he made in designing JS. There are tons of complaints about the language you can find online: over aggressive type coercion, weird behaviour on numeric calculation, highly dependent on global variables, lack of proper scoping, callback hell… (To be fair, some of these issues have been resolved in more recent versions of the language.) The list goes on and on to the point that one of the most famous JS book is called “JavaScript: The Good Parts”. In the book’s description, it fairly states that “Most programming languages contain good and bad parts, but JavaScript has more than its share of the bad, having been developed and released in a hurry before it could be refined.”

In short, many developers, especially large teams where code maintainability is a big focus, are not totally satisfied with their experience using JS. Microsoft has come up with TypeScript back in 2012. As the name implies, it’s supposed to be a typed JS. Adding type check to JS is surely sweet but it does not solve every problem in the language.

What is the root issue? It’s the aforementioned fact that JS is the only language browsers speak. Developers cannot pick their favourite language or language that best fits the task when front-end coding is involved. Monopoly often is bad, especially in the world of technology.

The game changer was born in 2015, when WebAssembly (WASM) was announced. WASM is a new portable binary-code format that can be run on modern browsers. Just like assembly is a low level language that other high level languages can compile to, we can compile high level languages to WASM, which can be run on browser.

The work process is like this:

1. Developers write code in languages they favor.
2. The language is passed to WASM engine, which does AoT compilation and optimization. Now your language is complied to WASM.
3. The engine runs WASM natively just like it runs JS.

For demonstration purpose, here is how you would write a C program, compile it to WASM, and run it on browser:

1. In awesome.c, write:

   int add (int first, int second)
   {
     return first + second;
   }
   

2. Compile the program to .asm file (note the –target=wasm32 flag):

   clang --target=wasm32 --no-standard-libraries -Wl,--export-all -Wl,--no-entry -o add.wasm awesome.c
   

3. In the html, call our awesome code:

   <html>
     <head></head>
     <body>
       <script type="module">
         (async() => {
           const response = await fetch('add.wasm');
           const bytes = await response.arrayBuffer();
           const { instance } = await WebAssembly.instantiate(bytes);
           console.log('The answer is: ' + instance.exports.add(1, 2));
         })();
       </script>
     </body>
   </html>
   

You may wonder if browsers can really run WASM painlessly like they do with JS. The answer is yes. All mainstream browsers now support WASM. In December 2019, W3C has accepted WASM as the fourth native language of browser, after HTML, CSS, and, of course, JS.

Why might WASM be a threat to JS, despite of the WASM community’s claim that it is just to complement JS, not to replace it?

WASM is neutral. It has no bias on how web application should be built. Every team can pick their favorite language and framework, as long as there is a WASM complier that supports it.

WASM is fast. It’s way faster than JS. With WASM, the web can achieve things JS cannot do: high performance gaming, video editing, VR… all on browser!

Note that WASM still needs a JS glue to be added to web page now (see the script tag in the above code), and there is no straightforward way for WASM to interact with the DOM (yet). So JS is not going anywhere soon. However, let’s not forget that the JS’s privilege has been diminished largely, and there is nothing stopping developers to move away from JS, as long as the web frameworks of other high level languages do the heavy lifting for them.

In summary, is JS eating the world today? Yes.

Is JS dying tomorrow? No.

But, is JS dying the day after tomorrow?