12 ms·

> Untold amounts of human effort are exhausted globally every day on rebuilding identical components for web apps. This should not be the case. The UI community

> Untold amounts of human effort are exhausted globally every day on rebuilding identical components for web apps. This should not be the case. The UI community should standardize namings and structures for common components. It's so tempting to think of all the efficiency that could be gained if we'd stop replicating the same work and just all decide how to do things 'right', unfortunately though this isn't how the best results are achieved. This is fundamentally a conversation about markets - in this case for ideas. Lots of parallel work is done in a distributed manner, much of it is wasted, but because of the competition between and combination of different ideas, you get emergent results that are really finely tuned to what people actually want in practice. Top down planning won't get you this. You'll have less waste, to be sure, but you'll also have inferior results.

_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."
Traster 7y ago
Exactly, this is essentially a 'free market' vs 'command economy', the free market has inefficiency in lots of individual actors doing the same thing at varying levels of success. The command economy has inefficiency from a weaker link between product fit and success. In most of the cases we see that better results are seen in terms of product quality through the free market. There are cases where the commmand economy works better - well understood problems where success is easily measured, but I think UIs are about as far away from that as I can imagine.
gitgud 7y ago
Another factor with UI is it's inherently about appearance and what's in fashion... bootstrap, material etc.. A single unifying framework can never dominate, because everyone wants a unique looking website
- spankalee 7y ago
  open-ui is not proposing to make components look the same, it's proposing the exact opposite: to make the common components customizable enough that each design system / UI toolkit can use them rather than rolling their own.
  - dchyrdvh 7y ago
    Like a button that supports thousand styles and carries megabytes of styles?
    - spankalee 7y ago
      No, not like that. Why would it?
  - gitgud 7y ago
    Fair enough, but I'm having trouble understanding the point of the abstraction. Open-UI sounds like it wants to be an overarching standard that all design systems should work to. So they can inter-operate. Which in my opinion is a flawed idea.
  - quantummkv 7y ago
    > it's proposing the exact opposite: to make the common components customizable enough that each design system / UI toolkit can use them rather than rolling their own. Honestly, that just sounds like re-implementation with extra steps and an extra layer of wrapper/bridge nonsense. If I am going to completely redesign and customize the provided controls, I might as well roll my own. It would be way quicker and easy to maintain than a mountain of hacks on top of each other.
    - 7y ago
philosopher1234 7y ago
I think this is an insufficient argument. There are lots of examples where standardization works and is effective, eg HTML, HTTP, SSL, FTP, CSS ... The argument you posed is against standardization in general, but if the conclusion is “all standardization/regulation is bad” that holds no empirical water. You have to make the case that this specific standardization is bad, since standardization as a concept is not in question.
- desert_boi 7y ago
  Think of the dead and dying standards that competed against those listed above in the marketplace of ideas (SOAP, Gopher, ECMAScript 1.4[1]). [1] https://en.wikipedia.org/wiki/ECMAScript#4th_Edition_(abandoned) https://en.wikipedia.org/wiki/ECMAScript#4th_Edition_(abando...
  - cptroot 7y ago
    I regret to inform you that SOAP's death has been limited to open source. Enterprise continues to eat it up.
    - DeathArrow 7y ago
      You can even do much more complex things using SOAP, but Rest is much easier to learn and use, so a junior programmer can pick it up in days or hours. People dislike having to make efforts.
      - shawnz 7y ago
        In my experience, SOAP has poor tooling compared to REST and nobody implements it properly. Given that, it's not really more powerful than REST in practice.
        Bombthecat 7y ago
        Not more powerful. More standarized. Wss for example.
tracker1 7y ago
That said, which standard do you follow? For me, I've been a pretty big proponent of Material Design, and in particular the material-ui component library implementation. In the end, nobody is going to fall into a "standard" set of components, if for nothing else, because designers want variance and customization.
GuiA 7y ago
Well expressed, thanks for your thoughtful comment. The beautiful things about standards is how many there are to choose from!
imvetri 7y ago
Here is an example of what top down planning helped me to build something https://github.com/imvetri/ui-editor https://github.com/imvetri/ui-editor. There are doers and talkers. open-ui.org is a doer.
- imtringued 7y ago
  I can't get your demo to work. When I delete one component in the list the entire site turns blank.
DeathArrow 7y ago
There's room for both approaches. Some people can use pre-made UI components while others can have them tailor-made to better fit the case. I, as a programmer, have a tough work to design UI components that fit well together, and of course I don't do as a good job as someone trained to do this. So, I rather reuse components done by others if the project I am working on does not have a budget for UI specialists as can happen to a lot of projects.
- jaredklewis 7y ago
  Using premade components from big popular UI libraries like bootstrap, material UI, ant and so on is the market approach the parent mentions. All of those libraries are completing. This project is not about reusable components. My understanding is that they want to standardize things across all of those projects so that a “switch” refers to the same kind of component in every project, for example.
- Avamander 7y ago
  But most of those components do exist in browsers already and just have to be styled?
littlestymaar 7y ago
I think it might be a result of the massive propaganda against communism during the cold war, but the efficiency of central planning is too often overlooked in such comments. Of course it's not a silver bullet, but it doesn't produce inferior outcome by design. Remember: most big coorp (think Walmart) are actually centrally-planned mini state and yet, their profitability is excellent compared to smaller actors.
otabdeveloper2 7y ago
> Untold amounts of human effort are exhausted globally every day on rebuilding identical components for web apps. This should not be the case. The UI community should standardize namings and structures for common components. Yeah, they're called 'HTML forms'. If you want a standards-compliant, accessible UI that works everywhere then just use them. If you want some godawful 'SPA' with UI elements that 'communicate your corporate style', then no amount of standardization will help here.
oleganza 7y ago
I disagree that there's waste. People do not participate in winner-takes-all contests very often. When you have 10 competing approaches, you still try to have a plan B and a plan C for when you are not finding the best-for-everyone solution. Maybe you cover a smaller chunk of the demand, or find a way to make it cheaper. So while someone is taking up a longer-term, higher-risk project, others are trying shorter term solutions. And everyone wins: you have something done sooner rather than later, and long-term projects face less competition, so their chances of success are more tied to an actual fit than to a luck of outcompeting others.
xgiok78xh 7y ago
Our core protocols would like a word about the value of standardization. Are you sure you’re weighing where the demand is correctly? We’re talking the cognitive consumption layer which is trivial to generate desire for customization in. Try writing your own TCP/IP stack. The web UIs are taxonomy. Design. Easily customized for small tasks. Work that needs to be done generically (protocols) is more abstract and becomes a de facto standard. We fought the protocol wars on the same grounds (ipx, netbui, tcp/ip, oh my!) and we stuck with the free ones. The demand is for jobs. Having a lot of web developers is a matter of ideology for jobs, and is not an indicator we have so much demand for unique web UIs we need all these people making them. That’s not real demand. That’s demand to keep our ideology about work alive. Given all these UX libs, a desktop app could have tabs and in each tab a specific style (mail form, blog post) with a random design applied. The user could punch in their data, click a button to deploy. But we atomized each task for jobs. We have enough content and our consciousness only really seems to like certain styles generally. Throwing more monkeys at typewriters isn’t due to demand for UI. It’s to meet demand of middle class Americans that don’t want to work at McDonalds.
nick_meister 7y ago
Every market is different. As I see it, there are many factors at play: - Network effects - Economies of scale (usually not large in software development) - Other barriers to entry? How important each of these is, depends on each particular market. In some cases, some coordination between agents could achieve better results. Regarding network effects, uncoordinated efforts or competition between a lot of agents could lead to an inefficient solution that is very hard to change without coordination of resources (perhaps the QUERYT keyboard layout, that was created for old mechanical keyboards?). Anyway, I don't think this is the case for UIs, but perhaps in other cases, some coordination could be better for long term results without sacrificing innovation. Besides that, in a capitalist economy, inside every company/organization, there is some sort of 'Top down planning' and coordination between resources (Example: Alphabet: Google Search, Youtube) to gain efficiency and efficacy.

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

Traster 7y ago

Exactly, this is essentially a 'free market' vs 'command economy', the free market has inefficiency in lots of individual actors doing the same thing at varying levels of success. The command economy has inefficiency from a weaker link between product fit and success. In most of the cases we see that better results are seen in terms of product quality through the free market. There are cases where the commmand economy works better - well understood problems where success is easily measured, but I think UIs are about as far away from that as I can imagine.

gitgud 7y ago

Another factor with UI is it's inherently about appearance and what's in fashion... bootstrap, material etc.. A single unifying framework can never dominate, because everyone wants a unique looking website

spankalee 7y ago
open-ui is not proposing to make components look the same, it's proposing the exact opposite: to make the common components customizable enough that each design system / UI toolkit can use them rather than rolling their own.
- dchyrdvh 7y ago
  Like a button that supports thousand styles and carries megabytes of styles?
  - spankalee 7y ago
    No, not like that. Why would it?
- gitgud 7y ago
  Fair enough, but I'm having trouble understanding the point of the abstraction. Open-UI sounds like it wants to be an overarching standard that all design systems should work to. So they can inter-operate. Which in my opinion is a flawed idea.
- quantummkv 7y ago
  > it's proposing the exact opposite: to make the common components customizable enough that each design system / UI toolkit can use them rather than rolling their own. Honestly, that just sounds like re-implementation with extra steps and an extra layer of wrapper/bridge nonsense. If I am going to completely redesign and customize the provided controls, I might as well roll my own. It would be way quicker and easy to maintain than a mountain of hacks on top of each other.
  - 7y ago

philosopher1234 7y ago

I think this is an insufficient argument. There are lots of examples where standardization works and is effective, eg HTML, HTTP, SSL, FTP, CSS ... The argument you posed is against standardization in general, but if the conclusion is “all standardization/regulation is bad” that holds no empirical water. You have to make the case that this specific standardization is bad, since standardization as a concept is not in question.

desert_boi 7y ago
Think of the dead and dying standards that competed against those listed above in the marketplace of ideas (SOAP, Gopher, ECMAScript 1.4[1]). [1] https://en.wikipedia.org/wiki/ECMAScript#4th_Edition_(abandoned) https://en.wikipedia.org/wiki/ECMAScript#4th_Edition_(abando...
- cptroot 7y ago
  I regret to inform you that SOAP's death has been limited to open source. Enterprise continues to eat it up.
  - DeathArrow 7y ago
    You can even do much more complex things using SOAP, but Rest is much easier to learn and use, so a junior programmer can pick it up in days or hours. People dislike having to make efforts.
    - shawnz 7y ago
      In my experience, SOAP has poor tooling compared to REST and nobody implements it properly. Given that, it's not really more powerful than REST in practice.
      - Bombthecat 7y ago
        Not more powerful. More standarized. Wss for example.

tracker1 7y ago

That said, which standard do you follow? For me, I've been a pretty big proponent of Material Design, and in particular the material-ui component library implementation. In the end, nobody is going to fall into a "standard" set of components, if for nothing else, because designers want variance and customization.

GuiA 7y ago

Well expressed, thanks for your thoughtful comment. The beautiful things about standards is how many there are to choose from!

imvetri 7y ago

Here is an example of what top down planning helped me to build something https://github.com/imvetri/ui-editor https://github.com/imvetri/ui-editor. There are doers and talkers. open-ui.org is a doer.

imtringued 7y ago
I can't get your demo to work. When I delete one component in the list the entire site turns blank.

DeathArrow 7y ago

There's room for both approaches. Some people can use pre-made UI components while others can have them tailor-made to better fit the case. I, as a programmer, have a tough work to design UI components that fit well together, and of course I don't do as a good job as someone trained to do this. So, I rather reuse components done by others if the project I am working on does not have a budget for UI specialists as can happen to a lot of projects.

jaredklewis 7y ago
Using premade components from big popular UI libraries like bootstrap, material UI, ant and so on is the market approach the parent mentions. All of those libraries are completing. This project is not about reusable components. My understanding is that they want to standardize things across all of those projects so that a “switch” refers to the same kind of component in every project, for example.
Avamander 7y ago
But most of those components do exist in browsers already and just have to be styled?

littlestymaar 7y ago

I think it might be a result of the massive propaganda against communism during the cold war, but the efficiency of central planning is too often overlooked in such comments. Of course it's not a silver bullet, but it doesn't produce inferior outcome by design. Remember: most big coorp (think Walmart) are actually centrally-planned mini state and yet, their profitability is excellent compared to smaller actors.

otabdeveloper2 7y ago

> Untold amounts of human effort are exhausted globally every day on rebuilding identical components for web apps. This should not be the case. The UI community should standardize namings and structures for common components. Yeah, they're called 'HTML forms'. If you want a standards-compliant, accessible UI that works everywhere then just use them. If you want some godawful 'SPA' with UI elements that 'communicate your corporate style', then no amount of standardization will help here.

oleganza 7y ago

I disagree that there's waste. People do not participate in winner-takes-all contests very often. When you have 10 competing approaches, you still try to have a plan B and a plan C for when you are not finding the best-for-everyone solution. Maybe you cover a smaller chunk of the demand, or find a way to make it cheaper. So while someone is taking up a longer-term, higher-risk project, others are trying shorter term solutions. And everyone wins: you have something done sooner rather than later, and long-term projects face less competition, so their chances of success are more tied to an actual fit than to a luck of outcompeting others.

xgiok78xh 7y ago

Our core protocols would like a word about the value of standardization. Are you sure you’re weighing where the demand is correctly? We’re talking the cognitive consumption layer which is trivial to generate desire for customization in. Try writing your own TCP/IP stack. The web UIs are taxonomy. Design. Easily customized for small tasks. Work that needs to be done generically (protocols) is more abstract and becomes a de facto standard. We fought the protocol wars on the same grounds (ipx, netbui, tcp/ip, oh my!) and we stuck with the free ones. The demand is for jobs. Having a lot of web developers is a matter of ideology for jobs, and is not an indicator we have so much demand for unique web UIs we need all these people making them. That’s not real demand. That’s demand to keep our ideology about work alive. Given all these UX libs, a desktop app could have tabs and in each tab a specific style (mail form, blog post) with a random design applied. The user could punch in their data, click a button to deploy. But we atomized each task for jobs. We have enough content and our consciousness only really seems to like certain styles generally. Throwing more monkeys at typewriters isn’t due to demand for UI. It’s to meet demand of middle class Americans that don’t want to work at McDonalds.

nick_meister 7y ago

Every market is different. As I see it, there are many factors at play: - Network effects - Economies of scale (usually not large in software development) - Other barriers to entry? How important each of these is, depends on each particular market. In some cases, some coordination between agents could achieve better results. Regarding network effects, uncoordinated efforts or competition between a lot of agents could lead to an inefficient solution that is very hard to change without coordination of resources (perhaps the QUERYT keyboard layout, that was created for old mechanical keyboards?). Anyway, I don't think this is the case for UIs, but perhaps in other cases, some coordination could be better for long term results without sacrificing innovation. Besides that, in a capitalist economy, inside every company/organization, there is some sort of 'Top down planning' and coordination between resources (Example: Alphabet: Google Search, Youtube) to gain efficiency and efficacy.