Hacker News Reader

Comment by gspr | Hacker News Reader

I wanted to love it. As someone who hasn't done any web stuff since I was a child, I thought it'd amazing for it to be "just another platform".

I'm a bit disappointed though:

* There's still no way to do DOM manipulation. So then it's tempting to just grab a canvas and draw everything yourself, which of course wreaks on things like accessibility. I'm no fan of the web, but at least it comes with a somewhat agreed-upon way to display graphical stuff – it's a bit of a shame if we're all gonna just treat it like a surface for pixels.

* WASI still leaves something to be desired. Why can't I have raw sockets and file access and stuff, in a POSIX-like way? I understand that sandboxing is important, so this can all be on a per-request-basis, but still. This "just another platform" is still too far from just that.

* The amount of JS glue needed to actually load WASM stuff in the browser is annoying. The idea of needing a bunch of magic "bundlers" is sad.

View on HN

Using WASM to make cross-platform code run in browsers isn't any more weird/esoteric than targeting Android via the Android NDK. The least painful way is to do some things in the 'native' platform language (e.g. Javascript or Java/Kotlin). Emscripten's FFI features for calling out into Javascript code snippets (even JS snippets that are directly embedded in C/C++ source files) is actually really nice, much better than any other FFI solution I've seen so far (and light years ahead of anything offered by the Android NDK).

In the end the web is just another platform, but a platform that is quite a bit different from the UNIX/Windows duopoly we're used to.

You can call JS in which you can manipulate the DOM.

Of course architecturally (also regarding your file access) it's better to use the wasm for logic as much as possible where the web (HTML/JS) provides the UI and IO, data flows into wasm for work and results flow back to the web.

This also has the benefit that you can keep your original C/C++ source code much more platform agnostic which helps reusability and testing.

> You can call JS in which you can manipulate the DOM.

Well sure. But for me, the promise of WASM was to make the browser "just another platform". Now it's "this special platform where you have to access some of the most important functionality through FFI interop with a very high-level, very opinionated language".

> Of course architecturally (also regarding your file access) it's better to use the wasm for logic as much as possible where the web (HTML/JS) provides the UI and IO, data flows into wasm for work and results flow back to the web.

OK, but like, I wanted the browser to be "just another platform". I don't want to use JS, and I consider HTML orthogonal to my logic. I realize that's not where we're at, but that's what I dreamt of. Hence my disappointment. Which is OK, I don't matter :)

> This also has the benefit that you can keep your original C/C++ source code much more platform agnostic which helps reusability and testing.

It feels the opposite to me.

JS in the web context is what C or assembly is in the native context: something you have to use, because it's the foundation the platform is built on, and every language needs a way to interact with it, and good languages support it inline when you need it.

Hmm well I guess I don't quite get what counts as "just another platform." Surely every platform is going to have the native APIs that you need to abstract over. Why is WASM different?

Is it just a matter of WASM being too new to have full featured wrappers and APIs for your language of choice?

Yeah it's like how if you want a cross-platform UI in C, you kinda need to use something like SDL that abstracts away the platform specifics. Even then might be hard for everything to work.

Web is "just another platform" with its own specifics, and the advantage is multiple OSes can run that platform pretty much the same way.

Trying wasm is still on my todo list, but this sounds like how I'd expect it to work

If enough people adopt identical or similar js glue then they can use that for a new standard. If people dont care about a standard interface then why both creaing a new standard? Look what happened with jquery selectors and ajax. People loved it and it became the new standard built into browsers.

FWIW, the various Rust react-like libraries (Yew, Dioxus, Leptos) are all reasonably fast for many/most applications. Even if the DOM goes through a JS interpreted layer.

Something akin to raw sockets over a host interface (or WSS bridge) could be cool... similar for sandboxed FS access, which browsers are starting to improve upon.

Yes, fully WASI/WASM would be nicer than some of the JS glue... but it's still useful all the same.

> WASI still leaves something to be desired. Why can't I have raw sockets and file access and stuff, in a POSIX-like way?

FWIW, that's exactly what they shipped first, with WASI preview 1 (wasip1). You can still use this today, and all runtimes with any level of WASI support will be able to run it.

Wasip1 did not specify sockets. Some implementations have made non-standard additions to add them, but sockets were not added to the standard until wasip2.

Sockets are officially specified in wasip1: https://wasi.dev/releases/wasi-p1

Notably, listen and connect are missing. But sockets themselves were in there.

There's no way to draw on a canvas in WASM either. You just decided to write JS wrapper functions for that. But you didn't write wrapper functions for DOM manipulation.

You're right. But at least the JS wrapper for the canvas is just used for setting up the shared memory, if I remember correctly?

At any rate: this doubly makes my point.

Reply on news.ycombinator.com