DEV Community

Vaibhav Shah
Vaibhav Shah

Posted on

Will WebAssembly replace JavaScript? Or Will WASM Make JavaScript More Valuable in Future?

Will WebAssembly replace JavaScript

Since the time WebAssembly started gaining traction, a question has arisen among the developers: Will it put an end to JavaScript? Whereas, some developers and enterprises think that WebAssembly will complement JavaScript and accelerate the web development.

What is WebAssembly?

WebAssembly (WASM) is a binary instruction format which has been built to compile high-level languages such as C, C++, Java, Python and Rust. It allows deployment on the web and server applications.

Users write the code in multiple languages to run it on the web. WebAssembly allows them to run the code on the web at a native speed.

Future of WASM and JavaScript

Mozilla developers, the ones who created WASM, define it as the code that users can run in web browsers. It provides new features and major improvements in performance.

Like JavaScript, it is also executed in a sandbox environment and exhibits the same security. But, to say that it will put an end to JS is very unrealistic. Even the creators of WASM deny such intent.

According to GitHub’s latest report, JavaScript is the most used programming language for the last several years. Also, it has the most number of contributors to public and private repositories.

JavaScript is showing no sign of slowing down and wouldn’t be replaced by anyone in the near future. Further, as the modern technologies like blockchain explode in popularity, JS will be a new age language among web developers and gain traction across industries.

Will WASM replace JavaScript?

Let’s assume that JavaScript gets replaced. Will WebAssembly be able to play all the roles of JS? Don’t forget that WASM is still a young player who debuted just a few years ago in 2015. Whereas, JavaScript is here for around a couple of decades now. It has become the ideal language for web development.

Business leaders say that it is an overstatement that WASM will replace JavaScript. What they think is that it wouldn’t remain a monopoly, and grow over time.

A limitation of JS is that it wasn’t built to be a compilation target. On the other hand, WebAssembly has been built as an efficient compilation target. It is ready to use, provides smaller payloads, rapid parsing, as well as consistency in performance.

As per the FAQ page of WebAssembly, it reduces costs by having a design that enables web browsers to use WASM inside its existing JavaScript engine. Hence, from the cost perspective, WASM should be comparable to a big new JS feature, rather than a fundamental extension of browser model.

Currently, JavaScript supports all the major browsers. To use WASM, a web development company will need to move away from the browsers that don’t support WebAssembly. Till the time WebAssembly brings support for new browsers, JavaScript ecosystem will further grow and more developers will use it for their projects.

The ecosystem of JavaScript development is very large, with most of the developers writing all their libraries and frameworks in it - Bootstrap, Angular and React to name a few. In order to overtake JS, WebAssembly will need replacement options for all these libraries and frameworks, which doesn’t seem easy.

Further, the replacement of an existing JS code to WebAssembly wouldn’t be feasible. Even if it happens, companies wouldn’t prefer it because it will be very slow while the code base in JS will be huge. JavaScript already has a lot of competitors in the market, but none of them has been able to replace it.

With time, WebAssembly will become more popular to power browser-based games, VR (virtual reality) applications and other compute-intensive tasks. It can only decrease the market share of JavaScript, but not replace the applications that are already written in JavaScript.

WebAssembly Complements JavaScript

A website development company can use WebAssembly and JavaScript together as both of these can complement each other. WebAssembly can be run alongside JS using WASM JavaScript APIs. It will load the WASM modules into a JS app and share the functionalities together.

When used together, developers get the benefit of expressiveness and flexibility of JavaScript and performance and power of WebAssembly. Therefore, WASM has the ability to move JavaScript to a scripted role. If enterprises and developers think of WebAssembly as a sidekick, it can result in an iconic pair.

Wrapping up

WebAssembly will bring a lot of improvements to the web with its core features and native speed. But it is very less likely to overtake JS. Whether you like it or not, JavaScript will continue to dominate the web development sphere.

Even the FAQ of WebAssembly states that WebAssembly will allow compilation of multiple languages on the web, but JavaScript has got an incredible amount of momentum. Thus, JS will remain the single, privileged language of the web.

Top comments (16)

Collapse
 
jillesvangurp profile image
Jilles van Gurp

I disagree. Javascript as such will of course stick around in the same way that other languages seem to stay relevant as well. But there will be other options and those options will be operating on a completely leveled playing field. You won't have to use it because there are things that you can't do without it. A lot of people will choose not to. Even so, some might still prefer Javascript in the end.

However, what is going to change is that it is first going to lose its special status as the only language usable for frontend development. Then once people are using many languages on top of wasm, it's status as a special language with dedicated browser support will also be up for debate.

Right now it is special in the sense that the runtimes in browsers are specifically made and designed and optimized to run javascript. These runtimes have now been modified to also run wasm. Very soon that will be the primary thing they do. My prediction is that eventually somebody will figure out that javascript interpreters run perfectly fine on top of wasm and that there's no technical need whatsoever to have all these complicated bits and pieces around that are not related to running wasm code.

It's not like javascript is particularly fast. In fact the main early usecase for wasm seems to be not having to use javascript for things that need to be fast. In other words, people will start running javascript on top of a runtime that ships as wasm; in the same way that you can run other interpreted languages like python in wasm.

At that point browsers will know how to run wasm code and everything else just ships as wasm. Javascript will stop being special. If it needs to be fast, people will ship something precompiled as wasm. If it needs to run on old (pre wasm) browsers, they'll still use javascript. If they want to run a particular flavor of javascript, they'll just bundle their own wasm compiled runtime and not wait for all four browsers to be updated. It will be just yet another thing that you run on top of wasm. Transpilation will no longer be necessary if you can ship your own runtime.

Collapse
 
ratherbsurfing profile image
Chad Collins

Interesting, but to be clear. How much JavaScript do you really write? You do not have it on your CV? And can you list some sites you have made with JavaScript and other langs? I mean your reply seems common to someone who has long hated the language and has not used it in a real professional way. Just so I can calculate your prediction plus your bias toward "something else" in this case WASM. What is your real understanding of JavaScript... and please do not start parroting types and JS is not a real language and all that. Just tell me if you have made any good apps with it? Maybe even ones I can see. - regards.

Collapse
 
jillesvangurp profile image
Jilles van Gurp

@chad A lot more lately than I care to advertise on my CV because I'm not planning to be a full time front end developer. I wrote a couple of tens of thousands of lines of JS and typescript in the last six months for inbot.io. The front page is react and not done by me but the application linked from there was rewritten completely by me. It's a mix of typescript and javascript and uses a small framework called redom. I'm at this point pretty familiar with both languages and have migrated a lot from one to the other.

To give you the context; we used to have a front end developer and I took over his tasks end of last year. As we had some significant new requirements, I ended up touching and modifying large parts of it; converting most of it to typescript; and developing some pretty significant new features from scratch. The typescript conversion is still ongoing and has been totally essential for me to get a grasp on this code base. Refactoring other people's Javascript is just not a thing and when tests are also not a thing, you basically are forced to slowly reverse engineer what everything does. This is extremely painful in JS. Lets just say that I learned a lot of interesting javascript hacks that I would argue are seriously misguided by picking them apart and trying to figure out WTF was the intention before rewriting in typescript.

And you are right, I'm not particularly liking either language but you'd be wrong to assume I can't work with them. Typescript particularly, is actually fine and I wrote many thousands of lines of Javascript before switching to that.

But if you know other languages like Kotlin it kind of feels a bit messy and limited. It sort of gets you part of the way to a better language but not all the way. Part of that is just because they want all JS to be valid TS, which just means you are stuck with a lot of legacy.

Typescript adoption in the industry is unprecedented. I've never seen anything getting adopted this quickly. I've seen numbers suggesting that well over half the new projects are typescript now. It's for a good reason because Typescript indeed gets you types and better tools.

IMHO, if you are doing Javascript instead of Typescript at this point, you are simply doing it wrong. I've been fixing a lot of very obvious type errors as part of converting code to typescript. IMHO that's a category of bugs that is simply inexcusable in modern development. JS apologists seem to be increasingly on the defensive when it comes to this. You see the same in other dynamic languages that are also moving to stronger typing (e.g. Ruby and Python).

On the WASM front there are a few blocking issues like e.g. garbage collection still being in the process of implemented in browsers. ETA for this seems to be 1-2 years max. Despite this, you can run e.g. C# with Blazor (brings its own GC), Rust with several rust specific frameworks (no need for GC in rust) and a few other things. Google just released Google Earth as a WASM application.

Right now the limiting factors seem to be that it is mostly quite early. Despite this you see some efforts to completely bypass the js/npm ecosystem in several language communities targeting WASM. This is kind of the point. WASM is a runtime for people who'd rather not use Javascript. It's not going to be limited to just the stuff that JS is too slow to do.

E.g. the Rust people are pretty serious about doing everything in Rust. If you are doing Rust, you'll not have a lot of patience for languages like Javascript.

Similarly, C# people won't have a lot of appetite for javascript either when they are doing stuff with Blazor. The trend is pretty clear: these are very young projects but there seem to be lots of people interested in driving them.

I have good hopes for Kotlin and Swift in this space. They are already quite popular with frontend developers and both have llvm based compiler tool chains capable of producing WASM. This won't happen overnight but it is already starting to happen.

Thread Thread
 
ratherbsurfing profile image
Chad Collins • Edited

@jilles - that is a thoughtful and educational reply. And in turn, I can see that you have carefully thought about why JavaScript is not doing the best job you could hope for. 20 years writing javascript, I cannot say my code did anything special beyond doing the expected job. I can see the complexity and need growing for ever more modern approaches to building apps for the web. Many years ago, I saw middle and backend tier developers whom looked down on javascript and frontend web developers come over to writing javascript.

As the stack (in many cases) began to shift further toward "the client" and to stay relevant, and have work, many of these long time software programmers began to move into JavaScript and essentially the front-end, and javascript moved to the middle and backe-end. And now here we are, folks still seem to fall into camps.

Front-end development is just more difficult than backend development in some ways, and targeting multiple browsers as platforms with the same code base is just plain hard to do, or at a minimum requires real dedication to the work at hand.

Making multi-modal applications requires mastery and dedication to make a great web application and I get the inclination that the industry will always be chasing a carrot, even when it had something great that almost matured to be what was best for the expected outcome for our web.

Let us see how this new future for WASM evolves. To give some more context, I started my career 25 years ago building print layouts with tools that laid things out perfectly on the screen, and as the web evolved, so did my web coding. To share more, I have long been challenged with long hours making things pixel perfect with modern approaches, but I always succeed at the task.

I have trusted people, who swore the new ways would solve what seemed taken for granted in the digital print industry to no avail. Hence why I am seeking out mentors and masters in WASM. I like c# and what I have seen from Blazor so far. I make desktop apps and browsers with c# for automation often. I also make desktop hybrid apps with electron.js. I am open to the better future you describe and finally will close this reply with thanks for being so detailed and clear in your reply, and I look forward to more opinions from you and the community in the future. Sincere regards Jilles!

Collapse
 
tux0r profile image
tux0r

WebAssembly lacks built-in DOM support and browsers still don't allow me to do this:

<script src="mymodule.wasm" type="application/wasm"></script>

Those are the only two things that keep me from never touching JavaScript ever again.

Collapse
 
psupanova profile image
Peter Edwards

The writing will be on the wall for JavaScript as soon as webassembly gets direct access to the DOM. At first it will be slow but then some one will write tools to automate fundamental libraries like Date and time, and localisation to webassembly. Better typed checked languages without the need for transpilers will ensure JavaScript being used mainly for legacy code.

Collapse
 
rhymes profile image
rhymes

There's a proposal on WASM module integration which should make your life easier: github.com/WebAssembly/esm-integra...

You still won't get rid of JS

WebAssembly is going to get a lot better in the future: WebAssembly’s post-MVP future: A cartoon skill tree

Collapse
 
tux0r profile image
tux0r

You still won't get rid of JS

Not yet. :-) I'll keep watching it.

Collapse
 
ratherbsurfing profile image
Chad Collins

Really the only thing? Do you have experience making Rich Internet Applications? Do you recall compiled binaries for the web? They ran in ActiveX, Flash and Silverlight. Your advocation for WASM, which I welcome by the way, seems to point to a holy grail that does not yet exist? Please share more. - regards.

Collapse
 
pojntfx profile image
Felicitas Pojtinger • Edited

JS/TS has the biggest development community and ecosystem in the world, by far. Although other languages (especially Rust IMHO, which is awesome when used in conjunction with Parcel - zero config FFI in a nutshell) will make the web even more awesome, modern JS/TS won't go anywhere - in fact, with more and more Apps going full PWA (or JAMStack) I suspect JS/TS to grow even more fastly in the future.

Collapse
 
ratherbsurfing profile image
Chad Collins

Finally, someone who is not "hoping" and "waiting" and who basically is correct. Thanks for being the voice of reason. It is usually folks who have not made any real modern web apps with javascript that seem to say Javascript will die.

Collapse
 
tomasoplt profile image
Tomas Opis

WebAssembly is the furture of all business web application development. I am pretty sure. Especially for business applications which has huge front end functionality. Frameworks which compile code into WebAssembly like Blazor can save about 40% development time and this is major fact for choosing this framework. You can save your development time and save customer costs. Companies, which stay in the past and continue development in Angular, React or Vue will be slower and more expensive than their competitors over time. For simple web pages, there will be always Javascript. There is no big advantage for simple web pages to use WebAssembly or frameworks which are built on WebAssembly.

Collapse
 
ratherbsurfing profile image
Chad Collins

I kind of lost your point when you started using percentages without real data? Do you have data tha backs up the 40% number?

Collapse
 
dinsmoredesign profile image
Derek D

+1, would be very interested in seeing numbers for this. It's my experience that developing in all these WASM languages takes way longer than JS and there's no way there's going to be a 40% increase in productivity without solid frameworks to handle the heavy lifting.

You mention Blazor - have you actually used Blazor? I honestly don't know a single .NET dev that likes Razor (and I know a lot), let alone Blazor.

Collapse
 
kb_mathan profile image
Mathan kb

Web applications are a complex but important part of any business. Having a secured and responsive web app can increase customer and employee engagement to multifold. These applications are commonly used in communication with customers, collaboration with employees, secure storage of data, and providing data and information to management. We at Hakuna Matata Solutions is an experienced web application development company that has been helping companies achieve their full potential in their respective field.

Collapse
 
tjgodel profile image
Terry J Leach

Ok JS is not going to be displaced by WebAssembly, what about the future of languages that compile to JS, for example elm? Elm to JS and WebAssembly seems like a great transition to event-driven systems.