The quiet, pervasive devaluation of front end
joshcollinsworth.com
joshcollinsworth.com
frontend development used to be much simpler than the backend, in the same way that a car tire is much simpler than the engine. useful, valuable, necessary, but no one gets bragging rights for being able to replace a tire (vs working on an engine).
Over the last ~10-15 years the frontend has grown to be extremely complex. _overly complex_. Imagine a tire that can now play the radio.
What the author is seeing (I hope) is an acknowledgement by our industry that the frontend need not be that complex to successfully do it's job. That feels bad for "frontend developers" who feel they can display much of their skill solely in the frontend. ---
The very idea that anyone would call html and css a programming language kind of says it all. To use an analogy, I can program my VCR, that doesn't make my VCR a programming language. words can have different definitions but industries tend to have more specific meanings than the general meaning.
These same developers like to rail against the idea of a fullstack developer. A fullstack developer is someone who can move between the frontend, backend, and data at will. They exist (I'm one of them). The frontend has gotten so complex people have started arguing fullstack can't exist because no one can be an expert in everything.
As if they themselves are even an expert in the frontend (hint: you're not).
When I hover over something in question, I expect popout tip box containing a full blown but very terse explanation of what that object is (in short, I just want the tire pressure monitor).
Over the last ~10-15 years the frontend has grown to be extremely complex. _overly complex_. Imagine a tire that can now play the radio.
At the same time, we literally have front-ends that are a whole application - VSCode, Slack, Discord, Google Docs, Google Sheets, Figma, ec. These apps load instantly from any browser, connects to the cloud, and they can be downloaded to work as a desktop app. These aren't just tires with wheels. They're the actual car and the server is just the gas.
I’ve never worked with a self-proclaimed “full stack” developer that does what they say they can. On my teams I always have an expectation, even if unwritten, that a developer will naturally end up specialising in front end or back end technologies. It’s always the case. And honestly in my experience it’s usually front end developers that have vastly miscalculated the complexities of the back end.
The argument has never been that nobody can be a mediocre front end developer and a mediocre back and developer at the same time. The argument has always been against the allure of ‘full stack’ developers in the eyes of management and PMs. Suddenly all your team balance concerns go out the window. Communication overhead between front and back end developers goes out the window. Yada yada. The reality is that full stack developers only really work when the bar is low or the team/org is big enough that ‘Jack of all trades’ types can sustain themselves with a workload whilst leaving some other stuff up to specialists.
My speciality is in back end development. I also know a bit of client-side JS and can put together a sorta-decent HTML/CSS interface. I’d never self-identify as “full stack” because I know what expectation that sets.
You say this and then you repeat what I said just with more words.
If you can call yourself a frontend developer despite there being developers who are better at the frontend than you, then a fullstack developer can call themselves that despite there being developers who are better than they are at frontend development.
A DBA is going to be stronger with data than a fullstack developer, yet this does not imply that a fullstack developer cannot model data.
There is an "art" to the frontend, though I wish I could think of a better term than that. If I optimize a database query to shave off 100ms the benefits are immediately obvious and tangible. If I improve the frontend so that a feature is more discoverable it can't be measured by code so it's intangible.
And while I would think there is some connection between this effect and the observed effect of wasteful frontend practices, I think the more direct answer of innate human laziness and self-interest seem like a bigger factor to me.
Yes. CSS is, simply, objectively, not a programming language. It is not for writing programs.
That doesn't mean it isn't worth developing expertise in. Lots of technical subject matters are not programming languages.
> Surely it’s a coincidence the first group tends to be more male than the second.
I'm starting to suspect that what the author perceives is more about how seriously people take the author, rather than how seriously people take front-end development.
Yes, under appreciation of front-end skills is a real problem. No, that doesn't mean HTML or CSS are programming languages. You aren't "programming the presentation logic", you're configuring the browser.
Under-appreciation of frontend skills in action. Do you think of "presentation logic" as an oxymoron?
I think many people can't see HTML, CSS and even SQL of backend land as programming languages, because they don't think declarative Domain Specific Languages (DSLs) count, don't think of their specificity and limitations as design strengths, and because each one is super easy learn to start but the rest of the enormous iceberg is so often ignored.
That being said, to my knowledge front-end developers generally are JavaScript programmers. I consider front-end developers to be programmers.
There was a time where there weren't 15 job titles to build a web app, and building a webapp was relatively the same. This sharding, pershaps to make tech adjacent jobs more approachable was a good idea, but I don't see it having evolved.
Front end can be very, very complex, sometimes too complex. The same can be said about backend.
If anyone reads about actual full stack development, where a developer had to learn the bare metal, linux, devops, to be able to serve a single page.. it did become easier, but the understanding of how things can best work together or not is a gap I see more and more.
Complexity slows down development pace, which is the antithesis of growing fast. Adding more people triggers the mythical man month clause.
Burning innovation points early on unnecessary complexity for the future is often the single biggest nail in the coffin when complexity and curveballs arrive and flexibility seems to have dissapeared to do what's needed.
Technologies like Alpine.js, Htmx, especially livewire, all are bringing the best of the tooling together with an unapologetic simplicity.
Should it be more complex to build the same 2004 webapp in 2024? I hope not in each and every case.
At a job I worked at "fix it in the frontend" was a running joke.
My suggestion in these cases, is to give the front-end devs a node/express server where they can compose the API calls the way they like and consume that from the webapp. But... they have to own it.
I have no good answer for what makes sense but I usually straddle 2 and 3.
3 seems to be the most pragmatic option to me when you have good control over each side.
At some point there will be a need for some "bloated" API requests. GraphQL can help minimize how many of those you need.
SPAs are only a good idea if you ignore all the complexity required to make them actually work decently - like carrying over the whole data model all the way to the frontend app.
Even back in the multi-page application days people doing large apps were already splitting their code MVC style with a model-layer that functions much like an API layer does today in an SPA.
Most devs don't understand that some techniques just don't work after a certain point and others are too complex for simple use cases. Everybody wants their silver bullet...
It used to be, a page that was primarily rendered on the server but used javascript for dynamicism in the frontend was still considered SSR. nowadays people try to relegate SSR to only rendering on the server, but that's never been the case and is a strawman.
But I guess now with things like Supabase joins in the front end are normal?
It's weird how these things change. But regardless, worth noting that people are using "frontend" to mean different things.
https://supabase.com/docs/guides/database/joins-and-nesting
"The data APIs automatically detect relationships between Postgres tables. Since Postgres is a relational database, this is a very common scenario."
There will be many people with the title Full Stack or Front End engineer who are using Supabase in this way and they may consider the code that triggers this to be front end code. There might or might not be another engineer who is in charge of the database and does some coding for it but always refers to him/herself as "backend" and is not aware that some of these joins are happening and need indices.
Very common in companies that keep their backend and frontend teams separate or companies with very dogmatic backend people.
This isn’t a “trend” it’s a feature of the industry and has been going on for at least two decades. The fact we pressed web technologies designed for content publishing into frontend user interfaces is a product of how little we care about frontend.
The heyday of the “frontend” was the late 1980s and early 1990s when Apple was serious about UIs. But even within Apple that’s dead.
This is the internet where you can say whatever you want, but our industry has a strong understanding of what these terms mean.
IMO A LOT of bad frontend code is a direct consequence of bad API design.
Entire backend teams can become unnecessary using cloud services like Firebase, then the front-end devs are the only devs.
Also on the back-end, SQL is often not considered a programming language.
I wouldn't get all twisted about sematics, schemantics. What people probably mean is that CSS/SQL aren't general purpose programming languages. Maybe you can make a complete webapp in CSS or SQL, but I wouldn't want to maintain one.
It turns out the word program has multiple meanings but we get to define what it means in our industry and CSS/HTML sure as shit aint it.
We have also done a horrible job by making people learn javascript as their first language. That has further made this problem bad because new script kiddies come in with very poor fundamentals and make the frontend even more bloated and unusable.
I've been thinking about identifying as a web developer instead, learning skills from graphic design to search engine optimization -- everything that helps me make better websites. I think some people avoid that label so as not to be confused with people who merely make websites with wordpress. But why? Why are those worth less?
Frameworks with total DOM manipulation capabilities in React et al are not needed by almost the entirety of the web. They were built for the needs of services like social networks, stock/finance sites etc, which need to send constant updates to the remote client. Facebooks sends likes, shares, friend requests, messages, other numbers. Financial sites run tickers, statistics that are needed live.
But the rest of the internet doesnt need those. The last thing you want to have in an ecommerce checkout page is to send any kind of update to the customer and confuse them. For that reason these pages are as simple as possible. We also keep any kind of conversion flow extremely simple for that reason. In fact, even in almost all the other applications outside of social networks, finance sites and the like, we keep everything extremely simple.
But, we are running entire stacks, infra and a codebases built on such frameworks. Worse, we are sending all of the resulting blob to the device of the user to be processed and displayed. Nobody thinks about the users who are using average devices. Nobody even thinks about the users who have high spec devices but who are temporarily in a low-connection-bandwidth location.
As a result, there is immense bloat both on the user side and organization side. Large fe epds are dealing with complex problems that stem from the complexity of the stack and the inappropriate frameworks that are used in inappropriate places.
What's worse is that programmers must program. Boredom causes engineers to start solving problems dont merit solutions. This is further exacerbated by organizations pushing 'productivity' on their epds by counting prs, or features shipped, changes done etc. These two phenomena amplify each other and you end up with complexity on the front end that solves problems nobody cares about. Of course, engineers also have to do this to keep their jobs - keep busy or the organization wont like it.
So the mainstream tech is digging its own complexity grave by its fad-driven, profit-maximizing, wrong-metric-optimizing behavior patterns.
A product, user oriented perspective must come back to the frontend. Users must come first. Organizations must stop pushing for false 'productivity' that only helps to complicate everything. Correct tech/stack/framework must be used in the correct place.
> And come to think of it, you’ll probably be expected to learn at least one backend language, too. (“So you can unblock yourself” is the reason given, although “so you can do your own job, plus a little bit of someone else’s,” is sometimes more accurate.)
The general trend is we all become poorly-trained "Full-Stack" developers.
> Every tool promises to make frontend uncomplicated and fast; that’s the only concern. They say it the same way I reassure my five-year-old that his vaccinations will be swift and painless; just something necessary to get out of the way as quickly and thoughtlessly as possible.
> But when did speed become the main concern? And why?
The general trend is that companies want to commodify development, both frontend and backend. Fewer developers is less money which is more budget/runway/profits/etc. It also drives a devaluing (in perception and in fact) of our profession where "anybody" can do it.
> The web is positively overrun with inaccessible code. Odds are, even if that specific problem doesn’t currently affect you, you still see forms that won’t submit, invisible buttons, errors surfaced in the UI, utterly broken layouts, things that don’t work on mobile devices or in certain browsers, text and fonts that are difficult to impossible to read, interfaces that are impossible to zoom or scroll, interactions that break down, and silent or unhelpful error messages—all quite likely on a daily or near-daily basis.
All. The. Time. Especially since I use Firefox as my daily driver, I see exactly which companies and websites didn't bother to test outside a Chrome browser. Even Chromium breaks down sometimes (looking at you Slack), and the fix is sending a different useragent. Opening up developer tools for a commercial site is a deluge of errors and warnings. The problem has grown far worse in the last few years even for websites I've used for decades.
To further the author's point, I think much of the complexity of CSS/HTML (and, yes, JS) these days is the sheer amount of complex `<div>` nesting that tool-assisted development spits out. Modern CSS is hard because it must conform to this nested Tower of Hanoi that makes old table layouts look appealing. Thoughtfully laying out a page is like designing an API; you have to think of its ergonomics that aren't quantified in any meaningful way. Of course, what isn't quantified is ripe for layoffs.
The greater push/reliance of tool-assisted development by commercial enterprises drives out expertise in favor of low-cost mass hiring/firing. Two decades ago I saw outsourcing developers grow to the same hype that AI is currently enjoying. Just like before, I expect a large wave towards tool-assisted development built on the hype, only for it to collapse under the weight of its own impossible expectations. By then the damage will be done.