The javascript people should stop innovating for a couple of years. To much innovation that lead nowhere. How many ways can one build a web javascript project?

Browser people should pick up slack and start developing sane components for the web. How about a backend-supporting combobox, or a standardized date picker across browsers? Then we wouldn't need to constantly innovate how we manage the state of those fundamental operating controls that browser still don't have in 2025.

I think part of the problem is that browsers don't really serve their original purpose anymore.

Google functionally controls just enough of a monopoly via chrome that they can generally do whatever they want (and not do whatever they don't want to do). So that standards still mostly can't do anything google isn't enthusiastic about dumping dev time into.

And they're just barely not enough of a monopoly that they can't just go wild and actually turn the browser into a locked down capital-P Product. Safari and Firefox (in that order... much to my chagrin) are holding them back from that.

So browsers just kind of hang out, not doing too terribly much, when obviously there are strong technical forces that want the browser to finally finish morphing from a document viewer to an application runtime. Finally fulfill the dream of silverlight and java applets/JNLP and so on. But nobody wants to bother doing that if they don't get to control it (and firefox doesn't have the dev power to just trailblaze alone in OSS spirit).

So instead the js people just have to plow along doing their best with the app-runtime version of NAND chips since the incentives don't want to offer them anything better at the browser/platform level.

> How many ways can one build a web javascript project?

How many ways can one build a web API? Why are there hundreds of options to build one? Why do people keep inventing new ones, while the problem has been solved 20 years ago?

To be fair browsers/CSS have been solving a lot of use cases you'd normally turn to js for, lately. We should continue escalating this effort.

> How about a backend-supporting combobox,

Interesting. How would this specification look, in context of browser standards?

> a standardized date picker across browsers

Not possible for the majority of use cases. Too much variation in what the date is used for and how the display must be constrained.

For example the lack of constraining the dates makes it unusable in most contexts (flights, hotels, meetings, etc).

Then those constraints need to interact with other elements on the page, like a checkbox for "weekends only" or similar.

Even without constraints, sometimes you want the user to go next/previous by years, sometimes by hours, etc

Date picking is just not general enough to have as a single component.

I'd go further and suggest that we need maybe five or six browsers. One for shopping, one for banking, one for socializing...

Let the platforms for these things compete on the back end only and provide a uniform experience on the front end across competitors. This way the people writing the code that runs on our devices don't have conflicts of interest that lead them to betray their users.

It would also be easier to use because once you know the structure/flow/hotkeys for one bank you're now wizardly at navigating the interface for every other bank.

It's just such a waste to have each business writing a separate front end even though what they end up with is always more or less identical to their competitor.

Sandwich shops should compete by making a better sandwich, not by outmaneuvering each other re: how they leverage the app they managed to get 8% of their customers to install.

Frankly it's incredible what any of these frameworks have been able to accomplish given the bonkers platform they have to work on.

HTML, CSS, and JS made sense back when the web was primarily text with some simple forms. It's a dog shit foundation to build highly interactive apps on. The whole thing needs to be thrown out and rebuilt.