Hacker News Reader

Comment by arcadialeak | Hacker News Reader

I love how WASM is the thing that finally blurred the line between Web and Native programming, formely two realms isolated from each other for a long time. This both develops better awareness of how the code is executed by the hardware, which JavaScript devs often lack, and also brings skilled folks from the Native platforms who seem to be not so against WASM as they were against JavaScript (and all other parts of the Web, really). Maybe this will bear fruit in that people will make more Native user interfaces again.

View on HN

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.

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.

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.

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.

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.

ActiveX, Alchemy, PNaCL,...

Besides ActiveX, old (<9) Internet Explorer supported VML (Vector Markup Language), which was neither supported by anything else, nor widespread. It could be made dynamic with the help of JavaScript, and the only dynamic example I could remember was an analog clock.

JVM, Z-Machine, P-Code.

Woz's own Sweet 16 Dream Machine on the Integer Basic ROMS of the Apple II! ;)

https://en.wikipedia.org/wiki/SWEET16

https://techwithdave.davevw.com/2024/05/running-sweet-16-ste...

I remember Java applets; when did z-machine and p-code make it to the browser?

Everything made it to the browser through emulation.

UCSD Pascal:

https://archive.org/details/UCSD_Pascal_1.1_1

Wizardry:

https://archive.org/details/WizardryProvingGrounds

Saying ActiveX here shows a fundamental misunderstanding of what both WASM and ActiveX are.

Is ActiveX platform independent? No. it's exclusive to windows. Is it sandboxed? Nope, digital signing and prayer, does it implement a virtual machine? Nope. Compromises out the wazoo? efficiency, data orientation, or predictable performance? You betcha. ActiveX is closer to a DOM sandbox escape exploit than a real piece of engineering. Why do we need WASM when we've have GET since 1990?

Don't confuse the map for the territory, implementation details matter, just labeling something "Mars Colonial Transporter" doesn't mean it actually flew to mars.

What is a fundamental misunderstanding is selling WebAssembly as the first time bleeding Web and native code has been achieved.

All those "look Python on the browser!" were already done by ActiveState with Perl, Python and Tcl.

Wasm still doesn't let you make native user interfaces, the UI is in the web browser. You can put native UI components into a React Native or Electron app though.

> Wasm still doesn't let you make native user interfaces

That's currently only not possible because nobody wants to do the work to create something like wasi-gfx (https://wasi-gfx.dev/), but for native UI frameworks instead of 3D APIs.

The inconvenient truth is that even "native" cross-platform applications hardly ever go through the trouble to target the platform-native UI framework (and instead they go through non-native frameworks like Qt or a webview wrapper).

For that matter, there's so much diversity in actual rendering anymore, very few apps on any platform are really native feeling. Especially with a few electron apps in the mix.

Would be cool to get some standardization on at least a few APIs for default fonts, light/dark mode, background and accent colors, etc... so that apps are a little less alien in practice. I'm really not even the idea of Tauri or similar to use a native browser engine, but better skinning APIs so you can get something like Material, but tuned to better match the desktop you're on.

For that matter, a wasi component package would be nice as well. Harder for accessibility though.

I meant, in-browser wasm can't do native things like creating a blank non-browser window on my Mac like a Swift app could, no matter what libraries it uses.

Reply on news.ycombinator.com