this is going to sound rude but I think the author is just a typical frontend developer.
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).
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.
Disagreed. Are we overcomplicating static blogs using fancy frameworks, CDNs, edge DBs, functions? Yes.
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.
This is kind of funny because you’re fighting hubris with hubris, and a large part of what you’re saying is based on a huge misunderstanding of the industry’s dislike of the term “full stack developer”.
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.
> a large part of what you’re saying is based on a huge misunderstanding of the industry’s dislike of the term “full stack developer”.
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.
Instead, all we are getting are tires encrusted with seemingly-useless accessories (even the bells and whistles).
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).
This spoke to me. Time and time again I see that when our industry is faced with a choice between user experience and developer experience, developer experience wins. So we ship insanely massive virtual DOM trees for sites that are 90% static, bundle hundreds of dependencies into giant JS files without thinking once about the user on a slow, outdated Android phone.
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.
There is real effect where we as humans optimize for things that are easier to measure and model. For example GDP vs quality of life.
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.
> It might seem like I’m just asserting my stance in some petty online argument.
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.
The likening of the percieved "front-end devaluation" to gender and racial inequality completely derailed this article for me. The author, a white man funilly enough, seems to be desperately trying to use these issues to give his own ideas legitimacy. Unfortunately most of his arguments are thinly veiled tantrums thrown in response to his misunderstanding of his own role in software 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.
>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.
No, I don't. I consider presentation logic to be the browser code parsing those configurations. Many people "can't see" HTML, CSS, or SQL as programming languages because they aren't programming languages. When you write markup, database queries, and styles you are factually not programming. This is fine, it does not devalue those skills in any way.
That being said, to my knowledge front-end developers generally are JavaScript programmers. I consider front-end developers to be programmers.
I'm not even convinced front-end is devalued. We spend way more grooming time on user experience than database structure. We spend way more testing time on section 508/ADA compliance than on backup audits. I'm sure there are places where front end is devalued, such as internal business software, but nobody is hiring out consultants at $500/hr to "rebrand" their PHP variable or MySQL column naming conventions.
Author seems desperate to tie sexism into everything which is weird considering software engineering has been dominated for men so long I am not sure how he comes to the conclusion there is some sort of subtle sexism at play, like he believes that every male backend engineer is calling every male frontend engineer a sissy or something.
The separation of frontend and back end has devalued both, and also can complicate both.
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.
This is something I struggle with a lot in API design. If the frontend is to never join, then the backend has to provide either:
1. a very dynamic API (e.g. GraphQL) and support arbitrary queries
2. a static but 'bloated' API where every query joins in too much data to cover every use case
3. a static but 'wide' API where each use case gets its own specially crafted response
I have no good answer for what makes sense but I usually straddle 2 and 3.
If GraphQL was actually a query language (as in: allowing you to change the result set, not only the result shape), maybe 1 would be easily possible. Intuitively I would like that.
3 seems to be the most pragmatic option to me when you have good control over each side.
Supporting the interface of graphql from the backend though is usually not very easy - you usually end up with a half baked database implementation that wraps a better database
It depends a lot on the product, how wide and deep your API is and the division of labor. Like are frontend and backend separate teams? do people do full stack?
At some point there will be a need for some "bloated" API requests. GraphQL can help minimize how many of those you need.
That's an interesting comment because while the author was clearly defining front end as HTML and CSS, you went to a layer with joins. Joins used to always be considered a back end activity. I think it's very contextual but in relation to the article they may also be what the author considers to be backend.
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.
By frontend JOINs I mean backend APIs with so little regard to the client that the client needs to over-fetch data and perform JOINs/GROUP BYs in the client.
Very common in companies that keep their backend and frontend teams separate or companies with very dogmatic backend people.
"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.
Good example why using HTMX is usually a great idea. You can do your joins right there in the DB, it's easy and natural.
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.
This is also why SSR JS frameworks are gaining traction. But I still think as a product grows eventually you need some kind of formal API to help separate concerns and scale teams.
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...
there's nothing wrong with the browser doing work for the rendering, the issue is that _all_ of the work has been offloaded to the browser.
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.
I also see the opposite where a company has a web app product and a public API. The API is also a product. Some front-end developers think the API is the webapp's API and they shouldn't have to make any tradeoffs.
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.
This is also known as BFF (Backend For Frontend). Every client gets it's own API tailored for it's use case that will mostly just aggregate/orchestrate calls to the general purpose API.
> Mostly, nobody actually says frontend is less important, or less real, or that you don’t have to be as smart to do it. But it often seems to be implied.
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.
I wrote a long comment but basically it boils down to: 1) "backend" developers have always devalued front end to try to protect their (sometimes easier) cushy jobs and salaries involving slower-evolving technologies from often younger "frontend" developers, 2) "frontend" and "backend" without a lot of context are basically meaningless at this point, and 3) if someone is really good at CSS and wants a title with the word "Engineer" in it, I think they deserve it.
As I read this, I kept thinking to myself “I sure hope the author is right.” I have grown weary of the way JavaScript infects and sucks the joy out of everything it touches.
Frontend and raw SQL are the steepest and most effective, yet lesser regarded skills you can have imho. The entire backend stack feels like a giant relay. You connect the meaningful dots in the database and whatever the user sees. That's where most projects I've seen shine and fall the harshest. This didn't seem to be the case when MVC was a thing. Nowadays REST APIs just mirror a domain or CRUD where you offload the thinking to the frontend. I have seen horrendous amounts of spaghetti...
I call it the "Frontend Join Ratio" how many normally SQL operations frontend devs are forced to make because backend is just too isolated from the user requirements or doesn't want to bother with frontend needs.
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.
people used to program their VCR's, yet somehow I suspect no one would argue that calling VCR interfaces programming language is purely about semantics.
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.
I have long said that frontend development is fundamentally easier than backend development. However the whole frontend industry sort of took that and as a jungian response started building the most complicated systems possible to show text on screen so that they are also considered as "real developers." But the thing is, there is a reason why frontend developers are considered lesser compared to software engineers and that's because it is indeed easier and less complicated.
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.
If you identify as a programmer, it's tempting to think that you're more of a programmer by learning more programming languages and to argue about whether HTML and CSS are programming languages.
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?
Completely anecdotal but I feel like I’ve been seeing ‘engineer’ more than ‘developer’ lately - front end web application engineer, JavaScript software engineer, etc
Let's face it: In the FE, we are using the wrong technology in the wrong places.
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.
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).