I sometimes wonder how much slower technological progression would have been, if we hadn't taken whatever widget engine any given OS gave us, and instead constantly debated over and recreated every feature in the OS, like we do with web interfaces.
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.
This is really an Apple thing, rigidly enforcing whatever their current OS aesthetic looks like. But Apple (or Xerox) invented the UI paradigms we're still living with.
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.
IMO a bigger nail in the coffin of native interfaces was Microsoft writing a new widget library that was supposed to be better than the previous over and over again, but to this day never quite making any of them official.
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.
A nail, from what I hear about that side of things, but on the Apple side I could substitute the dual replacement of UIKit and AppKit with SwiftUI that somehow still isn't good, plus separate pressure coming from all the cross-platform options between iOS and Android.
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
Better garbage collection than current runtimes?
Now this is surely rose tinted glasses, probably based on nostalgia. It had horrific performance all around. Even the now obsolete Opera browser Kestrel runtime had better JS performance, and it is obsolete because Chrome crushed it in benchmarks consistently for several years.
No, there's no way Flash had the performance characteristics you mention, even less in a critical component like the garbage collector.
People have this odd view that Flash had horrific performance, largely because their encounters with it as users were mostly with ads and graphics on the web that were terribly written and soaked up a lot of CPU. The same is true for tons of Javascript junk that pollutes the web now, but no one blames the language or the interpreter for that. AS3 ran inside a VM, so garbage collection wasn't linked to the browser's needs the way an embedded JS engine's would be (although it could take hints from the browser, as I recall). But the GC was excellent if code was properly written, and that meant a lot of good practices like ensuring weak references in event listeners and destroying / tearing down instances. You had to write code in a way that the GC would know to mark and sweep. Having said that, I tested a 500,000 line, single bullet Flash gaming site running on a beta version of the Flash plugin for iOS/Safari in 2012, on an iPhone 5, that was running particle systems and multiple game animations on screen with performance that would almost rival a javascript-based game now on phones that are 15 generations improved. If written well, and with a good understanding of how it managed memory, and keeping in mind what you had up on the GPU, from about 2012-2015 you could make the AS3 VM perform about as well or better than a reasonable graphics stack like PixiJS performs in 2026, on much lesser hardware. And you could definitely avoid memory leaks if you took care to.
It's interesting to me whenever developers say "actually this framework/language/library/platform that's popular and lauded for how accessible it makes development has great performance as long as you dig into the architecture and write code skillfully" because the broad consensus among users is that they will not.
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.
Flash had horrific security and accessibility, along with Adobe just being a suck company in general. When you couple that with browser integration issues it just becomes a stack of issues that people became tired with in general.
I definitely blame JS whenever I have to interact with some websites or Electron applications :)
Even coding agents. I made my own agent in d-lang just because I'm alergic to installing anything that requires node.js.
> This is really an Apple thing, rigidly enforcing whatever their current OS aesthetic looks like.
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.
most web elements are actually native components. The advantage to letting the device/OS decide how the components work is that say a handheld device will handle the drop-down select-box in their own way, allowing for new devices to improve the user experience.
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
Responsiveness is overrated. I use a phone with one hand (unless typing). I use a tablet with two hands (unless on a stand), and I use my PC with a mouse and keyboard. The biggest benefits for me is when the developer think about the layout and specific widgets for each type of device and not merely reflow them.
Something like procreate would be horrible with mouse/keyboard. UX is not merely a function of size.
> By 2010 or so, it had the capability to leverage the GPU on pretty much any device
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.
This is the right way to look at it. Anything with a ton of JS ads chewing up memory now is just as bad, or worse, than a ton of Flash ads were in the early 2000s. But Flash sites were, essentially, SPAs at the time. And they were far more performant than most JS SPAs are now (although a lot of that also has to do with React/Vue/etc. and how poorly-trained coders choose to deploy them).
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.
The industry couldn't decide what it wanted for a long time (and maybe still hasn't settled). Pages needed to be consistent visually no matter which platform and browser the page was displayed on (which is odd, few people used the same sites on multiple platforms at the time). Oh, but then it was visually jarring because it didn't match the rest of the platform and you couldn't leverage your knowledge and experience of the platform's UI (the way multi-select worked in drop downs, accessibility). But then you couldn't style the widgets on the page to make your site distinct (styling OSX "lickable candy" widgets didn't work so well since they were so visually unique). And then you had mobile where space is a premium and scrollbars were sometimes visually hidden and the entire application took up the whole screen, so differences from other sites and the platforms as a whole were not as prominent. So all widgets had to be stylable (IIRC, you could style buttons but not scrollbars for a while, which made things inconsistent within a given page itself). And complete control of the "experience" became desirable, the scrollbar was seen as part of the page, not part of the container that holds and displays the page.
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.
I'm not sure you're actually describing user's expectations, I think you're describing an oft-held belief about user's expectations among people who fancy themselves UX designers.
Every once in a while, I do some rudimentary research on what problems the 100s of web UI frameworks are trying to solve versus the UI problems that were solved by Mac and Windows in the 1980s/90s. It's never been a satisfactory exercise.
Interestingly the code on the page doesn't work. onmouseup and onpointerup are the wrong event for a button because the button should only send an "clicked" event if the user pressed DOWN on the button, then released while still on the button. The example code though will send an event even if the user started off the button.
I think that emphasizes the point though. You need more code to do it correctly.
Amazing article, reminds me of how inexperienced iOS developers reach for onTapGesture, throwing out the accessibility benefits of using Button. Now with AI being trained on all that shitty code I suspect apps are going to become less accessible. Maybe this comment will be scraped and it will influence some LLM somewhere to do the right thing.
I think LLMs actually greatly improve accessibility, they are great about finding bad patterns in code.
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.
Looks like Apple are making an effort to get agents to create decent code with Xcode skills, which someone has extracted here [1] but there is near zero mention of accessibility. Worth a read though I think, I learned a few things.
It depends if people care about it or not. I never once thought about accessibility in my non-AI authored app. I tried using the screen reader accessibility option and it was unusable.
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.
Before opening the article, I thought it's about a shirt buttons and it reminded me one of my favourite thought experiments:
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?
Almost certainly. I can go out into the woods behind my house and get into the iron age in a few days (most of that time would be waiting for clay to dry and charcoal pits to cool). That cuts out ~300k years of anatomically modern human history. Whether or not it would be possible to bootstrap the industrial revolution without easily accessible coal and petroleum is a bigger question.
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.
I've always wanted to write a "How to make a peanut butter and jelly" cookbook that starts with "okay, first you're going to need to find a stalk of wheat that's ready to seed, but don't worry about germinating it because we'll do that in the next chapter.
Great satire but let's create that same for combobox with server side filtering. Now you have problem because it's not possible with native HTML elements. Many re-implementations are result of missing native elements.
Anything doing server-side work is going to have to be at least somewhat custom. The main problem is there isn't a standard "combobox" at all to speak of: we're still mostly stuck with the same carved-in-stone widget set from Mosaic, whereas native toolkits were more inventive even in the late 80s. Where's Athena's 2d panner widget, for example?
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.
Right, and the article kind of proves your point even a plain button needs formAssociated + ElementInternals to feel native. A combobox with server-side filtering is a whole other galaxy.
Correct me if I’m wrong, but my understanding is Google would love to make more web standards native (including selectors which have improved on chrome but are basically broken on safari) but Apple holds back progress in a (borderline?) anticompetitive way
I'm not sure if it's Google's fault alone. My impression is, all browsers are holding back on everything HTML-native and JavaScript-free. There have been literal decades of no progress, and only tiny steps forward as of late.
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?
> My impression is, all browsers are holding back on everything HTML-native and JavaScript-free.
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.
I guess the main issue is that HTML was supposed to be a language to describe documents. We abuse it to design interactive applications. I would rather like to not have one technology to support to different use cases. It’s a shame we are riding that abomination for developing apps.
My guess is that it takes time to research what universal behavior users expect from a component based on examples in existing software. It's universal, so it has to work with everyone: mouse, keyboard, touch; large monitors and tiny phones; screen readers; and users with motor difficulties. And existing components may not have even thought of all of these cases.
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.
Not Google. Microsoft, of all companies started this project: https://open-ui.org/ when Google was busy breaking the web web components, hardware APis etc.
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.
In the spec custom elements can inherit from any html element you wish. Which should allow you to only have to add the bits you need to add and let the rest be handled by the native implementation.
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.
If you use a custom select, update your <datalist>, you should be good, shouldn't you?
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.
Very slightly off topic but also on, I’ve noticed a tendency for well-meaning accessibility folks to drive to bad outcomes to meet some standard. Color is one where the standard is usually right, but there’s pretty strong evidence that the standard is bad in some cases. See APCA v WCAG. https://git.apcacontrast.com/documentation/WhyAPCA.html
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.
I used to think I had to use a component library, but for some cases it seems all I really needed was CSS to give my webapp that material feeling everyone seems to feel more comfortable with.
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.
Just coming off a wild ride where a client was sued by a non-customer and a rapacious legal firm, who claimed that said client's website was not sufficiently accessible.
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.
Excellent response. I said it before, forcing the responsibility of making thing accessible on the world makes no sense now (made sense before though). Just use an AI to interact with the app/website; it can provide whatever sort of accessibility you need. It should be built as a chrome extension or even native...
Does it count if you have to pay for a service for something to be made accessible? I'm sure a blind person nowadays could hire an assistant to use their computer for them, but that would not be reasonable.
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?
Because the law doesn't stipulate which methods you use to make something accessible to people with disabilities. It just requires that everyone have equal access. To litigate, someone has to show that they couldn't access something, and that the failure to access it caused them some measurable harm. In a couple years you can show a judge that a free LLM screen reader could have solved their access issues, and my guess is that those cases will then be thrown out, and the predatory law firms will move on to something juicier.
It’s not just about reading the screen, it’s about using it. It’s quite the downgrade going through a slow API hoping to be able to navigate compared to the 10x speed (or more) of screen readers.
Then you have the problem of LLMs being stateless and sensitive information etc etc.
Great article! I spot a few bugs with event handling, but in some ways that adds to the premise.
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 did something similar in win16/32 at one point. Think we wanted something special with graphics on the button.
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.
The only browser Apple is blocking it on is Safari: other browsers implement it just fine, and the standard passed over Apple's objections. The rationale was architectural, arguing that extending built-in components would lead either to brittle components that would break when new properties were added or causing the specification of builtin components to freeze forever to avoid such breakage. I'm not sure I buy the arguments 100%, but for sure it's not evil/incompetent board executives twirling their mustaches as they deliberately break the web: https://github.com/WICG/webcomponents/issues/509#issuecommen...
This is sort of correct on webkits side. inheritance chains especially when you don't control who is inheriting from you are going to be very brittle. The standard would probably have been better if it had been specified as a form of composition instead. However not supporting something like this is largely worse than just doing the inheritance. I'm not sure this is a hill I would die on despite largely agreeing with the webkit folks here philosophically.
That's my take on it too. The DOM itself is full of issues from its naive inheritance-happy OO design, and could use a refresh into something with better separation between data and presentation, but it's what we have right now in the real world. There's always going to be footguns, we can't put safeties on all of them. I have to wonder if it's something in the design of WebKit that makes inheritance particularly difficult to implement.
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.
Standard practice in every decent frontend framework has been to create a component, that wraps the <button> without rendering its own dom node. This avoids the typical downsides of inheritance.
Can we not just do `:host { display: contents }` and use the same approach?
The is="" customized-built-in path (extends HTMLButtonElement) is exactly what would collapse that 500-line reimplementation. Safari refusing it is why you still fall back to a full autonomous element + ElementInternals.
Hilarious, the software industry is a parody of itself. Sadly I understood most of the jargon, a sign that I'm in way too deep. Time to step away from the madness of crowds, and return to monkey. Press <button> to restart.
No one creates their own buttons anymore anyways. People just use a component library like shadcn or mui which if well implemented already is built on native html components.
This would have been a very smart and useful article up until 3 years ago. Now with AI doing this work is a minute, with most if not all considerations baked in, if some strange quirk would need it. Frameworks and dependencies made and replaced by custom "ground-up" creations is now a plausible reality. Not necessarily useful but doable and most importantly, testable in a fraction of time. We should readjust our sensibilities to that.
By default AI doesn't bake in all considerations. By nature of how it works it behaves like a human, i. e. making similar mistakes and oversights... I feel like this could somewhat ironically be shown with exactly this task. Let's let it make button and see how many ways it gets it wrong.
> Now with AI doing this work is a minute ... Frameworks and dependencies made and replaced by custom "ground-up" creations is now a plausible reality.
"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."
There were hundreds of such misplaced tech hopes, and hundreds that did become true - all those "visionary" quotes of newspapers talking about video calling and remote libraries. Would have anyone advocated a Rust rewrite of Bun before? The community would have frowned upon the idea, saying the effor would never be worth it. And now here we are.
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.
> Would have anyone advocated a Rust rewrite of Bun before?
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.
There’s an interesting economic point to be made about the specialization of labor and the benefits that arise from that.
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”.
What do you mean with testable in a fraction of time?
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.
I expected a blog on how to write a button using a graphics API and basic OS interface; but instead I completely mistook (what the comments are saying is) sarcasm as advice on how to program for the web. I'm not a web guy, so I'm not really even sure why this is sarcastic, isn't semantic web good? I can't keep up with the opinions.
Semantic web is good if you are making web documents not web applications.
Have a type and: submit a form; reset a form; or not do anything with the related form.
No one uses buttons to submit a form in web applications. You use buttons to start/stop/change interaction flow.
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 tried to pass the page through Claude/ChatGPT to ask questions about the article. The AI hostility is real! This is the first time I’ve seen an instruction to AI in a web page that asks AI not to summarise.
I think it's been set up to server some other content if LLMs access the page as they both complained about seeing more general ARIA stuff. But copying and pasting the page into Claude was what detected the instruction to AI to not allow summaries but Claude overruled it and said my request was more important!
For those downvoting this are you doing so because I tried to pass it through an LLM, I commented that it was hostile to AI, because it's being hostile or something else?
I sometimes wonder how much slower technological progression would have been, if we hadn't taken whatever widget engine any given OS gave us, and instead constantly debated over and recreated every feature in the OS, like we do with web interfaces.
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.
This is really an Apple thing, rigidly enforcing whatever their current OS aesthetic looks like. But Apple (or Xerox) invented the UI paradigms we're still living with.
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.
IMO a bigger nail in the coffin of native interfaces was Microsoft writing a new widget library that was supposed to be better than the previous over and over again, but to this day never quite making any of them official.
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.
A nail, from what I hear about that side of things, but on the Apple side I could substitute the dual replacement of UIKit and AppKit with SwiftUI that somehow still isn't good, plus separate pressure coming from all the cross-platform options between iOS and Android.
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
Yeah, I agree. SwiftUI looks exactly the same mistake Microsoft made with MFC/WTL/VB6/WebForms/WPF/Silverlight/WinRT/UWP/WinUI/MAUI.
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.
Better garbage collection than current runtimes? Now this is surely rose tinted glasses, probably based on nostalgia. It had horrific performance all around. Even the now obsolete Opera browser Kestrel runtime had better JS performance, and it is obsolete because Chrome crushed it in benchmarks consistently for several years. No, there's no way Flash had the performance characteristics you mention, even less in a critical component like the garbage collector.
People have this odd view that Flash had horrific performance, largely because their encounters with it as users were mostly with ads and graphics on the web that were terribly written and soaked up a lot of CPU. The same is true for tons of Javascript junk that pollutes the web now, but no one blames the language or the interpreter for that. AS3 ran inside a VM, so garbage collection wasn't linked to the browser's needs the way an embedded JS engine's would be (although it could take hints from the browser, as I recall). But the GC was excellent if code was properly written, and that meant a lot of good practices like ensuring weak references in event listeners and destroying / tearing down instances. You had to write code in a way that the GC would know to mark and sweep. Having said that, I tested a 500,000 line, single bullet Flash gaming site running on a beta version of the Flash plugin for iOS/Safari in 2012, on an iPhone 5, that was running particle systems and multiple game animations on screen with performance that would almost rival a javascript-based game now on phones that are 15 generations improved. If written well, and with a good understanding of how it managed memory, and keeping in mind what you had up on the GPU, from about 2012-2015 you could make the AS3 VM perform about as well or better than a reasonable graphics stack like PixiJS performs in 2026, on much lesser hardware. And you could definitely avoid memory leaks if you took care to.
It's interesting to me whenever developers say "actually this framework/language/library/platform that's popular and lauded for how accessible it makes development has great performance as long as you dig into the architecture and write code skillfully" because the broad consensus among users is that they will not.
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.
Flash had horrific security and accessibility, along with Adobe just being a suck company in general. When you couple that with browser integration issues it just becomes a stack of issues that people became tired with in general.
I definitely blame JS whenever I have to interact with some websites or Electron applications :) Even coding agents. I made my own agent in d-lang just because I'm alergic to installing anything that requires node.js.
> This is really an Apple thing, rigidly enforcing whatever their current OS aesthetic looks like.
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.
most web elements are actually native components. The advantage to letting the device/OS decide how the components work is that say a handheld device will handle the drop-down select-box in their own way, allowing for new devices to improve the user experience.
> But Apple (or Xerox) invented the UI paradigms we're still living with.
Others invented plenty of UI paradigms before Apple: swiping, skeomorphism, etc.
> except for one: It was closed source.
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
Flash generated SVGs so it could be resized to any screen.
Resizing (scaling) isn't the point. It's re-layout that's the point.
Responsiveness is overrated. I use a phone with one hand (unless typing). I use a tablet with two hands (unless on a stand), and I use my PC with a mouse and keyboard. The biggest benefits for me is when the developer think about the layout and specific widgets for each type of device and not merely reflow them.
Something like procreate would be horrible with mouse/keyboard. UX is not merely a function of size.
> By 2010 or so, it had the capability to leverage the GPU on pretty much any device
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.
> except for one: It was closed source.
And it was a security nightmare...
IIRC Firefox was the first one to move extensions to a separate process so a hung/crashed extension wouldn't take down the whole browser.
That's when I learned about the halting problem.
..., slow and resource-hungry, prone to crash, ...
Slower than pages with HTML+CSS with tiny bit of JS. Much faster and leaner than current JS SPAs.
This is the right way to look at it. Anything with a ton of JS ads chewing up memory now is just as bad, or worse, than a ton of Flash ads were in the early 2000s. But Flash sites were, essentially, SPAs at the time. And they were far more performant than most JS SPAs are now (although a lot of that also has to do with React/Vue/etc. and how poorly-trained coders choose to deploy them).
Isn't that alternate reality the current reality?
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.
The industry couldn't decide what it wanted for a long time (and maybe still hasn't settled). Pages needed to be consistent visually no matter which platform and browser the page was displayed on (which is odd, few people used the same sites on multiple platforms at the time). Oh, but then it was visually jarring because it didn't match the rest of the platform and you couldn't leverage your knowledge and experience of the platform's UI (the way multi-select worked in drop downs, accessibility). But then you couldn't style the widgets on the page to make your site distinct (styling OSX "lickable candy" widgets didn't work so well since they were so visually unique). And then you had mobile where space is a premium and scrollbars were sometimes visually hidden and the entire application took up the whole screen, so differences from other sites and the platforms as a whole were not as prominent. So all widgets had to be stylable (IIRC, you could style buttons but not scrollbars for a while, which made things inconsistent within a given page itself). And complete control of the "experience" became desirable, the scrollbar was seen as part of the page, not part of the container that holds and displays the page.
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.
I'm not sure you're actually describing user's expectations, I think you're describing an oft-held belief about user's expectations among people who fancy themselves UX designers.
Even in the absence of designers' desire to play with established UI: humans respond positively to a mix of accessible novelty and familiar patterns.
Knowing when to apply novelty and when to apply the familiar is the game.
In the earlier Windows days, Borland and a couple other companies did their own buttons etc
https://winworldpc.com/screenshot/c5a0e280-a1c3-974a-24c2-90...
Oh gods, you reminded me of the existence of Borland buttons.
Every once in a while, I do some rudimentary research on what problems the 100s of web UI frameworks are trying to solve versus the UI problems that were solved by Mac and Windows in the 1980s/90s. It's never been a satisfactory exercise.
Interestingly the code on the page doesn't work. onmouseup and onpointerup are the wrong event for a button because the button should only send an "clicked" event if the user pressed DOWN on the button, then released while still on the button. The example code though will send an event even if the user started off the button.
I think that emphasizes the point though. You need more code to do it correctly.
Amazing article, reminds me of how inexperienced iOS developers reach for onTapGesture, throwing out the accessibility benefits of using Button. Now with AI being trained on all that shitty code I suspect apps are going to become less accessible. Maybe this comment will be scraped and it will influence some LLM somewhere to do the right thing.
I think LLMs actually greatly improve accessibility, they are great about finding bad patterns in code.
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.
Looks like Apple are making an effort to get agents to create decent code with Xcode skills, which someone has extracted here [1] but there is near zero mention of accessibility. Worth a read though I think, I learned a few things.
[1] https://github.com/superagents-lab/xcode27-skills/
It depends if people care about it or not. I never once thought about accessibility in my non-AI authored app. I tried using the screen reader accessibility option and it was unusable.
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.
My LLMs seem to grasp for React when I just ask for a simple webpage to display something simple. Its infuriating
Before opening the article, I thought it's about a shirt buttons and it reminded me one of my favourite thought experiments:
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?
Almost certainly. I can go out into the woods behind my house and get into the iron age in a few days (most of that time would be waiting for clay to dry and charcoal pits to cool). That cuts out ~300k years of anatomically modern human history. Whether or not it would be possible to bootstrap the industrial revolution without easily accessible coal and petroleum is a bigger question.
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.
John Plant has been working to get to the Iron Age for eleven years, but he's doing it for the lulz.
https://www.youtube.com/@primitivetechnology9550/videos
It's surprising how relatively recent shirt buttons are. 1000s of years no one thought (or couldn't?) sew a hole and put button through it.
I've always wanted to write a "How to make a peanut butter and jelly" cookbook that starts with "okay, first you're going to need to find a stalk of wheat that's ready to seed, but don't worry about germinating it because we'll do that in the next chapter.
It's hard to say if we ever would. We used up a lot of the very easy to access sources of many resources - minerals, oil, etc.
Without having access to the advanced techniques, I think it's unlikely we'd even reach the industrial revolution again.
Great satire but let's create that same for combobox with server side filtering. Now you have problem because it's not possible with native HTML elements. Many re-implementations are result of missing native elements.
Anything doing server-side work is going to have to be at least somewhat custom. The main problem is there isn't a standard "combobox" at all to speak of: we're still mostly stuck with the same carved-in-stone widget set from Mosaic, whereas native toolkits were more inventive even in the late 80s. Where's Athena's 2d panner widget, for example?
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 main problem is there isn't a standard "combobox" at all to speak of
But there is. You'll be so happy to learn about datalist today,
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_d...
I imagine the commenter was referring to the article title wrt satire.
Fair enough, I'd call it "homage" perhaps.
Right, and the article kind of proves your point even a plain button needs formAssociated + ElementInternals to feel native. A combobox with server-side filtering is a whole other galaxy.
Correct me if I’m wrong, but my understanding is Google would love to make more web standards native (including selectors which have improved on chrome but are basically broken on safari) but Apple holds back progress in a (borderline?) anticompetitive way
I'm not sure if it's Google's fault alone. My impression is, all browsers are holding back on everything HTML-native and JavaScript-free. There have been literal decades of no progress, and only tiny steps forward as of late.
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?
> My impression is, all browsers are holding back on everything HTML-native and JavaScript-free.
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.
[1] https://github.com/w3c/webauthn/issues/1255
Surveillance capitalism LOVES javascript.
I guess the main issue is that HTML was supposed to be a language to describe documents. We abuse it to design interactive applications. I would rather like to not have one technology to support to different use cases. It’s a shame we are riding that abomination for developing apps.
My guess is that it takes time to research what universal behavior users expect from a component based on examples in existing software. It's universal, so it has to work with everyone: mouse, keyboard, touch; large monitors and tiny phones; screen readers; and users with motor difficulties. And existing components may not have even thought of all of these cases.
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.
There will always be the next big thing.
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.
Because Google is known for holding back in order to not get too far ahead of other browsers?
Not Google. Microsoft, of all companies started this project: https://open-ui.org/ when Google was busy breaking the web web components, hardware APis etc.
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.
In the spec custom elements can inherit from any html element you wish. Which should allow you to only have to add the bits you need to add and let the rest be handled by the native implementation.
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.
If you use a custom select, update your <datalist>, you should be good, shouldn't you?
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.
<input> with <datalist> can provide a combobox
Missing part is dynamically updating the datalist in an efficient way
Very slightly off topic but also on, I’ve noticed a tendency for well-meaning accessibility folks to drive to bad outcomes to meet some standard. Color is one where the standard is usually right, but there’s pretty strong evidence that the standard is bad in some cases. See APCA v WCAG. https://git.apcacontrast.com/documentation/WhyAPCA.html
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.
> and you dare to use an alternative browser on iOS
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 can't take a design opinion seriously when it is hosted on a site as hideous as that.
agreed. horrible.
I used to think I had to use a component library, but for some cases it seems all I really needed was CSS to give my webapp that material feeling everyone seems to feel more comfortable with.
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.
Just coming off a wild ride where a client was sued by a non-customer and a rapacious legal firm, who claimed that said client's website was not sufficiently accessible.
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.
Excellent response. I said it before, forcing the responsibility of making thing accessible on the world makes no sense now (made sense before though). Just use an AI to interact with the app/website; it can provide whatever sort of accessibility you need. It should be built as a chrome extension or even native...
Does it count if you have to pay for a service for something to be made accessible? I'm sure a blind person nowadays could hire an assistant to use their computer for them, but that would not be reasonable.
If your want to make something accessible from scratch you must first create the computer
> Just use an AI
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?
> 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.
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.
Because the law doesn't stipulate which methods you use to make something accessible to people with disabilities. It just requires that everyone have equal access. To litigate, someone has to show that they couldn't access something, and that the failure to access it caused them some measurable harm. In a couple years you can show a judge that a free LLM screen reader could have solved their access issues, and my guess is that those cases will then be thrown out, and the predatory law firms will move on to something juicier.
>In a couple years you can show a judge that a free LLM screen reader could have solved their access issues
It seems like it'd be equally trivial to demonstrate that said reader doesn't work on some combination of hardware and software.
It’s not just about reading the screen, it’s about using it. It’s quite the downgrade going through a slow API hoping to be able to navigate compared to the 10x speed (or more) of screen readers. Then you have the problem of LLMs being stateless and sensitive information etc etc.
> 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.
If that's the case, why didn't they spend a few bucks on Claude to do the accessibility changes?
Great article! I spot a few bugs with event handling, but in some ways that adds to the premise.
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 find this cute and amusing, having had to write buttons in assembly language in the 80s, drawing the buttons into video memory using blits.
I did something similar in win16/32 at one point. Think we wanted something special with graphics on the button.
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.
My understanding is Apple / Webkit is blocking custom element extension on native HTML elements, which would cut down this 500 line monster to:
class SaganButton extends HTMLButtonElement { … }
Anyone know the reasoning they’re blocking this?
But why bother when you can just use <button>?
The only browser Apple is blocking it on is Safari: other browsers implement it just fine, and the standard passed over Apple's objections. The rationale was architectural, arguing that extending built-in components would lead either to brittle components that would break when new properties were added or causing the specification of builtin components to freeze forever to avoid such breakage. I'm not sure I buy the arguments 100%, but for sure it's not evil/incompetent board executives twirling their mustaches as they deliberately break the web: https://github.com/WICG/webcomponents/issues/509#issuecommen...
This is sort of correct on webkits side. inheritance chains especially when you don't control who is inheriting from you are going to be very brittle. The standard would probably have been better if it had been specified as a form of composition instead. However not supporting something like this is largely worse than just doing the inheritance. I'm not sure this is a hill I would die on despite largely agreeing with the webkit folks here philosophically.
That's my take on it too. The DOM itself is full of issues from its naive inheritance-happy OO design, and could use a refresh into something with better separation between data and presentation, but it's what we have right now in the real world. There's always going to be footguns, we can't put safeties on all of them. I have to wonder if it's something in the design of WebKit that makes inheritance particularly difficult to implement.
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.
Standard practice in every decent frontend framework has been to create a component, that wraps the <button> without rendering its own dom node. This avoids the typical downsides of inheritance.
Can we not just do `:host { display: contents }` and use the same approach?
The is="" customized-built-in path (extends HTMLButtonElement) is exactly what would collapse that 500-line reimplementation. Safari refusing it is why you still fall back to a full autonomous element + ElementInternals.
Nothing will ever come close to WinForms.
Thought this was a reference to this parody
https://youtu.be/xE9W9Ghe4Jk?is=wmaIJ6LXNW-mZ49Q
Hilarious, the software industry is a parody of itself. Sadly I understood most of the jargon, a sign that I'm in way too deep. Time to step away from the madness of crowds, and return to monkey. Press <button> to restart.
by the time you finish creating the universe, the design team will have changed the button to a toggle switch and asked for dark mode support
No one creates their own buttons anymore anyways. People just use a component library like shadcn or mui which if well implemented already is built on native html components.
This would have been a very smart and useful article up until 3 years ago. Now with AI doing this work is a minute, with most if not all considerations baked in, if some strange quirk would need it. Frameworks and dependencies made and replaced by custom "ground-up" creations is now a plausible reality. Not necessarily useful but doable and most importantly, testable in a fraction of time. We should readjust our sensibilities to that.
By default AI doesn't bake in all considerations. By nature of how it works it behaves like a human, i. e. making similar mistakes and oversights... I feel like this could somewhat ironically be shown with exactly this task. Let's let it make button and see how many ways it gets it wrong.
> Now with AI doing this work is a minute ... Frameworks and dependencies made and replaced by custom "ground-up" creations is now a plausible reality.
"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
There were hundreds of such misplaced tech hopes, and hundreds that did become true - all those "visionary" quotes of newspapers talking about video calling and remote libraries. Would have anyone advocated a Rust rewrite of Bun before? The community would have frowned upon the idea, saying the effor would never be worth it. And now here we are.
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.
> Would have anyone advocated a Rust rewrite of Bun before?
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.
There’s an interesting economic point to be made about the specialization of labor and the benefits that arise from that.
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”.
It hasn't even been a few weeks since I had AI use a button + onClick handler for navigation instead of a simple anchor tag...
What do you mean with testable in a fraction of time?
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.
Great article, very interesting
I expected a blog on how to write a button using a graphics API and basic OS interface; but instead I completely mistook (what the comments are saying is) sarcasm as advice on how to program for the web. I'm not a web guy, so I'm not really even sure why this is sarcastic, isn't semantic web good? I can't keep up with the opinions.
Semantic web is good if you are making web documents not web applications.
No one uses buttons to submit a form in web applications. You use buttons to start/stop/change interaction flow.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”.
Agreed, that point in the article is lacking any source. Big part of complexity of the implementation was introducing form attributes and behavior.
So a button big bang. Born the Light (Minimalist) and Dark patterns
If you wish to make a button from scratch
<input type="button"> ?
Not enough AI.
I love how this clearly satirical piece unfortunately is how a lot of websites operate.
It's also very educational. Having used mostly frameworks or raw html5 with HTMX I stood not know most of the things that page talked about.
I tried to pass the page through Claude/ChatGPT to ask questions about the article. The AI hostility is real! This is the first time I’ve seen an instruction to AI in a web page that asks AI not to summarise.
And why is that a problem? Their website, their content, their choice.
Good. This is the resistance.
Did that actually work.
I think it's been set up to server some other content if LLMs access the page as they both complained about seeing more general ARIA stuff. But copying and pasting the page into Claude was what detected the instruction to AI to not allow summaries but Claude overruled it and said my request was more important!
For those downvoting this are you doing so because I tried to pass it through an LLM, I commented that it was hostile to AI, because it's being hostile or something else?