The crazies part is that when we actually research it, a default button is about 20% faster than the the flat nonsense we've settled on (https://www.theregister.com/offbeat/2017/09/05/its-official-...) and nearly a decade letter we still prefer looks over usability.
Look at the progress of Flash/AIR AS3 as an embedded runtime prior to its annihilation. By 2010 or so, it had the capability to leverage the GPU on pretty much any device, directly uploading bitmaps and shaders. It had garbage collection as good as or better than any existing [modern] JS engine, had strong types and compile time errors. It was better and cleaner than the modern fractured Typescript-and-canvas web app gaming paradigm in every respect, except for one: It was closed source.
I'm not a fan of AS3's demise, nor of the current state of affairs. We are stuck a decade ago because of it.
But I can also imagine a world where Adobe has a stranglehold in 2026 on most cross-platform game development, and where little arose to compete with it outside their ecosystem. And they've become such a hideous company blinded to their users, even without the advantage they used to have of dominating browser plugins, that I can see now maybe it was for the best that they're not the guardians of the way we do things anymore.
The anarchic process of creating standards is messy, and it results in a huge amount of wasted effort by developers. And it's often a lot less fun.
On the other hand, the job is to make shit using whatever is available.
Instead, I've had people from Microsoft itself recommending me to "just write it in HTML, there's no standard" and "accessibility sucks with native".
When you have the market leader telling you to write HTML for their OS, it's a carte blanche to do it everywhere.
At this point, I think HTML+JS is able to be a better choice than SwiftUI for most things: Yes, some stuff will still need to go to a native layer, but that's true for HTML as well. ;P
It's not just that I think, using their native components also ensures accessibility and consistent UX throughout different apps, which is a huge benefit to e.g. screen reader users. Everyone else - especially web interface builders, especially if they eschew just using native elements - reinvents the wheel and considers accessibility as an afterthought.
At least we have laws now that mandate accessible websites for corporates, in addition to government sites.
And it was a security nightmare...
That's when I learned about the halting problem.
For whatever reason, developers and some users expect an app to look the same across all platforms, while also looking distinct from other apps—otherwise, the app looks indistinguishable from a low effort one. This involves creating a design system and departing from each operating system's native widgets.
Knowing when to apply novelty and when to apply the familiar is the game.
You can literally run a "open this codebase and improve accessibility where you can" and get mostly perfectly good changes. Models and harnesses can be tuned to prioritize it by default, but usually the developer only needs to nudge it a bit to get good accessibility.
I prompted Claude to "make my app accessible and usable with a screen reader" and it pretty much did a perfect job making it usable. *
* I'm not a a11y expert so "perfect job" might be an overstatement, but it made the app completely navigable by me using a screen reader.
I didn't read any satire in the article at all, it just laid out all the built-in behaviors that a proper button has, and how much work it is to reimplement all of them. Something declarative and CSS-like would have been ideal for customizing elements, but instead we got the half-assed Custom Elements API and the completely different DX atrocity that is Web Components.
I can't really fault Custom Elements too much though, it's an imperfect API for an imperfect DOM and it's better than waiting forever for perfection. But I don't extend the same generosity to the Web Components spec.
The one exception is Safari which has been slowly getting more and more special over time when it comes to web standards but is still relevent. If Safari found their way to supporting it then you shouldn't need to completely re-implement a button or combobox and instead just improve the native versions.
We've had things like https://doc.qt.io/qt-6/qtwidgets-module.html since the late last millenium. Back in the day, there was Delphi, now there is Lazarus, with even nicer Data-Bound widgets. Look at some tutorial for those, that's like magic, and also from before 2000!
Does anyone know why there have been 3 lost decades in native HTML widgets? Any ideas how to fix this?
Somewhat tangentially, the official response to a request for WebAuthn without JavaScript[1] was that the big websites don’t care and thus neither do the browsers.
For example, they've recently introduced the Interest Invoker API for tooltips on hover. Tooltips are ubiquitous, but they still haven't settled on what the trigger is for non-mouse users. Long press for touch is far less discoverable than mouse hover, for example.
Maybe it's a good thing they didn't rush this design three decades ago, when virtually all users were on desktop.
Maybe VR glasses will be big soon. Do we trigger on 'blink'? 'look harder'? 'eyeball wiggle'?
Maybe voice interfaces? Trigger on 'say it louder'? 'stuttering'? 'hesitant'?
Maybe guestures, facial expressions, thought patterns? 'think hard about that button to trigger tooltip'? 'furl your eyebrows'?
As I've said, decades have passed with no progress. If progress in other fields is a reason for waiting, it'll be stagnant forever and eventually just dead.
Google was very, very, very late to the project and of course immediately trampled all over it like they did with all the web standards.
Apple isn't holding back progress on that. They are all in on it, though they do tend to be more cautious than the "break fast and lose things" Google.
There are UI components that are not available in native browser controls (infuriatingly: some are only available in some browsers on some platforms), but even then you're better off writing a shim to replicate normal browser behaviour than ruining the experience for everyone because Firefox on Android doesn't have a colour picker.
Missing part is dynamically updating the datalist in an efficient way
If you click any link on this page (to the author’s site) and you dare to use an alternative browser on iOS, it shows a full page modal that can only be navigated around by clicking an “escape” button which tries to execute a Siri shortcut. Apparently in-app browsers are a threat to user freedom, but Orion is caught in the dragnet. Perhaps an example of the paternalist approach to development on the web gone wrong.
The website works just fine for me on Firefox+iOS, it seems like whatever matching the author is doing just doesn't include detection for Orion.
I now have a more critical eye and look into potential UI components code to decide if it really does need the custom code or if styling alone can get the job done.
Shoelace upending everything to Web Awesome has given me an incentive to revisit this rather then blindly find/replacing all the sl- prefixes to wa- given how much larger it makes my bundle.
The day after the lawsuit was filed, a company specializing in accessibility testing mysteriously contacted the client, offering a solution. Client had not even gotten notice of the litigation yet.
The net result of this was several tens of thousands of dollars spent actually removing Aria tags and using standard modern HTML on their aging website, to barely meet some threshold that appeared to be compliant.
The company who did the "work", and I mean, it was barely any work, maybe 100 LoC, stands by it and says the client won't get sued again, as long as they pay for ongoing compliance testing. So it's all a fucking racket.
I pointed out to the client that I didn't think that this half-assed effort was remotely sufficient to actually improve accessibility, but they had an interesting response. Which was this:
In 3 years, all this compliance shit will be out the window, because AI screen readers and agents are going to make the whole point moot.
I can't really disagree with that.
Since the whole compliance racket is totally disconnected from actual accessibility outcomes, why would AI have any impact here?
There’s a standard and a law and money to be made.
It seems like it'd be equally trivial to demonstrate that said reader doesn't work on some combination of hardware and software.
The implementation assumes that onpointerup is mutually exclusive to the other two, but it fires in addition to mouse/touch events. Only onpointerup is needed, if you include onmouseup and ontouchstart then the button action will fire twice.
However, you also need an onpointerdown handler to verify that the pointer press started inside the button. Without it, the button would activate if you started holding down the mouse button outside the button area, and then releasing inside the button area.
class SaganButton extends HTMLButtonElement { … }
Anyone know the reasoning they’re blocking this?
Can we not just do `:host { display: contents }` and use the same approach?
"You only have to want it and believe in it, then it will succeed."
- Count Ferdinand von Zeppelin
"The airship [is] the future of commercial air transport in general."
- Dr. Hugo Eckener
"The age of the airship is no longer a dream of the future; it is a reality of the present. Giant dirigibles will soon cross every ocean, making obsolete the slow surface ships of today."
- Popular Mechanics, December 1929
I'm not saying use custom html elements because we can. But if somehow a html button is a valid technical problem, it can be reasonably done well for the scope of that app.
That’s hardly a “tech hope” or “visionary”. Dirigibles continue to be interesting and fascinating to new generations, even if just as a concept; the language used to write a JavaScript runtime is uninteresting and unimportant in the scheme of things.
> The community would have frowned upon the idea, saying the effor would never be worth it. And now here we are.
Here we are where? Is the Rust release out yet? Didn’t it have tens of thousands of `unsafe` blocks? What’s so great about it? At this point in time, even implying the transition was a success is the same as calling the Hindenburg or the Titanic a success. You’ve seen the thing exists but have no idea how it’ll perform in the real world under real scrutiny and real scenarios. Perhaps that wouldn’t matter had much of Bun was just an internal project used by just one company, but it isn’t.
Just like it is more efficient to have a food system than to have everyone feed themselves from their backyard (if they have one), maybe someday people will realize that it will be more efficient to build things once and re-use.
Similarly, every argument for “AI makes it cheaper so we can do it now” falls apart under “AI also makes it cheaper to not do it”.
Generated tests can help, and if we go into that direction we can now certainly afford to introduce more proven code (Lean/Roq/Frama-C…), but that will still not be wild reality proof until it faces the whole user base and their widely different environments.
And large load of code is still large load of code.
Have a type and: submit a form; reset a form; or not do anything with the related form.
Native browser controls are not workable in a modern web application. It is not that developers are lazy it is that you get requirements from businesses that no one would pay for implementing using native controls because it would cost too much to do it right, where right means „how customers want it and how they want to use it” not „technically right like some native browser control nerds feel world should work”.