← Back to context

Comment by gspr

9 hours ago

> 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.