131–140 of 251 posts
> “near-native performance”. What this actually means is that WebAssembly is almost always faster than JavaScript
Nice try! That is not how I look at it.
Reading the article, I felt like I was back in 1996 reading about the Java bytecode compiler and the JVM plugin for the browser. Java had such great promise for web page-hosted code, that would be portable, performant, and safe. Why would one think WebAssembly will succeed where Java failed? (Well, Java did not exactly fail, but its purpose and typical usage radically changed over the years.)
Webassembly is a small stack machine based on an open standard.
It is built bottom up, with a very small core. Additional features like SIMD, garbage collection,posix style system interfaces (WASI), linking, garbage collection,... are built as optional extensions based on real world feedback.
There already are a multitude of different implementations. (the three browsers, the Wasm3 interpreter, wasmtime, Wasmer, ... )
Java, in contrast, was and is a huge runtime , not based on a standard, and has extremely complex semantics, many of them tied to a single language model.
Wasm is already seeing adoption across a wide range of domains.
I do believe the potential for WASM to succeed where Java failed is wide open.
Earlier quoted context omitted.
Java failed because - it depended on an installation outside the browser, poorly versioned - and a plugin too, which was extra noise for the user, and not nearly so pain-free as Flash's was - it was not , under any circumstances, performant (this was before HotSpot) - AWT was truly, thoroughly, god awful (this was before Swing) Finally, it was caught between two realms. Clunkier than JS and more difficult to work wit…
>- it was not, under any circumstances, performant It was performant enough for one of the most popular games of all time, Minecraft, which was originally a game in a Java applet.
There are two versions of Minecraft now.
The main reason Minecraft Java is still alive is the hackability and the resulting extensive mod ecosystem.
Another random reason webassembly is really cool is that it let's you run ML models way faster after page load than through the GPU (which can take a ton of time to load all the buffers into VRAM).
I am surprised there is no isolation schema for binaries. WASM may look lite and fast compared to Docker, but its still painfully slow compared to AVX or Neon enabled assembly. We went from VMs to Containers. From Containers to WASM. Now, I guess, we just need to learn how to properly isolate simple binaries.
> [WASM is] still painfully slow compared to AVX or Neon enabled assembly. There's an open proposal to add SIMD intrinsics to WASM. https://github.com/WebAssembly/proposals/issues/1
https://github.com/WebAssembly/proposals/blob/main/finished-...
Reading the article, I felt like I was back in 1996 reading about the Java bytecode compiler and the JVM plugin for the browser. Java had such great promise for web page-hosted code, that would be portable, performant, and safe. Why would one think WebAssembly will succeed where Java failed? (Well, Java did not exactly fail, but its purpose and typical usage radically changed over the years.)
There are fundamental differences here. Webassembly is a small stack machine based on an open standard. It is built bottom up, with a very small core. Additional features like SIMD, garbage collection,posix style system interfaces (WASI), linking, garbage collection,... are built as optional extensions based on real world feedback. There already are a multitude of different implementations. (the three browsers, the W…
My single use for docker is to containerize / isolate, not to run across architectures.
I get the in-browser optimized / compiled code. That makes sense.
Earlier quoted context omitted.
I have low faith in the current WebAssembly GC proposal. It's been such a daunting task that they've started talking about "mini-mini MVPs". The GC proposal does not do what most people think it does, the current draft is basically impossible for most languages to target, and even contributors are finding it difficult to reach consensus [0]. It might be a while before it becomes useful. [0] https://github.com/WebAsse…
This is the most concerning thing I have about the web in general. It feels like nothing is getting done because everyone is fighting with everyone else about everything. I feel like WASM has just sort of rotted. It feels like so many advancements from threads to GC have been stuck in committee for years now. I feel the same way about WebGPU. Just doesn't feel like anything is getting done when it comes to new comput…
I've been noticing this for years too and I've concluded that a significant driver is the fact that certain major corporations (eg Apple, Google, MSFT) who sit on central web standards committees feel their app store and operating system businesses would be threatened if the full potential of Web Assembly gets in standards, implemented and widely deployed.
Perhaps everything always bogging down in a way that delays or precludes fully unleashing these disruptive capabilities may not be entirely accidental. To be clear, I'm not asserting there's an intentional, pre-mediated conspiracy afoot. It's always a possibility, of course, but it's also possible that the various stakeholder business units inside these corporations are themselves conflicted, causing internal battles leading to confusion, delay and mixed signals on standards bodies. Sadly, that can end up having very much the same net effect as intentional sabotage.
Earlier quoted context omitted.
There are fundamental differences here. Webassembly is a small stack machine based on an open standard. It is built bottom up, with a very small core. Additional features like SIMD, garbage collection,posix style system interfaces (WASI), linking, garbage collection,... are built as optional extensions based on real world feedback. There already are a multitude of different implementations. (the three browsers, the W…
So, honest question. if we're compiling our code to run on servers, why are we compiling it to run on a bytecode interpreter rather than native? My single use for docker is to containerize / isolate, not to run across architectures. I get the in-browser optimized / compiled code. That makes sense.
A few benefits why it is even useful in a server context:
You can distribute a single (small!) artifact and run it everywhere. On a developer machine, on Windows, on a x86 server, on an ARM server, ... Right now you have to build a separate Docker image for each architecture. And Docker is really a second class citizen on Windows.
Docker images have a huge dependency: an entire operating system syscall API and an entire userspace (with libraries, binaries, a file system, ...) The surface for a Wasm module is much smaller.
Building a Docker image is a somewhat redundant exercise of picking a base image, figuring out the dependencies, keeping it up to date, ... None of that should be necessary.
Security is another benefit. The vulnerability exposure of a Wasm module is much lower than that of an entire OS + userspace sandbox.
Wasm is designed around isolation. In addition, the interface types proposal + WASI is pushing capability based security that works by passing around capabilities, which is a pretty great model.
I outlined some more benefits here a few days ago: https://news.ycombinator.com/item?id=30020121&p=2#30020964
This article mentions inflection points, but doesn’t delve into clientside apps significantly (e.g. SPAs). How far away are we from transitioning from component based JavaScript frameworks like react, to something which compiles to wasm?
Agree with sibling comment - the JS ecosystem has a huge momentum behind it and probably isn't going away anytime soon. On the web, Wasm has currently found the most success with compute-intensive applications, since the JS Wasm bridge is still pretty expensive. There are already some Wasm-based frameworks like https://platform.uno/ that work on the web, but things like React/React-native and Flutter have a huge head…