Hacker News new | ask | show | jobs
by K0nserv 162 days ago
Having worked on a design system previously I think most people, especially non-frontend developers, discount how hard something like that is to build. LLMs will build stuff that looks plausible but falls short in a bunch of ways (particularly accessibility). This is for the same reason that people generate div-soup, it looks correct on the surface.

EDIT: I suppose what I'm saying is that "The paid products Adam mentions are the pre-made components and templates, right? It seems like the bigger issue isn't reduced traffic but just that AI largely eliminates the need for such thing." is wrong. My hunch is that AI has the appearance of eliminating the need for such things.

5 comments

I think you're overestimating how much people care about quality.
If you can produce something that works 80% of the time for 5% of the cost? People take that all the time when they buy cheap shit off Temu or Amazon.

They almost completely just give money back if it fails/sucks, and they are still coming out ahead.

Amazon (AWS) is not cheap! :D
It's not that people care about quality, but that people expect things to "just work".

Regarding the point about accessibility, there are a ton of little details that must be explicitly written into the HTML that aren't necessarily the default behavior. Some common features of CSS and JS can break accessibility too.

None of this code would obvious to an LLM, or even human devs, but it's still what's expected. Without precisely written and effectively read-only boilerplate your webpage is gonna be trash and the specifics are a moving target and hotly debated. This back and forth is a human problem, not a code problem. That's why it's "hard".

I use the web every day as a blind user with a screenreader.

I would 100% of the time prefer to encounter the median website written by Opus 4.5 than the median website written by a human developer in terms of accessibility!

That's really interesting. Are you speaking from experience with websites where you know who authored them or from seeing code written by humans and Opus 4.5 respectively?
So I have been using the human-authored web since well... 1999 or so, starting with old AOL CDs. I've obviously seen a lot of human content.

Back in the old days you might have image links and other fun stuff. Then we entered the era of flash. Flash was great, especially the people who made their whole site out of it (2004 + not being able to order ... was it pizza? something really sticks in my memory here.)

Then we entered the era of early Bootstrap. Things got really bad for a while -- there was a whole Bootstrap-Accessibility library people ended up writing for it, and of course nobody actually used the damn thing. The most frustrating thing at this point (2010?) was any dropdown anywhere. Any bootstrap dropdown was completely inaccessible using typical techniques, and you'd have to do something tricky with ... mouse routing? Gods it's been 15 years.

CAPTCHAs for stupid things became huge there for a brief moment -- I remember needing to pass a CAPTCHA to download ... was it Creative drivers? That motivated me to make a service called CAPTCHA-Be-Gone for other blind people for a while.

Then we see ARIA start to really come into its own... except that's a whole new shitshow! So many times you'd get people who thought "Oh to add accessibility, we just add ARIA" and had no fucking idea what they were doing, to the point where the most-common A11y advice these days has become "Don't use ARIA unless you know you need it."

Oh then we had this brief flash (~10 years ago?) of "60 FPS websites!" -- let's directly render to the fucking canvas, that'll be great. Flutter? ... Ick!

Nowadays the issues are just the same as they ever were. People using divs for everything, onclick handlers instead of stuff that will be triggered with keyboard... Stuff that Opus just doesn't do!

I guess I've only been using Opus 4.5 for about a month but just ... Ask it to build something? Use it with a screen reader? Try it!

> Then we see ARIA start to really come into its own... except that's a whole new shitshow!

I am not blind, but my experience trying to write accessible web pages is that the screen readers are inconsistent with how they announce the various tags and attributes. I'm curious what you think about the screen readers out there such as NVDA, JAWS, VoiceOver, TalkBack, etc. and how devs should be testing their web pages.

Many of the larger corporate clients tend to standardize on the exact behavior of JAWS and I am not sure that is helpful. It's like the Internet Explorer of screen readers.

If you want to know why a page ends up riddled with ARIA overriding everything, that's why. In even the best cases, the people paying for this dev work are looking for consistency and then not finishing the job. It's never made the highest priority work either since testing eats up a ton of time.

To reinforce my original point, I just don't think LLMs can write anything but the most naive code and everyone has opinions and biases completely incompatible with standardization. It's never "done" and fundamentally fickle and political just like the rest of the web.

Knowing obscure things you need to do for accessibility is actually something I would expect an llm to be pretty good at.
Satisfying constraints like these isn't merely about knowing the spec and having lots of examples. Accessibility requirements are even more subjective than ordinary requirements already are to begin with.
Accessibility is an interesting space for quality because under the ADA you can be sued for it and be exposed to huge liability.
But accessiblity on the frontend is to a large extend patterns - if it looks like a checkbox it should have the appropriate ARIA tag, and patterns are easy for an LLM.
That kind of pattern was easy before AI.

It's just… a lot of people don't see this on their bottom line. Or any line. My awareness of accessibility issues is the Web Accessibility Initiative and the Apple Developer talks and docs, but I don't think I've ever once been asked to focus on them. If anything, I've had ideas shot down.

What AI does do is make it cheap to fill in gaps. 1500 junior developers for the price of one, if you know how to manage them. But still, even there, they'd only be filling in gaps as well as the nature of those gaps have been documented in text, not the lived experience of people with e.g. limited vision, or limited joint mobility whose fingers won't perform all the usual gestures.

Even without that issue, I'd expect any person with a disability to describe an AI-developed accessibility solution as "slop": because I've had to fix up a real codebase where nobody before me had noticed the FAQ was entirely Bob Ross quotes (the app wasn't about painting, or indeed in English), I absolutely anticipate that a vibe-coded accessibility solution will do something equally weird, perhaps having some equivalent to "As a large language model…" or to hard-code some example data that has nothing to do with the current real value of a widget.

Accessibility testing sounds like something an LLM might be good at. Provide it with tools to access your website only through a screen reader (simulated, text not audio), ask it to complete tasks, measure success rate. That should be way easier for an LLM than image-based driving a web browser.
Oh no I'm very cynical about that.
I think perhaps the nuance in the middle here is that for most projects, the quality that professional components bring is less important.

Internal tools and prototypes, both things that quality components can accelerate, have been strong use-cases for these component libraries, just as much as polished commercial customer-facing products.

And I bet volume-wise there's way more of the former than the latter.

So while I think most people who care about quality know you can't (yet) blindly use LLM output in your final product, it's completely ok for internal tools and prototyping.

LLMs are not that cheaper, a customizable accessible component is still worth hours of work.
The Tailwind Team's Refactoring UI book was a big eye opener for me. I had no idea how many subtle insights are required to create truly effective UX.

I think people vastly underestimate just how much work goes into determining the correct set of primitives create a design system like Tailwind, let alone a full blown component library like TailwindUI.

While I believe you, its an argument that artists bring forward since the beginning of art, so even many hundred years before the internet on average humankind did not value this work.
> design system ... discount how hard something like that is to build.

This is probably a good thing. The web would be much better off with fewer design systems.

It's not that hard to build a design system with decent accessibility. Just use shadcn ui components instead of rolling your own.
It's not really a refutation of my point about how building a good component library is hard, to suggest using another component library. Of course, if you use one it's easier, that was my entire point.
shadcn ui is not a component library but the basis for a component library that has great accessibility built-in from the start, so yes, it is a refutation.
You're thinking of Radix primitives which Shadcn is built on, but both are component libraries.
Maybe we're arguing semantics, but I think calling shadcn a "basis for a design system" is more accurate than a traditional component library. The difference to me is that shadcn lives inside your codebase and you can fully customize it as you please. You cannot customize a component library like MUI nearly to that extent.