
Open UI - twapi
https://open-ui.org/
======
davnicwil
> 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
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
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
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.

------
_bxg1
The standard is the web platform itself. That's the only standard that will
ever be followed to any meaningful degree.

Much of the needless splintering we see today can be traced back to having too
many mutually-incompatible reactive rendering systems. If you make a button in
React, even though I'd like the exact same button in my Vue app, I can't use
it because it's rendered via a different API.

The core barrier _here_ comes down to the different templated-rendering
systems. What we need is a browser standard for templated/reactive rendering
of DOM content (data + template = DOM). The <template> element doesn't count
because it doesn't actually do anything. Web components are nearly useless
without having a story for reactive rendering.

Beyond just compatibility this would give web apps a massive performance
boost, in terms of both CPU cycles and initial payload size. It's long past
due.

~~~
spankalee
> The core barrier here comes down to the different templated-rendering
> systems.

This shouldn't be a barrier at all. The rendering system a component uses
should be an entirely encapsulated implementation detail of the component.
Components should absolutely not have to use the same template system to be
used together.

This is something web components get very, very correct.

> Web components are nearly useless without having a story for reactive
> rendering

There are libraries that address just that specific need, like lit-html which
I maintain. Again, it's an implementation detail of the component.

> What we need is a browser standard for templated/reactive rendering of DOM
> content (data + template = DOM)

While rendering should be an implementation detail, I still agree with you
here, simply because templating is such a universal need that the platform
should provide some primitives to help developers.

The current best proposal in this area is Template Instantiation:
[https://github.com/w3c/webcomponents/blob/gh-
pages/proposals...](https://github.com/w3c/webcomponents/blob/gh-
pages/proposals/Template-Instantiation.md)

The main idea is that it lets you mark up a <template> with references that
will be cloned along with the template contents. These references can then be
used to dynamically update the cloned instance. You can accelerate most
template systems with these primitives. It's critical because the DOM doesn't
have any other way to clone a chunk of DOM along with references to specific
nodes in that tree without manually walking the clone's tree.

~~~
jeffmcmahan
Thank you for your work on lit-html. I use it daily. What a great tool.

------
interactivecode
Projects like these are saying just because we figured out how chairs work,
everyone should use the same chair.

It just completely misses the point, people like it when they build something
themselves it looks how they like it. Want to spend years working on something
that looks exactly like everything else?

~~~
slfnflctd
To many developers, what the software _does_ is several orders of magnitude
more important than how it looks.

There are certainly cases where visual design is much more critical to what
you're building, but there are plenty where it's little more than an annoying
distraction.

~~~
asjw
Use standard html then

A select is a select using a native widget

An input is a standard OS input widget

And so on

~~~
rusticpenn
That does not really work. The whole point of frameworks is to reduce work.

~~~
DeathArrow
But I can do things faster using MVC on server, ES6 + jQuery on front end, VS
having to use something like Angular.

It also looks and feels better.

~~~
yoz-y
> But I can do things faster using MVC on server, ES6 + jQuery on front end,
> VS having to use something like Angular.

That boils down to which technologies you are familiar with.

> It also looks and feels better.

And this is highly subjective too. Of course looks are very independent from
system to system but the feels depend on the tech stack quite a bit.

------
c-smile
Am I the only one who think that <switch> [https://open-
ui.org/components/switch](https://open-ui.org/components/switch) is a
usability disaster?

Distinguishing on/off state only by color is highly non-usable. Neither from
a13y perspective nor for ordinary users. And to keep in mind LTR/RTL problems
if someone rely on knob position.

What's wrong with classic check box for that purpose?

~~~
superhuzza
Check boxes don't imply immediate effects. They require 'saving' to take
effect. Like when you're filling out a form, the checkbox doesn't do anything
until the form is 'interpreted' by a human.

Switches(toggles) on the other hand, imply immediate effects. Like a light
switch, we expect the change to occur immediately.

[https://www.nngroup.com/articles/toggle-switch-
guidelines/](https://www.nngroup.com/articles/toggle-switch-guidelines/)

~~~
saagarjha
I have never heard of or expected this from my "binary choice components". To
my knowledge, switches are used on iOS, while checkboxes are a macOS thing
(though they just added support for iOS-style switches, but with a very
specific purpose).

~~~
pvg
_I have never heard of or expected this from my "binary choice components"._

It's fairly standard in 'traditional' desktop UI where actions are supposed to
be initiated by regular buttons and things like radio buttons and checkboxes
are for setting the options of the action. "Radio buttons never initiate an
action" says the classic MacOS HIG, for instance.

~~~
saagarjha
Right, but on macOS, checkboxes often apply immediately. Just look through
System Preferences, which largely doesn't even have a "save" action:
checkboxes have take effect instantaneously. (So do many radio buttons…)

~~~
pvg
Yep, that's why I said 'traditional', this has drifted a fair bit because
there's a benefit to providing immediate feedback, especially if the action is
some visual and reversible change like turning on dark mode. Windows ribbons
are also full of such radio buttons and checkboxes.

------
bmn__
Project neglects UI paradigms/technical terms outside of the browser, that
kind of wilful ignorance can only end in tears. Open up `designer-qt5` some
time and marvel at the sheer number of UI widgets.
[https://duckduckgo.com/?iax=images&ia=images&q=qt+designer](https://duckduckgo.com/?iax=images&ia=images&q=qt+designer)

~~~
kitsunesoba
Having cut my programming teeth on a Visual Basic analogue and later
Cocoa/AppKit, both of which have a similarly rich roster of widgets, going
into front end web development was somewhat shocking and frustrating. Where I
would've been writing application logic, I was instead writing common widgets
from scratch.

It's hard to believe that this has barely changed in the decade+ since then.
The web has grown and matured immensely as a platform, yet it's still
necessary to bring in (often heavy) third party libraries to not spend all our
time writing basic widgets.

At minimum, browsers should provide basics like recycler views that can
satisfy a majority of use cases with a little CSS and act as a foundation for
libraries to build upon for the use cases they can't. One shouldn't need to
pull in heavy third party code for such common functionality.

~~~
DeathArrow
That would transform browsers into operating systems.

------
airstrike
For a project on UI, the mobile version of the website is so bad it's almost
impossible to read...

~~~
Tepix
Even on desktop their site isn't great. There are hardly any hints regarding
what is a hyperlink. Only the mouse cursor changes. I've seen far more
accessible designs.

------
Geeflow
To me, the most exciting aspect of this project is the common language. I
would love to have a kind of dictionary of UI components where I can easily
look up the correct (and widely accepted) name for a type of component.

No more carousels that are called sliders because they slide. No more
wondering if it is a split button or button group...

Especially the Component Name Matrix[1] is great. Bookmarked.

[1] [https://open-ui.org/analysis/component-matrix](https://open-
ui.org/analysis/component-matrix)

------
memco
Ambitious project! I hope there's some useful contributions to come for UI
development. I was confused by the "concepts" sections—there's little meters
with red and green, but it doesn't really express what those meters mean nor
how they've been evaluated for each concept. It's surprising to me that
something like a "basic" checkbox would get a 3/14 green: checkboxes are a
pretty standard form element for both electronic and printed forms: what's so
poor about the UI of this element? What's the better alternative?

~~~
chiefofgxbxl
> I was confused by the "concepts" sections—there's little meters with red and
> green, but it doesn't really express what those meters mean nor how they've
> been evaluated for each concept.

It isn't explained, but if I'm not mistaken it looks like they put a green box
in the meter for each different UI system that they've recorded for it.

E.g. on [https://open-ui.org/components/switch](https://open-
ui.org/components/switch), the "basic" switch has 5 green boxes in the meter:
Ant Design, Atlaskit, Evergreen, Lightning Design System, Material Components
Web. The next example, "autofocus" only has 1: Ant Design

So it appears they are ranking the features (basic, autofocus, default, large,
etc. of each component by how much support each feature has across design
kits.

I was confused too because using the green/red meter makes it seem like
they're giving it a score or rating. A better alternative would to say: "We
found 5 frameworks that support this feature"

------
ryanmarsh
I cannot get over the irony of all these web UI framework sites that don’t
work on mobile.

I’m like, oh please tell me how to build a UI for the web...

------
sdfhbdf
This website has really messed up mobile view (Safari on iPhone) for a UI
project.

~~~
ricardobeat
It also pollutes your browser history with a ton of navigation routes. Not the
end of the world, but I feel a project with this ambition needs to have
flawless standards to succeed.

------
PaulDavisThe1st
Back when <insert-SQL-database-vendor's-name-here> "Forms" SDK's and tools
where the way that data-centric applications were developed, do you think
there was any consensus on naming and components?

You might have been able to leverage some conceptual knowledge from Oracle's
tools to the ones associated with Postgres, but everything was different at
the syntactic level.

When <insert-software-development-corp-here>'s GUI toolkit were the way that
data-centric applications were developed,do you think there was any consensus
on naming and components? Not all. People using MS GUI tools would flounder
amidst Cocoa, and vice versa. Qt users would have to constantly read the GTK
manual, and vice versa.

You might have been able to leverage some conceptual knowledge from one
vendor's tools to the ones associated with another's, but everything was
different at the syntactic level.

It might be a good idea to settle on some "global" definitions and components,
but that hasn't happened before, and I can't see any particular reason it will
happen for applications developed around the web platform.

~~~
nexuist
> It might be a good idea to settle on some "global" definitions and
> components, but that hasn't happened before,

But it has. We all know what buttons, dropdowns, forms, windows, text boxes,
etc. are. Windows and macOS gave us these concepts and the Web adopted them.

~~~
PaulDavisThe1st
It's not as if the web-UI "toolkits" that openui is attempting to
"standardize" don't already have those things either.

The issue seems to be that the way they work, and the way to work with them,
differs from toolkit to toolkit.

I.e. just like ye olde SQL forms tools and ye not so olde desktop-native
toolkits.

------
dfabulich
The vision of Open UI is "interoperability" but it doesn't explain what
exactly is supposed to interoperate.

To support that vague vision, Open UI identifies four goals, and all of them
are silly.

 _1) Document component names as they exist today_

 _2) A common language for describing UIs and design systems_

 _3) Eventual browser standards for web app components_

 _4) Converging designer processes and developer workflows_

#1 and #2 seem like two sides of the same coin, but they don't directly solve
any "interoperability" problem. Agreeing to use the same name for "button" or
"switch" would hardly solve this problem from the vision statement: "Untold
amounts of human effort are exhausted globally every day on rebuilding
identical components for web apps."

#4 is so vague that I literally have no idea what it means.

As for #3, we already have have browser standards for web app components. What
would Open UI deliver?

My best guess is that Open UI is laying the groundwork for built-in
standardized web components like std-switch [https://github.com/tkent-
google/std-switch](https://github.com/tkent-google/std-switch) and std-toast.
[https://github.com/jackbsteinberg/std-
toast](https://github.com/jackbsteinberg/std-toast)

In that case, I think the vision statement should say:

"Open UI will develop new web components that we hope will one day become
built-in standard browser features. To do that, we're going to scrutinize
popular UI design systems, looking for cowpaths to pave."

------
Koshkin
_The nice thing about standards is that you have so many to choose from._ \-
Andrew S. Tanenbaum

------
darepublic
Well the site is pretty broken on Android for Firefox.. that aside I
sympathize with the mission but not sure preaching about wasted effort is
going to help anything. Presentation should be completely up to the client, we
need a UI that can understand what is being sent back from the server and
dynamically visualize it in various ways based on user preference. We should
not be stuck with whatever JS and mark up is sent back from the server. Ie we
both are visiting hackernews but we should be able to configure our UI to view
it in completely different ways based on preferences. And this can't be based
on a standard per se because there won't be buy in. There just needs to be a
UI client that is basically intelligent that you can tell it how you want your
data visualized or presented and it will do it for you magically.

------
cdata
In this thread there seems to be no end of comments seeking to tear down the
project under consideration.

In my opinion, this project is a good initiative and more folks should take a
page from this project's book. Even if you think such a project is critically
flawed, an effort to thread a needle and help the community deserves praise
and constructive feedback. In this particular case, the author(s?) is
apparently taking the time to study a broad selection of UI frameworks and
synthesize what they are learning into something everyone can benefit from.
That's awesome, and I hope they keep up the good work

~~~
carapace
It's been _done._ Done and done and done.

[https://wiki.python.org/moin/AnyGui](https://wiki.python.org/moin/AnyGui)

> The purpose of AnyGui project was (development stopped in 2002) to create a
> generic access API to different types of GUI libraries found to work with
> Python. The name is inspired by the standard Python module anydbm, which
> provides generic access to DBM-style databases.

That's just _one_ example of a meta-gui framework.

Without an extensive "related work" section this is just navel-gazing.

~~~
skue
They aren’t the same thing at all. This isn’t trying to be a framework, it’s
simply a lexicon.

~~~
carapace
So it's even less useful? Apologies for the snark.

I'm actually in favor of the general idea. And these folks seem like they
might know a thing or two:
[https://www.w3.org/community/wicg/participants](https://www.w3.org/community/wicg/participants)

I would be way more impressed though if there was a nice "related work"
section.

------
nudpiedo
The whole vision is full of "shoulds" and "deserves" words. That's not how the
world works, neither The Internet which has been built for decentralization. I
don't think that will work, because unless there is a common interest no
framework will be tempted to be compatible with a competing one, and ever in
the cases they could be then each one would implement different UI designs,
concepts, patterns etc so they won't match as it happens assets from different
game studios.

Good luck with the project.

------
Tabzz98
Crudely speaking, something like this could allow components built for React
to easily be used in Angular apps. Where's the harm in that? Any existing
framework can adopt the standard, and new frameworks can be built upon it. A
new one pops up every day, and honestly, I'd love the ability to use some of
the thousands of React components from the shiny new framework I'm trying out.
I don't get all the fuss.

------
g8oz
Sort of related - it drives me up the wall when css frameworks change low
level component class names. Bootstrap did it going from versions 2 to 3 and
Foundation did it going from 5 to 6. Existing sites are either left to bit rot
or or have to be given attention that would have better been spent elsewhere.

------
austincheney
This site screams at me _don’t reinvent the wheel_. The premise is that
frameworks aren’t enough and developers are wasting time working too hard on
things they already know.

When I hear things like this it begs the question: _Exactly how easy do you
need it to be?_ Should UI developers not be required any greater effort than
copy/paste?

The reality is that most of the components the site proposes are already copy
paste if you aren’t locked into a giant framework like React. Like some other
comments have said there already is a common platform for building reusable UI
components: web standards. The world surely doesn’t need a framework for
riding on top of your framework.

~~~
Zarel
As far as I can tell, this is a collaboration between Microsoft Edge and the
W3C for deciding what reusable UI components should be put in web standards,
and what they should be named.

So it's already exactly what you want. What are you complaining about?

~~~
austincheney
It’s an unnecessary artificial solution to a non-problem. If you need a
reusable drop down you are fortunate because it already exists with full
accessibility: the HTML _select_ element. But but but it looks boring... CSS.
But but but form elements are impossible to style and modify their behavior...
probably because you are breaking accessibility for vanity.

My complaint is that this idea is an unnecessary work around to sole something
that isn’t a real problem to supplement your unnecessary work around (your
giant framework). I have reinvented this wheel enough to know that people
frequently want nonstandard things for nonstandard reasons because vanity is
more important than everything else, accessibility is an add on to worry about
later, and they are hopeless without the world’s largest framework to do their
jobs for them.

I already have to be saddened with framework nonsense spaghetti code by
incompetent developers at work. The idea of taking mental laziness and bad
ideas to another level for some senior surrogate dev to parent is horrific.

------
orliesaurus
This looks interesting to me because I have dreamed of a mobile-first
operating system where every app is using predefined UI components. Where
every action is just an API call away (both web and non-web API) from a
req/res. We could ship tiny apps (instead of multi-MBs), I think apps like
twitter, instagram, etc that are mostly just interacting with a "feed" could
literally become KBs worth of JSON/YML code... Sure this would kill creativity
but also make the web more accessible...sometimes it's a good tradeoff

~~~
xixixao
This was Windows Phone. It was pretty great. Unfortunately we won't find out
what would happen if it was a major OS (primarily: would the heavy constraints
work well?).

~~~
tomgp
Yeah, I used a windows phone for 18 months. There were some fantastic ideas in
there and when it worked well it felt like the right way to do things BUT: in
practice It was a mixed bag, where the back button would take you at any given
moment was a mystery (last app? Last state within current app? Something in
between?) and other components also had the feeling of being overloaded in
terms of possible meanings. I get the impression that they lacked clear
guidelines around usage, not an issue when components look different but when
everything has the stamp of official OS look and feel divergent behaviour
undermines trust in the whole system.

------
grizzles
It would be neat for AB testing if you could make a one line code change and
get a whole new style.

This project could just make a positioning component that's a parent to it's
different child components and then also way to catch and translate all it's
events to it's consumers.

It wouldn't be so bad if you just had to write a thin shim layer to do this
for each new component framework you tried out.

------
goblin89
I wonder whether UI component patterns have, in fact, stabilized, and whether
an attempt to standardize them could result in stagnation.

~~~
imvetri
UI components have stabilised. Since the day of the first usage. Its the
different mindset and competing frameworks that creates the noise.

The day it results in stagnation is where we will find the true pattern.
Patience.

------
stevenpetryk
Not seeing much in the way of accessibility here.

------
Avamander
Okay, but what does this project add that the current HTML5 components can't
offer? Is the goal of the project to standardize the style? Or is the
project's goal to get HTML5 UI elements extended to support more features? The
website isn't very clear on that and doesn't mention already existing HTML5 UI
components.

------
filmgirlcw
The lack of a responsive website for this project makes me reject it on its
face.

------
longtermd
This page is not working [https://open-
ui.org/components/dropdown](https://open-ui.org/components/dropdown)

------
dragonwriter
Design languages standardize control naming and structure, but while there is
some borrowing between design languages, there is always going to be variation
between them.

------
DeathArrow
What about a web UI component library written in HTML and CSS, because not
everybody is using JS frameworks?

------
turbotum_
Can I just say, this is the most beautiful homepage I've ever seen?

------
squant0
[https://xkcd.com/927/](https://xkcd.com/927/)

------
Koshkin
> _we should also standardize_

Windows tried, and failed (unfortunately).

~~~
imvetri
If someone failed, its an opportunity to learn from their mistakes. Feel free
to share what windows tried and what failed. It will help out other readers.

------
rusticpenn
I assumed that this was related to openui5 from SAP. is it?

------
rs23296008n1
Another standard? Welcome! Always room for one more.

~~~
imvetri
Please share list of other standards.

------
willart4food
It's a nice thought, unfortunately the human ego factor will get in the way.
We live in a world where we cannot standardize on which side of a car the gas
tank opening is.

~~~
imvetri
Choose your side. Do you think this project is on your side ? then provide
your contributions in form of directions the project needs to take. Thanks.

------
sizzle
Bootstrap comes to mind

------
rendall
It's time to bust out the XKCD for this specific situation, "How Standards
Proliferate"

[https://xkcd.com/927/](https://xkcd.com/927/)

"We need one universal standard that covers everyone's use cases!"

------
NKCSS
I'd have to quote XKCD 927 here:
[https://xkcd.com/927/](https://xkcd.com/927/)

------
gonational
I feel like this is relevant:

[https://xkcd.com/927/](https://xkcd.com/927/)

------
johnmarcus
[https://xkcd.com/927/](https://xkcd.com/927/)

------
maxcan
Ok, I’ll post the obligatory XKCD reference
[https://xkcd.com/927/](https://xkcd.com/927/)

~~~
jimhefferon
Fair enough, but there _does_ need to be a standard, or at least a convention.

~~~
Traster
Does there? I don't mean to be flippant, but it seems to me there's an
enormous number of companies that use UI as their competitive advantage. What
exactly do we gain by standardising user interfaces?

~~~
Avamander
Accessibility.

If common UI elements are denoted the same, it means things like screen
readers, alternative navigation options, custom styling (high-contrast) can
work more reliably.

Everyone implementing their own UI means such things are often secondary.

