Hacker News Reader

Comment by TekMol | Hacker News Reader

I don't see WASM as a significant step forward. In fact, I question its purpose altogether.

Before WASM you could already compile code from other languages into JavaScript. And have the same benefits as you have with WASM.

The only benefit WASM brings is a bit faster execution time. Like twice the speed. Which most applications don't need. And which plain JavaScript offers about two years later because computers become faster.

And you pay dearly for being these two years ahead in terms of execution time. WASM is much more cumbersome to handle than plain JS when it comes to deployment, execution and debugging.

In IT we see it over and over again that saving developer time is more important than saving CPU cycles. So I think chosing WASM over plain JS is a net negative.

View on HN

Debugging a Rust program compiled to Javascript is MUCH harder than debugging one compiled to WASM. That is the whole point. And even making the program work when compiled to JS is iffy, as JS has a few breaking constraints, notably that it is single threaded.

Sure, native JS is easier still. But there is a huge wealth of code already written in languages that are not JS. If you want a web app that needs this code, you'll develop it many times faster by compiling the pre-existing code to WASM than by manually rewriting them in JS, and the experience will be significantly better than compiling that code to JS.

ngl I've tried using Rust -> WASM and it's been an awful experience, I'm much much happier with C. Rust generates enormous blobs because you have to include stdlib, and if you don't you don't get any of the benefits of using Rust. I'm probably overrotating on binary size but it sure is nice being able to just read the WASM and make sense of it, which is generally the case for WASM made from C and is absolutely not the case if you're building from Rust.

Did you run the output through wasm-opt? The size isn't terribly bad. I have a whole complex GUI with realtime charts, based on egui, under 4MB uncompressed. This includes three fonts and even some images.

Yeah no obviously the size of the stdlib is fixed so as your binary sizes grow it stops mattering.

I'm curious why you're taking the approach you describe, I think compiling entire GUI apps to WASM is the absolute worst thing, so clearly you have a different set of constraints on your work.

Yeah very much different constraints. I would send a screenshot if I knew I could make it public because the results look spectacular. Rendering at 60 to 120FPS, perfectly smooth navigation, rendering even 10k OHLC candles without a hiccup.

Don't worry I'm ok without having my eyes burned out by the lack of proper subpixel AA on your fonts. :P

10k candles at 120 fps seems like you could absolutely do it in JS alone, though I suppose the app came first and wanting to deploy it to end users via a webpage is an afterthought. Tbh writing performant JS for something like this isn't fun so despite my comments to the contrary you're probably making the right choice here.

> 10k candles at 120 fps seems like you could absolutely do it in JS alone

I think so too. I think everything we have is entirely possible to achieve in JavaScript but you're spot on, writing performant JS like this isn't fun and harder to maintain.

> Don't worry I'm ok without having my eyes burned out by the lack of proper subpixel AA on your fonts. :P

Fair fair. It is definitely happening, more noticeable in certain situations. :)

> Before WASM you could already compile code from other languages into JavaScript. And have the same benefits as you have with WASM.

If you are referring to asm.js you must be joking. asm.js was basically a proof of concept and is worse in every way compared to WASM.

Like parsing time overhead alone makes it a non-option for most large applications.

You seem to imply you should just do it in plain JS instead for "deployment, execution and debugging" benefits. Imagine if you could be free to use those python ML libs in any language of your choice, that alone is enough of an argument. No one is going to reimplement them in JS (or any other environemtn) unless there is a huge ecosystem movement around it.

The days of computers doubling in speed every 2 years are loooong gone.

Look into the history of WASM. They did try compiling everything into JS with asm.js, but then sensibly decided to do things properly. I don't know why anyone would object to proper engineering.

Only because Mozilla refused to adopt PNaCL.

When computers become faster, WASM will still be twice the speed of JavaScript, because untyped languages limit the optimizations.

Bad take. Yes, you can probably optimize a lot of algos in JS such that they are pretty fast, but THAT is cumbersome. I'd much rather write the things I need to go fast in a language that's good at that (I use C for this). I'm currently working on a toolpath optimizer and I'm compiling just the optimizer function to WASM, it's a couple kilobytes and will probably be an order of magnitude faster than the JS implementation while being FAR LESS cumbersome to write. My JS doesn't change at all because i can just call the "native function" from JS, replacing my original JS impl.

    probably be an order of magnitude
    faster than the JS implementation

What makes you think so?

Off the rip because I didn't spend time to make the JS implementation keep all of it's data in a typed array that I manually manage, because it's tedious to do that in JS and it's straightforward in C. Though I'm betting there are other benefits I'll get from -O2 and static analysis.

Compiling your C to WASM might make it run twice as fast as compiling it to JS.

That's all. All other aspects of the workflow are the same.

I will try but I suspect the final score will be

    1. WASM
    2. JS handwritten for speed
    3. C compiled to JS

and the gaps will be greater than 2x

Awesome. I will notice when you reply here, no matter when. I routinely check for new replies even to old comments.

You forgot 'C compiled to the asm.js subset of Javascript', that would be on second place right after WASM (the switch from asm.js to WASM was hardly noticeable in my C/C++ code performance-wise - some browsers had special 'fast paths' for the asm.js subset though).

Javascript is incredibly well optimised, I'm surprised if there's an order of magnitude difference between JS and WASM without a fundamental difference in algorithm chosen.

I will likely spend time implementing my solver in several different styles because this is a project I'm tackling largely to make some points about how I think WASM should be used. I'm far from final benchmarks on this but my suspicion is that the gap will be large.

Yes javascript is very well optimized, but as someone who's spent a lot of time writing javascript where speed matters, it's not easy, and it's not predictable. You're at the mercy of arcane optimizations in V8 which might not work for your specific situation because you did something weird, and if you're taking a lot of care not to do anything weird, and manually managing your memory with typed arrays, well, then you might as well write C and compile to WASM.

When it comes to GC languages they can often appear very fast for use cases that don't use a lot of memory.

If you use an algorithm that near exhausts memory, that's where you'll start seeing that "order of magnitude" difference between JS and something like C++. The same goes for Java and C#.

At low memory utilization, the GC can just put off collection, which saves execution time, so the runtime appears fast. But if you're close to the limit, then the GC has no choice but to pause often before continuing. Not very many algorithms will encounter this, but applications might, depending on what they do.

It's difficult or impossible to compile many languages into JavaScript. WASM is more general.

Theoretically or because of the tooling landscape?

Do you have a source for this?

asm.js (the spiritual precursor to WASM) worked pretty much the same, and an awful lot of languages were compiled to it.

WASM does provide a more predictable compilation target to be sure, but I don't think it actually opens any new possibilities re what languages can be compiled.

Multithreading and 64-bit integers come to mind as creating difficulty, and I imagine "raw" memory buffer access having much higher latency to the point where it's completely impractical. For example, a quick search gave me this library [1] that compiles FFMpeg into Asm.js but the author says it is almost a factor 10 slower. Asm.js would also become extremely verbose for any larger code base (imagine compiling a AAA PC game to Asm.js).

It may be as you say that there are no new theoretical possibilities being opened by WASM, but to me it is a natural step forward to resolve inefficiencies and ergonomic problems in ASM.js and make it all less painful. And hopefully WASM won't be frozen in time either - the platform needs to keep improving to make more use-case scenarios practical.

[1] https://github.com/Kagami/webm.js/

> WASM is much more cumbersome to handle than plain JS when it comes to deployment, execution and debugging.

For some of us it's much easier than dealing with Javascript though (for instance debugging C/C++ in Visual Studio is much nicer than debugging JS in Chrome - and that's possible by simply building for a native target, and then just cross-compile to WASM - but even the WASM debugging situation has improved dramatically with https://marketplace.visualstudio.com/items?itemName=ms-vscod...)

You’re assuming a lot of things in this comment, it seems like you believe every software engineer is working with the same constraints, language and platform as yourself.

No. I say we could build the same dev experience to non-js coders by offering them compile-2-js tools instead of compile-2-wasm tools.

Not really because then you need a JS environment everywhere you want to run your code. If I write a Rust module I have the possibility to compile to WASM or machine code. This is what I meant in my other comment, your assumption is everyone is making browser apps in Javascript that don't have any performance or resource constraints.

    possibility to compile to WASM or machine code

How is this better than "possibility to compile to JS or machine code"?

There are significantly more (and more varied) wasm runtimes than js runtimes.

You can probably optimize JS to run as fast in most cases.

What actually WASM brings is predictable performance.

If you're JS wizard, you can shuffle code around, using obscure tricks to make current browser to run it really fast. The problem is: JS wizards are rare and tomorrow browser might actually run the same code much slower if some particular optimization changed.

WASM performance is pretty obvious and won't change significantly across versions. And you don't need to be wizard, you just need to know C and write good enough code, plenty of people can do that. Clang will do the rest.

I agree that using WASM instead of JS without reasons probably is not very wise. But people will abuse everything and sometimes it works out, so who knows... The whole modern web was born as abuse of simple language made to blink the text.

Reply on news.ycombinator.com