Live data from Hacker News

WASM 3.0 Completed

webassembly.org

491–500 of 520 posts

Re: WASM 3.0 Completed

#491
post #465

Earlier quoted context omitted.

Yep, think different.

I don't know if you are serious or just trying to evade the discussion. Two questions: 1) What is the primary OS for your desktop ? 2) Would you sincerely make the argument that a world where everyone submits to a single design (Apple-style) would be better than an "organic" world where the barrier of entry is lower, but less "optimal"?

1) Windows or macOS, depending on the project or customer provided hardware

2) Yep, the Year of Linux Desktop already happened, it is a VM hosted on 1)

Re: WASM 3.0 Completed

#492

Earlier quoted context omitted.

Plenty of people still want local-first apps that function offline.

Totally possible today with modern SPA technology that all major browsers support

You mean the convoluted enginnering exercise of service workers, in-browser proxies, and in-browser databases to simulate something native platforms don't need to care about?

Re: WASM 3.0 Completed

#494

Earlier quoted context omitted.

I guess I’m just a crusty ol’ greybeard C++ developer, but it seems like a video editor is out of place in a document browser. There’s a perfectly good native operating system that nobody uses any more. If we think we need a more thoroughly virtualized machine than traditional operating system processes give us (which I think is obvious), then we should be honest and build a virtualization abstraction that is actuall…

There is no difference between a "document" and an "app". There has never been a difference between the two, it's a purely artificial distinction. Word and LibreOffice "documents" can run embedded macros. Emacs has `org-mode`, which can call out to any programming language on your $PATH. A PDF document is produced by running code in a stack-based virtual machine. Even fonts have bytecode instructions embedded inside…

> There is no difference between a "document" and an "app". There has never been a difference between the two, it's a purely artificial distinction.

Every distinction is artificial if you are willing to hair-split. No useful conclusion follows from this realization.

Re: WASM 3.0 Completed

#495
post #388

Earlier quoted context omitted.

You can do all of this using Rust today. Very sane access to multi-threading => writing rust code that runs in parallel and is compiled without you worrying about it to run under several web workers

That still requires a bunch of glue code right? Like, I can't simply compile my application to a wasm target and threads just work cargo build --release --target wasm64 I think wasi has access to threading, but I don't think browsers support wasi?

Yes there is some glue needed. The amount of boilerplate needed can be reduced with a bundler or depending on the library you use (just like it is the case when you use workers with JavaScript on the web, you can use a bundler with support for them or plugins to make it less of a pain to setup). wasm bindgen rayon provide support to use rayon in that context. There are also projects that provide lower level apis similar to std::thread. Std::thread will probably never support the wasm target.

It’s not WASI that gives you access to threading. Multi threading is a WebAssembly spec feature. Each thread is a separate web assembly module, they can share memory/code using SharedArrayBuffer if needed or WebAssembly tables for code. The host runtime for WASM whether it’s the web or something like wasmtime is responsible for instantiating those module in Web workers on the Web (or node…) or in new OS threads for wasmtime. I guess this is the thick amount of glue needed

Re: WASM 3.0 Completed

#497
post #491

Earlier quoted context omitted.

I don't know if you are serious or just trying to evade the discussion. Two questions: 1) What is the primary OS for your desktop ? 2) Would you sincerely make the argument that a world where everyone submits to a single design (Apple-style) would be better than an "organic" world where the barrier of entry is lower, but less "optimal"?

1) Windows or macOS, depending on the project or customer provided hardware 2) Yep, the Year of Linux Desktop already happened, it is a VM hosted on 1)

(2) reads like "to be free, first you need to submit yourself to the Overlords".

I will take the minor inconvenience of having to run web apps over the dystopia you are willing to subject yourself to in the name of "optimization", thank you very much.

Re: WASM 3.0 Completed

#499
post #180

When is WASM finally going to be able to touch the DOM? It feels like that was the whole point of WASM and instead its become a monster of its own that barely has anything to do with web anymore. When can we finally kill JavaScript?

Agreed. This and (sane) access to multi-threading. I want to be able to write a Rust application, compile to wasm and load it with Would be great for high performance web applications and for contexts like browser extensions where the memory usage and performance drain is real when multiplied over n open tabs. I'm not sure how code splitting would work in the wasm world, however. v8 could be optimized to reduce its m…

I completely agree. The WebAssembly multi-threading programming model with its reliance on the web worker API is a pain to deal with. Google’s Native Client had native threading support, why can this not be replicated in WebAssembly?
Post reply on HN