Comment by rapnie | Hacker News Reader

Comment by rapnie | Hacker News Reader

Ian 'Hixie' Hickson gave his view on the future of the web in January this year in a public Google doc titled "Towards a modern Web stack" [0]. On its HN submission (referencing the wrong URL, so I resubmitted [1]) he defends against criticism [2]

Quoting from the doc here's the stack:

    - WebAssembly (also known as Wasm) provides a portable compilation target for programming languages beyond JavaScript; it is being actively extended with features such as WasmGC.
    - WebGPU provides an API (to JavaScript) that exposes a modern computation and rendering pipeline.
    - Accessible Rich Internet Applications (ARIA) provides an ontology for enabling accessibility of arbitrary content.
    - WebHID provides an API (to JavaScript) that exposes the underlying input devices on the device.

    This document proposes to enable browsers to render web pages that are served not as HTML files, but as Wasm files, skipping the need for HTML, JS, and CSS parsing in the rendering of the page, by having the WebGPU, ARIA, and WebHID APIs exposed directly to Wasm.

[0] https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC...

[1] https://news.ycombinator.com/item?id=36968263

[2] https://news.ycombinator.com/item?id=34612696

> On its HN submission (referencing the wrong URL) he defends against criticism [1]

And it's a very weak defence. There are great rebuttals to whatever he writes in there.

I mean, he rants that HTML failed, and then literally proposes "By providing low-level primitives instead, applications could ship with their own implementations of high-level concepts like layout, widgets, and gestures, enabling a much richer set of interactions and custom experiences with much less effort on the part of the developer."

Has he tried to implement any of those from scratch using only low-level primitives? How is it "much less effort on the developer"?

In general it just reads like a justification for Flutter:

"This API alone is not useful for application developers, since it provides no high-level primitives. However, as with other platforms, powerful frameworks will be developed to target this set of APIs. A proof of concept already exists in Flutter"

Why not provide high-level powerful primitives out of the box? Oh, then Flutter wouldn't have a reason to exist.

---

As a side note: WebHID is a Chrome-only non-standard. They literally dumped a non-spec onto other browser vendors, shipped it to prod, and then "updated" the spec later: https://github.com/mozilla/standards-positions/issues/459

Ah, that is enlightening, thank you. I knew he works for Flutter, but I know very little about Flutter and the standards it uses. That WebHID I hadn't heard of till this doc, so figures if this is a non-standard. More Google worrying power play then, similar to the web integrity bomb under the open web.

So what are these great rebuttals? "Why not provide high-level powerful primitives out of the box?" <- the browser is a 30 year effort to do that and has always failed at it. This thread is full of people complaining that the browser implementations of even basic widgets aren't usable, of course any higher level or more complex features are often missing, and that's with web tech relying heavily on patrons that have budgets the size of the Sun.

So in practice most devs bypasses them and write their own high level primitives anyway, relying on the browser only for low level APIs. That's the point the article is making. Hixie is merely observing that this situation exists, has always existed and probably always will, so browser makers may as well embrace it. And if you see the discussion thread, that's essentially what the Chrome WebUI PM says they plan to do: just talk to the authors of React and other frameworks, ask them what they need and do that i.e. give up on HTML tags like <section> and <progress>, refocus on obscure features that make framework devs happy. And then just tell web devs to adopt a high level framework that isn't HTML.

> So what are these great rebuttals?

Those that you apparently read but didn't understand.

> the browser is a 30 year effort to do that and has always failed at it

And so the "we will not give you anything at all, implement everyting including all layouts, all widget all interoperability etc. from scratch" will work?

> browser implementations of even basic widgets aren't usable

Great article on the topic: "You can't capture the nuance of my form fields https://drewdevault.com/2021/06/27/You-cant-capture-the-nuan..."

The problem with the basic widgets is not that they are incomplete, but that they are not enough. Almost any attempt to re-build even the built-in widgets sucks and fails in numerous ways. Now Hixie wants to remove event that and pretend that building all that from scratch is "easier for developers".

> that's essentially what the Chrome WebUI PM says they plan to do: just talk to the authors of React and other frameworks, ask them what they need and do that i.e. give up on HTML tags like <section> and <progress>

Here's what that PM said, verbatim:

--- start quote ---

No one needed <section> and <aside> they needed <tabs> and <accordion>

Developers mostly don't want the assembly language of the web, they want their chosen frameworks to have excellent DX and the UX they produce to be fantastic. When we see frameworks as a core customer/partner for web APIs, things turn out a lot better.

--- end quote ---

How you read this as "give up on HTML tags" and "refocus on obscure features" is beyond me.

BTW, here's what Dan Abramov, on of the key developers of React, had to say a while back: https://dev.to/dan_abramov/comment/6kh1

--- start quote ---

React users would love to not have to npm install a date picker and bloat their bundles! If they need to "use the platform" then why doesn't that platform ship the features they actually ask for? Instead of a <carousel> they get an <aside>. Features like service workers are touted as a solution to many problems in the web, but their ergonomics are so under-designed that people actually have to change domains to bust the cache from a broken build (I’m not making this up).

--- end quote

But sure, "give up on HTML tags like <section> and <progress>, refocus on obscure features that make framework devs happy". Making the platform be only extreme primitives will definitely not make framework authors happy.

To more fully quote the Chrome PM:

You didn't solve the problems devs find challenging. Frameworks do. The existence of frameworks on the web is a feature, not a bug. Developers mostly don't want the assembly language of the web, they want their chosen frameworks to have excellent DX and the UX they produce to be fantastic.

We're shipping container queries, scope, nesting, style queries, state queries and a host of other features devs tell us they need to architect component systems

In other words, the Chrome team (today) assumes the use of frameworks as a given and sees their job as empowering frameworks. Note that "devs" here clearly refers to framework authors, the sort of people who architect component systems. She doesn't mean app devs.

So HTML as an all-inclusive app framework is going to die, arguably has already died, and the argument between Hixie and stubbornella is just an argument about what specific way to empower framework authors. Hixie argues that the focus should be on features for big frameworks that skip HTML entirely, stubbornella argues for features for smaller frameworks that still use some HTML, but they're both in agreement that raw HTML is just kind of useless and not the way devs want to go anymore. After all "state queries" is not <tabs> either. There's less between these positions that may seem.

Now the real question is not could browsers theoretically ship really great HTML widgets. Sure, there's no rocket science in GUIs, in theory, browsers could do this. Yet after 30 years of immense effort they don't do so. That suggests some deeper structural issue. It might be team scalability issue. Chrome has a truly enormous team, but clearly they're struggling to do everything people might want from a browser. All that code has to be maintained after all, so as Chrome gets bigger we should expect them to slow down. Since the death of plugins the web is a completely monolithic platform. Given a choice between implementing some API that only a browser developer can do (e.g. WebUSB) or implementing an API that devs can hack up their own alternative to (a widget), it's clear why they always choose the former. Anything that browser makers can push off to web developers they clearly will, because there's so much to do that can't be pushed off in that way. Hence why HTML is still a poor UI toolkit and why JS frameworks are so widely used. It's a division of labor issue.

Reply on news.ycombinator.com