Hacker News Reader

Comment by klodolph | Hacker News Reader

There is currently no path for any of that. No rendering without a DOM, and no opening WASM files by themselves. The same is true for JavaScript... if you open a JavaScript file, you just see the source code.

Of course, why not just use a small HTML+JS shim for your WASM?

View on HN

Because it slows things down by 3 or 4 orders of magnitude?

Because there is value in ditching legacy cruft.

That’s a short-term view. There’s going to be legacy cruft either way. Either we have the existing HTML + JS with WASM alongside it, or we introduce a ton of new APIs to let WASM function by itself.

Using the existing HTML + JS avoids creating as much future legacy cruft.

You still capture the vast majority of that value by having a minimal “legacy cruft” loader that sets up, and passes control to, the modern toolchain

HTML isn't legacy cruft, it's an essential part of the web that will never go away. If you want to ship an app with no HTML, then use a different platform.

This is a generic argument that can be used against any sort of proposed improvement. “If you don’t like the status quo, use something else”. It also comes off as defensive; I’m not sure if that’s what you intended or not.

I don't think WASM is proposed as an improvement over either HTML or JS. It's proposed as an addition that fills out certain shortcomings for particular niches. WASM is not (currently) envisioned as the "new" way to write for the web, but as a handy capability to reach for if you need it.

I don't think anyone is suggesting that WASM is the new way to write for the web, but I think it's certainly an aspiration that WASM will allow more languages to be used for everyday web development in addition to solving other more niche problems.

It has not been my perception that that's an aspiration or a goal of WASM, but there's much I haven't read. Can you point me to where this is stated as one of WASM's goals?

https://webassembly.org/docs/high-level-goals/

> 3. Design to execute within and integrate well with the existing Web platform:

> * execute in the same semantic universe as JavaScript

> * access browser functionality through the same Web APIs that are accessible to JavaScript

Lawyering aside, I would say that this is pretty much the same thing as "enabling the development in web apps in other languages".

If you don't want cruft, don't make a browser-based app?

Reply on news.ycombinator.com