[helloguillecl]

I highly support this initiative.

One of the many reasons of why frameworks like React are used so extensively is because they provide a bridge for the lack of modern HTML implementation of basic control elements, like multi-selectors, search selectors, calendar pickers, and autofill inputs.

Now what we see around the web as "controls" are just a group of <div>s with hidden JS behaviour, lacking both accessibility and deeper integration. With hundreds, if not thousands, of implementations for things like calendar pickers, search selectors, etc.

We need better native controls for the web.

[sumtechguy]

> lack of modern HTML implementation of basic control elements, like multi-selectors, search selectors, calendar pickers, and autofill inputs

It was about the spot where CSS popped up then everyone decided native controls was not useful. Every framework since then has basically reinvented them. They had to as the browsers and standards didnt help. Plus the fact that for awhile the junk would just not render correctly at all or weird between the different browsers.

> We need better native controls for the web.

The reality is people want all of these controls with a nice simple way to skin them. But the browsers made it very 'interesting' to do. There is no real reason at this point other than 'i just want to' for these controls being recreated yet again (and they will be with the next framework).

[nicoburns]

For some controls (I have in mind <select> and date pickers) there is also a lot of functionality missing from the built-in ones.

[sumtechguy]

Totally. It is like the browser venders just kinda stopped iterating on them. When the reality is people just want the controls and the ability to skin them. Also with all of the events that all of the newer controls have.

[RobotToaster]

>calendar pickers

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

[helloguillecl]

I know this exists, but while the implementation in iOs is excellent, I see that a very awkward-looking datepicker shows up in Chrome.

Some things that one can think of as missing:

- Masking (Being able to display "Wednesday, 12th of March 2028")

- Callbacks for enabling/disabling days (for dates)

- Ranges for searches.

[homebrewer]

Compare the native picker to e.g. one from antd:

https://ant.design/components/date-picker/

Actually, compare everything they have to native elements. If the project can afford it (in terms of bundle size, etc — it's fine for intranet), I don't even bother with native controls anymore.

[neogodless]

I'm on a sub-optimal connection, so the Ant Design one took me about a minute to be responsive, while the native one worked in seconds.

I also am confused by this Ant demo page. Is every single date item supposed to be selected in a different element?

In this comparison, I vastly preferred the native date picker over the Ant ones. But I am probably misunderstanding the demo page. Or maybe it's just giving you "too many" options? I just need to pick a date and this seems like overkill, at best.

[test6554]

Better native standards could mean ant.design updates their components to use less js with the same ux. So everyone still wins.

[spookie]

I'm not in the most common browser and even for me, with a good connection, it took a while to load.

[Y-bar]

I really like my native pickers and UI compared to those examples. I can start with the fact that those are not usable on iOS 18, and they took almost a minute to load.

[spartanatreyu]

This goes back to the jQuery and MooTools days, back when Microsoft was holding back web standards. Then when the web started pushing forwards again, some developers didn't want to learn new things and went out of their way to teach new developers not to learn the standards.

That's how we ended up with developers who reach for frameworks instead of just using a simple html element or attribute.

Now we have an entire industry of bootstapping con-artists who are just teaching people to just search for a react thing that does what you want and if that doesn't work use an LLM

They're not actually being taught how to program.

---

Now it's true that some commonly requested features (e.g. date pickers) don't have what everyone needs. But most people also don't realise that a date picker is one of those few specific features where everyone wants it to do things differently. Even when you think you want what everyone else wants, you'll eventually hit a corner case where you realise you need one extra thing changed. There's no way to get everything right in a standard so you'll need to create your own or reach for a 3rd-party implementation.

But just because you may want to use non-standard code for a date picker, doesn't mean you shouldn't learn about (and use) things like <dialog>, <details>, <hgroup>, <menu>, <slot>, etc...

What we'll probably end up with in a few years is the generic standard datepicker, but it'll become extensible, so you can add/remove alter that one extra thing you need. (kind of like <select>'s new ::picker psuedoelement)

[osullivj]

Standards consolidate. Business differentiates. How will openui resolve that fundamental tension?

[madeofpalk]

I just rebuilt a custom Select/Combobox component in react for a Business, and I promise you I had no intention of differentiating. I wish I could have used more native browser behaviour.

[brookst]

Too reductive.

Businesses differentiate to create revenue. Standardization and commoditization are important strategies as well. “Commoditize your complementary goods” and all that.

A web design shop may want to visually differentiate and therefore not use openui. But a restaurant that just wants to have a simple website probably doesn’t want either 1) a crappy looking website, or 2) to invest heavily in web design

[pembrook]

Allowing for nuanced CSS selectors on each part of these components would get you 90% of the way toward resolving that tension.

[rapnie]

Yes, a la the old and famous CSS Zen Garden [0].

[0] https://en.wikipedia.org/wiki/CSS_Zen_Garden

[viraptor]

Businesses differentiate when there's a good reason or no common solution. Nobody creates a new calendar picker or database or... "just because" but because there's no easy alternative. Yeah, there will be exceptions, but if you're paid to create something, your manager will usually not be impressed by "but the wheel I reinvented is slightly different!", unless you justify it with a specific requirement.

[cruffle_duffle]

> Yeah, there will be exceptions, but if you're paid to create something, your manager will usually not be impressed by "but the wheel I reinvented is slightly different!", unless you justify it with a specific requirement.

Depends on the org. Some places incentivize wheel reinvention by having rubrics that basically resolve to “if you want to level up, you need ‘org wide impact’”, which translates into “all the existing databases suck (for …reasons…) so I need to write our own”.

The company might not actually want this behavior but if the people in charge don’t see how important it is to make sure incentives align with expected behavior, the wrong behavior will always happen. So while it makes absolutely no sense to write your own database and Calendar Picker Platform (Now With a Fully Staffed Team!), unless the rubric incentivizes the right thing that is all people are gonna do.

[viraptor]

I get where you're coming from and we all know Google as the bad example here, but looking at it industry-wide, I'm not sure it holds. Like in a lot of cases, "you're not Google" applies and the similar incentives will not be there for a large majority of companies. Software is a cost centre for almost everyone.

[williamdclt]

There’s no tension, you’re just wording this to make it sound like there’s one.

The things that standards consolidate and the things on which business differentiate are entirely different things.

[whstl]

Most business just adopt something existing, we saw this with Bootstrap, then with Material UI. Now things are a bit more diverse but still.

I feel like the pressure to differentiate is coming from internal design departments rather than business itself in 90% of cases. It's just people generating extra work for other people.

[troupo]

No one prevents businesses from using their custom implementations if they so wish. Just as nothing prevents them from doing so on literally every platform from desktop OSes to mobile OSes

[esafak]

Differentiation on UI components adds no value. This is the place for standardization. Users want them familiar.

[emseetech]

This leads newer devs to "learn React" instead of learning web dev, so even after the web catches up, they still reach for React components when a simple html element would do.