Hacker News Reader

Comment by davnicwil | Hacker News Reader

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

View on HN

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.

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.

But most of those components do exist in browsers already and just have to be styled?

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.

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_(abando...

I regret to inform you that SOAP's death has been limited to open source. Enterprise continues to eat it up.

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.

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.

Not more powerful. More standarized. Wss for example.

Well none the less, the standard doesn't help if nobody follows it. Since REST is less prescriptive, the tooling is generally more tolerant of all the funny implementations out there. At least, that's what I've found.

Are you talking RPC or true REST?

Don't understand what I ask - look here http://greglturnquist.com/2016/05/03/rest-soap-corba-e-got/

> I regret to inform you that SOAP's death has been limited to open source. Enterprise continues to eat it up.

How apropos. A behind-the-times punishment for being so behind-the-times? [1]

[1] https://en.wikipedia.org/wiki/Washing_out_the_mouth_with_soa...

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.

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.

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.

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.

> 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/

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.

Epic face palm. I provided a link to the DOM specification. Please point me to the part about virtual DOM.

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

Array has .map(), .reduce(), .filter(), etc.

List comprehensions are "[x for x in list]". Map, reduce and filter are just functional constructs.

Okay, I appear to have used the wrong term but that's beside the original point.

Fair enough. It just confused me, I thought it somehow got accepted into the spec without me noticing :p

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

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

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.

Like a button that supports thousand styles and carries megabytes of styles?

No, not like that. Why would it?

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.

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

There is also no need for a central standard. My company just took an existing CSS framework (it doesn't matter which framework) and then slapped their own customization on top of it and then reused it in dozens of applications. Not much time was actually wasted on the design itself.

Bootstrap and material have made half of the web to look the same.

It's not a great thing.

I disagree, As an end user I want websites to all look and function the same - standards matter for usability so if half the web is using the same approach to me that is a very good thing.

> I want websites to all look and function the same

Really? That would be really terrible wouldn't it? Did you imagine that world? (Maybe I misunderstand you.)

Which currently existing website would you most want all websites to look and function like, if you had to choose?

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.

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.

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.

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.

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

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.

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

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

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.

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.

Reply on news.ycombinator.com