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.
Crazy statement. Any API not supported by Safari might as well not exist.
WebSQL? WebUSB?
It seems like Safari bends towards whatever is in common use, at least within a few years.
I really hope that never happens if only because the web dev on ramp will discourage anyone without preexisting technical chops.
No other GUI runtime or framework delivers true cross platform implementation. HTML, CSS and js are as open and as standard as it gets.
GTK sucks in its own ways and is not international standard.
This is a good thing! It keeps salaries high and keeps the dilettantes out. I am sick of getting my work devalued by morons
There are too many people trying to build "tech" who shouldn't be. We need more gatekeepers
In the last 10 years, 3D NAND memory has scaled 10x (in bits per unit area). So… maybe not the best analogy?
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.
Also iOS accessibility screen reader APIs are way better than the web. Accessibility actions for instance are great.
Even if you could ship chrome renderer on iOS you won’t be able to make a mobile web app feel as good as an iOS app. The little details, animations, and microinteractions that come with native apps are better, plus there are other less visiual capabilities like background uploads and prefetching. The moment you need something like an in app camera, a native app is going to be so much better.
I am old enough to remember the days of Internet Explorer, I can tell you that it was not fun. It is a blessing that we can at least deliver some pretty decent web apps today, and we should keep pushing for it.
Unfortunately we decided the correct way to provide the functionality was by layering bonkers ass abstractions on top of a system meant to largely display static text and images. In the year 2025 there is absolutely no reason we shouldn't have a unified coding language that allows you to render things in a web browser in a sane way.
At the very least we should have seen a substantial expansion of what HTML is capable of, closer to what HTMX is doing now, with a better way to style everything then fucking CSS. People complain about JavaScript but for my money CSS is the greatest sin.
Every other toolkit was not gaining adoption because it was shut down by one or the other corporation owning one or the other system. GTK is mostly irrelevant as it doesn’t do mobile.
Web stuff is best we could get away with circumventing corporate greed and ownership.
Even if we nag technically it could have less complexity - in reality not because all it was required to work around corporate bullshit.
I use inline styles mostly, with an external CSS file only used for a few very global styles. And I try to only use it very simply, avoiding all kinds of clever tricks that some dev think is the mark of good code.
GTK or QT, Java toolkits?
There is no better cross platform way of implementing applications, especially if you want to do mobile in the same stack.
Compare how it feels to use an Electron app like VSCode or Discord to a native app like Zed or Sublime. It's night and day, but the latter takes a lot more effort.
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.
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 don't know how browser standards work. As an end-user, our feedback doesn't seem to be considered (see the recent XSLT discussion), never went through the trouble of finding out.
In terms of implementation, sure we don't need it to be backend aware (was just throwing that out there as a common pattern for which one reaches to components in frontend frameworks). What they could do is build upon datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... . There are two things they could do with that element to make it usable in this context.
1. A loading indicator, which could be enabled with a bool element property while the Javascript code fetches from the server the data and updates the datalist options. 2. Decouples presentation from value. In a standard select field the option's value can be (and often is) different from the label. In the case of datalist it's not possible. It basically autocompletes on the values that also act as labels.
> 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.
On almost all of my personal projects, I just use the built-in date and time pickers available in browsers. I very rarely can do so for client projects, because the inconsistent rendering and patterns across browsers. Having a fixed way of rendering and interacting with those input fields would go a really long way.
You're right on all those things related to constraints, and UX. But for most CRUD experiences you really need only a consistent cross-browser picker, instead of reaching for a component library. Some of what you're talking about can be handled with the browser based Javascript validation, while a couple tailored interfaces makes sense for essential flows where you want to improve user experience.
I've built my fair share of custom forms and controls for the critical flow, but for the common case, accessible (most component libraries weren't in the past) built-in components are better and generally good enough.
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?
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.