Hacker News new | ask | show | jobs
by hackerfromthefu 3155 days ago
Perhaps WASM will provide the better match for business applications, sidestepping HTML entirely.

It should allow side-stepping the complex morass of piecemeal evolved html features and implementation border case incompatibilities.

e.g. Today you can use Unity game engine to target WASM as a runtime and it should render, and function, very much identically across all browsers, and with a bit of creativity can be used to include forms and business functionality.

This does come at the cost of downloading the app runtime and UI libraries with the app, but frankly the download size is not such an issue anymore and in the future for many markets. e.g. 5G mobile broadband is targeting Gbit speeds!

1 comments

I know people put high hopes into it, but WASM by itself does exactly nothing to improve the basic rendering model of browsers (CSS and it's various layout models). It just replaces JavaScript (which I have no problem with at all), making browsers even more complex. WebGL, OTOH, can be used from JavaScript without problems, including typed arrays and SIMD.

I was thinking more about ditching the browser entirely for apps. Because what WASM and WebGL do is just a very tiny subset of what's been possible for ages with plain old native languages and D3D/OGL. And why do we need a new bytecode format when basically all phones run on the ARM ISA? I guess I don't get why games should run in a web browser with all it's security and privacy issues.

But yeah, almost anything is better than HTML/CSS/JS for complex UIs.

Since you stressed the point that WASM does nothing to improve the rendering model, it's worth noting I never wrote that it did.. but about replacing the UI with custom libraries (rendering to canvas), hence why I used Unity as an example, then mention the need to download UI libraries.

This is the only approach supported by WASM in the near future, although a browser DOM bridge is roadmapped for a couple of years on. ie ditching the (DOM of the) browser entirely for apps (in WASM) - apps that can run on ANY platform with a modern browser.

>> And why do we need a new bytecode format when basically all phones run on the ARM ISA?

There are in fact some good reasons

* It's an open standard, which it seems many vendors will get behind and it will become ubiquitously available, and as such stands a chance of competing with Html/JS for the crown of the 'everywhere platform'.

* Being sandboxed by the browser instead of running on bare metal has huge value for security.

* Being sandboxed as an abstraction layer allows ISA portability. You mention most phones run on ARM, but more than a handful of people want to use PCs running Intel too! Also not all phones run ARM, and there are future ISAs that don't exist or aren't mainstream yet (such as open source ones) and the abstraction of a runtime makes it easy. WASM has been design to be good as a portable target (ie easy to implement on a new ISA as opposed to writing full emulation).

The first one is the most important one, about being an open standard with enough industry implementation to achieve critical mass for users and become a sustainable 'any/everywhere' platform .. the technical issues could be addressed other ways, but that only matters if people can access your runtime (which is what killed Flash and Silverlight).

There are downsides too, such as performance, however the market has shown it doesn't really care about performance by choosing the bloated Javascript mess have today.

tl;dr; Runtimes are good for the majority of consumer and business software, and WASM is the first one all the big players are supporting instead of the competition sabotaging

>> I guess I don't get why games should run in a web browser with all it's security and privacy issues.

The question implies that native code has a better security and privacy profile than a hardened browser sandbox.. actually that right there is the issue. You actually get a far better security and privacy 'platform' on the browser, despite/because of the much larger attack volume.

With native you can do and access anything the OS allows, and find vulnerabilities in the entire OS APIs. Even on e.g. iOS the native code can do all sorts of things and call private hidden apis etc, Apple just tries to use static analysis to attempt to find these issues before you download it..