The End of Front-End Development
joshwcomeau.com
joshwcomeau.com
But replacement? ChatGPT and GPT4 can't solve real world problems without heavy time investment of an engineer to prompt-engineer a semi-usable (if lucky) solution that still needs a lot of debugging (so coding yourself is still way faster for sufficiently complex things) and adjustment to your codebase.
Will people get left behind that don't adapt? For sure. That's always the case. If productivity is significantly increased with use of such AI tools, then those that won't use it due to whatever reason, including incompetence, will be let go eventually. All others will be fine, as always. This fear-mongering is actually good for us that can adapt, makes us more valuable.
Let's talk in 2030 again. Then in 2035. Then in 2040. And so on until we have AGI that generates you a new revenue stream just by reading the thoughts of a non-technical middle-manager, by which time we will probably have completely different problems.
People afraid of AI automating things just don't know how it works. I mean, no one does really, but if you went to University and studied AI, statistics, machine learning, deep learning and some of the variations then you'd know that that shit isn't intelligent or magic.
It predicts the most likely next tokens + some randomness based on what's in the training data. It can't do more than that. That it can conjure up well known algorithms and some variations of them that help solve some specific problems that "look complex" is not a surprise, but alas, a mostly useless party trick that scares some people apparently.
Frontend development involves a large number of fuzzy human bits that are constantly moving underneath you. Yes, your backend dependencies can change and you may need to update an API version, but in frontend you have browsers, screen readers, frameworks, and all sorts of massive icebergs largely outside of your control constantly moving.
In the backend, you probably have a language that is fairly stable. Write some unit tests, write some integration tests, but things are predictable and mockable.
Writing UI (properly) requires testing against several versions of several browsers, each with their own rendering quirks. UI tests - screenshots, whatever - are inherently flakier and when something breaks it's harder to know for sure if it's your fault.
You need to test against a variety of screen readers and accessibility tools. None of them are well documents, all of them parse the DOM (or native accessibility stack if you're not doing a web app) in a slightly different way, and the standards are constantly changing. As a bonus, you're legally obligated to get it "right", not that anyone can tell you precisely what "right" is.
Visual design isn't a walk in the park either. The designers will tell you to use color X. Its contrast ratio against colors Y, Z, and B on various pages will hopefully meet the contrast ratios, but then someone will point out that in exactly one of Windows' four different high contrast schemes this ends up being black on black and you will stare into a dark Lovecraftian abyss wondering what hellish algorithms Microsoft uses to pick colors. You'll fix HC Black and break HC white, you'll fix white and break black #2, and you will eventually throw your computer into the Marianas trench and go repair bicycles for a living.
And I’d also say that the argument is a bit straw man-y because it considers (some of) the complexities of frontend, with a fairly ideal view of the backend. Once you bring concurrency, scale and state, backend can become fairly Lovecraftian as well.
My thought, from a long career or full-stack development, is that front-end is very much about how people interact with things. It's more a matter of doing a thing with strong attention to the details of the display, interactions, and behaviors in different environments.
Back-end development is more about how machines interact with each other. Things are more deterministic, but instead of scrutinizing minutae of human-machine interaction, I'm thinking about how a machine will do this hundreds or thousands of times per second.
What we see ChatGPT being good at is largely boilerplate. The folks who are like "I am 5x more productive now with ChatGPT" raise alarm bells in my head - it suggests that they were typing the programming equivalent of pablum for most of their day.
Yeah, if you ask ChatGPT to author some simple HTML it will do so with a refreshing level of accuracy (though far from being able to do without extensive supervision) - but who is writing plain HTML? Likewise it's cool that it can generate a sort function whole cloth... but who is writing their own sort functions?
The trick with boilerplate is that the industry has already spent the past two decades automating large amounts of it away via frameworks and baking much of the functionality into programming languages themselves. If you're writing boilerplate for so much of your day that a boilerplate-spitting AI massively increases your productivity, I'd argue you've got bigger problems!
The trend - across both backend and frontend dev - is to make things more declarative and close the gap between what the developer wants and the amount of code needed to implement it. Use these technologies - it has made people dramatically more productive, but didn't require a LLM!
If you find yourself spending a significant portion of your day writing boilerplate, stop doing that! There are many options for you that allow you to more directly express what you want!
For most of our industry's history telling a computer what to do involved a lot of very painful and boring things that aren't really related to what you actually want from the computer. Moving registers around. Assigning variables. Managing memory.
But the entire time we've also been converging on doing less and less of this rote busywork. Advances in frameworks and programming languages has, in each iteration, gotten us closer and closer to simply telling the computer what you want, reducing the need for this rote busywork.
So now we have an AI that is quite good (though again: far from good enough to be unsupervised) at this busywork. For people whose jobs are largely consisted of this busywork this may be highly impactful - but your job as a programmer is to minimize this busywork to the maximum extent possible anyway.
When we reach that point, anyone's job will be at risk. Give that AI an AWS account and a credit card and it'll take over the world, not build websites when someone asks it to.
Compared to something like Qt/QML’s anchors and layouts, flexbox still feels like a crude hack, to me.
place-self: center;Meta: Stuff like this doesn’t really fit in HN imho. Besides being low effort it just feels weird to read things like this on a site literally called hacker news. I feel like someone misspelled “tired techies complaining about the same thing over and over again”.
Is it that much harder to come up with a genuinely funny or constructive answer or, you know, go outside, and touch some grass instead of posting?
I'm looking for alternatives, but the best I have at the moment is chatting with random people via my Calendly.
Yes, it was semantically ugly but it %(#% worked every #%#% time.
For those of us who know we won't be replaced, we only benefit from this FUD
Additionally all the statements that follow along the lines of "GPT today has a hard time with xyz" are all problematic too. Today is not tomorrow, and what it can do tomorrow is what we should be talking about.
The fact is in just 3 months we've gone from fairly basic code reviews to super helpful code reviews with code examples and intelligent code contextual comments.
Comparing GPT to Homestead or any number of early attempts to translate mockup to HTML+JS is unhelpful. This is wildly different technology. Talking about what GPT can do today and landing at "it's not good enough" is also missing the point, we are nowhere near the limits of this tech and it's evolving so fast that these assessments are not insightful in the slightest.
Talking about GPT as being merely a probability evaluator is also demonstrating the authors limited insight. WE ARE ALL probability evaluators. Humans work on prior experience, employ heuristics to make decisions based on that. GPT, indeed all AI, is more or less based on that paradigm. The difference is an AI can hold the whole of its learning in a perfectly memorized model. It doesn't forget what's in that model and can draw on billions of data points to make its probabilistic determinations. We pull on bias, false memories, misunderstandings, and so on. Now, that's not to say AIs won't also be afflicted by these comprehension errors, but that just doubles down on AI doing what humans do which is astounding either way.
Jobs are going to be lost, it's a fact. Even if it's just that junior who was learning code reviews and supporting basic development, that job will be around for maybe a year or two at the rate we are moving.
And how is that not a disaster for those who are out of work?
Just as often with AI's detractors who claim that it "merely" predicts the next word, I have to wonder if those making these grandiose claims about the near future of AI have actually used GPT-4 and its predecessors in their work. There has to be some sort of logical fallacy regarding "well [insert literally any limitation here] won't exist in GPT(n+1) at this rate."
> Jobs are going to be lost, it's a fact.
What percentage of a programmers' time have compilers automated? It's gotta be multiple orders of magnitude of efficiency gained. I could see a GPT-4 based GitHub Copilot being something like a 3-5x improvement on development in the best use cases (e.g. CRUD development built on public frameworks.) That's a colossal impact, but it's hard to even put on the scale to other ways programmers have automated their work in the past. Every time programming has automated giant swaths of programmer time, the end result has been that programmers can generate far more economic value even faster. This end result has consistently (and paradoxically) led to far more work and jobs for developers than before.
> Even if it's just that junior who was learning code reviews and supporting basic development, that job will be around for maybe a year or two at the rate we are moving.
At least in my admittedly niche area of work, juniors just aren't all that helpful. The time they take away from seniors or other members of the team makes them at net negative for at least a few months. It's often a year or more before we reach break even. Junior positions are investments in potential future independent contributors at a time where filling IC roles is still extremely difficult.
I have used GPT-3 a fair bit, and used GPT-4 today. The differences are impressive, scary impressive so far. I am basing my `GPT(n+1)` observation on the rapid rate the tech is filling in holes that previous detractors pointed out.
The differences in code reviews is amazing. In GPT-3 it basically explained the method and said it looked good, "add some comments" was its only suggestion. GPT-4 on the other hand gave a code snippet to explain why JS "await" was unnecessary, suggested better variable names, and suggested moving some imports to a more simple file structure to reduce verbose import paths.
I think that's a beyond expectations improvement, it's so impressive it beats out the humans who reviewed the code and we implemented one of the suggestions.
If GPT-4 had ingested the entire code-base code reviews would easily be automated, humans would still do their passes but as a co-worker GPT would be invaluable. It would find swaths of missed efficiencies, fix slow SQL queries, look for testing gaps, and perhaps even assist in refactoring.
Personally I think we are underestimating the potential, I feel like we are where the world was in 1990 looking at the emerging internet. So many people underestimated the impact of the internet, many technology writers said it was hyperbole, couldn't replace bricks and mortar stores, email was never going to be for everyone, and so on. All of it wrong, profoundly missing the potential.
This stuff is beating out expectations at every release and I think that is reason enough to take it seriously and be much more considered when downplaying the hype.
As for junior devs, we don't hire IC1 for the same reasons you outlined. However, small studios do because they are cheap and serve a purpose where it's just WordPress maintenance and HTML POCs. Those jobs will disappear.
This is where my 3-5x efficiency improvement estimate came from for GPT4-based Copilot, especially for CRUD apps using popular frameworks, which while game changing is far from the great efficiency gains programming has seen in the past.
Compilers have conservatively led to 100x-1000x gains of efficiency at scale as have operating systems and various key libraries. GPT-assisted code generation doesn't yet seem to offer the same result. Even if it did, if history is our guide, this would lead to developers being able to generate far more economic value with less, which has consistently led to more developer jobs than before.
> Personally I think we are underestimating the potential, I feel like we are where the world was in 1990 looking at the emerging internet.
It doesn't feel correct to me to think of GPT-x as some technology similar to the internet as much as it is a way of experiencing the already existing internet, like a smart, context-aware search for specific details (though there aren't any good analogies for the role LLMs play/will play in tech moving forward.) If search engines had continued to improve with the momentum they had in the early days, we should've expected some experience not unlike GPT a decade ago (or more.)
> However, small studios do because they are cheap and serve a purpose where it's just WordPress maintenance and HTML POCs. Those jobs will disappear.
That seems very possible.
Currently I don't think LLMs represent a risk to my job in that I work for a small company and personally handle many aspects of the development process on my own. However, at a larger company where those roles are spread out I could see some of them going away soon.
I work on a large WordPress theme. If an LLM were trained on that theme it could possibly have the global scope I need to make changes and understand their impact. It won't be long before we have software that allows you to easily train an LLM for your use. That could threaten my job. But then, my company would still need someone to manage and QA the results.
So I see fewer jobs, but not the end of the profession.
I worked at a job where I built out UI templates for a larger system. I could see that job reducing to perhaps more of an QA or automation engineer to manage the pipeline. Too bad, though, as that job was menial but gave me the longer term skills of muscle memory to write out HTML code.
Side note: I’m looking forward to a viable OpenAI competitor to come along and introduce their own chatbot…right now all of the speculation in the LLM area of AI are concentrated to the work of one company…what else can be out there?
"The code isn't the hard part of the job"
I've heard this tossed around and in the old days it used to be true.
BUT in the process of learning to predict text, just like with CNNs that learned to predict image types, it seems GPT learned some very interesting functions that bring it very close to "cognition".
I would not be at all surprised if we found those neurons in GPT, the same as I saw on fast.ai the building blocks of neurons that predicted images back in the day.
Funnily enough this is almost exactly how human children work when they're learning to talk
I read that animals dream in the woumb partially to pre-train their nervous system, including vision stuff.
But I'm convinced GPT-3/4 did learn a lot of features/generalization/reasoning, even if part of a "text prediction".
Sure, it's predicting text... but to do so it learnt some calculus and quantum mechanics -- it's just an example, I don't know the cognitive building blocks to explain how humans/future AI do their reasoning.
I don't expect, however, that she will program front ends any time soon
Liar :) If she wrote/scored as good as Chat GPT-4 does, you'd be worried she's going to steal your job :).
I mean, I know I'm lucky my wife doesn't know programming, lest she'd know more about anything that I do.
Obviously this doesn't apply to all workplaces, but there are a ton where the slowest workers set the bar for how fast things get done, and anyone who can get stuff done quicker works a couple total hours per week and is dicking around or in meetings the rest of the time.
Given how many BS jobs exist - and I've witnessed them personally - it's a bit early to declare LLMs the death of the programmer. It seems to me that the more likely outcome is that, rather than being put out of work, we programmers will become somewhat more efficient. Somebody has to babysit and evaluate the output of the robots, after all.
Does that translate to more actual productivity? Maybe in some cases, but given low expectations it might also just mean that we slack off even more. Perhaps ultimately, many more programming jobs will devolve into BS jobs.
Anyway most appreciated, thank you.
https://www.history.com/news/rise-fall-telephone-switchboard...
There's a lot I hate about my job (learning/using the latest silly thing React's rolling out, configuring new projects, Webpack, etc.). If AI can handle this garbage while I solve actual problems, I'll have it made in the shade.
When it starts doing that the relevancy of interactivity and design on the web starts plummeting as less and less humans will use it.
AI won’t care. User won’t see it.
> There is no real meaningful discussion taking place about replacing people, it's just about augmenting people.
I guarantee that there are discussions taking place in countless executive meetings trying to figure out how to replace people with this tech. People are expensive.
Some organizations are going to take the first approach, and some will take the second. Neither is right; some organizations can expand on what they do. Others have a narrower scope, and would be better off getting leaner.
There's always been a tension between an organization's needs and an individual's needs. I'm pretty sure these tools are going to increase that tension for a while.
I think the description as such will be the difficult tasks, followed by fine tuning your description if ChatGPT's result isn't correct.
But, nobody really has a job like this in the front end. They were all replaced by Squarespace/Wix/Webflow/etc years ago. Which seems to confuse people who aren't really in web development, and where Josh Comeau is mainly making the argument from (against the social media idea that "front end is dead").
T,FTFY
More or less sums up why I think FE dev has reached peak ridiculous.
Good luck ChatGPT.
Pretty embarrassing man.
From my view, chat gpt already codes a lot like a jr. developer but much faster
Unless Open Ai found some completely novel way of training GPT to enable the exponential growth in training data required up until now.
It will churn through frontend frameworks way faster than humans can.
I personally would be fine if LLM replaced my $DAYJOB if it meant I could work on learning violin, gardening, or creating videogames.
If LLM replaces a bunch of $DAYJOB you won't have people learning violin, you'll have widespread unemployment and the civil unrest that accompanies it.
Thus the need to start talking about how we will all benefit from this and demand those kind of outcomes...
Which makes it kind of suck if you have an economic system that is so centered around maximizing the concentration of capital and the extraction of value by that class that it is named for it, but the problem there isn’t automation.
2. Why would they?
https://twitter.com/stealthygeek/status/1604513283972767745 Quote: 1960's Futurists: Automation will free mankind from meaningless tedium to focus on creative pursuits only human beings can master.
2020's Techbros: We're building AI that will write all your books, music, and TV so you can focus on the meaningless tedious of your cubicle job.
Now, to expect to do a hobby as a job, forever (coding, art, music, whatever), that is a very privileged position to be in and most people in human history have not been that fortunate.
But let's be realistic -- that's not at all what it would mean.
The reason front end development as a skillset is coming to an end is that we've solved all of the problems that front end devs were responsible for. Front end used to be a very specific skill set that dealt with taming the complexities of cross browser support, and shoehorning the browser into a proper application platform. Those concerns are no more. Browsers have all converged on chromium-as-a-standard. Things like Tailwind/CSS-in-JS are quickly making traditional CSS skills obsolete; gone are the days of needing someone who knows how to cast arcane incantations of CSS rules to get an image centered on a page. And with modern frameworks and development techniques, all the stuff about semantic HTML and whatever else is being thrown out in favor of DevX and rendering everything as a pile of <div>s.
There has been a massive shift in the last 3-4 years where practically all job listings are now "full stack", with the expectation that UI work is "just some silly thing we have to deal with" on top of the real work. Perhaps some huge companies will maintain the separation but most have already given it up.
This statement literally makes no sense.
This is kind of my point. UI development will always be a thing of course. But the "front end dev" was a phenomena of the early days of the web, and needing someone to wrangle the insane complexity of the browser. Nowadays you just install some framework and off you go without any concerns for browser issues. And so it becomes like any other programming environment, where the average developer of any skill set can do it sufficiently.