I'm sure I'm not alone in feeling the "deep expertise" OP laments was actually deeply inconvenient to many people. I understand that there's a good living to be made from knowing browser quirks, hand-rolling accessible components, mastering CSS specificity, but this is largely accidental complexity. More people building things is straightforwardly good, and if some of those things are slower or less accessible, that's a tradeoff people are entitled to make.
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.
That's all true - I taught myself how to code from 2009-2012 so I remember what it was like. However, around that time there was also deep focus on architecture, an obsessive focus on rendering performance and page weight. Everyone could recite the loading sequence that HTML pages used, we knew how many requests could be downloaded in parallel, how to best bundle assets for the fastest time to render, etc. So it was a mix of both pain and frustration on one hand, and a pride in one's work on the other hand.
Both have been lost; good riddance the former, but I miss the latter.
The problem is, mastering accessibility, intuitiveness, compatibility, responsiveness, scalability, architecture, performance, and all those other less immediately visible, "forward-thinking" parts of UX/software development has always been difficult. Ultra high-level frameworks and now LLMs have, on the other hand, made it even easier to botch all of these and quickly roll out a half-baked MVP. The gap between "acceptable" and "decent" has thus been widening. As a protagonist of "decent", you have it increasingly harder competing against those pushing for "acceptable". And the push is understandable as well, it's MVPs that make money and details only "increase customer satisfaction" at best (and these days, who even cares about customers?).
The end result is more crunch and a sharp decline in software quality, maybe even job satisfaction in general. As an (unfortunately anecdotal) example, I started to find myself fixing up broken websites or removing elements that get in the way with dev tools and uBlock every once in a while, and have heard from other people on here that they have been doing the same (https://news.ycombinator.com/item?id=47042747). All to restore basic functionality of websites I go on. This was never required back in the day, Flash and early web browsers didn't even have the option to do this.
>I'm sure I'm not alone in feeling the "deep expertise" OP laments was actually deeply inconvenient to many people.
And I'm sure I'm not alone in feeling that the convenience from ignoring the "deep expertise" and piling on hacks and lazy abstractions, all the way to modern multi-MB frameworks and Electron, is a regression.
Of course no one gives a shit about things like the user's computer/memory utilization. Or degraded experience. Or wasted bandwidth. Or the extra energy costs per 8 billion people - and the environmental impact.
>More people building things is straightforwardly good,
Is more people building public infrastructure "straightforwardly good"? If it means worse roads, worse bridges, systems that fail?
The same holds for software. And most things really.
> I'd argue back that LLMs likely have a better understanding of a11y conventions than I do as well.
No, other people did. They wrote about it, and LLM can sometimes use that. Once they no longer write about it, what then?
> More people building things is straightforwardly good, and if some of those things are slower or less accessible, that's a tradeoff people are entitled to make.
That I agree with. The more the merrier, all else being the same. And if "AI" trickled into everything because of the undeniable improvements it leads to, the situation and most of the sentiments would be very different, I think.
But even then, people aren't entitled to the knowledge "created" by doing the work. If attribution and compensation were tackled in earnest, if you could only train on the materials of the people you pay to produce those materials, it might be much quicker and cheaper to just learn CSS.
> More people building things is straightforwardly good
Is it? More than a decade ago there was a Cambrian explosion of software, Flash alone was the defining force of indie gaming industry. And now what? We have so much shit/shovelware that nobody wants to touch with a ten-foot pole.
Totally. Every "we're losing our craft" article has the same gloomy shape. That's enough of a bummer, but they also argue against themselves halfway through.
This one, for instance:
> But exactly which details are deemed “unimportant” is a very consequential and sometimes subjective decision. And eventually, the details always leak through.
Right, so you're saying this new technology will still reward deep technical understanding, because there's no way around it. I agree. Why is the whole tone of this thing "AI is making my craft a cheap commodity?"
Websites are largely better, technically, than they were 10 years ago. They're more full-featured, they're faster, SSL/a11y/responsiveness are stronger defaults. Content mills / SEO / news sites are a separate, terrible failure mode of ads and corporate incentives. That's not React's fault!
I used to make a living doing frontend development, and quirks and knowing idiosyncrasies is a burden to your craft. Yes, it meant there were higher barriers to entry, but it also resulted in a lot of broken websites, and I can tell you it was never fun nor rewarding.
I think the original author has a much stronger thesis around AI devaluing the craft of coding, but his specific examples don't stack up.
Is it? I know hating CSS is a fun pastime for folks around here, but maybe it’s just that building good, rich user interfaces that people can use is an inherently hard problem.
Sure, the browser is slightly more difficult due to maintaining backwards compatibility and multiple implementations, but I’ve yet to see a better UI framework/language that has to deal with the other constraints of the web platform.
"Frontend's Lost Decade" has nothing to do with a11y or semantic HTML. The original talk argues performance went to hell because of React and friends, which is why we have electron CRUD apps that consume 2GB+ RAM.
It doesn't seem to me that the author is saying 'AI bad, abstraction bad, knowing browser quirks GOOD'. Looks to me like someone making a specific claim about a trend where having an easier time getting off the ground can lead to a lower ceiling.
I'd read it kind of like 'The man and the butterfly' story. Or the Kant passage about how doves might wish air didn't exist, without realising that friction is exactly what permits them to fly.
Exactly. Nobody wants smalltalk programmers or IIS whisperers. You just have to embrace the idea that your skills become worthless every five years and move on.
>...and if some of those things are slower or less accessible, that's a tradeoff people are entitled to make.
It depends. My country (Germany) introduced accessibility laws recently which enforces you to build everything public with accessibility in mind. If a page doesn't meet the expected standard you can get extremely high fines.
Yes it's still bad there's no viable headless UI in browser one can really style and it has all the a11y etc. but need extra library for selects that work etc. Invented work for no good reason. The real complexity is in diversity of devices though nowadays in the frontend.
> More people building things is straightforwardly good
No it's not, its the opposite actually its very bad and leads to far far more noise in the system to sort through to find value as someone who's competent.
> the "deep expertise" OP laments was actually deeply inconvenient to many people
This reminds me of the Upton Sinclair quote: “It is difficult to get a man to understand something when his salary depends upon his not understanding it.”
LLMs feel threatening to anyone who had an edge by knowing how to navigate domains with a lot of weird and complex behavior. It’s nice to feel like businesses need you if they want to solve a problem. It’s scary when a cheaper solution arrives that does 70% of that deep knowledge navigation at 1% of the cost.
Yesterday we saw on the frontpage that LLM’s can’t even accurately assess if California produces literally all the almonds in the world.
The really weird gaps and inconsistencies just make it to untrustworthy. I spend so much time vetting all the outputs that it often cancels out the time it saves me, and I find enough errors that I don’t have an incentive to streamline things/not vet it.
Making UI less accessible is specifically not a trade off people are entitled to make. Accessibility is a legal requirement. This is like arguing it's ok to use robot construction workers who forget to install wheel chair ramps because "gotta go fast".
It really depends, up until recently (January) reading all the Temporal doc and doing the courses allowed me to frequently suggest to the current frontier model things they didn't remember. I don't know if this changed recently.
Each time you say that an LLM "understands" something better than you do, you also say that you're not actually qualified to judge the LLM's understanding.
being able to increase both a11y and i18n even if imperfect are definitely a LLM value add; the problem is simply business. This doesn't make the heat->cash register bling.
The "frontend skills" whose growing irrelevance are bemoaned in this article consist largely of navigating a minefield of unintuitive edge cases, browser incompatibilities, historic baggage, exceptions to exceptions to exceptions.
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.
> a common-sense mental model for web development.
You are contradicting yourself. Either its a "minefield...of edge cases..." Or it's a common-sense model. Not both.
I'm convinced we're still in this minefield of edge cases, not in a situation where we've solved all this, and where the tech to build "frontend" is clean, predictable, free of historical baggage etc etc etc.
All we have done, is plaster over these foundational mistakes and invcompatibilities. We haven't solved them. React doesn't solve the fact HTML was never designed to be a UI toolkit. Next.js doesn't solve the fact that JavaScript is full of design mistakes that prohibit it from ever becoming a safe, sane, reasonable (literally) language. Tailwind doesn't solve the problem of CSS being haphazardly introduced to style a markup which was never designed to be styled. Etc.
All LLMs now do, is having the "knowledge" of the horrors under the plaster, in a statistical model that was trained on examples from an era where 99% of the examples are hardly more than plastering to fix the ever reappearing cracks in the previous layers of plaster.
I've interviewed far too many nextjs experts who couldn't do anything else. That's not a skill, that's just knowledge, which at this point is freely available.
> And we’re saddened that the new process results in lower quality work, and that a lot of people just don’t seem to care.
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.
>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.
I think this is more of "another brick in the wall." There was already a LOT of pressure to do the bare minimum to fulfill requirements and then declare success. Now, those pressures seem insurmountable.
This is something that recently also crossed my mind. I haven't really done frontend developing for at least 10 years know, but I am already old enough to remember the time in the late 2000s when suddenly everyone stopped developing web GUIs by hand and used frameworks, and anyone still writing HTML, CSS, JS and database queries by hand was ridiculed. Job offers suddenly stopped asking for PHP / HTML / CSS / SQL / JS skills and demanded Ruby on Rails and Django and Spring and GWT, later Angular skills.
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.
On the other hand, using frameworks later on was a good attempt to standardize things. Having some homegrown GUI nobody knows how to work with isn't an advantage either.
Personally I refuse things that "feel" too big (Nuxt/Next), but like Vue... Currently though, I want to get rid of most Javascript so I'll work my way to HTMX or Alpine type solutions with server side templates.
Personally the less tech I use the better, there was a time where you had all kinds of bullshit in a web app prior to even adding a single line of custom code.
I must say that already in the early 2000s web developers were tired of hand-coding everything, and many sought some sort of automation -- a framework, a CMS. Already in 2004 I made a site with barebone approach -- put a txt in a diretory tree and let PHP simply add tags instead of linebreaks and insert it into HTML. The alternative those days was a heavy content management systems. And I came to Django after two awful PHP frameworks, written by lead developers at the workplaces. So, frameworks like Django were a more gradual transition, and they were much more pleasant to work with.
Sure, as you pushed it further, like add versioning to objects, things got very tricky and not guaranteed to work, and no way to fix.
While AI coding helps a ton in building product prototypes, it also results in products that folks spot as AI from a mile away.
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.
We're in the software industry. The whole point of that industry is automating things that are very repetitive. Frontend projects are very repetitive. And now AI is doing that for us. Fantastic, fees up a lot of time to build more interesting things.
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!
> Just like artisans and craftsmen that were replaced by assembly line workers more than a century ago
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.
Isn't a lot of this complexity going away for good reason? Browser compatibility was only an issue because browsers didn't stick to the standards closely enough. It's something that's not supposed to be noticeable at all.
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.
Sometimes I think the techniques we used to build complex user interfaces in HTML without AJAX or DOM manipulation back in the early 2000s are effectively lost, like the techniques used to build the pyramids: insofar as younger full-stack developers have been "deskilled" many of them think you need Javascript to, say, validate forms.
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"
and not have to bring in <Helmet> but even if you think of front end as "just" updating the UI when data comes in from the server a complex application may need to update several bits of the UI and at some point you need to create some kind of communication or state management bus that handles that. Could it have been done differently? Sure.
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.
You talk about deskilling. But are these skills even relevant to the ultimate goal of producing a web page according to the design specification? Should we have been worried about the "deskilling" that happened when we transitioned from punch cards to high level languages?
We already had a phase of "deskilled" frontend development: Adobe Flash. Any designer could open it and create interactive websites in it, no CSS or HTML knowledge required. Some slight JS knowledge (rebranded as ActionScript) you could get full interactivity, and animations were fully editable in UI. Sure, all of this came at a terrible price: no accessibility, no SEO discovery, huge loading times. But it also created some of the most innovative and artistic front ends. And a lot of things that should have never seen the light of day
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
“Some slight JS knowledge (rebranded as ActionScript)” is laughably inaccurate - the was a deep familiarity with AS and all its quirks to make a performant, durable, responsive GUI in Flash. There were layers to consider when shipping a self contained executable ala Adobe Air - there were other alternative IDEs and compilers apart from Flash proper - fonts, frames, bitmaps vs vector graphics, how audio and video embedding were handled - it was a complete platform, every bit as complex a battlefield as the browser wars.
Hand-waving AS3-driven app development in the 2010s as ‘some slight JS knowledge’ makes me doubt you were actually there. I was there, and that was not what was happening.
> Any designer could open it and create interactive websites in it, no CSS or HTML knowledge required.
Please note that that "any designer" should have had at least a fairly decent knowledge of ActionScript because Flash wasn't all just magic and sparkles. I know this because I was one of them. Though I had to learn ActionScript by neccessity, I actually learned HTML/CSS/JS before needing to deal with AS
Right. And Flash wouldn't end until Jobs won't come out on stage and say that Flash is eating the battery and Apple won't support Flash in their next iPhone, then Flash just ceased to exist. Apparently nobody needed innovative frontends anymore ¯\_(ツ)_/¯
There is no break pedal on this stuff, it just rolls down the hill until eventually it doesn't. It's a runaway process that feeds itself.
I'm not entirely convinced the framework comparison holds.
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.
> Just like AI is deskilling programming now, JavaScript frameworks have deskilled frontend development in the last decade.
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.
I don't think we should blame the LLMs, frameworks and the libraries necessarily. In my own experience, it feels like the real problem is a lot of companies (especially start ups) like to talk about "rapid prototyping", but are quite keen to just keep the prototype as the final product. Bootstrap, Rails, Tailwind, Nextjs and now LLM generated code... great for getting something up quickly with a semi-polished look to demo a thing. The real problem is that we're selling prototypes as products.
I have a slightly different take on deskilling argument. I don't think AI is going to deskill. Someone who has spent 10 years working in any field before AI is not going to get lose too much. Yesterday I sat down to solve a medium hackerrank problem without any assistance (code complete, AI etc) and it took me 10-15 minutes to get into that mode but i was able to do it comfortably just like how i used to do it pre-chatgpt. AI might unskill the younger workforce which will enter the field, aka they will never learn the way we did.
The term applies to the skills required from workers, not to how the skills of an individual evolve over time. The argument is that AI lowers the skill requirements for software development, and therefore less skilled workers will displace the more skilled ones because they are cheaper, as (allegedly) happened in front end over the past decade.
I just vibe code the html and css. I review the JS, but I figure if the flow of data is correct, I can just verify the html/css code through manual testing
I don't agree that you don't have to know CSS/HTML when you use a frontend framework.
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
My previous employer fired all front-end developers a few years ago, we went back from tons of frameworks (Vue/jQuery/Ruby/Nextjs) to simple HTML and CSS. Turns out dedicated front-end developers aren't really needed, at least not where I was employed.
I worked mostly on frontend in 2012-16, in plain HTML+CSS, and then quit, because React was required everywhere, and I tried and hated it.
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.
Are we getting some real data in any industry really where AI eating jobs? I was kinda expecting those to kick in by now, but don't think it's happening.
> frontend used to be a highly specialized skill, requiring knowledge of semantic HTML, CSS, the differences of various browsers, accessibility, progressive enhancement, network performance, interface design and user testing
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.
And knowing the differences between various browsers meant negotiating whether the layout being 3px off on Internet Explorer was acceptable, or whether we should ship different CSS files for different browsers to fix this discrepancy
I think there might have been two overlapping periods, but it definitely started out as you said. What I wonder is, will AI increase frontend churn, or calm it down? (More churn would be, new frontends because of new frontend frameworks, AI accelerated, less churn would be, because AI is trained on what existed before)
I think I also reject the premise of the article, that frameworks caused frontends dev to de-skill. For sure, that happened to some extent. But it also caused a lot of frontend devs to be incredibly skilled in their chosen niche. (React for instance.)
> Just like AI is deskilling programming now, JavaScript frameworks have deskilled frontend development in the last decade. As someone who started with HTML/CSS and a bit of PHP, later did Ruby on Rails, and then was frontend team lead of a major Swiss newspaper (Next.js at the time), I’ve seen the transformation first-hand.
What does he mean by this? What skills were lost? Writing HTML templates?
Very interesting, i didn't know that frontend developers experienced deskilling before. I thought that slop was the usual way of doing things in frontend (or backend).
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.
Everyone had a chance to learn vanilla js from the mozilla docs but using jquery was much much simpler. Concede that jquery is more difficult than prompting. The issue for me is that prompting a front end and everything looks exactly the same. More cookie cutter than what wordpress and wix offered
My humble opinion: “deskilling” is an illusion. Sure, I don’t write code by hand anymore, but I spend most of my time using the knowledge and “sixth sense” I’ve developed throughout my career to control what AI is doing.
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 article compares LLMs to Stack Overflow and calls it "a continuation of the same trend", but I think there's a big difference.
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.
> A lot of programmers may not know this, but frontend used to be a highly specialized skill, requiring knowledge of semantic HTML, CSS, the differences of various browsers, accessibility, progressive enhancement, network performance, interface design and user testing
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.
I'm allegedly a fullstack dev, often working on fullstack features, but I haven't had to think deeply about much on the frontend all year. 90% of my thought/work goes into backend work. The AIs just handle the FE stuff easily based on our existing patterns. Not saying it's perfect or can't be improved, but it pretty much always "just works" perfectly well enough.
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
What's one more layer, right?
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.
I mean, maybe it was a "lost decade" from the perspective of frontend developers, but I can't say I'm nostalgic for an age where everyone is handrolling everything from legacy browser support to responsive designs and I'm hoping they have a good understanding of all these things because the average page would be much worse than it is with everyone using these libraries.
Opening with this claim of ‘Front end’s Lost Decade’ then not explaining what that is is infuriating to me, a front end developer - which decade was this supposed to be? How/Why was it ‘lost?’ How did I miss it?
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.
The part on the Bauhaus movement is weird, and I'm not sure I agree about how the author thinks about users.
>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.
I’m using AI to create UIs and I find myself having more time to think about UX rather than CSS. It actually gave me “time” to quickly test design ideas an implement minor details.
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.
I think it's more likely to cause a lost Decade of people not going into CS or tech due to lack of entry-level jobs. Maybe next time there's a boom and the pendulum of the power dynamic between management and labor swings more towards the workers, tech workers will unionize or organize better. I think overall it will benefit the industry because these boom and bust cycles for employment are just not healthy.
There is no guarantee that there will be a boom again. Some jobs disappear. Maybe we'll really only need a handful of elite engineers who continue advancing the foundational tools we use (kernels, databases, hyperscale low level cloud products, drivers, etc.) and the rest of "programmers" and "software engineers" will be replaced by "prompt engineers". With a new generation mostly unable to read and reason about source code.
> frontend used to be a highly specialized skill, requiring knowledge of semantic HTML, CSS, the differences of various browsers, accessibility, progressive enhancement, network performance, interface design and user testing – to just name a few.
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.
Honestly I think what is missing is not developers but designers. Or, I should say, designers hired to create competent designs that serve people well and not to instead manipulate users. If you want better front ends - get more and better designers! As for front-end code, I don't expect to ever write a line of that again in my life.
People don't use web tech because they care about quality, they target it very specifically because its one of the places where quality doesn't matter. If your native app crashes, your users will curse your name. Webpage or Electron slop freezes? They'll shrug and restart.
This idea that quality ever existed on the web is ahistorical at best.
> JavaScript frameworks have deskilled frontend development in the last decade. As someone who started with HTML/CSS and a bit of PHP, later did Ruby on Rails, and then was frontend team lead of a major Swiss newspaper (Next.js at the time), I’ve seen the transformation first-hand
I'm sorry but that simply does not make any sense. How is increasing the breadth of your skills leading to a deskilling?
Read in context. He's referring to the evolution of skill at group level, he even puts out the definition of deskilling and mentions 'skilled labor'. He then explains how frontend used to be a 'highly specialized skill', and how modern devs use Frameworks to consider browsers almost hidden compilation targets.
The article explains at length what they mean by "deskilling" and it does not mean that individuals lose their skills.
The author having worked with various technologies over time is also not an example of "deskilling", it's a way of asserting that they have had time to observe the deskilling of the domain (since deskilling means a particular domain requires less specialised skills than it did before, not that the workers are losing skills) happen.
Just watch the terrible soup produced by MIT-bred Leetcode ninja "engineers" in money raining startups and FAANGs.
Low accessibility, terrible performance, lack of any fundamentals of html and css, abuse of those awful solutions like Tailwind or using 2016 technologies like React for rendering what should mostly be static websites + some web component, all plagued by memory leaks and very basic usability bugs.
I'm sure I'm not alone in feeling the "deep expertise" OP laments was actually deeply inconvenient to many people. I understand that there's a good living to be made from knowing browser quirks, hand-rolling accessible components, mastering CSS specificity, but this is largely accidental complexity. More people building things is straightforwardly good, and if some of those things are slower or less accessible, that's a tradeoff people are entitled to make.
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.
That's all true - I taught myself how to code from 2009-2012 so I remember what it was like. However, around that time there was also deep focus on architecture, an obsessive focus on rendering performance and page weight. Everyone could recite the loading sequence that HTML pages used, we knew how many requests could be downloaded in parallel, how to best bundle assets for the fastest time to render, etc. So it was a mix of both pain and frustration on one hand, and a pride in one's work on the other hand.
Both have been lost; good riddance the former, but I miss the latter.
The problem is, mastering accessibility, intuitiveness, compatibility, responsiveness, scalability, architecture, performance, and all those other less immediately visible, "forward-thinking" parts of UX/software development has always been difficult. Ultra high-level frameworks and now LLMs have, on the other hand, made it even easier to botch all of these and quickly roll out a half-baked MVP. The gap between "acceptable" and "decent" has thus been widening. As a protagonist of "decent", you have it increasingly harder competing against those pushing for "acceptable". And the push is understandable as well, it's MVPs that make money and details only "increase customer satisfaction" at best (and these days, who even cares about customers?).
The end result is more crunch and a sharp decline in software quality, maybe even job satisfaction in general. As an (unfortunately anecdotal) example, I started to find myself fixing up broken websites or removing elements that get in the way with dev tools and uBlock every once in a while, and have heard from other people on here that they have been doing the same (https://news.ycombinator.com/item?id=47042747). All to restore basic functionality of websites I go on. This was never required back in the day, Flash and early web browsers didn't even have the option to do this.
Another, less anecdotal example from a while ago: https://news.ycombinator.com/item?id=47390945
It gets worse when you realize that most of the money saved through these cuts only benefits the very top of the hierarchy.
>I'm sure I'm not alone in feeling the "deep expertise" OP laments was actually deeply inconvenient to many people.
And I'm sure I'm not alone in feeling that the convenience from ignoring the "deep expertise" and piling on hacks and lazy abstractions, all the way to modern multi-MB frameworks and Electron, is a regression.
Of course no one gives a shit about things like the user's computer/memory utilization. Or degraded experience. Or wasted bandwidth. Or the extra energy costs per 8 billion people - and the environmental impact.
>More people building things is straightforwardly good,
Is more people building public infrastructure "straightforwardly good"? If it means worse roads, worse bridges, systems that fail?
The same holds for software. And most things really.
> I'd argue back that LLMs likely have a better understanding of a11y conventions than I do as well.
No, other people did. They wrote about it, and LLM can sometimes use that. Once they no longer write about it, what then?
> More people building things is straightforwardly good, and if some of those things are slower or less accessible, that's a tradeoff people are entitled to make.
That I agree with. The more the merrier, all else being the same. And if "AI" trickled into everything because of the undeniable improvements it leads to, the situation and most of the sentiments would be very different, I think.
But even then, people aren't entitled to the knowledge "created" by doing the work. If attribution and compensation were tackled in earnest, if you could only train on the materials of the people you pay to produce those materials, it might be much quicker and cheaper to just learn CSS.
> More people building things is straightforwardly good
Is it? More than a decade ago there was a Cambrian explosion of software, Flash alone was the defining force of indie gaming industry. And now what? We have so much shit/shovelware that nobody wants to touch with a ten-foot pole.
Totally. Every "we're losing our craft" article has the same gloomy shape. That's enough of a bummer, but they also argue against themselves halfway through.
This one, for instance:
> But exactly which details are deemed “unimportant” is a very consequential and sometimes subjective decision. And eventually, the details always leak through.
Right, so you're saying this new technology will still reward deep technical understanding, because there's no way around it. I agree. Why is the whole tone of this thing "AI is making my craft a cheap commodity?"
Websites are largely better, technically, than they were 10 years ago. They're more full-featured, they're faster, SSL/a11y/responsiveness are stronger defaults. Content mills / SEO / news sites are a separate, terrible failure mode of ads and corporate incentives. That's not React's fault!
I used to make a living doing frontend development, and quirks and knowing idiosyncrasies is a burden to your craft. Yes, it meant there were higher barriers to entry, but it also resulted in a lot of broken websites, and I can tell you it was never fun nor rewarding.
I think the original author has a much stronger thesis around AI devaluing the craft of coding, but his specific examples don't stack up.
> this is largely accidental complexity.
Is it? I know hating CSS is a fun pastime for folks around here, but maybe it’s just that building good, rich user interfaces that people can use is an inherently hard problem.
Sure, the browser is slightly more difficult due to maintaining backwards compatibility and multiple implementations, but I’ve yet to see a better UI framework/language that has to deal with the other constraints of the web platform.
"Frontend's Lost Decade" has nothing to do with a11y or semantic HTML. The original talk argues performance went to hell because of React and friends, which is why we have electron CRUD apps that consume 2GB+ RAM.
Most of software engineering is accidental complexity. Sharding, buffering, caching, load balancing, contention, async, functions, classes, recursion…
Big corporations behind LLMs are taking it all.
> More people building things is straightforwardly good
I still don’t understand this perspective, how is it good when a growing portion of stuff that’s built is straight garbage?
It doesn't seem to me that the author is saying 'AI bad, abstraction bad, knowing browser quirks GOOD'. Looks to me like someone making a specific claim about a trend where having an easier time getting off the ground can lead to a lower ceiling.
I'd read it kind of like 'The man and the butterfly' story. Or the Kant passage about how doves might wish air didn't exist, without realising that friction is exactly what permits them to fly.
Exactly. Nobody wants smalltalk programmers or IIS whisperers. You just have to embrace the idea that your skills become worthless every five years and move on.
>...and if some of those things are slower or less accessible, that's a tradeoff people are entitled to make.
It depends. My country (Germany) introduced accessibility laws recently which enforces you to build everything public with accessibility in mind. If a page doesn't meet the expected standard you can get extremely high fines.
Yes it's still bad there's no viable headless UI in browser one can really style and it has all the a11y etc. but need extra library for selects that work etc. Invented work for no good reason. The real complexity is in diversity of devices though nowadays in the frontend.
> I'd argue back that LLMs likely have a better understanding of a11y conventions than I do as well.
To make the obvious counterargument, “then you shouldn’t be creating websites at all”.
I don’t actually believe this, but I know people who do. Some would add “shouldn’t be allowed to”.
> More people building things is straightforwardly good
No it's not, its the opposite actually its very bad and leads to far far more noise in the system to sort through to find value as someone who's competent.
> the "deep expertise" OP laments was actually deeply inconvenient to many people
This reminds me of the Upton Sinclair quote: “It is difficult to get a man to understand something when his salary depends upon his not understanding it.”
LLMs feel threatening to anyone who had an edge by knowing how to navigate domains with a lot of weird and complex behavior. It’s nice to feel like businesses need you if they want to solve a problem. It’s scary when a cheaper solution arrives that does 70% of that deep knowledge navigation at 1% of the cost.
Yesterday we saw on the frontpage that LLM’s can’t even accurately assess if California produces literally all the almonds in the world.
The really weird gaps and inconsistencies just make it to untrustworthy. I spend so much time vetting all the outputs that it often cancels out the time it saves me, and I find enough errors that I don’t have an incentive to streamline things/not vet it.
Making UI less accessible is specifically not a trade off people are entitled to make. Accessibility is a legal requirement. This is like arguing it's ok to use robot construction workers who forget to install wheel chair ramps because "gotta go fast".
> that's a tradeoff people are entitled to make
The users are also entitled to hate your website or app. At what point do you admit you're just making excuses for cheap and sloppy work?
It really depends, up until recently (January) reading all the Temporal doc and doing the courses allowed me to frequently suggest to the current frontier model things they didn't remember. I don't know if this changed recently.
Each time you say that an LLM "understands" something better than you do, you also say that you're not actually qualified to judge the LLM's understanding.
being able to increase both a11y and i18n even if imperfect are definitely a LLM value add; the problem is simply business. This doesn't make the heat->cash register bling.
The "frontend skills" whose growing irrelevance are bemoaned in this article consist largely of navigating a minefield of unintuitive edge cases, browser incompatibilities, historic baggage, exceptions to exceptions to exceptions.
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.
> a common-sense mental model for web development.
You are contradicting yourself. Either its a "minefield...of edge cases..." Or it's a common-sense model. Not both.
I'm convinced we're still in this minefield of edge cases, not in a situation where we've solved all this, and where the tech to build "frontend" is clean, predictable, free of historical baggage etc etc etc.
All we have done, is plaster over these foundational mistakes and invcompatibilities. We haven't solved them. React doesn't solve the fact HTML was never designed to be a UI toolkit. Next.js doesn't solve the fact that JavaScript is full of design mistakes that prohibit it from ever becoming a safe, sane, reasonable (literally) language. Tailwind doesn't solve the problem of CSS being haphazardly introduced to style a markup which was never designed to be styled. Etc.
All LLMs now do, is having the "knowledge" of the horrors under the plaster, in a statistical model that was trained on examples from an era where 99% of the examples are hardly more than plastering to fix the ever reappearing cracks in the previous layers of plaster.
I think your ignorance is showing.
There is far more to it than all that.
I've interviewed far too many nextjs experts who couldn't do anything else. That's not a skill, that's just knowledge, which at this point is freely available.
That's true and it also seems like the bundle of C, Unix conventions, and so on, is similar in a way, but older and so we're more used to it.
> And we’re saddened that the new process results in lower quality work, and that a lot of people just don’t seem to care.
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.
>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.
I think this is more of "another brick in the wall." There was already a LOT of pressure to do the bare minimum to fulfill requirements and then declare success. Now, those pressures seem insurmountable.
> the idea that, prior to AI, most of this type of work was being done by skilled artisans dedicated to quality work product
Some of us were lucky to have a few periods in our career where this was the case. I would agree that this disappeared prior to AI.
This is something that recently also crossed my mind. I haven't really done frontend developing for at least 10 years know, but I am already old enough to remember the time in the late 2000s when suddenly everyone stopped developing web GUIs by hand and used frameworks, and anyone still writing HTML, CSS, JS and database queries by hand was ridiculed. Job offers suddenly stopped asking for PHP / HTML / CSS / SQL / JS skills and demanded Ruby on Rails and Django and Spring and GWT, later Angular skills.
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.
On the other hand, using frameworks later on was a good attempt to standardize things. Having some homegrown GUI nobody knows how to work with isn't an advantage either. Personally I refuse things that "feel" too big (Nuxt/Next), but like Vue... Currently though, I want to get rid of most Javascript so I'll work my way to HTMX or Alpine type solutions with server side templates. Personally the less tech I use the better, there was a time where you had all kinds of bullshit in a web app prior to even adding a single line of custom code.
I must say that already in the early 2000s web developers were tired of hand-coding everything, and many sought some sort of automation -- a framework, a CMS. Already in 2004 I made a site with barebone approach -- put a txt in a diretory tree and let PHP simply add tags instead of linebreaks and insert it into HTML. The alternative those days was a heavy content management systems. And I came to Django after two awful PHP frameworks, written by lead developers at the workplaces. So, frameworks like Django were a more gradual transition, and they were much more pleasant to work with.
Sure, as you pushed it further, like add versioning to objects, things got very tricky and not guaranteed to work, and no way to fix.
But otherwise, yes, the attitudes look similar.
While AI coding helps a ton in building product prototypes, it also results in products that folks spot as AI from a mile away.
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.
We're in the software industry. The whole point of that industry is automating things that are very repetitive. Frontend projects are very repetitive. And now AI is doing that for us. Fantastic, fees up a lot of time to build more interesting things.
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!
> Just like artisans and craftsmen that were replaced by assembly line workers more than a century ago
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.
Isn't a lot of this complexity going away for good reason? Browser compatibility was only an issue because browsers didn't stick to the standards closely enough. It's something that's not supposed to be noticeable at all.
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.
Sometimes I think the techniques we used to build complex user interfaces in HTML without AJAX or DOM manipulation back in the early 2000s are effectively lost, like the techniques used to build the pyramids: insofar as younger full-stack developers have been "deskilled" many of them think you need Javascript to, say, validate forms.
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
and not have to bring in <Helmet> but even if you think of front end as "just" updating the UI when data comes in from the server a complex application may need to update several bits of the UI and at some point you need to create some kind of communication or state management bus that handles that. Could it have been done differently? Sure.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.
You talk about deskilling. But are these skills even relevant to the ultimate goal of producing a web page according to the design specification? Should we have been worried about the "deskilling" that happened when we transitioned from punch cards to high level languages?
We already had a phase of "deskilled" frontend development: Adobe Flash. Any designer could open it and create interactive websites in it, no CSS or HTML knowledge required. Some slight JS knowledge (rebranded as ActionScript) you could get full interactivity, and animations were fully editable in UI. Sure, all of this came at a terrible price: no accessibility, no SEO discovery, huge loading times. But it also created some of the most innovative and artistic front ends. And a lot of things that should have never seen the light of day
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
“Some slight JS knowledge (rebranded as ActionScript)” is laughably inaccurate - the was a deep familiarity with AS and all its quirks to make a performant, durable, responsive GUI in Flash. There were layers to consider when shipping a self contained executable ala Adobe Air - there were other alternative IDEs and compilers apart from Flash proper - fonts, frames, bitmaps vs vector graphics, how audio and video embedding were handled - it was a complete platform, every bit as complex a battlefield as the browser wars.
Hand-waving AS3-driven app development in the 2010s as ‘some slight JS knowledge’ makes me doubt you were actually there. I was there, and that was not what was happening.
> Any designer could open it and create interactive websites in it, no CSS or HTML knowledge required.
Please note that that "any designer" should have had at least a fairly decent knowledge of ActionScript because Flash wasn't all just magic and sparkles. I know this because I was one of them. Though I had to learn ActionScript by neccessity, I actually learned HTML/CSS/JS before needing to deal with AS
Good news is that HTML in canvas might bring back these cool days :)
Right. And Flash wouldn't end until Jobs won't come out on stage and say that Flash is eating the battery and Apple won't support Flash in their next iPhone, then Flash just ceased to exist. Apparently nobody needed innovative frontends anymore ¯\_(ツ)_/¯
There is no break pedal on this stuff, it just rolls down the hill until eventually it doesn't. It's a runaway process that feeds itself.
I'm not entirely convinced the framework comparison holds.
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.
> Just like AI is deskilling programming now, JavaScript frameworks have deskilled frontend development in the last decade.
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.
I don't think we should blame the LLMs, frameworks and the libraries necessarily. In my own experience, it feels like the real problem is a lot of companies (especially start ups) like to talk about "rapid prototyping", but are quite keen to just keep the prototype as the final product. Bootstrap, Rails, Tailwind, Nextjs and now LLM generated code... great for getting something up quickly with a semi-polished look to demo a thing. The real problem is that we're selling prototypes as products.
I have a slightly different take on deskilling argument. I don't think AI is going to deskill. Someone who has spent 10 years working in any field before AI is not going to get lose too much. Yesterday I sat down to solve a medium hackerrank problem without any assistance (code complete, AI etc) and it took me 10-15 minutes to get into that mode but i was able to do it comfortably just like how i used to do it pre-chatgpt. AI might unskill the younger workforce which will enter the field, aka they will never learn the way we did.
The term applies to the skills required from workers, not to how the skills of an individual evolve over time. The argument is that AI lowers the skill requirements for software development, and therefore less skilled workers will displace the more skilled ones because they are cheaper, as (allegedly) happened in front end over the past decade.
i wonder if you’ll still feel the same way in two years. knowledge decays slowly and the suddenly, at least for me.
I just vibe code the html and css. I review the JS, but I figure if the flow of data is correct, I can just verify the html/css code through manual testing
I don't agree that you don't have to know CSS/HTML when you use a frontend framework.
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
My previous employer fired all front-end developers a few years ago, we went back from tons of frameworks (Vue/jQuery/Ruby/Nextjs) to simple HTML and CSS. Turns out dedicated front-end developers aren't really needed, at least not where I was employed.
I worked mostly on frontend in 2012-16, in plain HTML+CSS, and then quit, because React was required everywhere, and I tried and hated it.
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.
Are we getting some real data in any industry really where AI eating jobs? I was kinda expecting those to kick in by now, but don't think it's happening.
> frontend used to be a highly specialized skill, requiring knowledge of semantic HTML, CSS, the differences of various browsers, accessibility, progressive enhancement, network performance, interface design and user testing
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.
And knowing the differences between various browsers meant negotiating whether the layout being 3px off on Internet Explorer was acceptable, or whether we should ship different CSS files for different browsers to fix this discrepancy
I think there might have been two overlapping periods, but it definitely started out as you said. What I wonder is, will AI increase frontend churn, or calm it down? (More churn would be, new frontends because of new frontend frameworks, AI accelerated, less churn would be, because AI is trained on what existed before)
I think I also reject the premise of the article, that frameworks caused frontends dev to de-skill. For sure, that happened to some extent. But it also caused a lot of frontend devs to be incredibly skilled in their chosen niche. (React for instance.)
nostalgia is one hell of a drug
> Just like AI is deskilling programming now, JavaScript frameworks have deskilled frontend development in the last decade. As someone who started with HTML/CSS and a bit of PHP, later did Ruby on Rails, and then was frontend team lead of a major Swiss newspaper (Next.js at the time), I’ve seen the transformation first-hand.
What does he mean by this? What skills were lost? Writing HTML templates?
Very interesting, i didn't know that frontend developers experienced deskilling before. I thought that slop was the usual way of doing things in frontend (or backend).
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.
Everyone had a chance to learn vanilla js from the mozilla docs but using jquery was much much simpler. Concede that jquery is more difficult than prompting. The issue for me is that prompting a front end and everything looks exactly the same. More cookie cutter than what wordpress and wix offered
My humble opinion: “deskilling” is an illusion. Sure, I don’t write code by hand anymore, but I spend most of my time using the knowledge and “sixth sense” I’ve developed throughout my career to control what AI is doing.
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 article compares LLMs to Stack Overflow and calls it "a continuation of the same trend", but I think there's a big difference.
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.
> A lot of programmers may not know this, but frontend used to be a highly specialized skill, requiring knowledge of semantic HTML, CSS, the differences of various browsers, accessibility, progressive enhancement, network performance, interface design and user testing
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.
Abusing a document mark up language and a scripting language to make "UI" is not a treasure of a skill. We can move on.
I'm allegedly a fullstack dev, often working on fullstack features, but I haven't had to think deeply about much on the frontend all year. 90% of my thought/work goes into backend work. The AIs just handle the FE stuff easily based on our existing patterns. Not saying it's perfect or can't be improved, but it pretty much always "just works" perfectly well enough.
> undeterministic abstraction
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:
What's one more layer, right?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
I mean, maybe it was a "lost decade" from the perspective of frontend developers, but I can't say I'm nostalgic for an age where everyone is handrolling everything from legacy browser support to responsive designs and I'm hoping they have a good understanding of all these things because the average page would be much worse than it is with everyone using these libraries.
Opening with this claim of ‘Front end’s Lost Decade’ then not explaining what that is is infuriating to me, a front end developer - which decade was this supposed to be? How/Why was it ‘lost?’ How did I miss it?
>writing all code by hand
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.
The part on the Bauhaus movement is weird, and I'm not sure I agree about how the author thinks about users.
>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 using AI to create UIs and I find myself having more time to think about UX rather than CSS. It actually gave me “time” to quickly test design ideas an implement minor details.
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.
I think it's more likely to cause a lost Decade of people not going into CS or tech due to lack of entry-level jobs. Maybe next time there's a boom and the pendulum of the power dynamic between management and labor swings more towards the workers, tech workers will unionize or organize better. I think overall it will benefit the industry because these boom and bust cycles for employment are just not healthy.
There is no guarantee that there will be a boom again. Some jobs disappear. Maybe we'll really only need a handful of elite engineers who continue advancing the foundational tools we use (kernels, databases, hyperscale low level cloud products, drivers, etc.) and the rest of "programmers" and "software engineers" will be replaced by "prompt engineers". With a new generation mostly unable to read and reason about source code.
Unionized workers are also losing their jobs in this economy.
Unions are, by nature, anti-progressive. They would rather use 15 year old technology, then replace workers and allow efficiency.
This will never work in the tech industry.
I think it's more likely to cause a lost Decade of people not going into CS or tech due to lack of entry-level jobs.
That could be a good thing, or a bad thing.
Maybe it will push more people into medicine, science, art, or other worthwhile careers.
Or maybe they'll end up lawyers, SEO experts, or venture capitalists.
It could go either way.
Front end is mostly an enshittified disaster hiding behind "UX" and "design principles".
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.
if you value intelligence (and likely income from that intelligence) above all other human qualities, you're gonna have a bad time. -Ilya.
> frontend used to be a highly specialized skill, requiring knowledge of semantic HTML, CSS, the differences of various browsers, accessibility, progressive enhancement, network performance, interface design and user testing – to just name a few.
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.
Honestly I think what is missing is not developers but designers. Or, I should say, designers hired to create competent designs that serve people well and not to instead manipulate users. If you want better front ends - get more and better designers! As for front-end code, I don't expect to ever write a line of that again in my life.
People don't use web tech because they care about quality, they target it very specifically because its one of the places where quality doesn't matter. If your native app crashes, your users will curse your name. Webpage or Electron slop freezes? They'll shrug and restart.
This idea that quality ever existed on the web is ahistorical at best.
> JavaScript frameworks have deskilled frontend development in the last decade. As someone who started with HTML/CSS and a bit of PHP, later did Ruby on Rails, and then was frontend team lead of a major Swiss newspaper (Next.js at the time), I’ve seen the transformation first-hand
I'm sorry but that simply does not make any sense. How is increasing the breadth of your skills leading to a deskilling?
Read in context. He's referring to the evolution of skill at group level, he even puts out the definition of deskilling and mentions 'skilled labor'. He then explains how frontend used to be a 'highly specialized skill', and how modern devs use Frameworks to consider browsers almost hidden compilation targets.
The article explains at length what they mean by "deskilling" and it does not mean that individuals lose their skills.
The author having worked with various technologies over time is also not an example of "deskilling", it's a way of asserting that they have had time to observe the deskilling of the domain (since deskilling means a particular domain requires less specialised skills than it did before, not that the workers are losing skills) happen.
The phenomenon of bootcamp graduates who knew React but did not know JavaScript.
I guess the author never tried to write big FE application in jQuery :D It definitely required some skill.
Just watch the terrible soup produced by MIT-bred Leetcode ninja "engineers" in money raining startups and FAANGs.
Low accessibility, terrible performance, lack of any fundamentals of html and css, abuse of those awful solutions like Tailwind or using 2016 technologies like React for rendering what should mostly be static websites + some web component, all plagued by memory leaks and very basic usability bugs.