[adimitrov]

There are crucial differences between Java applets and JS.

- Applets tried to render their own GUI, Wasm doesn't and defers to the browser.

- applets needed a big, slow to start and resource hungry VM. Wasm is running in the same thread your JS is also running in, it's light, and loads faster than JS

- Java and flash were plugins, which needed to be installed and kept up to date separately. Wasm is baked into your browser's JS engine

- Wasm code is very fast and can achieve near native execution speeds. It can make use of advanced optimisations. SIMD has shipped in Chrome, and will soon in Firefox

- The wasm spec is very, very good, and really quite small. This means that implementing it is comparatively cheap, and this should make it easy to see it implemented by different vendors.

- Java was just Java. Wasm can serve as a platform for any language. See my earlier point about the spec

So it's apples and oranges. The need to have something besides JS hasn't gone away, so their use cases might be similar. The two technologies couldn't be more distinct, though.

[croes]

You must view the browser with JS and WASM as a unit.

The browser renders it's own GUI too, it's not OS native

The browser uses lots of resources too.

The browser is kind of a plugin to the OS and must be updated separately.

Java nowadays is pretty fast too.

Java VM serves a platform for multiple languages like Scala, Kotlin, Clojure.

Let's face it, the browser is the new JVM and a soon it gets the same permissions like the JVM to access the file system and such, we get the same problems.

[westurner]

From https://news.ycombinator.com/item?id=24052393 re: Starboard:

> https://developer.mozilla.org/en-US/docs/Web/Security/Subres... : "Subresource Integrity (SRI) is a security feature that enables browsers to verify that resources they fetch (for example, from a CDN) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash that a fetched resource must match."

> There's a new Native Filesystem API: "The new Native File System API allows web apps to read or save changes directly to files and folders on the user's device." https://web.dev/native-file-system/

> We'll need a way to grant specific URLs specific, limited amounts of storage.

[...]

> https://github.com/deathbeds/jyve/issues/46 :

> Would [Micromamba] and conda-forge build a WASM architecture target?

[kierangill]

> You must view the browser with JS and WASM as a unit

“Web” assembly is a bit of a misnomer. It’s an IR at the end of the day and can be run without a browser[1]. But your other points could be true one day if the de facto WASM runtime becomes bloated or decides to ship with some GUI renderer.

[1] https://github.com/bytecodealliance/wasmtime

[Dzugaru]

> a soon it gets the same permissions like the JVM to access the file system and such

Like... never?

We get better systems as we get more experience. That's why C# was better than Java, Java today is better than Java was when C# launched. That's why we now have amazing languages like Rust and also that's why the same problems will never be the same given we have a ton of experience with VMs, docker, sandboxing in browsers etc.