[deleted]
WASM 3.0 Completed
481–490 of 520 posts
Re: WASM 3.0 Completed
#482Anyone know a language that compiles to WASM v3?
Re: WASM 3.0 Completed
#483Earlier 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…
> ... document browser ... document reader ... I'm going to assume you're being sincere. But even the crustiest among us can recognize that the modern purpose for web browsers is not (merely) documents. Chances are, many folks on HN in the last month have booked tickets for a flight or bought a home or a car or watched a cat video using the "document browser". > If we think we need a more thoroughly virtualized machi…
While web apps make sense, those are pretty weak examples. Booking and buying are pretty document-based and need to run little to zero external code. The cat video isn't technically a document but upgrading a photo to a video is not a very big change and doesn't require any external code at all.
Re: WASM 3.0 Completed
#484Earlier quoted context omitted.
Why not just do the whole DOM out of your WASM?
If you're at that point, the logical step would be to just support replying to the HTTP request with a "content-type: application/wasm" and skip the initial html step entirely.
I'm on this team 100%. It makes a lot of sense for a lot of use cases (where SEO doesn't matter).
Re: WASM 3.0 Completed
#485Earlier quoted context omitted.
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…
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
Re: WASM 3.0 Completed
#486When 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?
Basically never, because it would require re-standardizing the DOM with a lower-level API. That would take years, and no major browser implementor is interested in starting down that road. https://danfabulich.medium.com/webassembly-wont-get-direct-d... Killing JavaScript was never the point of WASM. WASM is for CPU-intensive pure functions, like video decoding. Some people wrongly thought that WASM was trying to kill…
It's really not that hard. Node.js has a very mature C FFI for interacting with JavaScript.
Just agree on some basic bindings
wasb_create_u32(env: *const env, value: u32, result *mut value) -> status
wasb_create_string_utf8(env: *const env, str: *const c_char, length: i32, result: *mut value) -> status
Heck, just include that in the browser so it doesn't need to be loaded at runtime
Stack that with support in the browser for wasi and you have everything you need to work with the DOM from wasm as well as things like threading
Re: WASM 3.0 Completed
#487Earlier quoted context omitted.
You can write Wasm bindings to the native UI toolkit of your choice and render with that. It doesn’t have to be in the DOM.
You understand why that is exactly pointless… I could write those exact same bindings for my language that I will compile to wasm and then use the current WASI interface, but even that is pointless because at that point I have written a native app, what good reason would I need to run it through an emulator, specifically when a modern OS is already sandboxing things. If I am targeting the browser my above point stand…
> what good reason would I need to run it through an emulator, specifically when a modern OS is already sandboxing things.
One good reason would be that “Which OS specifically?” is a question with at least 4-5 mainstream answers (and even more not-so-mainstream answers). That's what motivated the push from WWW-as-a-bunch-of-interconnected-documents to WWW-as-a-bunch-of-remote-hosted-apps in the first place: to be able to develop and deliver applications without having to worry quite so much about the client platform.
WASM is in this regard analogous to the olden days of Java/Silverlight/Flash, with many of the same tradeoffs (and some of the rough edges filed down due to lessons learned around browser integration and toolchains and such).
Re: WASM 3.0 Completed
#488Earlier quoted context omitted.
> booked tickets for a flight or bought a home or a car or watched a cat video Would you install a native app to book a flight? One for each company? Download updates for them every now and then, uninstall them when you run out of disk space etc I can ask the same question about every other activity we do in these non-native apps.
You're doing all these things with web apps also, it's just that the browser orchestrates it for you. But for some reason this takes 20M lines of code, which creates a moat that prevents browser competition.
Any sufficiently-capable graphical application runtime* contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a web browser.
(* including every web browser)
Re: WASM 3.0 Completed
#489Earlier quoted context omitted.
That's literally ChromeOS now, it comes with a terminal built in and you can run any Linux apps
Without doing too much fancy stuff can I just run Zed or JetBrains IDEs?
Back when I tried to daily-drive a Chromebook Pixel it was, like, one flag in the settings app to enable Crostini and run whatever (GNU/)Linux program my heart desired, and that was many years ago; can't imagine it's gotten any harder (especially now that even Android is starting to offer similarly-turnkey Linux app support through the newfangled Terminal app).
Re: WASM 3.0 Completed
#490Earlier quoted context omitted.
You understand why that is exactly pointless… I could write those exact same bindings for my language that I will compile to wasm and then use the current WASI interface, but even that is pointless because at that point I have written a native app, what good reason would I need to run it through an emulator, specifically when a modern OS is already sandboxing things. If I am targeting the browser my above point stand…
> what good reason would I need to run it through an emulator, specifically when a modern OS is already sandboxing things. One good reason would be that “Which OS specifically?” is a question with at least 4-5 mainstream answers (and even more not-so-mainstream answers). That's what motivated the push from WWW-as-a-bunch-of-interconnected-documents to WWW-as-a-bunch-of-remote-hosted-apps in the first place: to be abl…
The discussion here was building bindings for the OS layer, which means to explicitlY worry about the client platform.
When using the web I have my own issues with that platform, or more specifically using wasm in it since it is literally useless for building web based applications over JS/TS. It is being targeted more as a library platform which gets called into from JS than being an actual “assembly “ language.