> 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.
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.
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.
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.
> 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.
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.
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 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.
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.
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.
> 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 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.
This division isn't unexpected. Compare the Mac OS toolbox and the Windows API for UI elements. UI's widget toolkits are built atop the graphics and input APIs below them and tend to end up tightly interwoven (and the projects that attempt to provide a spanning set of widgets across different graphics / input UIs seem to tend to end up looking like a lowest-common-denominator solution with the clock rolled all the way back to the late '80s / early '90s concept of what "good UI" looks like).
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?
I agree - this fear of "reinventing the wheel" needs to go away. People gravitate towards products that suit their needs, and if they don't they'll cook something up themselves. It's really not the end of the world if you're writing something that someone else somewhere wrote. Everything has its advantages and drawbacks.
That’s not what this is about at all. This is simply looking around at people using benches, stools, stumps, and piles of rocks and suggesting we come up with a word to describe something constructed that you sit on... then looking at the nicknames currently being used and highlighting the most common. It has nothing to do with prescribing any particular style of chair.
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.
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?
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.
I absolutely hate them. 80% of the time it's confusing as to which way is on/off either because of design or because of the wording for that setting/option.
I also prefer checkboxes to switches – at least on desktop.
Although anecdotally, I've helped a few older, technophobic people learn how to use websites/phones, and the majority of them know exactly what to do when presented with a switch, but they don't realize that they can click a checkbox. To them, it just looks like a square and they ignore it. (Take this with a grain of salt, my sample size is <10.)
> Distinguishing on/off state only by color is highly non-usable.
All of the examples use at least color and position, the majority also add an additional icon in the checked state (one of those also has a different icon on the unchecked state) and Material Design uses a relative contrast distinction (which, unlike a simple color distinction, is readily distinguishable for the colorblind.) There is exactly one (ANT design) that uses only color and position to distinguish between checked and unchecked states.
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
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.
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.
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?
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.
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?
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."
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.
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
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.
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.
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.
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.
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
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?).
[+] [-] davnicwil|6 years ago|reply
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.
[+] [-] DeathArrow|6 years ago|reply
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.
[+] [-] philosopher1234|6 years ago|reply
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.
[+] [-] _bxg1|6 years ago|reply
[+] [-] gitgud|6 years ago|reply
A single unifying framework can never dominate, because everyone wants a unique looking website
[+] [-] otabdeveloper2|6 years ago|reply
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.
[+] [-] Traster|6 years ago|reply
[+] [-] xgiok78xh|6 years ago|reply
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.
[+] [-] oleganza|6 years ago|reply
[+] [-] GuiA|6 years ago|reply
[+] [-] tracker1|6 years ago|reply
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.
[+] [-] imvetri|6 years ago|reply
[+] [-] littlestymaar|6 years ago|reply
Remember: most big coorp (think Walmart) are actually centrally-planned mini state and yet, their profitability is excellent compared to smaller actors.
[+] [-] nick_meister|6 years ago|reply
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|6 years ago|reply
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|6 years ago|reply
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...
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.
[+] [-] austincheney|6 years ago|reply
They already created that a long time ago and nobody used it.
https://en.m.wikipedia.org/wiki/XForms
Before anybody starts crying about it being XML please remember that SVG is XML. Everybody loves SVG and it integrates into HTML just fine.
I really don’t see the practical difference between your idea and the idea proposed by this site.
[+] [-] shadowgovt|6 years ago|reply
[+] [-] longtermd|6 years ago|reply
[+] [-] interactivecode|6 years ago|reply
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?
[+] [-] jturpin|6 years ago|reply
[+] [-] skue|6 years ago|reply
[+] [-] imvetri|6 years ago|reply
[+] [-] slfnflctd|6 years ago|reply
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.
[+] [-] c-smile|6 years ago|reply
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|6 years ago|reply
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/
[+] [-] hanniabu|6 years ago|reply
[+] [-] mtm7|6 years ago|reply
Although anecdotally, I've helped a few older, technophobic people learn how to use websites/phones, and the majority of them know exactly what to do when presented with a switch, but they don't realize that they can click a checkbox. To them, it just looks like a square and they ignore it. (Take this with a grain of salt, my sample size is <10.)
[+] [-] dragonwriter|6 years ago|reply
All of the examples use at least color and position, the majority also add an additional icon in the checked state (one of those also has a different icon on the unchecked state) and Material Design uses a relative contrast distinction (which, unlike a simple color distinction, is readily distinguishable for the colorblind.) There is exactly one (ANT design) that uses only color and position to distinguish between checked and unchecked states.
[+] [-] bmn__|6 years ago|reply
[+] [-] airstrike|6 years ago|reply
[+] [-] Tepix|6 years ago|reply
[+] [-] avindroth|6 years ago|reply
[+] [-] imvetri|6 years ago|reply
It's an open project. Feel free to provide a fix.
[+] [-] zo1|6 years ago|reply
[+] [-] Geeflow|6 years ago|reply
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
[+] [-] memco|6 years ago|reply
[+] [-] ryanmarsh|6 years ago|reply
I’m like, oh please tell me how to build a UI for the web...
[+] [-] sdfhbdf|6 years ago|reply
[+] [-] PaulDavisThe1st|6 years ago|reply
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.
[+] [-] dfabulich|6 years ago|reply
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 and 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|6 years ago|reply
[+] [-] darepublic|6 years ago|reply
[+] [-] cdata|6 years ago|reply
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
[+] [-] nudpiedo|6 years ago|reply
Good luck with the project.
[+] [-] Tabzz98|6 years ago|reply
[+] [-] g8oz|6 years ago|reply
[+] [-] austincheney|6 years ago|reply
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.
[+] [-] orliesaurus|6 years ago|reply
[+] [-] xixixao|6 years ago|reply