The asteroid currently hitting front end web development

> For better or worse, React is heavily overrepresented in the training weights, and “agent experience” is starting to matter more than developer experience.

Another winner takes all situation. This and the other post on agent tool use[1] makes me think we are in a period of great homogenization. I'm sure there's a group that's delighted about this but for me, it just makes me feel a little uneasy.

[1] https://armature.tech/blog/which-tools-coding-agents-install

My wife's experience is managing teams and has been involved in creating corporate websites using contractors. She doesn't know anything about html at all. She just manages people.

She's now working on a biotech start-up pre-funding. They have pretty much zero money. They want to redesign their website.

I set her up with my deepseek key and she's been using flash-v4 with image detection (I think deepseek says it's still experimental). She just provides the current website, tells how she wants it to look and it works great. I mean it's obviously ai generated but she gets quick results and is able to tweek things to look better by just telling deepseek what to do. She was even able to change the text in one of their images to its new product name without having to contact the graphic designer.

This is a simple example. Basically it's one of those earlier jobs that you could get someone to bid on for $x but now you can do yourself for $20.

I was originally a Flash developer, when that died when Steve Jobs banned it from iPhones, I pivoted to frontend. I got to see web evolve over the next decade or so and loved every part of it.

Now, still as a frontend engineer albeit much more senior. The writing is on the wall, again. It's time to reskill for AI.

It's not bad news.

We as experienced engineers are needed to help build in the guardrails, frameworks, the new tooling, etc. There is a lot of work that is needed that requires actual engineers with technical experience.

Like the early internet, I see this as a new beginning and we get to decide how it evolves.

> Meanwhile, Cursor and Viget have blogged about migrating their codebases from Solid and Lit, respectively, to React.

That was maddening to read. Here I was thinking we should all be migrating to better performing frontend solutions. Does it really take an agent that many more tokens to write Lit or regular HTML and HTMX?

I can't wait for the asteroid to hit C-Suite and senior execs. These are the most meaningless jobs and easiest to automate, with the most cost savings.

There is going to come one day that companies (and any website owner) will wish they didn't use AI and instead used a simple (maybe even plain-text) website. That will come when people really need information from that website but can't get to it.

https://sparkbox.com/foundry/helene_and_mobile_web_performan...

Discussion regarding that post: https://news.ycombinator.com/item?id=46494734

> If you write a React component with an agent, though, then the risk of just yolo’ing it into production is (typically) much lower.

If your state management gets out of sync with the form controls your users are working with it can become pretty high risk because now users see one thing and something else actually gets sent to the backend.

> The frontend is less risky to just hand to an agent.

The smaller the problem, the less risky it is to do this, regardless of the nature of the problem. This is not a frontend-specific issue today.

In my useless opinion, most people are not aware of how big AI is and how bigger it will be in 3~5 years. It's not worthy to be worried about it, because it will be a global problem, but there are people who are completely blind about it

"Note I’m not saying there are zero risks: the agent could mess up accessibility, it could cause an infinite loop that blocks users, etc. But in general, frontend code is a lot more ephemeral and replaceable than other types of code. So I expect many AI coders will feel comfortable just letting their agent handle it unsupervised (for better or worse)."

This is a weirdly reductive take on frontend correctness. Just for the record, I'm a backend dev. So I don't have much stake in this game.

This idea is, of course, not uncommon. "If the backend has to treat the frontend as adversarial anyway, and has all this cool stuff (constraints etc) for guaranteeing consistency of the system, then the frontend can just do whatever, right?" It plays into a lot of biases around typical frontend devs, typical backend devs, language stereotypes, etc. So it _sounds_ good.

Let me tell you for a moment about one of the spookiest bugs I've seen. It was an app for sorting personal photos. You'd upload pics/vids off your phone, they appear in the UI, you click a folder for them to go into (or click delete to discard), etc. Simple app, right?

Well, naturally, pics from even vaguely modern phones are regularly 5MB or more. Not really something you want to sling around while a user is browsing and their main activity is going to be looking at said pic to decide what folder it goes in (or if it gets deleted). So we thumbnail. And the main app only ever shows the user the thumbnails. The backend organized things quite simply: it gets a list of images from the frontend, it assigns each of them a zero-based index, and generates a thumbnail you'll also access via index. Imagine a URL scheme like `images/0` and `images/0/thumbnail` serving the real assets and the thumbnail.

Well, this app had a bug at one point. The backend was indexing by the arbitrary order the user uploaded them in. The frontend was mostly doing this too. Unfortunately the logic for thumbnails was incorrectly indexing by the "taken time" (which was a post-upload timestamp constructed by looking at basically every available timestamp and picking the "best" one. i.e. hopefully the one the iOS camera app adds, but obviously pics come from other places too and you never know what a user will upload). The end result being users would upload pics, see a thumbnail of an accidental pic they took of their shoe, hit delete. But actually they were deleting a pic of their baby or similar.

Literally none of the testing caught this for 2 main reasons: headless tests don't look at images, and you can't write an assertion like ("does this image look like a downscale of this other image") (at least not easily... i guess image models could do it now? but probabilistic? not a word i like in my unit tests? I digress, this predated the current crop of "AI").

Now let me generalize: your frontend isn't just a weird way to call RPCs on your backend. It's part of the application. I don't think you can just hand-wave. And as we saw above, you can't even say "well the frontend is stateless! any bug is 1 deploy away from fixing!" - deploying the frontend didn't get anyone their baby pictures back.

Maybe I'm an outlier here but I moved into front end to steer products and the resultant architecture into making sense from the incomplete or contradictory "requirements" we got from product and even UX. I've been doing this for over 20 years and every company has needed good engineers to make the product a logical reality.

LLMs piping out UIs from PM prompts aren't solving that imho.

  Prompt: Answer without searching the internet:

It already slurped "the internet". You can't seriously say it doesn't count!

>But in general, frontend code is a lot more ephemeral and replaceable than other types of code.

Tell that to Digg.

If you slop oit a front-end, your users will leave. It's that simple. The front-end is the part the users use the most, nobody cares how "elegant" your APIs are, or what kind of database the system uses. The front-end matters to users, a lot.

I've seen AI take a perfectly good front-end and slop out a piece of crap that will make the users leave in droves. And when nobody raises their hand (or in my case, everyone else is in the grip of AI psychosis) then bad times are ahead.

In a related but less public way, I've found myself less motivated to write internal documentation at work. It feels like in a lot of cases, it'd be better for the reader to throw Claude at the codebase to explain things.

A separate document explaining how a system works can go out of date. While I'm quite good at highlighting the most important insights and non-obvious traits of a system, I'd still be guessing what the reader needs from my doc at the end of the day. Claude can answer questions based on what the reader is curious about and wants to learn.

Some types of document are still useful, namely higher-level directional or philosophical topics about the intention of a codebase. e.g. "we would like to eventually move X system to Rust for Y reason", "we chose mutable data structures over immutable in this part of the system because Z". But fewer than before.

I offer this, as someone who is heavy into AI development (as a coding assistant, not vibe-coding). I was pretty fast before and now I'm easily an order of magnitude faster.

* I scrutinize every line of backend code and frequently make revisions.

* I pay just barely enough attention to the frontend code to make sure it's not doing anything dumb.

* I pay zero attention to the CSS.

Either our expectations for UI interaction are going to go up a lot, or FE devs should start looking at product management roles. I think the asteroid metaphor is apt.

As someone who loves FE the slop people are pushing where I work is really quite upsetting to me.

I reviewed some code earlier which clearly wasn't intended for consumed by humans and I know with certainty this dev wouldn't have understood 90% of what that code did. It looked like hours of Claude trying to force square into a round hole tbh, but it worked.

Was I going to reject the PR because of my code preferences? No, of course not. Ultimately it doesn't matter anymore. If Claude can maintain it then who cares... Even if it's broken (which it didn't seem to be) it's just FE anyway so not the end of the world.

I wish it did matter of course, but like most of coding these days, it just doesn't.

Being a programmer in the era of AI now means configuring the AI and run environments to produce the sought result, than manipulating the code itself. It's like how C runs on top of assembly.

[dead]

[dead]

writing about your dates with an ai prompt are not that interesting