Hacker News Reader

Comment by matthberg | Hacker News Reader

The parallels with the Destroy All Software talk "The Birth and Death of Javascript" [0] are crazy. Seeing the section where they address the possibility of Node modules and system access from WASM is like seeing a flying car advertisement in real life.

[0]:https://www.destroyallsoftware.com/talks/the-birth-and-death...

View on HN

Re: like seeing a flying car advertisement

Ditto the feeling. I don't "get" WASM from a typical in-house CRUD development. Game makers, maps, movie editors; sure they need the speed. But some say it's gonna revolutionize most browser-based application dev, but I can't get specific examples that are relevant to us. And even for those domains listed, relying on inconsistent and buggy DOM as found in browser variations is a problem it probably won't solve. DOM will still suck as a general purpose UI engine.

WASM just makes DOM bugs run faster.

The DOM isn't particularly "buggy", relative to, say, Win32 or Cocoa. It may or may not be a bad API, but implementations are pretty solid.

(I have to confess I've never understood the objections to the DOM. I have literally never had an instance in which I had to use the raw Win32 API that didn't turn into a miserable experience.)

With Win32 and Cocoa you pretty much have one vendor with roughly 3 or so major releases. But with browsers you have roughly 8 vendors above 1% market-share with 3 or so (notable) major releases each. Therefore, you have to target roughly 8x more variations of the UI engine.

Look how hard Wine's job is to be sufficiently compatible.

I believe we need to either simplify the front-end standards (pushing as much as possible to the server), or fork browsers into specialities: games, media, CRUD, documents, etc. What we have now sucks bigly. Try something different, please!

Interoperability, and the standards process, is how we get specs that are sensible. Whenever I have to program using Win32, Cocoa, etc. I inevitably spend a ton of time reverse engineering how the proprietary APIs work. For DOM APIs, things generally work how they are supposed to work, because they were actually designed in the first place (well, the more recent APIs were).

Wine isn't comparable, because the Web APIs are designed by an open vendor-neutral standards committee and have multiple interoperable open-source implementations.

Your proposals break Web compatibility and so are non-starters. Coming up with fixes for problems in the DOM and CSS is the easy part. Figuring out how to deploy them is what's difficult.

Re: "the standards process, is how we get specs that are sensible." - They are not sensible: different vendors interpret the grey areas differently. A sufficiently thorough written standard would be longer and harder-to-read than the code itself to implement such.

Re: "Your proposals break Web compatibility" -- Web compatibility is whatever we make it. A one-size-fits-all UI/render standard has proven a mess. What's the harm in at least trying domain-specific standards? We all have theories, but only the real world can really test such theories.

Between WASM and modern graphics APIs, we might be able to actually kill DOM altogether. Something like this:

http://blog.qt.io/blog/2018/05/22/qt-for-webassembly/

Let's not do that until we have a way to make non-DOM-based web applications accessible to screen readers and other assistive technologies.

Meta-data can be embedded to describe and categorize content. But accessibility is usually not a goal for many "office productivity" applications (per my domain-specific standards suggestion). Usage of DOM alone does not guarantee accessibility either.

As far as Qt, while it may be a good starting point, I don't think direct C++ calls is practical. Some intermediate markup or declarative language should be formed around it: a declarative wrapper around Qt.

> accessibility is usually not a goal for many "office productivity" applications

I think I might be misunderstanding you. Are you saying accessibility is usually not a goal for the kind of applications that people need to be able to use to do their jobs?

I believe there's a reasonable limit to how adaptable workplace software has to be to those with poor vision, etc.

> Some intermediate markup or declarative language should be formed around it: a declarative wrapper around Qt.

QML is exactly that.

Reply on news.ycombinator.com