[tannhaeuser]

Congrats to the new release! I've got a lot of respect for putting so much energy into open source projects.

Predictably, the discussion evolves around Angular vs react/vue/ember or whatever (personally, I like react).

My current customer project introduced me to a new generation of web front-end developers specializing in a particular framework (react/redux in our case) but know very little about CSS and the myriad of plumbing and polyfilling going on in browsers. In the end, they delivered an app that would only run on Chrome. Sadly, the whole thing makes me realize just how utterly inadequate the web platform after all these years still is for the kind of MVw apps folks want to use it for.

I think there's a place for a new "opinionated" web framework once again which more closely matches the needs of business apps, and which has an option to stand-alone app deployment outside web browsers. Mind you, this isn't a sentimental reflection on Java applets and their failure or some such, but based on years of actual project experience, including in front-end developer roles.

For example, the other day I learned that in 2017 there's no way to query the current zoom level of a web app (until very recently with the brand new Viewport API; but it's not supported using media queries; I mean, seriously?). Furthermore, I'm using a very simple SVG background image for a text area element, and the latest Chrome release introduced laughable aliasing bugs, which I could only workaround by using `opacity: 0.99`. There are still just so many tricks and hacks necessary for even the most basic of UI tasks that a realistic web app project feels like jumping from one ridiculous issue to another, frantically searching through StackOverflow, CSS-tricks, etc.

With the somewhat naive reception of react, Angular, and co (which don't actually do anything GUI-related, nor help with browser compatibility problems), I'm wondering whether I'm the only one feeling like putting square pegs into round holes using the web for anything other than content-driven sites.

[hackerfromthefu]

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!

[tannhaeuser]

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.

[hackerfromthefu]

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

[chrisco255]

I mean, I feel ya. The web was built for rendering PhD research papers, not the complex, rich, responsive apps we have today. Square peg, round hole for sure...but we been hacking away at the hole for sometime to get that peg in there...and today it is feasible to build these things. But you're right that if the web had conceived of being used for rich apps from the beginning we would have been spared a lot of trouble.

[Horatio9000]

Its easy to say that, but what form could it have taken? RPC? X11?

The adoption of simple REST style resources over SOAP, corba etc shows how useful the original "handle system + simple verbs" design really is.

[chrisco255]

I think, at a minimum, they would have needed support for something like HTML5 canvas. Then Flash would have never happened. HTML should probably should have been XML with a component centric model from the beginning. Modules from the start with JS. Scoped CSS...lots of things would have improved the web's position earlier...but you know, hindsight and all that.