5 ms·

The web has traditionally followed a pattern where people are left to try out new things themselves, experiment with ideas, have a competitive marketplace of li

by _bxg1 7y ago

The web has traditionally followed a pattern where people are left to try out new things themselves, experiment with ideas, have a competitive marketplace of libraries and frameworks, and then once there's a consensus the selected approach gets enshrined and implemented as a browser standard that everyone can use. This happened with DOM selection and XHR fetching (jQuery), with promises, with list comprehensions, with modules syntax (ES Modules). It's time it happened with reactive DOM rendering.

davnicwil 7y ago
I know what you mean, but I'd argue while that works for technical details with defined inputs->outputs, it doesn't really work for UI which is a much more open ended problem/solution space which the user directly interacts with. Beyond even the practical concerns with locking yourself down to certain modes of doing UI, there's also just evolving taste, trends of usage, device types etc. I just don't think UI is something you can ever call done.
- akiselev 7y ago
  I don't think what the GP is describing would restrict anyone from innovating in the UI space. What we need is a standard API for framework+component life cycles, tracing - i.e. a currentComponent api for tracking the relationship between JS scopes and DOM elements, and context/slot apis powerful enough to bridge between the parent-child semantics in React/Vue/etc and more complex implementations like Svelte's slots. A better abstraction between browsers and OS accessibility layers also wouldn't hurt. Think aria attributes, window.requestAnimationFrame, source maps, and the JS debugger statement - not UI frameworks or new standard HTML elements.
- Polylactic_acid 7y ago
  Also even if browsers did implement standard UI elements no one would use them. Its the same situation we have today where everyone re implements the browser default inputs because they are too basic and not flexible enough and work different on every browser.
austincheney 7y ago
> It's time it happened with reactive DOM rendering. This is framework nonsense. Rendering isn’t related to the DOM. https://dom.spec.whatwg.org/ https://dom.spec.whatwg.org/
- _bxg1 7y ago
  Okay, maybe the technically precise term is "Node tree", which is a part of the DOM. But colloquially people today know what I meant. Even the term "Virtual DOM" implies my usage of the term.
  - austincheney 7y ago
    Epic face palm. I provided a link to the DOM specification. Please point me to the part about virtual DOM.
Kaze404 7y ago
List comprehensions in JS were never made part of the standard.
- _bxg1 7y ago
  Array has .map(), .reduce(), .filter(), etc.
  - Kaze404 7y ago
    List comprehensions are "[x for x in list]". Map, reduce and filter are just functional constructs.
    - _bxg1 7y ago
      Okay, I appear to have used the wrong term but that's beside the original point.
      - Kaze404 7y ago
        Fair enough. It just confused me, I thought it somehow got accepted into the spec without me noticing :p
mstade 7y ago
> once there's a consensus the selected approach gets enshrined and implemented as a browser standard that everyone can use That's kind of a charitable way to put it I think, implying democracy has anything to do with it. The "consensus" really is "will enough browser makers care to implement this thing?" meaning the consensus of TC39 and other bodies doesn't really matter much, what matters is the will of a select few corporations. Even if you do squint and look at the committees involved and try to take the charitable view, you'll see that the future direction isn't so much dictated by any kind of "invisible hand of the market" but rather by who has the tenacity to show up and stick with it. That's how we get half measures like the Promise API, and abominations like EME. Truth of the matter is that the standard bodies have no stick, so they just kind of have to hope that the big three (Blink, WebKit, Gecko) play ball, and these days increasingly the smaller two have to play catch up to Blink. I commend everyone involved in these standards processes – they're doing a thankless and difficult job – but they're mostly paving Google's cow paths rather than those of "the market."

by _bxg1 7y ago

davnicwil 7y ago

I know what you mean, but I'd argue while that works for technical details with defined inputs->outputs, it doesn't really work for UI which is a much more open ended problem/solution space which the user directly interacts with. Beyond even the practical concerns with locking yourself down to certain modes of doing UI, there's also just evolving taste, trends of usage, device types etc. I just don't think UI is something you can ever call done.

akiselev 7y ago
I don't think what the GP is describing would restrict anyone from innovating in the UI space. What we need is a standard API for framework+component life cycles, tracing - i.e. a currentComponent api for tracking the relationship between JS scopes and DOM elements, and context/slot apis powerful enough to bridge between the parent-child semantics in React/Vue/etc and more complex implementations like Svelte's slots. A better abstraction between browsers and OS accessibility layers also wouldn't hurt. Think aria attributes, window.requestAnimationFrame, source maps, and the JS debugger statement - not UI frameworks or new standard HTML elements.
Polylactic_acid 7y ago
Also even if browsers did implement standard UI elements no one would use them. Its the same situation we have today where everyone re implements the browser default inputs because they are too basic and not flexible enough and work different on every browser.

austincheney 7y ago

> It's time it happened with reactive DOM rendering. This is framework nonsense. Rendering isn’t related to the DOM. https://dom.spec.whatwg.org/ https://dom.spec.whatwg.org/

_bxg1 7y ago
Okay, maybe the technically precise term is "Node tree", which is a part of the DOM. But colloquially people today know what I meant. Even the term "Virtual DOM" implies my usage of the term.
- austincheney 7y ago
  Epic face palm. I provided a link to the DOM specification. Please point me to the part about virtual DOM.

Kaze404 7y ago

List comprehensions in JS were never made part of the standard.

_bxg1 7y ago
Array has .map(), .reduce(), .filter(), etc.
- Kaze404 7y ago
  List comprehensions are "[x for x in list]". Map, reduce and filter are just functional constructs.
  - _bxg1 7y ago
    Okay, I appear to have used the wrong term but that's beside the original point.
    - Kaze404 7y ago
      Fair enough. It just confused me, I thought it somehow got accepted into the spec without me noticing :p

mstade 7y ago

> once there's a consensus the selected approach gets enshrined and implemented as a browser standard that everyone can use That's kind of a charitable way to put it I think, implying democracy has anything to do with it. The "consensus" really is "will enough browser makers care to implement this thing?" meaning the consensus of TC39 and other bodies doesn't really matter much, what matters is the will of a select few corporations. Even if you do squint and look at the committees involved and try to take the charitable view, you'll see that the future direction isn't so much dictated by any kind of "invisible hand of the market" but rather by who has the tenacity to show up and stick with it. That's how we get half measures like the Promise API, and abominations like EME. Truth of the matter is that the standard bodies have no stick, so they just kind of have to hope that the big three (Blink, WebKit, Gecko) play ball, and these days increasingly the smaller two have to play catch up to Blink. I commend everyone involved in these standards processes – they're doing a thankless and difficult job – but they're mostly paving Google's cow paths rather than those of "the market."