[1] https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
What they did was cutting it to 30% or by 70%.
newLoadTime = oldLoadTime - (70% of oldLoadTime)
newLoadTime = oldLoadTime / 3
Personally I find the additive expression unintuitive and find the multiplicative expression easier to reason about. "cut by" does generally indicate an additive expression. It should really have been phrased as something like "reduced by a factor of 3"
Factor, noun "a number or quantity that when multiplied with another produces a given number or expression."
It's not an exact integer factor, but I think the concept of factor is more general than that.
That would imply the phrase has to be "reduced by a factor of 1/3", which leads to the wrong impression. The better technically correct phrase would be "reduced by a divisor of 3"
More seriously, one of the main draws is being able to us the same language on both the front and back end, which might be beneficial to reduce the need to duplicate model or just to be able to develop on the front end in ones preferred language.
Personally, it allows me to write tools that can run either on the command line or in the browser. Only the user-interface need be rewritten - internally both versions can share a lot of code.
WebAssembly makes it possible to do this using a language other than JavaScript. However, the languages I can use are still limited - AFAIK WebAssembly is currently only well-supported by C, C++ and Rust.
I think the core use case is "Being something that's not Javascript".
The desktop programming world gets benefit from having multiple languages that suit different use-cases, so why would the web not?
e.g you can develop parser in console application and then ship it to the browser and use it there to parse e.g code without changing a single line of code or having to do some bullshit or traspiling it to js.
Once it matures it will allow you to get rid of writing javascript and use java, c#, rust, c++ and many other to write frontend.
There is no access to the DOM and the POSIX-like WASI interface is limited so the main use case is reusing code with manual memory management (C, Rust, etc).
WebAssembly also targets server-side JavaScript runtimes like Node, Deno, and Cloudflare Workers.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
JS doesn't have integers; all numbers are represented as doubles. One of the reasons having actual integers is important is performance, as integer operations are often faster than floating point operations. BigInt doesn't help with that.
I have a web app where every time there is an error on the client side it sends it back to the server. On normal JS it locks up the browser for 10+ seconds. In WASM it's instant.
Never found another use except for this.
Weird, I think I do the same thing (global exception catcher) and it works fine
TL;DR: - "almost fast as native code for web browsers” - in case you wanna do some expensive computing without a server - "Compiling Existing Applications for the Browser" - port existing code into the browser (eg cpp apps)
Forgive my ignorance (I haven't done front end web dev in almost a decade), but what is the use case for WebAssembly? What does it enable websites to do that (1) needs to be done within browsers and (2) can't be done with JS?
Also, are there any prominent websites that use WebAssembly? It's shipped with all browsers, but what percentage of users ever make use of it?