For at least 8 years now, I’ve been hearing about the imminent death of frontend - or at least JavaScript. One of the tools that is supposedly goin...
For further actions, you may consider blocking this person and/or reporting abuse
I work on a mid size wasm first language and I think this misses the mark slightly. Typescript and JavaScript will be around a long time. But the true major advantage of webassembly isn't speed it's portability, AutoCAD is a great example of how wasm allows traditional apps to be ported to the browser. Once the right framework in the right language comes along that can target every platform without exception wasm will gain a lot more popularity. There is a really cool wasm proposal in phase 1 still called component model which allows any language to easily link to any other language removing any bar for cross language interior which is truly amazing.
Totally agree - portability is a huge strength of WASM, and the AutoCAD example is amazing. And yes, the Component Model could be a game-changer once it matures.
But that’s kind of the future 🤖✨ - in my post I focused more on where things stand right now, in everyday frontend work. At the moment, JS is still more than enough for most use cases, and WASM shines mainly in specific heavy-compute scenarios.
Thanks a lot for the insightful comment! 🙌
That's very fair.
I honestly don't think JavaScript or typescript will ever die either, at the end of the day rust is just a worse language for web development. A web developer doesn't want to deal with memory management, something like reScript is a much better option for a nicer type system.
Exactly - I don’t think JS is going anywhere either, especially since it’s effectively the host language of the web.
I’d just add that WebAssembly doesn’t have to mean Rust + manual memory management. There are options like AssemblyScript, which feels much closer to TypeScript and avoids a lot of the low-level complexity.
Curious what you think about AssemblyScript as a Wasm target for web devs?
If you really want to you can write javascript or python that runs in a webassembly runtime like Wasmer or Javy. The penalty with using those solutions is the runtime needs to be downloaded together with your code.
Great point - and yeah, that’s a really good observation 👍
Running JavaScript or Python inside a WASM runtime (like Wasmer, Javy or Pyodide) is absolutely possible and can be very useful, especially for portability and sandboxed execution.
As you mentioned, the main trade-off is shipping the runtime itself - startup time, bundle size and memory usage can easily outweigh the benefits for typical frontend apps.
I personally see those tools more as portability / compute engines rather than a replacement for native JavaScript in the browser, but they’re definitely an interesting part of the WASM ecosystem.
Great article, good explanations ...
WASM is gonna "kill" JS in the same way as NoSQL is gonna kill RDBMS/SQL, or GraphQL is gonna kill REST/HTTP - not !
All of these new pieces of "hipster" tech are useful for specialized niche cases, but are not going to replace the mainstream tools/tech - basically because they're just harder to use, and don't offer any measurable advantage for most basic/mainstream use cases ...
Exactly — that was pretty much the main point I wanted to get across 😊
JavaScript is already really fast and more than enough for the majority of everyday frontend use cases.
At the same time, in certain specific contexts (especially heavy computations), WASM is simply hard to beat — and when you do have those cases in your app, it’s a tool worth reaching for rather than something to be afraid of.
Thanks a lot for the comment!
You're welcome - yes, you explained that well in your article, I just wanted to emphasize the point that many people really like jumping on the hipster/hype tech bandwagon, and insist on using all that flashy tech "because they can" - even when there's totally no need (from a functionality or performance point of view) !
You remember when NoSQL and GraphQL were all the rage and people insisted that everyone HAD to use them, or you'd be some kind of dinosaur? Well, we know how that ended ;-)
There are good use cases for NoSQL, GraphQL or WASM - but for mainstream cases just use mainstream tools, they get the job done with less effort! :-)
Yesss — especially the GraphQL hype, I still remember all the “REST is dead” takes 😂
NoSQL was being pushed around the same time as well, very similar story 😀
Totally agree with you: there are solid use cases for all of these tools, but mainstream problems usually benefit most from mainstream solutions.
Thanks for this comment — it actually made me a bit nostalgic, not gonna lie 😂
Haha yes, the "overhyped things" of yesteryear :-)
I would like to make a really fast markdown/code editor. A goal is protable, small as possible, and can solve my personal problems of course, which is the a proper jsDoc syntax highlighting. Which is really tricky, with lot of different question. Also hughe pain is the markdown when a certain point we can including any language with syntax highlight. A worst one is the HTML, because the HTML natural contain a CSS, JS, SVG, HTML structure and so many more.
I feel this task is a never ending problem. But the rust generated syntax parser I think reach fare more optimized solution compared to a JS/regex one.
I hate, when I need to spend a so many times to get a correct highlight. Maybe the rust macro solution is my friend on end of the day.
Yeah, I totally feel this - proper Markdown + embedded languages highlighting is way harder than it looks.
Once you go beyond simple cases, JS + regex just becomes painful and fragile. A Rust-based parser (or macros) can actually make this manageable: faster, more predictable, and less hacky in the long run.
Sounds like a solid direction. Fingers crossed 🤞 and let me know how it goes - I’m rooting for this project!
thanks for the post and nice demo! Performance results and explanation in the first tab is kinda inconsistent. For bigger
nlike 300-500 the page shows run time forjsless than forrustthenjs/rustis less than 1.0 but green note below states that it is oppositeThanks a lot, Timur! 😊 And you're absolutely right - good catch!
I focused mostly on implementing the benchmarks themselves, and the UI/UX around the results definitely needs a bit more love 😅
Those notes should be clearer and consistent with the actual numbers shown on the chart - I’ll clean it up over the weekend so everything lines up nicely.
Thanks again for pointing it out! 🙌
For your average JS dev, WASM is basically vaporware, borderline useless aside from a few rare CPU-bound tasks.
WASM probably has another 10 years before "killing JS" is anything but COPE from the JS hater crowd.
Yeah, that’s fair — modern browser engines are insanely fast these days and for the average JS developer they’re more than enough.
Especially when you take the JS ↔ WASM boundary cost into account, WASM often doesn’t make sense by default.
Still, it’s one of those tools that can suddenly become very handy once you hit a CPU-bound corner case, so I think it’s good to at least know it exists 😄
Thanks for sharing your perspective!
I've only really thought of WASM as a way to access C/C++ libraries from a JS app.
In other words it's a bridge to access other code. I can't imagine doing an entire front end app in WASM ... Nor can I imagine doing computationally intensive apps in JS.
Different horses for different courses.
/shrug
Thanks for the clarification - I fully agree.
JS and Wasm can absolutely coexist peacefully, each playing to their strengths. In the article, my main goal was to highlight how that coexistence can work in practice and what the gains are when you use Wasm alongside JS, rather than framing it as an either/or choice.
Different horses for different courses 🙂🚀
The idea of WebAssembly replacing JavaScript always sparks debate, but the reality is more balanced. WebAssembly brings strong performance for heavy tasks, while JavaScript still handles the core of web interaction. Both technologies work well together, and each covers different needs. The demo helps show how WebAssembly can support demanding workloads without taking over the whole stack. It’s a helpful look at how the two can coexist rather than one replacing the other.
Thanks for the comment - I agree, this feels like the right balance.
JavaScript and WebAssembly complement each other really well, at least for now. Each has its place, and using them together makes much more sense than framing it as a replacement story.
Who knows - maybe one day a real “Wasm star” will emerge, but until then, coexistence feels like the healthiest path 🙂
hey Sylwia, thanks for this post. It is really interesting and showcasing the outputs is very helpful to grasp the results...
It is also so nice that you mentioned web workers and webGL... I am quite curious on these topics and hope to get in more detail, even maybe I will try to do a demo/study project similar to yours above (just not sure where to start).
best, alptekin
Thank you so much, Alptekin - really appreciate the kind words! 😊
It’s great to hear you’re interested in graphics-related topics. If that area caught your attention, I highly recommend looking into WebGPU - it has just become a standard in modern browsers and opens up a lot of exciting possibilities.
I’m actually planning to put together a small WebGPU demo early next year, so hopefully that can be a good starting point as well.
Best of luck with your experiments - a demo/study project like this is a great way to learn!
Another good language is missing from this article, and it is ZIG. Compiling WASM is simple, no need for entire visual studio on windows.
Good point 👍
Zig is a great WASM target indeed - especially if you want a very lightweight toolchain and minimal runtime.
I went with Rust mainly because of the ecosystem and familiarity, but Zig is definitely a very solid alternative, particularly for small compute-oriented modules. Thanks for bringing it up!
I used WASM 2 years ago, and at that time, I faced too many challenges to add WASM to different runtimes of JavaScript.
Totally fair - the WASM ecosystem was much rougher around that time.
Different JS runtimes had different loading APIs and limitations, and the tooling was still maturing back then.
Out of curiosity: what were the main issues you ran into? Was it bundling, runtime differences (Node vs browser), or something else entirely?
I’d love to hear more details 🙂
The main issue was that I had to call some WASM functions in the frontend and some on the backend of the nextjs application. The WASM target for the browser didn't work on the Node environment.
Thanks a lot for the follow-up, Abdullah - that makes total sense, good point!
Mixing browser and Node runtimes with the same WASM module is still pretty painful right now. Very often you end up needing different targets / build configs for the browser (e.g. wasm32-unknown-unknown or a "web" target) and for the backend (Node / WASI).
I really hope the tooling story for “isomorphic WASM” will get better over time 🤞
Nice! I like your demo :). I like that you show your prototype (demo) on a website. It make easier for the user to interact!
Thanks so much, Benjamin! 😊
Really happy you liked the demo - making it interactive was exactly what I was aiming for.
Appreciate your comments as always 🙌
you are welcome, Sylwia :). You can call me Ben!
Haha ok, Ben :)
I can't wait for the next post:)
Rust cant kill C/C++. JS cant be killed off, PHP has been getting "killed off" for like two decades. Everyone is moaning about Java.. and yet it is still there. Popular languages will be fine, maybe the usage comes down a bit but it will be hard to get rid of stuff like this completely.
Totally agree, Martins! 😄
Thanks for sharing your thoughts - the ecosystem momentum behind languages like JS, PHP, Java etc. is massive, and that alone keeps them alive and well for decades.
I also don’t believe in “language death” prophecies anymore 😂 Everything just finds its niche eventually.
But I do love experimenting - it’s kind of my little hobby on the side 😄 So WASM, Rust and all those “shiny new toys” will probably keep showing up on my blog from time to time. Thanks again for the great comment! 🙌
Love how balanced this is. No hype, no fear — just real benchmarks and clear takeaways. The JS ↔ WASM boundary explanation is gold, especially the part about “JS looks faster” because of overhead. And the Gaussian blur result was a fun surprise 😄 Great demo and write-up! 👌🔥
Thanks a lot, really appreciate this! 😊
I’m glad the balance and the benchmark context came through — the JS ↔ WASM boundary is one of those details that easily gets overlooked. And yeah, the Gaussian blur result surprised me too 😄
Thanks for taking the time to check out the demo!
Thank you for sharing this! The post is easy to understand, and the demo is intuitive!
Thank you! 😊
I’m really glad the post and the demo were helpful - that was exactly the goal.
Gdzie tu mozna wyslac do ciebie wiadomosc, poza tym syfem jak LI bo nie mam tam konta i nie zamierzam. Masz jakis numer tel , email , tt ,snap czy cos :)