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?
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.
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.
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.
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.
But there is. You'll be so happy to learn about datalist today,
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_d...
It took forever but safari mobile got it right.
Extra fun to be had if you attempt to dynamically update the list.
Conclusion: utter garbage, stay away from it.
I just typed this by hand (lol) in 3-4 minutes:
https://jsfiddle.net/tjc4mpxe/
This is what we are waiting for? This is what is taking so long for browsers to support?
Missing part is dynamically updating the datalist in an efficient way
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.
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.
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.
"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.
In a same vain, why create functions or classes, when AI can rewrite the code in place and keep track of rules.
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.
And it was a security nightmare...
That's when I learned about the halting problem.
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.
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
Is it a better interface and developer experience? For sure. Is it gonna replace the previous API? Doubtful.
I have to admit I'm still ignoring it though.
As a user, comparitive "performance" is about the code people actually write, and even more on the code that I'm most likely to interact with. I don't actually care whether or not the code could be faster if it was written better, because it always could, and it never is. When people say "Electron is slow and bloated" they don't mean that exhaustively written Electron apps could never" be performant, they mean that apps that use Electron tend to be slow and bloated. The way to change that reputation is not to argue that Electron could* be fast if people held it right, but to make it easier and more natural for Electron apps to be faster than they currently are.
So I do understand why it got that reputation. But I'm using Javascript's raw performance in 2012 as an objective point of comparison. Consider a browser game. Given well-written JS coded with a competent understanding of the engine architecture versus well-written Flash, rendering the exact same animations, effects and interactions, you would find that the framerate in Flash could stay 25-30 fps on an iPhone 5, and be < 10 fps in Javascript. And that was with an alpha version of the Flash plugin. Similarly for JS bundled in Electron versus AS3 in the AIR engine as a "native" app. I know, because I wrote one of the first game engines for Javascript that attempted to do a subset of what could be done in Flash at the time.
What did make the dev process in Flash truly accessible was that it allowed the artists' pipeline to work in the same environment as the coders'. That did sometimes give rise to poorly written apps, but the fact is that the same thing in JS would have been even slower and more battery-draining, in an apples-to-apples comparison.
There are fewer browsers than native GUI environments but we still couldn’t make that work…
Others invented plenty of UI paradigms before Apple: swiping, skeomorphism, etc.
If your device was running Windows sure. On Linux, Flash absolutely sucked with 100% CPU usage to render the most basic still image and on Android it was kind of similar.
Two, it was not responsive. It was written for fixed sizes with keyboards and mice. Not portrait displays with touch screens, nor AR/VR displays with pointers/hands, and for resolutions of the day, not reflowing / resizing to fit the user's device
Something like procreate would be horrible with mouse/keyboard. UX is not merely a function of size.
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.
Ultimately the browser was recognized as its own platform and had to support all the customizations and accessibility concerns. User stylesheets are a thing, but few used that for much more than hiding annoying elements, and today the most likely user customizable thing is being able to switch between light and dark modes.
https://winworldpc.com/screenshot/c5a0e280-a1c3-974a-24c2-90...
Even Hollywood movies show better UIs than modern crap.
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.
Look, the goal is not to make things accessible. The goal is, out of generosity of the society (and I fully support it), to allow disabled people to access the services. Before recent times, it was only meaningfully possible thru building accessible friendly websites/apps.
This has always been a hit and miss. Usually only the super big companies did it right (see Google apple Ms) or people using big company's framework with some carefulness. But for the most, it didn't work out. That's why so much complaint against websites being inaccessible.
Now we have a better way. Use a local AI to consume or interact with the content. This will empower the disabled far more than they currently are. Apple will probably lead the way here.
Yes.
> What next? You don't have legs so everyone around you must carry you?
Too stupid to engage with.
Obviously society has to accommodate (i.e. spend money for) people who are disabled or unable to interact with it due to inalienable features of their body. Anything other than that is just cruel.
You mean like (a) assume this perfect AI that already exists never makes a mistake because AI doesn't do that, (b) accept all the security risks like prompt injection, (c) accept the fact that you don't deserve to enjoy the same privacy over your life as others do?
B. Like you accept the risk of running scripts? Or getting zero day thru your browser? Ridiculous. Sandbox it.
C. Local LLM is enough. Nothing needs to go to a server.
If that's the case, why didn't they spend a few bucks on Claude to do the accessibility changes?
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”.
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.
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.
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?
As for potential property collisions, I think the common wisdom is to just ensure the property name contains a dash, since the html5 spec goes out of its way to avoid using them. Doesn't solve brittle inheritance hierarchies in general, but it does at least stay out of the way of built-in behavior.
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.
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.
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.
Imagine everything man-made suddenly disappears but not the knowledge individuals carry. How long until we have an iPhone (or a plastic shirt button)? Would it even be any faster than the first time around?
Without having access to the advanced techniques, I think it's unlikely we'd even reach the industrial revolution again.
We might lose electricity for a while. There's not a lot of utility for electricity in pre-industrial society. Like, given enough copper, I could make a wind turbine, but I can't casually make a useful lightbulb. Maybe a ceiling fan, but it would almost certainly be easier to run that off of mechanical power directly via a series of gears and belts. Electrochemistry would be a neat party trick, but I don't think my shoddily built wind turbine would generate enough juice to process aluminum.
Firearms would probably continue to exist. I could make a musket, and its utility for hunting and defense would make it immediately worth it. Black powder's not terribly difficult to manufacture from base ingredients.
Are we including domesticated crops as "man-made"? Because that would complicate matters. A lot of knowledge could be lost in the time it takes to rebreed the kinds of grains that allow for stable settlement.
We wouldn't need to re-invent writing, since that's just knowledge, and that would give a pretty big leg up in not losing a bunch of knowledge every time someone dies.
On the whole, if we keep selectively bred crops, I'd say we'd be bumped back to about the Middle Ages at the most. If we're losing the crops, then it would come down to whether we could preserve our more advanced knowledge long enough for agriculture to redevelop.
Seems pretty optimistic based on the Primitive Technology videos.
Respectfully, this is laughable given the constraints.
All of the post-apocalypse LARP scenarios other responses are describing tend to assume at least books and some small number of durable structures survive. If nothing at all makes it, the first thing that happens is most everyone not living on a ground floor dies instantly from falling. Everyone living where it freezes dies in a few hours from exposure. Most people living anywhere experiencing a heat wave die from heat exhaustion in the next day or two. Most everyone else everywhere else dies from starvation or disease in the next few weeks. Even if you're living on a farm, you've got no fences or tools, so you better hope it's a farm with lots of edible plants and it's near harvest season. If you live in a city, you have no hope at all. Even existing food stores will spoil quickly with no containers or refrigeration. The people who do the best will be Hadza and uncontacted tribes and what not that lose their spears and tents, but all they have to do to get back to their prior situation is make more spears and tents, which thankfully doesn't require a global transportation network or modern manufacturing techniques. They're not the ones who know how to build iPhones, though. I'm not sure anyone knows how to build an iPhone, really. The knowledge is probably largely digital. The chief engineer at Apple knows where to look and who to ask, but no single person has all of the knowledge in their own head.
I am not really trying to get to anything except to have fun thinking about how society would organise itself. And since this is not an exam, everyone's free to think through different versions and enjoy the question as they like.
As for me, normally it comes up in a discussion and we develop and make assumptions as we go, but I've prefer to change as little as possible e.g. buildings/infrastructure do disappear but people "land" gently. And then most of what you said would be true: people in inappropriate climates, far away from a source of water or food die. I don't think it makes the thought experiment any less interesting to think about. In fact, the reason I like it is because progress may become so slow that some generations later we'd start believing or question in mythical iPhones and technologies.
We basically had to recreate all of the actions of focus/unfocus/etc. Everything a normal button could do. Now that I have done more stuff I a know for a fact I made my life way harder than it should have been and could have subclassed. But it was a full button recreation. Styling messaging and all. You have to watch for things like what if someone clicks outside of your button but lets go inside the button. What does that mean? All sorts of weird side effects. What if your button has focus and someone starts typing? What if someone clicks outside of your button but holds the button down as they slide across your button? What does that look like?
Would I ever do it again. Probably not. Seriously use the built in ones.
I think that emphasizes the point though. You need more code to do it correctly.