4 ms·

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 submis

• troupo 3y ago
  > 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 https://github.com/mozilla/standards-positions/issues/459
  • rapnie 3y ago
    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.
  • mike_hearn 3y ago
    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.
    • troupo 3y ago
      > 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-nuance.html 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 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.