It depends. Are you concerned about getting jobs or not? That’s a genuine question. If you are interested in the technical and conceptual aspects of programming, or you have control over a development project, I would recommend learning another language instead of JavaScript.

As I’ve said before, JS can be written just about any way you want it, which was excellent for me and my early education in programming. But while it can be written in any way, it’s not particularly good in any way either. Sort of a jack of all trades, master of none situation.

As such, once you cut your teeth with JS, or perhaps another high-level dynamic language like Python, move onto more well-structured languages.

For example, if you like Object-Oriented programming, learn Dart or Smalltalk. If you like procedural programming, learning C, Rust, or Go. If you like functional programming, take your pick: Haskell, Erlang, Elixir, Clojure, PureScript, Elm, or ReasonML. Want a little of everything but still better structured? Check out Scala and Ocaml.

Currently, most of these languages have good support for transpiling over to JavaScript. A few, like Elm and PureScript, were created specifically for transpiling over to JS. Considering the forward advantages of WA, I would expect many of them to start supporting that in the future as well, meaning that these skills will have solid forward value.

JavaScript is important because of its scale and popularity, not because of its underlying concepts and philosophy. That’s why it is at risk of dying. If greater rigor is brought to the language in the future, it could solidify its position, but considering the reticence with which the working group has made changes in the past, this is not likely.

If you are interested primarily in getting work, JavaScript is still growing, meaning that job numbers are still growing. Absolutely, positively, without doubt, learn more JavaScript if you are interested in finding work. As the spec grows and gets ever more bloated, JS specialists will become ever more valuable. Even in a distant future, where JS usage is near zero, JS specialists will be worth a bundle, just as Fortran and COBOL consultants today earn a ton of money.

So much faster…as in, starting at almost 20% faster?

OMG, you won’t be able to believe this! If I use WebAssembly, I might be able to see a response in 8ms rather than 10ms!

And something important to note is that much of the time spent waiting for a web page has nothing to do with JavaScript speed. There's server latency, poor page design with respect to minimizing network requests, and DOM rendering time. JavaScript is rarely the bottleneck. So to update the above example, it might be that a page renders in 899ms instead of 900ms. At the cost of a lot of work porting the code to C++, which could be better spent actually optimizing the page where it will actually help.

There are some use cases where WebAssembly can be way faster. It will be useful for games, which are often already written in C++ anyway. But for the most part, WebAssembly just means “you can compile C++ for use in a web page.”

And do you know what? I’ve developed GUIs (Graphical User Interfaces, i.e., like what web pages are) in C++, and developing GUIs in C++ sucks. Not that HTML+CSS+JavaScript is perfect, but it’s a lot better. And a lot more flexible. And a lot easier to debug. And a lot more component-driven. And the ecosystem is literally the largest that has ever existed for any language in history.

Other people have mentioned that you can’t yet manipulate DOM from WebAssembly, but several stacks already exist that handle that bridge. And there are over a hundred languages that compile to JavaScript, so if JavaScript were such a terrible language, wouldn't we be seeing the rise of one with solid modern engineering principles? Oh yeah, we are: TypeScript.

And as I mentioned above, most web sites are slow not because of JavaScript. So even if you could manipulate the DOM from WebAssembly directly, and you ported the code to C++, you would be hard pressed to even notice the speed difference. Aside from DOM and network issues, probably the next most common problem is the algorithm being used. Making your code 10x faster by converting from JavaScript to C++ is good, but making it 100x faster just by changing the algorithm in JavaScript a bit is a lot less work for a much better result.

So the real reason why we’re still using JavaScript and compile-to-JavaScript languages like TypeScript? It’s easier, it’s more powerful, it’s fast enough, and the ecosystem is unparalleled. Except for games and specialized libraries, I don’t see WebAssembly making a dent in the foreseeable future.

“In the near future”? No. It’s not ready yet - it misses direct DOM access and garbage collector, tools are in their infancy etc.

Down the line? Largely yes.

While WebAssembly has real size and performance advantages, there is something even more important: it acts as a common instruction set architecture (ISA) for the Web. This means that compilers for other languages can target it, just as they now target various CPU ISAs (x86, ARM etc.). This will bring other languages and ecosystems to the Web, and naturally displace a lot of JavaScript simply because they may be better tools for the job at hand. Even languages that currently transpile to JavaScript (TypeScript, Flow etc.) will target WebAssembly for performance reasons.

WebAssembly will also act as an interoperability layer between all these languages (and JavaScript itself). You’ll be able to call a library written in one language from another, just as you can with .NET today (C#, VB, F# etc.) or JVM (Java, Kotlin, Scala etc.).

In the end, JavaScript will still be a language that you can use on the Web, but it will be one of many.

Two reasons:

First, WebAssembly will not be the Great White Savior (or any other suitably-dated colonial metaphor) or the One True Platform. Nothing ever has been, nothing ever will be. Ada, D, C++, and many other contenders later, and we still have C.

C and JavaScript both have the advantage that, in their respective spaces, they are THERE. They have arrived. There is a huge body of code, and an equally-vast body of literature and lore, supporting each.

They're both "bad enough" to do what needs to be done; well-known and widespread enough to be relied-upon; and popular enough to have a supportive community to commiserate with your gripes about how terrible they both are, then tell you the ugly hack you need to do what you want to do.

Second, WebAssembly isn't a platform: it's a compile target. Do you have ten years to wait until a good platform or engine targeting your use case comes along, proves itself among the hackers necessary to give it momentum, becomes viable in the marketplace, and then gathers a working community around it to provide that ecosystem of literature, code, and support that separates the Cs of the world from the arguably more-perfect Adas?

No. Because in that time, if you're not writing JavaScript, you're going to become obsolete. You've got stuff to do; and like it or not, for many of the purposes WebAssembly may one day serve, JavaScript is your current best tool.

Besides, there's no such thing as "learning JavaScript" (or learning any particular language) in any meaningful sense: there is only learning to program -- to solve problems.

If you learn to program with JavaScript, and it becomes obsolete in a year, you've not even wasted a week. If you can't transfer your problem-solving and solution-specifying skills to the language-of-the-week when you need to, you're not much of a programmer; but if you are (or become) "much of a programmer" by working with JavaScript, you'll have no problem moving to that future One True Web Platform when it comes.

Just don't hold your breath. And remember, it's going to be just as ugly as JavaScript, simply in different ways. And in ten years, someone else is going to ask, on the descendant of Quora, "Why should I learn ThisThing, when NextThing is going to solve all our problems and create world peace?"

Then, then ... you will start a response, giving these same reasons.

Or new reasons, equally-bad, and equally-convincing.

Not sure if we would notice.

JavaScript will continue to be used by its fans and adherents.

But it's already not the only game in town.

New Angular projects, for example, and larger Node servers use Typescript - a different language.

This is compiled at build time into JavaScript, which can then be run in the browser.

It could just as easily be compiled into WebAssembly. We would never know.

Use of WebAssembly itself is likely to be as rare as using CPU assembly languages; highly rare.

It's hard to see the difference it will make, really.

It's also of note that other attempts have failed. In ye olden days of the late 90s, Java was a language you could run inside a browser.

Then cross compilers for Java into JavaScript came and went.

GWT is a memory.

So I'm not sure we will see traction in normal browsers. There's just not that hugely compelling killer reason.

If you just want to use C# instead of JS on the frontend or something, download Blazor and have fun - WASM adoption is almost 87%:

(source: Can I use... Support tables for HTML5, CSS3, etc)

WebAssembly the language though will never replace JS, as they’re not in the same category (WASM is a low-level assembly language; WASM replacing JS would be like x86 assembly replacing C++, it doesn’t make sense).

The problem is that WebAssembly doesn’t (yet) include things like DOM access, local file access and <canvas> interfaces. In order to get it up and running rapidly, all of those things are directed THROUGH JavaScript. Also, you need JavaScript code to download and launch a WebAssembly module at the get-go.

So it cannot LITERALLY replace JavaScript until those obstacles are removed. I don’t see their removal to be high on the list for the working group to decide on. There are still “bigger fish to fry”. However, providing this access is on their “ToDo” list - so it hasn’t been forgotten.

Right now - you can call JavaScript code from within wasm/C++ and call C++ from within JavaScript - and that works very well.

OpenGL-ES calls are also going through JavaScript/WebGL - but that’s already wrapped for you - so it’s not obvious.

So my approach has been to wrap all of my JavaScript DOM and <canvas> calls in C++ classes. So I have a C++ “class DOM” - the WebGL/OpenGL-ES wrappers are already there. I haven’t bothered to wrap the <canvas> stuff because it’s much easier to do all of that stuff in OpenGL-ES.

There are few other things that I’ve also “wrapped” - things like local file access and cookies - and some nicer ways to send messages to the JS console and do “Alert” type messaging.

It took me less than a day to write and test those libraries - easy stuff!

At this point, I can write pretty much anything in C++ and for the most part, I forget that JavaScript even exists.

My hope is that as we gain things like DOM access, I can just rewrite my “class DOM” to use the new feature - and that’s the only thing I’ll need to change.

So for me, the ultimate elimination of JavaScript is nothing more than an optimisation…and given how slow DOM access is always going to be - it’s not urgent.

I’m only working on personal projects - but should I need to do this in a team setting - I’d certainly bury the JavaScript stuff in a library, give one person the responsibility to maintain it - and have everyone else avoid all contact with JavaScript.

Honestly - if you’re still waiting - DON’T.

Wasm is ready for use…you just have to wrap anything that still requires JavaScript - which is ridiculously easy to do.

C++ is really amazingly fast in wasm - close to native performance - at least 50x faster than JavaScript for non-DOM stuff and about the same speed for DOM-intense stuff…and I’m seeing perfect portability between Linux/Windows/ChromeOS/Android - as well as between the mainstream browsers.

No.

The only thing PHP can kill is PHP itself, but that isn’t very likely.

At no time in programming history spanning ca 70 years, has one language killed another, except B (bpcl) killed A (algol) and C killed B, but both were not mainstream. There was not a whole lot of code written in BPCL and Algol, so C had an easy day to take over. I am sure Algol still lives today though it has gone through changes.

So, in all of computer history, never has one language killed another one. The only time when a language stops being used is when it no longer moves with the times and only runs on a specific hardware no one uses any more. I could say that 6502 Assembly language was dead, but that isn’t true. Today they are still making games and demos for machines that used 6502 CPU.

So will ANY language kill off Javascript ? Nope. Won’t happen, can’t happen.

Will Webassembly take off ? Sure, but I doubt strongly it will have any effects on Javascript as we know it. Webassembly will find its use, probably in more graphics heavy workings inside a browser, like games and physics.

It isn't.

You hear about it all the time becasue there are interested parties that push it, but this does not guarantee it will succeed in the end, as many other promising technologies proved. Only time will tell.

It will be used in some cases that require heavy computation (think games). Maybe some CPU-heavy webapps.

The major advantage here, I think, is developers who can't stand JavaScript would be able to - finally - write web apps (in theory). Every second post about WASM mentions that it will finally "end the domination of JS", so I assume it's the key selling point here. I can't really relate to this, because I can't see any major issues with JavaScript in its current form (unless you're into those 'guess what [] + {} equals to in JavaScript' jokes, haha). I've been working on some pretty large SPAs, and I can't really remember a case when we had an issue because "JavaScript does not have types, like Real Languages". There're lots of tested approaches to writing webapps in JS and sleeping well, really, it's not that broken.

For "traditional" web-development (think websites, typical CRUD apps, e-commerce, etc. - 98% of what makes the web today) WASM is pretty useless. There's nothing JavaScript can't do in these areas (and it's pretty fast, unless *you* make it slow). And it's not only these technologies (HTML/CSS/JS) that are important here, it's the enormous infrastructure around this all, online docs, tutorials, videos, books, JS libraries, CMSs (like WordPress), freelancers, etc - that allow even the complete beginners to create something published on the web and accessible to millions of other people for free (or really cheap). WASM-based solutions won't have that for a veeeery long time.

Some people mentioned, that DOM API/HTML is not the issue, because it'll be faster to generate it in combiled bytecode. Well, newsflash: browser is itself a compiled app and can parse html and css very fast. Why reinvent the wheel? Because you hate HTML & CSS too? Well, good luck with creating your own standard, then.

Now, I can't count the times when someone (client or a friend) asked me to find the cause of the issue on the page. You just open the DevTools and see it right away - whether it's CSS or JS. It's a matter of seconds, really. With bytecode - well, good luck with that.

So, while I believe it will definately be used and there'll be amazingly fast apps built with it, it won't be as widely used as current HTML5 "web-stack".

At least not in the near future.

No, it will be there for many years to come. There is vast amount of code written in Javascript and it will not disappear over night.

Javascript will still be used for scripting web pages, simple web apps, etc. It will be used for what it was designed to. There is no need to replace Javascript at all since it already has rich ecosystem and is well supported by browsers. Also, it’s extremely easy to put together simple web page logic in it.

However, I would expect webasm to be used for larger apps (compiled from something like Kotlin or even C/C++). Today, large web apps are often written in Typescript or something similar, so it’s not a big change to just compile it to webasm instead of transpiling to Javascript.

Webasm is not replacing Javascript, it’s opening door for other languages to be used for browser development which is great. Of course, I would expect Javascript to decline in use as Javascript isn’t very good programming language and there are tons of better alternatives webasm can help to “enter the world of browsers”.

Hey there! 👋

WebAssembly (often shortened to Wasm) is an exciting technology that allows developers to run compiled code, like C, C++, or Rust, in the browser, alongside JavaScript. It's particularly useful for performance-critical parts of a web application. But like any tool, WebAssembly comes with its own set of challenges. Let’s dive into some potential pitfalls and its impact on the future of JavaScript frameworks.

Potential Pitfalls of Using WebAssembly:

1. Interoperability with JavaScript:

• The challenge: While WebAssembly can run alongside JavaScript, communicating between the two can be tricky and costly performance-wise. Every time data needs to be passed back and forth between WebAssembly and JavaScript, there is a non-trivial overhead. This can diminish the performance gains, especially in scenarios where lots of back-and-forth communication is required.
• Solution: It's best to minimize interactions between Wasm and JavaScript. For tasks like number crunching or algorithms that need minimal interaction, WebAssembly shines. However, for anything that needs frequent interaction with the DOM or the browser, JavaScript is still more efficient.

2. Limited Access to Browser APIs:

• The challenge: WebAssembly itself doesn’t have direct access to many browser APIs (e.g., the DOM, Fetch API, etc.). You still need to use JavaScript as a "bridge" to interact with these. This makes WebAssembly less useful for UI-heavy tasks.
• Solution: Currently, WebAssembly is ideal for offloading computational-heavy tasks like image processing, video encoding, or physics simulations, but leave UI and DOM manipulation to JavaScript.

3. Larger File Sizes:

• The challenge: WebAssembly binaries are generally smaller than their JavaScript equivalents, but if you’re using heavy libraries (like C++ libraries) or pulling in a lot of dependencies, the Wasm files can get quite large. This can lead to slower page load times, which defeats the purpose of optimizing for performance.
• Solution: Make sure to optimize and reduce dependencies wherever possible. Use tree-shaking and other optimization techniques to reduce the size of the WebAssembly file.

4. Debugging Complexity:

• The challenge: Debugging JavaScript is relatively straightforward with built-in browser dev tools, but debugging WebAssembly is much harder. Since Wasm is a low-level binary format, finding and fixing issues can become a real challenge, especially for developers unfamiliar with lower-level languages.
• Solution: As of now, tools for debugging Wasm are improving, but there’s still a steeper learning curve compared to debugging JavaScript.

5. Tooling and Ecosystem Maturity:

• The challenge: While WebAssembly is promising, its ecosystem is still evolving. Compared to JavaScript, the Wasm community is smaller, and the tooling isn’t as mature. This could slow down development if you run into bugs or need support.
• Solution: Keep an eye on the growth of the Wasm ecosystem. In time, it will become more robust, and using it will become easier.

How Might This Affect the Future of JavaScript Frameworks?

Now, what does this mean for the future of JavaScript frameworks?

1. Complementary, Not Replacement:

• WebAssembly is not a replacement for JavaScript. Instead, it’s a complementary technology. JavaScript frameworks (like React, Vue, or Angular) will continue to handle user interfaces, DOM manipulation, and browser interactions because these tasks are still JavaScript's strong points.
• Where WebAssembly comes in is for performance-critical tasks like game engines, simulations, or processing-heavy tasks. So, instead of WebAssembly replacing JavaScript frameworks, it’ll work alongside them to improve performance.

2. Frameworks Supporting WebAssembly:

• Future JavaScript frameworks may evolve to have better integration with WebAssembly. We might see frameworks that let you easily offload parts of your app to WebAssembly for better performance, like handling large datasets, image processing, or other CPU-intensive tasks.

3. Blurring the Lines Between Web and Native:

• As WebAssembly matures, the lines between web and native applications will blur. We might see more hybrid applications that use WebAssembly to achieve near-native performance in the browser. This could push JavaScript frameworks to adopt WebAssembly-driven components for performance-sensitive parts of the application.

4. New WebAssembly-First Frameworks:

• It’s possible we’ll see new frameworks that prioritize WebAssembly, with JavaScript playing a secondary role. This could be especially true for industries that require high performance, such as gaming, video editing, or data visualization.

WebAssembly is an incredibly powerful tool, but it’s not without its challenges. Right now, it's best suited for performance-critical tasks that don’t need heavy interaction with the browser’s DOM.

As for the future of JavaScript frameworks, we can expect frameworks to integrate more seamlessly with WebAssembly for performance gains, but JavaScript will continue to dominate the web for UI/UX and interactions.

Happy coding!

The best quote I have found is that web assembly will become javascript nitro boost.

“What is WebAssembly? The Dawn of a New Era” @_ericelliott What is WebAssembly? The Dawn of a New Era – JavaScript Scene – Medium (https://medium.com/javascript-scene/what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6)

Web assembly will become an awesome kit for developers looking to optimize complex algorithms, manipulate graphics, and generally run incredibly performant platforms. But until complex frameworks with accessible Apis emerge it will mainly be used to make javascript only devs feel inferior and slow.

The popularity of javascript was because its ubiquitous use in front end development and later solidified “full stack" status with Node.js and it's complimentary modules. It took many years for this to develop, and all the right conditions (the advent of the V8 engine, the fall of Rails and Ruby, lack of native websockets in PHP, failure of active x, etc.)

So is it possible, maybe, but Javascript hasn't even hit its stride yet and processors aren't getting slower. Lets be honest, most websites really are just a MVC and a database with a thin server layer to glue everything together, and using web assembly will be useful at the end of that chain and also a lot like hitting that fly with a pneumatic drill.

But really ask a developer 8 years ago and he would have said Laravel/PHP or Ruby/Rails is the only way to go.

WebAssembly is not meant to be written by humans; it’s a low-level language, at a similar abstraction level like x86 assembly, or JVM bytecode.

Normally you use another language that you compile to WebAssembly - the two most popular choices being C++ and Rust.

Ignoring some technical limitations (e.g. like WASM not having access to the DOM), the performance gain for simple forms validation and AJAX requests and stuff, the things one normally uses JS for, will be minimal (let’s say, for example, JS is a thousand times slower than C++; the C++ program takes 0.001 ms, the JavaScript program takes 1 ms, and the network request and response take 150 ms, which will be the same for both - so the fast program will take 150.001 ms, while the slow one will take 151 ms - big deal, those numbers are essentially the same).

The benefit from WASM is when you want something like a custom video codec, a physics engine, a local AI, etc., in the browser. Another benefit is potentially making the life of some compiler writers easier (since they won’t have to write *-to-JS compilers anymore, but instead can target the simpler WASM language).

Would you stop investing time to prepare your meal today because you may think that tomorrow there might be a food buffet laid out for you?

You must do relevant things in relevant times.

Developers also ask that should they learn PHP or nodeJS

You have to understand what kind of work you are pursuing and what the market requires.

Some options are:

Popular skill for freelancer: PHP + some framework/CMS

Market: Lot of opportunities.

Popular skill for developers in a startup: nodeJS + React ecosystem

Market: Startups prefer nodeJS as JavaScript developers can be used in font end and back end which is cost saving for the startup.

JavaScript will still be a major player in the recent future probably for the same reason PHP might not die so soon.

WebAssembly is already available and can be used on all major browsers, including the latest versions of Chrome, Safari, Firefox, and Edge. That said, WebAssembly is a compilation target rather than an actual language that people will program in. In other words, in order to use WebAssembly you need to pick a programming language that supports WebAssembly as a compilation target, and use that. The list of such languages is already quite extensive, but, practically, the languages that you are currently likely to use are C/C++, Rust, AssemblyScript, and maybe also C#. It’s worth noting that some language choices require bundling a rather extensive runtime implementation, which makes them mostly impractical for production use at this time. For example, any language which requires Garbage Collection (GC) needs to provide its own implementation, as none is currently provided by WebAssembly itself.

And yet, despite this, JavaScript usage, both inside and outside the browser, continues to grow rather than shrink. Partially, this has to do with momentum: JavaScript is a juggernaut, while WebAssembly is a fairly new technology. I assume there are developers out-there who aren’t yet using WebAssembly simply because they’re unaware that it exists, or that it’s widely available. That said, there are also some practical limitations on the usage of WebAssembly. First and foremost, WebAssembly does not enable direct access to the browser DOM, and it’s unclear if and when such access will be possible. At this time, the only remedy for this limitation is to bundle some JavaScript code with the WebAssembly to use as a bridge for DOM access. There are some pre-built frameworks for that, such as Yew for Rust, but they can only support a subset of the DOM rather than all of it.

Another significant limitation of WebAssembly is lack of mature tooling. For example, debugging code compiled to WebAssembly in the browser is not yet a pleasant experience, to say the least. JavaScript tooling, on the other hand, is excellent, and all browsers provide a robust environment for debugging JavaScript code. Indeed, the JavaScript ecosystem is one of the best and most prolific the programming world has ever seen. It will likely take years for WebAssembly-based languages to close that gap sufficiently, and they’re unlikely to ever actually overtake JavaScript in this regard.

Last but not least, using modern JavaScript to program for the Web can actually be quite a pleasant and productive experience, if done properly. Modern JavaScript is a powerful, expressive and versatile programming language, and current implementation, such as V8, provide surprisingly good performance. I think it’s an excellent thing that WebAssembly provides alternatives to JavaScript in some use-cases. But I also think many people will continue to use JavaScript even as more alternatives become available simply because they enjoy using it. Case in point, there are many developers who choose to use JavaScript on NodeJS, even though there are many alternatives to NodeJS using programming languages other than JavaScript.

My answer was merged into a question with slightly different wording. As such, I’m rewriting this.

Web Assembly has the potential to replace JavaScript in most, if not all, use cases, but whether it will or not is unknown. If you had asked me a year ago whether it would be the successor to all front-end web development, I would have responded with a resounding no, but I believe that the world has changed in the lead-up to 2019.

First, Go has risen in popularity to become a Top-20 language, and while its growth has slowed, I expect it to become a Top-10 language in the next few years. It is achieving this growth to the detriment of Node and Java. And if the potential to use JavaScript on the server is reduced, a large piece of the psychological and institutional foundation of the language’s success is removed.

Basically, the biggest benefit of Node, aside from easy, non-blocking I/O, is not having to know another language. With WebAssembly, it’s more reasonable to take your server-side language to the client instead of vice-versa.

I also believe that there is more fertile ground on the front-end than ever before with the rise of TypeScript. TS is acclimating JavaScript developers to concepts like interfaces and strict types. And once they clear this conceptual hurdle, there is no reason aside from inertia and custom to choose JavaScript over better languages like OCaml, Java, Kotlin, Dart, Go, and C#.

But do not underestimate the strength of that inertia, though. Lacking a strong technical or cultural motivation to leave a language, most developers will simply stick with what they know. And considering how bloody much code has been written in JavaScript, and how huge NPM is, the amount of inertia in JS may be the greatest in the history of programming. That will take awhile to get away from.

But there is absolutely the possibility that we will. As I said, TypeScript has brought JavaScript development to a new level of respectability. Middleware engineers accustomed to static types are accepting Node written in TS in larger numbers. TS means that “Very Serious People” now see little ol’ JavaScript as a legitimate choice for “Very Serious Applications.” This shift can be seen in salary figures for TypeScript engineers, who earn much more than developers of vanilla JS.

But while TS has given JavaScript more respect than it has ever had, as I alluded to above, I believe that it has planted the seeds for JavaScript’s ultimate abandonment. It is a small leap from TypeScript to another static language, which is precisely what WebAssembly will allow.

WebAssembly can be faster than JavaScript because it’s the result of ahead-of-time compilation of some high-level programming language, such as C++ or Rust. JavaScript, on the other hand, is parsed, compiled, and optimized at runtime. All these operations have overhead, which is avoided with WebAssembly. Also, languages that are compiled into WebAssembly use static types to indicate exactly which code should be generated for specific operations. JavaScript, on the other hand, is dynamically typed, which means that the types of variables in expressions must be inferred at runtime as well. Until types are properly inferred, the JavaScript Engines cannot really optimize the code. All this means that the implementation of computationally intensive operations, such as image and video processing, or encryption, that have been compiled to WebAssembly will generally execute faster than equivalent implementations done in JavaScript.

But how much of your current JavaScript code is an implementation of computationally intensive operations, such as image and video processing, or encryption?

I assume that most of your current JavaScript code deals with responding to user interactions, and updating the browser DOM in response, either directly or using some framework. In such scenarios, it’s the DOM itself which constitutes much of the performance overhead. Moreover, at present WebAssembly cannot even access the DOM directly. Instead it must use a JavaScript bridge for such operations. You will find that the cost of marshaling data between WebAssembly and JavaScript in such cases often outweighs any of the benefits that are obtained from the advantages of WebAssembly, which I’ve listed above.

WebAssembly (wasm) is a binary format for the web browser. So probably new popular languages such as Go can compile to WebAssembly. A lot of people who dislike JavaScript use Clojure, and predictably that language might live on longer than JavaScript as a lot of data scientists use this language. I have more than a feeling any JVM language will still be used 20 years from now. Blame it on Universities!

About 10 years from now, if I am lucky to still be alive, I would definitely use WebAssembly. I am more optimistic so I think it’s very likely that the language of the web will no longer be JavasScript. It could be something else.

Years ago, Actionscript was so popular as a language. In the year 2002, it seemed like the only option for those who wanted to build games. While it was super popular back then, I knew it was going to fade and people will no longer see it as a good idea. You have to try for yourself and code in any language you assume will fade to know whether it really will. A lot of it didn’t make sense to me, but it was part of my job to animate things around the screen and use that language. Now, I pretty much feel the same thing will happen to JavaScript.

Today we have languages like Lua and Swift. Lua has a built-in game engine. Swift is obviously very powerful and flexible. It’s almost as pervasive as JavaScript. JavaScript’s popularity will wane.

The changes are always cultural and political. Just watch and observe how most engineers are like ants jumping from one new thing to another. We have no control of it even if we think we do have control of what will happen.

Not hating JavaScript or anything but I have never seen a long-lasting JavaScript software. Browsers change at a very fast rate. Deprecations happen on a monthly basis. There will be a time people will care more about languages that support Functional Programming well.

Google called WebAssembly the “future of the web.” So yes, it’s obvious everyone has to change their minds at some point and be in the middle of early adopters and people who react way too late.

I prefer to react early and adopt early, because I know it usually takes a much longer time for me to learn something. Let’s hope that something better will replace JavaScript because right now, it’s still crap.

Well, hmmm… there’s this:

extern "C" 
{ 
#include <stdio.h> 
#define WASM_EXPORT __attribute__((visibility("default"))) 
 
WASM_EXPORT 
int main(){ 
    printf("Hello world!\n"); 
    return 0; 
} 

(details vary, since every version of every compiler wants to see different preprocessor directives) followed by:

emcc main.cpp -O3 -o main.js -s EXPORTED_FUNCTIONS='["_main"]' SIDE_MODULE=1 

(For documentation on the preprocessor directives and command line options available to you, just file an issue in the compiler’s Github repository desperately pleading for help.)

Then there’s this:

console.log(‘This is so easy in JavaScript!”);

Slow for the CPU, but that C programmer is now outside enjoying a cigarette.

Although it’s a misdesigned, weakly-typed POS, there are a bunch of things that make JavaScript easy to work with. First of all JS code is easy to cut and paste. There is not as much copypasta available with a compiled runtime targeted by a dozen source languages. Libraries implemented in WebAssembly appear as opaque objects in JS. I recently used a JS library implemented in WebAssembly; it was written in C++ (by original authors obviously extremely uninterested in anything to do with JavaScript). It has a single method taking a Float32Array and returning a Float32Array. I have no idea WTF my thread is doing when it goes in there, but I also know that I’d have to wait years for a JS version to be released. WebAssembly is excellent for porting existing codebases into browser environments, where the original programmers had no idea their code would ever be running in a browser. But that means that as a JS programmer you’ll now be presented with APIs that weren’t exactly designed with you in mind. That’s life.

As much as we hate JS, there are ways WebAssembly might darken the future. There is no way to “View Source” in the browser, so you can expect all malware to be distributed as WebAssembly in the coming years. (This might actually compel people to turn it off in their browsers for security, which would really stick a dagger in it.) Companies wanting to write new, closed source projects have a powerful motive to start them in WebAssembly. You can even hire TypeScript developers off the street, have them write their stuff in AssemblyScript instead.

WebAssembly is faster but the speedup is extremely dependent on what you’re doing. JavaScript under V8 is actually pretty fast and will compile hotspots to machine code (although the code is still needlessly doing type checking because it’s still immersed in JS-world). I looked into WebAssembly’s usefulness for speeding up hotspots (see demo), and while there is some improvement, it isn’t consistent at all. I get different numbers for every combination of OS, browser, and WebAssembly compiler, which indicates that the tech is still quite new.

One of the biggest performance benefits of WebAssembly comes in larger projects- the code is compiled to a machine-friendly format once, by you. This current code delivery technique where we send out a megabyte of transpiler-generated ES5 dog food to be compiled to a machine-friendly format by V8 engines on a million cellphones has to stop. Webpack and Babel must be responsible for millions of tons of CO2 at this point.

Your question has two parts.

Will WebAssembly one day replace JavaScript

Probably not, no. There are many “substitute” languages that you can use on the frontend that can completely replace JavaScript today, with no need to wait for WebAssembly.

Aside from TypeScript, none have relevant amounts of traction. I don't see why a different language would suddenly replace JavaScript when we have hundreds of alternatives available today.

With Emscripten, you even have C/C++ and other compiled languages. All WebAssembly does is make the latter kind of compilation result run faster. That's it.

…how does one learn WebAssembly?

You don't. Not unless you're building a compiler.

If you have a specific need, like you're writing a game and you need the performance? Then figure out what language you want to use (hint: C++ and Rust are the current best bets), and learn how to program in that language first. Once you've learned it, then learn how to build for a WebAssembly target.

Most of the use of WebAssembly is likely to be to create plugins to be used from JavaScript. And game development. This is true for at least the next decade. Beyond that, it's always hard to predict the future.

WebAssembly (WASM) vs. JavaScript: Performance & Real-World Applications

Performance Comparison

1. Execution SpeedWebAssembly (WASM) is a binary format compiled from languages like C, C++, Rust, and Go, making it significantly faster than JavaScript for computationally intensive tasks.WASM executes at near-native speed, utilizing low-level optimizations and ahead-of-time (AOT) compilation.JavaScript, on the other hand, is interpreted and Just-In-Time (JIT) compiled, leading to runtime overhead.
2. Memory & CPU UsageWASM has efficient memory management and can handle complex operations with less CPU overhead.JavaScript relies on garbage collection, which can introduce performance bottlenecks in certain applications.
3. Parallelism & MultithreadingWASM supports Web Workers and SIMD (Single Instruction Multiple Data) for parallel execution.JavaScript has asynchronous execution but lacks direct multithreading support in a way comparable to WASM.
4. Startup TimeWASM has a faster startup time since it is precompiled and optimized before execution.JavaScript requires parsing and JIT compilation before execution, adding startup latency.

Real-World Applications

1. High-Performance Web AppsGame Engines: Unity and Unreal Engine export to WebAssembly for smooth browser-based gaming.3D Rendering & Graphics: Applications like AutoCAD Web, Figma, and Google Earth leverage WASM for real-time rendering.
2. Scientific Computing & Data ProcessingMachine Learning & AI: TensorFlow.js and ONNX leverage WASM for optimized model inference in the browser.Data Visualization & Analytics: Libraries like Pyodide (Python in the browser) use WASM for high-speed computations.
3. Cryptography & SecurityWASM is used in blockchain applications, cryptographic libraries, and password hashing (e.g., Argon2, BLAKE3) to improve security and performance.
4. Embedded Systems & IoTWASM is portable, making it useful for running logic on low-power devices, drones, and industrial automation.
5. Server-Side & Cloud ComputingWASM is emerging in serverless computing (e.g., Cloudflare Workers, Fastly Compute@Edge) as a lightweight alternative to containers.

When to Use WASM Over JavaScript?

Conclusion

• JavaScript is still the dominant language for general web development, especially for UI interactions.
• WebAssembly is ideal for performance-critical tasks, enabling native-like performance in the browser and even on the server.
• Many applications combine both, using JavaScript for UI logic and WASM for high-performance computations.

They’d continue using it because languages don’t really “die” in the conventional sense. They see a decrease in usage, sure. But then again that wouldn’t change the fact 90% of the Internet (off-the-cuff figure) is still reliant on it, so we’d still have document.getElementById()s on every other page, as unfortunate a fact as that might be.

Same old argument with PHP and every other “dead language” on the verge of being totally “defunct” because of new developer trends. Entry-level developers like myself will still continue to use it and make money off using it, so it’s a moot point.

Browser statistics on JavaScript disabled (https://stackoverflow.com/questions/9478737/browser-statistics-on-javascript-disabled)

I don’t think that WebAssembly will replace JavaScript.

• First, you would need to have support for all browsers and users need to move away from legacy browsers not supporting WebAssembly. This will take a couple of years, but will eventually be achieved. However, in the mean time, a lot of more JavaScript based projects will have started and the JS ecosystem will have grown.
• JavaScript already has an enormous ecosystem. Think about all the libraries and frameworks written in / for JavaScript. Bootstrap, Angular, React etc. To have WebAssembly replace JavaScript, you’d need good replacement options for those for WebAssembly. But then again, for someone to write a framework or a library for WebAssembly, it already needs some traction. It is a bit of a “chicken and egg” situation. JS has a tremendous first movers advantage.
• It is unclear, whether WebAssembly will ever have a good enough “boot up” time. If the loading times can’t be significantly reduced, it’s use will be likely limited to browser games and things that you’d boot once. That’s not the only thing unclear about WebAssembly, there can always be a lot of roadblocks in the way for such a young technology.
• Even today, there are a lot of other competitors to JavaScript, but they haven’t replaced it either. Think of CoffeeScript, TypeScript or Dart. I think if the market share of JS is reduced, then it’s not by a language that compiles to WebAssembly (like e.g. Rust or C++), but rather by something like TypeScript. WebAssembly would only indirectly reduce the market share of JS, by making the Web even more popular than it is today by enabling browser based games, virtual reality applications and whatever computationally-intensive tasks the future might hold. But not by directly replacing apps that were previously written in JS.
• Currently, languages that compile to WebAssembly are low level. If it stays that way, that’s one more reason for WebAssembly not replacing JavaScript: Developers often prefer a high-level language like JS to a low-level one like C++, if they aren’t forced to use a low-level language by very specific performance requirements.
• On the server-side, people definitely don’t have to choose JavaScript. Yet more and more projects are launched in Node.js every year.
• Replacing all the existing JavaScript code including the code that would be written until WebAssembly is fully mature, isn’t feasible. This replacement, if it were to happen, would be rather slow, as there are still many companies with huge code- and knowledge bases in JavaScript. For those companies to make the switch, there would need to be immensely compelling reasons.

Conclusion: I think that WebAssembly will be a great enhancement to the web as a platform, by allowing it to perform computationally-intensive tasks at near native speed. But it’s far more likely that JavaScript’s market share is reduced by a compile-to-JS language than a compile-to-WebAssembly language.

Well, yes, on it’s own it is, but there exists bottlenecks between the two, and you’re almost certain to need some traditional javascript to access the dom, for example, so there’s a threshold below which it would actually be slower, so managing a few hundred to a few thousand objects would be faster with well written javascript, but when you get to five figure numbers, then the javascript engine will hit limits that the webassembly code will handle more swiftly, but you still have to keep data transfer between the two apis to a minimum.

Also, it’s not the only way to get better speed out of your web app, there exists others:

1. Using web workers to take the load off the main thread.
2. Using webGL for super fast gfx rendering. OR
3. Offloading certain massively parallel processes to the GPU, using GLSL

If you want to know more I highly recommend Tom Lagier’s series of tutorials where he builds a memory visualisation tool, and he uses all of the above approaches, in one form or another, in one application! With some benchmarks and performance analysis. Well worth a read: Intuition Engineering and the Chrome Heap Profile (https://hackernoon.com/a-tale-of-javascript-performance-61c282f89f2a)

WebAssembly (WASM) and JavaScript serve complementary roles in modern web development, with distinct performance characteristics and applications.

Performance comparison:

• WebAssembly executes significantly faster than JavaScript, often approaching native code speed
• WASM provides predictable performance with consistent execution times
• JavaScript benefits from modern browser optimizations but still faces inherent limitations as an interpreted language

Real-world applications:

• WASM excels at: CPU-intensive tasks (3D rendering, video editing, scientific simulations), porting existing C/C++/Rust applications to the web, gaming engines, and cryptography
• JavaScript remains better for: DOM manipulation, typical web interactions, rapid development, and situations where peak performance isn't critical

Most sophisticated web applications now use both technologies together—JavaScript for UI and general functionality with WebAssembly handling performance-critical components. This hybrid approach leverages the strengths of both: JavaScript's flexibility and ease of development with WASM's near-native performance for computationally demanding tasks.