You can argue that abstractions hide consequences that fall on users who didn't choose them, but I'd argue back that LLMs likely have a better understanding of a11y conventions than I do as well.

Modern frontend, or the "tower of leaky abstractions", is finally a common-sense mental model for web development. Supplanted by force on top of an exploding bag of eccentricities that is web standards and conventions. The fact that it works at all and is merely a little leaky is an accomplishment in itself.

1. Arguments like this seem to be based on the idea that, prior to AI, most of this type of work was being done by skilled artisans dedicated to quality work product. As I think anyone who actually worked in the industry and is being honest knows, this wasn't the case. There was a lot of mediocrity and worse.

2. I'm not sure the work is "lower quality" depending on how you define "quality". AI might result in an uncomfortable uniformity but at the same time, a lot of AI work product is pretty darn usable because the models have been trained against conventions that, love them or hate them, "work" for the vast majority of end users.

It really feels strangely familiar to me: you could get very far very quickly without any real deeper knowledge and have a working web application within a few minutes. It felt like magic. Then you could customize it within the framework by skimming documentation and googling around until... you couldn't, because you had no clue how any of this really worked internally. And just like with vibe-coded web apps, you could recognize the standard framework web app that was patched together in an afternoon from a mile away, but it very much impressed managers.

Amusingly, I sometimes find that developers talk about their go-to frontier model in the same way that GUI developers talked about their favorite web framework ~15-20 years ago. Personification of the tool, even identification with it, frustration that things that worked with version X got worse with version X.1, "I am developing things 10x faster now", "I am going back to writing XYZ by hand", etc.

This would give the previous generation of frontend developers (aka C/C++ developers) a good chuckle. The web was viewed as a massive lowering of the barrier to entry and a "deskilling" of the craft. Assembly programmers probably thought the same of C/C++ developers.

De-skilling for skills that just aren't that relevant anymore because we've solved the problem (with AI or otherwise) has been a constant in our industry ever since computers were invented.

Move on, learn new skills. And actually effective use of AI is a skill some people seem to be struggling with. Stuff still doesn't build itself. If you can prompt it right, you can get it done. But are you prompting right? Are the tools doing what you ask them to do? How do you know? Did you check? I seem to spend an awful lot of time prompting AIs. I'm definitely getting better at it. But it's still a full time job.

And I'm sure in a decade or so we'll look back on this as a very inefficient way to build software. The tools will get better. The AIs more autonomous, etc. Because if you spend a day doing repetitive things prompting the same things over and over again, somebody or something should probably automate that!

I remember this period differently. The frontend work was mostly, sometimes solely, all about turning whatever monstrous PSD came from the designer’s sick mind into HTML, and getting shafted if the result was not pixel-for-pixel identical. When project leads heard the word “semantic”, they had to reach for the dictionary. Upon hearing the word “accessibility”, they would set the dictionary on fire.

Literally just saw startup demo their app and their app which had that “vibe coded UI” look to it.

They were given devastating feedback of “Guys this is kinda cool, but you obviously had AI build this and thus anyone else that wants this can have AI build it for them too very quickly. As such there’s really no value in what you’re trying to sell here.”

It was cold, but accurate feedback they needed to hear.

Once you are using AJAX and manipulating the DOM the complexity of asynchronous communication is going to lead to something of a similar magnitude as React. Sure you can write

   document.title="A new title"

If there's something wrong with the Reactisphere it isn't that it creates an abstraction which other abstractions live on, but these are leaky abstractions. You could use something like Bootstrap or MUI without understanding CSS if you are making something very simple and don't care what it looks like (don't have a marketing team who cares what it looks like!) but to do pro-level work you can put in front of customers you have to understand HTML, CS, JS and all the the frameworks used in your project.

Not to mention there are 1000X as many skilled engineers and you are competing with a global market. In the early 2000s there was very little competition. The skills of workers are loosely going to correlate with the demands the market puts on them, and it is extremely competitive now.

This was a small part of a large code base. I am afraid what a fully agent coding would look like. How are other developers handling large code bases with ai. Just accept what its providing?

I can now understand the valuation of AI companies. Once you go in ai its difficult to go back. You need to spend more tokens just to make it work. Ai companies could train to make their code more obtuse, making users very hard to change manually!

What does he mean by this? What skills were lost? Writing HTML templates?

Especially elderly people who rarely use devices suffer from this (and their relatives who do IT support :-))

And let's be honest, one of the best changes front-end development has seen is how previously complex problems now have built in, easy to use solutions. Yeah you could say it was harder to code layouts when flexbox and grid didn't exist and you had to deal with floated elements and absolute positioning, but the new setup is just better for everyone.

Customising select menus used to require lots of CSS and JavaScript to remake the element. Now browsers are implementing features to let you customise default select boxes the same way. Having an element expand to auto height use to involve JavaScript. Now it's something you can do in CSS alone. Creating modals used to involve writing CSS and JavaScript. Now an accessible and efficient version can be done with built in tech.

Meanwhile JavaScript frameworks are really just continuing the pattern started by previous tools, like WYSIWYG editors, Content Management Systems, jQuery, etc.

At the end of the day, any tech that gets more advanced will lower the skill floor and reduce the need to care about those minor intricacies. Most people don't need a particularly advanced solution to their problems, so whatever system can automate away most of the work will get used for that. It's not unique to web development or software engineering.

1. Scoping. I give juniors projects that are big enough to be valuable, but not so big that they get lost.

2. Instruction. I give juniors frequent, bite-sized lessons related to their tasks. In this, I invest in their skills.

3. Linting. Anything that could be considered a “nit” in a code review is relegated to machine lints. For example, I will never talk about formatting in a code review. That is solved by tooling.

This article makes me wonder if there’s some sort of machine-readable lint for costly abstraction? In a TS project, is there some way to say, “the shadow DOM under this component is too deep.” Or “this object’s inheritance tree is too long.”

Or for zero/cost abstraction languages, is it feasible/productive to lint “this packages dependency tree is too deep”?

How do you identify abstractions that are too leaky to be helpful?

SVG+CSS+HTML were hailed as the modern replacement for Flash, but nobody ever made an authoring tool suitable for the masses. LLMs are kind of fixing that, just with a very different interface

If FEs want to keep working in this area, I highly encourage them to become excellent designers. Many think they are, but can't quite fly solo without a designer and soar to the same heights.

At the end of the day, I have to make more architectural and business decisions than before - it’s just higher-level and more complex work.

On the other hand, there’s increasingly little reason to hire someone just to write APIs or work on the frontend, since AI handles most of the routine tasks.

So, this feels much more like the Industrial Revolution than “deskilling.”

The period 2015-2025 was a decade of frontenders fooling their managers into letting them build their own job security into their web UI.

Do you really need to go that far back for a comparison? We no longer need human computers to perform tedious calculations, or typists to draft and distribute correspondence.

The simplification of frontend development was never a final state. It has always been continuously evolving through abstraction and automation.

I have been a programmer for a long time and CSS is still the hardest language to master. There are countless quirks and APIs most people have never heard of that solve extremely specific problems.

For example, using @starting-style with allow-discrete to use display: none on CSS transitions. Knowing that you would need to use this API, what it does, and how to debug your CSS is a skill that will be hard to replace with an LLM because of the fine grained detail needed for CSS. If you do not know how this API works and you need to use it for whatever reason, and then need to adjust your transitions later, it's probably faster to have real CSS skills than to constantly have to prompt an LLM for you.

It still is!

> To distinguish what they’re doing from what “frontend” has become, practitioners of this arcane art nowadays often refer to it as the “front of the frontend”.

I have never heard this term before, but I'm sure someone will point me to the bullshit influencer who came up with it?

Frontend frameworks are really just for web apps and most frontend devs are familiar with several. If they cannot also write a web page from scratch, they're not really a web dev. This is not up for debate. If you hire someone for the role, you need them to handle the work. AI is not going to help you here when it gets into the testing and bugfix phase.

Often - the people who are replaced don't recognize the inherent skills of the people who operate the machines that do their work.

But there are often non-obvious tradeoffs.

Having Ikea means we can have vastly, vastly more selection and choice in the things we put in our homes.

And the 'quality' is usually fit for purpose (just because it's not made of Oak, doesn't mean it won't last a very long time).

But when you see a winding staircase or those custom moulds .... well you realize 'what we've lost'.

There's always a trade-off even if the net positive is there.

That 'externalized craftsmanship' sure does add up though ...

In the case of frameworks ( and higher level programming languages ) you are operating at a new layer of abstraction with the specific intent to hide the lower level, that's the whole point of the framework.

LLM's don't actually move the abstraction layer. You're still coding in react/python/whatever high level language. Yes you can generate the code using natural language but you still need to understand what's being generated, verify its correctness, and reason about the system it fits into. LLMs don't hide anything they produce the code you otherwise would've written and hand it to you to review.

This is now officially a pet peeve of mine. I don't write code "by hand" I write code "by brain." A craftsman who does something "by hand" actually needs manual skills to produce that carved wood thing. Even if you know what you want and know what it looks like, you need skill with your hands to make it happen.

Software is not like this. I don't need typing skill, the IDE autocompletes most of it for me. I think about what I want and it becomes reality. If you were using a bare text editor and typing out getters and setters your whole career, sorry, you were just doing it wrong. No wonder you love AI.

I guess some frontend frameworks can abstract it away but most don't and you almost certainly will run into the limitations of those frameworks and then you still need to understand HTML/CSS

that "knowledge" we held was to combat the absolute shit that was the browser ecosystem 20 years ago lol. you could argue it was a time of great experimentation and creativity, but no unified ui/ux patterns, adding in css hacks and doctypes blah blah to try to catch all these weird edge cases, if you're still reminiscing that time not sure what to say. today's tooling while also messy in it's own way is 1000x bettter. also i've never in my life referred to it as "front of the frontend".

https://www.youtube.com/watch?v=JOcz-H5u3Rk

Flash is/was the true time for front end innovation and people making cool unique stuff. html and javascript and usability studies killed all the fun and imagination

Not to be rude but this person doesn't understand the fundamentals of the topic they're discussing.

Frameworks just give patterns and abstractions to build a front-end, but you still have to actually know how to use those things to build a UI. You still have to know HTML, CSS, and JS (assuming you want to do it well, not just slap some junk together). Even with AI, unless you're comfortable shipping a half-working UI, just like programming: sorry dude, you still need to know your shit.

Apparently deskilled people are making it look like this is normal and it supposed to be so.

But i can relate to that. Another examples of deskilling would be, of course, Java, and a more modern example - Rust.

That said, i don't think deskilling is solving mass-production problem. It was already solved with open-source software, or with a software as is.

Software is information and there is little to no cost of copying information. So mass-production isn't the problem that is being solved here.

IMO the problem being solved is that business need unskilled labor, that is slop.

You would think that if business is producing slop, it will be replaced with another business producing quality stuff. If that was so, over time, there won't be any slop on the market, but if you open your app store, you are welcomed by all kinds of slop.

Because slop is what they buy. Supply is only following the demand, business need to produce slop because people are buying it.

How many of you guys have Claude subscription? Do you know that 5 years ago i would be asking "How many of you guy have GitHub Copilot subscription"?

This is what people buy, so it is deskilling, but not a mass-production, it's just slop revolution, slop is the new norm.

I'm sorry but that simply does not make any sense. How is increasing the breadth of your skills leading to a deskilling?

But before React, I don't recall frontend as very inspiring and joyful.

It was fun to see your work immediately on the screen. I did apply skills and had to solve some weird situations. I could optimize our CSS with OOCSS approach (later used in Bootstrap) -- only to complaints -- semantics! too many classes! (my trump card was that their commits contained +200 lines of CSS, while mine mostly had 0 -- and our CSS was already bloated into several megabytes).

But this was a dead end. I tried making tools to find out unused styles, to automate some patterns -- like click a button and load some content over Ajax. But the guys, who copy-pasted code with dumb solution to this, got 2-3x more tickets closed. I proposed a tool to make screenshots of pages and diff them to search for regressions, but the response was it's heavy RnD, we're not a research institute, we got to ship the next popup tomorrow, etc.

Nobody gave a shit much earlier.

Sorry, but developers from 2012 didn’t have proficiency in most of these skills any more back then than they do today. I would argue frameworks introduced a lot of welcome debate and discussion of these things and actually helped disseminate these skills far beyond the “old guard”, not to mention the pressure put on browsers to normalize behavior and the huge improvements to the JS language born out of the induced demand of the huge rise of web apps that were all but unmaintainable in the before-times. Obviating the need to know about browser quirksmodes is a good thing and we have frameworks, in part, to thank for that.

As someone who didn’t really know that being a front-end dev putatively doesn’t involve thinking about those things anymore, I think that list conflates a couple of different things.

Things like the differences between browsers and CSS/HTML quirks, needed to wrangle a document markup language into creating user interfaces, are accidental complexity caused by particular path dependencies, and if they can be abstracted out, that’s a great thing.

Accessibility, interface design, performance, and other things related to user experience, on the other hand? Those are mostly orthogonal. A UI framework can raise (or in some cases lower) the bottom in the sense of facilitating reuse of (hopefully well-designed) components, but no framework is going to make your UI accessible or well designed by itself.

In the fabled past, frontend development didn’t require you to be highly qualified in these matters – web UIs were simply terrible, mostly. High skill level was not required because nobody expected anything from web UIs beyond the barest core functionality.

There was UI programming before the web [citation needed]. In a sense it was "deskilled" because you used a "framework" aka the OS windowing and widget libraries rather than drawing rectangles manually (except in some special cases like games where very custom UI is desired – but those custom controls invariably have roughly 0% of the UX affordances provided by standard ones). Back then, Visual Basic and other RAD tools (anyone still remember that acronym?) were front line of "deskilling", but honestly WYSIWYG visual design is still one of the best ways to create UIs, it’s just rarely done these days for various reasons.

With Stack Overflow, you got multiple answers from different people with different viewpoints and different approaches, each consistent within itself. You could figure out where the author of each answer was coming from and judge whether they seemed to know what they were talking about. You could weigh the trade-offs and merits of the different answers against each other.

With LLMs, you get a single mushy pile of slop, not grounded in any person's actual experience or judgement. It might pretend to offer different perspectives, but it can't really, so it's much harder to evaluate.

you will need 100 times less of front end , if any action can be asked or explain in voice, text or video or slides always custom to your request. you don't need navigation complex forms to structure. just text, animation to wait, and a few way to embed more complex structures, like text and basic html with charts.

this sounds like "almost ui" but in reality it's not. this is text + some custom visuzalizations adhoc.

This is not the lament of the code getting worse (it's not) but the coders losing the knowledge of how to do it by hand without LLMs. If people really wanted to learn how to do things by hand, they can. In fact the AI is probably going to be infinitely more patient and knowledgable than any senior dev if you really wanna do this by hand. Just turn off the AI's ability to modify the code and just have it give you advice on the side.

The reason why nobody does that anymore is because most engineers work for capitalists not artists. It's the same reason I don't know how to farm my own food or make my own clothes like my ancestors did. Most people do programming because it's a job - not because it's an artistic passion. And that's OK.

I've seen people argue that LLMs will just add another layer to the top of the compiler stack: instead of writing code, we'll use English, and run it through a pipeline:

    English -> Rust -> ASM -> Machine Code

But what the author says about agents being "undeterministic abstraction" shows why that will never work.

Compilers rely on a concept called observational equivalence[1] to define when two programs are basically the same; this allows them to make changes under the hood like unrolling a loop or targeting another machine. Now, it turns out we know a lot about how and how not to do this, thanks to a logician named Frege who worked out exactly which properties a "definition" would need to have to count as a definition without becoming an axiom. In particular, that it should be "eliminable" and "conservative"[2]. In plain language, that a formal definition should always be able to be eliminated by rote string substitution, and that it shouldn't smuggle in any extra assumptions. When we talk about things like syntactic sugar[3] or hygienic macros[4], we are basically applying Frege's two conditions to programming languages.

LLMs are neither. They cannot reliably or provably go from the prompts they are given to the source code they generate, and they make a ton of implicit assumptions when they do so. There can never be any equivalence between two "prompts" in the same way that two programs can be equivalent modulo some level of abstraction. The whole process of starting from prompts is wildly nondeterministic, which is why the only pattern that works is to generate the code, review it, and test it, and then check it in and use that as the starting point for the next prompt.

Which is not to say that LLMs aren't useful for code generation; they clearly are. But they don't provide an abstraction that lets us get away from the details of actual code, and thanks to Frege we can understand why they never will.

I can say all this with such confidence because I did once write a wild little Python library that used a bunch of introspection to actually do this[5]. And it absolutely did not work in practice beyond toy examples.

[1]: https://en.wikipedia.org/wiki/Observational_equivalence

[2]: https://plato.stanford.edu/entries/frege/#ProDef

[3]: https://en.wikipedia.org/wiki/Syntactic_sugar

[4]: https://en.wikipedia.org/wiki/Hygienic_macro

[5]: https://github.com/olooney/fourth_gen

>What did previous generations of craftspeople do when everyday goods and buildings suddenly could be mass-produced by industrial processes? One reaction was to copy the style of old, and make the industry crank out widgets and buildings that at least looked like they were handcrafted.

Is this a reaction by craftspeople? I don't think it is, I think this was what industry people did?

>Countering this trend of historicism, an alternative approach was developed by the Bauhaus movement of the early 20th century. Instead of pitting factory workers against craftspeople, their stated goal was to have them work together, and redevelop the arts and crafts with industrial manufacturing processes in mind.

From what I understand the Bauhaus movement has/had a huge influence on modern architecture, which people tend to like less than traditional architecture [1]. It feels weird to have that followed by "Caring about quality and the user".

>The industrialization enabled lots of cheap plastic products, designed by people who didn’t take the time to think how they would be used and by whom – yet good industrial design is still a thing.

>And software like Wix and Next.js enabled the creation of lots of websites that load terribly slow and are not accessible – yet there are still practitioners of the front of the frontend out there.

I think the author really really really underestimates how important is it that something is "cheap". I personally like a lot having the option to use cheap and relatively good stuff, or pricier and better stuff, for most things.

This is a bit stretching the definition of "accessibility" but, I think in a way price should be thought as part of accessibility. If we consider that it's important that websites work well on slow networks, partially because not everywhere in the world has access to good network, partially because good networks cost money ; then I think we should consider that while a good website beats a bad website, sometimes a bad website beats no website. Sometimes a "cheap plastic product" means someone that can't buy the well designed product can still buy a product, and get started in a hobby.

This is pretty bad news for craftsmen I think, but as a software engineer that is very happy to be able to get into crochet or photo or cyanotypes or pottery or hiking for relatively cheap, I can't help but try to see the other side of software getting cheaper.

[1]: https://www.sciencedirect.com/science/article/pii/S026427511...

I’m actually building better UIs just because it became less time consuming to do so.

There is just a super noisy minority that spams the internet with slop so bad that no one can take their product seriously.

This idea that quality ever existed on the web is ahistorical at best.

If LLMs help me never use a front end owned/dictated by a corporation again it'll be no bad thing, regardless of the quality of the code they write.