Why I think we’ll soon be back to where we started.
Introduction
Before the advent of SPA, web applications were typically multi-page. This meant that every time a user interacted with the application, the server sent a new page in its entirety and a browser loaded it again. Each time the user navigated between pages, a complete page reload occurred, and it could slow things down and create a less-than-smooth user experience. Similar applications were often built using server-side technologies such as PHP, Ruby on Rails, ASP.NET, etc., which generated HTML code on the server side and sent it to the browser.
Web developers were universal specialists, they were responsible for front-end and back-end parts at the same time. After the development of web technology and the demand of users, new solutions, which would allow them to work with an interactive interface without any problems or waiting were required.
This is how the first solutions for SPA using BackboneJs or AngularJs appeared. They allowed us to reduce the load on the server, whose resources were limited at that time, and to provide interactivity when working with a web page via JS because there was no need to wait for a new page with updates from the server.
That’s how the division into front-end and back-end parts appeared. The role of purely front-end developers has become more demanded and diverse. They began to specialize in creating user interfaces, working with HTML, CSS and JavaScript, as well as interacting with APIs and the server. On the other hand, back-end developers became more focused on data processing, application business logic, working with databases, and creating server APIs.
And that’s how we entered the era of React, Angular2, Vue and other web application development tools. Instead of creating simple forms and lists, now we have js-routing, state management, browser API, binding authorization tokens to requests, data mappings, etc.
We started to complicate things which were simple.
As a result of this approach, the problems were obtained:
Difficulties in communication and coordination. Api Contracts and communication method — HTTP 1.1, Websocket, GraphQL. JSON parsing and validation.
Divergence in understanding and knowledge. For example, you could develop a front-end application that creates many queries and consider it a normal and optimized SPA. But for the back-end, this is a very dangerous situation, because it now needs a lot of database accesses and proper aggregation of this data, which will affect its performance and maintenance.
Duplication of work. Most CRUD operations on the back-end had similar behaviour on the front-end. We didn’t just get the list from the server, now we put it in the store(), each user action is processed via dispatch() and waits for the request to be executed, after that we update the store via reducer() depending on the result — everything the back-end does to the database, we repeat on the front-end. (page reloading and restoring SPA to the current state from the server are also worth mentioning — a separate pain for the moment)
Difficulties in debugging and testing. You now need to consider possible integration issues and test them in the context of both sides of the application. Yes, you can create isolated e2e-tests for the front-end application, but they cannot guarantee reliability in Production. Yes, there is ZoD for validating server responses, but what percentage of its usage?
Increased development time and cost. Any change to an API contract requires two people at the same time. You can’t directly change a template to a server like you used to. You need rallies, split into separate tasks, business-analytic specialists and so on to make the change smoothly.
SEO. Since our app is entirely formed through JS, search engines could not get the app content and its navigation to index it properly, thus SSR and SSG solutions were required.
Security. Any critical data entered on the page needs to be hidden before being passed to the server. Also, a lot of personal information needs to be requested from the server for the application, revealing access tokens.
So, why is the usual front-end dying?
Just go to any resource and you’ll see how many job vacancies are open:
Python + Django
PHP + Laravel
NextJs + React
Nuxt + Vue
These are all bundles for server-based web application development. Thanks to the Hydration and Resumability approaches, the server can only render the modified part of the interface, without reloading the page.
What they provide:
The server application now does not need complex HTTP or WS contracts and support them on both sides, it can use better methods to exchange information with other services like gRPC.
The process of making changes is faster due to the lack of intermediate approvals, for 1 person the result the user sees immediately changes.
Tests can check the application holistically, eliminating integration tests and reducing errors.
You exchange only HTML markup, all “request-response” logic is hidden for a user
Why pass a lot of data in JSON to restore SPA to the right state when you can pass a ready template?
You don’t need to worry about browser compatibility and use babel and other tools, because JS code on the page is minimal.
With the advent of No-Code solutions, template generation via AI, huge server resources, and SEO requirements — the current number of front-end developers as well as tools are not needed to develop only the front-end part.
Business owners have a valid question — “Why do I need to hire a pure front-end developer and a pure back-end developer to do a simple application?”
Full-stack developer is not a management fad, in terms of saving on staffing, now it’s a mainstay. You don’t need a pure front-end developer, you need a developer who can make a whole application, performing simple operations with the database directly or other services and displaying the result.
Yes, there will undoubtedly remain a complex or "headless" applications that require front-end and back-end separation but most of the applications will move away from SPA and go down the way that was already there, but now we have a solution to those problems. With the advent of HTMX, any back-end developer with basic knowledge can create a web application. You don’t even need to know JS to create a single-page app with little logic now.
You may ask, “The front-end developer was responsible, not only for JS logic but for CSS and proper selectors, HTML and its semantics, does the backend developer have to know that now ?” — No, now an AI or “HTML layout designer” can do template generation based on layouts from Figma. The logic and interactivity of the HTML-template are now defined on the server.
Conclusion
Now is a good time to think whether you really need all these sophisticated front-end development tools and whether you should remain a pure front-end developer.
I expect current front-end developers to move to Fullstack qualification with a 60%-front-end, and 40%-back-end split to stay relevant specialists. HTMX is just the beginning, the vector towards NextJs or Nuxt tools will grow, and Angular-type frameworks will die if they can’t adapt to new implementations, although the Angular ecosystem already has prototypes on AnalogJs as well
Top comments (57)
I would disagree that front-end is dying. The opposite is true: the fixed boundaries we knew become fluid; with Web Assembly, you can run back-end languages in the browser and with node/deno/bun/AWS llrt, you can run JS on the server.
This enables us developers to set our own boundaries where we want. This freedom comes with at the price of added complexity, but in the fear of missing out, people tend to miss that it's a choice and believe they have to pay the price regardless.
However, it would be wrong to say that we need to go full-stack to deal with the added complexity, on the contrary: it requires specialization to resolve and simplify.
As a front-end specialist with more than 20 years of experience (and more than 25 years of web dev work), I've seen the end of my vocation predicted lots of times. None of the prophecies ever came true and I don't believe any of them ever will.
Well, I'm gona nitpick. You run wasm, not the backend language. You write the backend language though!! Which is cool 🙌
Point taken. My wording was misleading due to a focus on conciseness, but I suppose the argument supported by the statement is still valid.
Yup!! It is
The writer's memory (or most probably, understanding of Web development history) is flawed and so are half of his conclusions. We didn't start with developers doing both back-end and front-end, or better, being equally adept at both, unless you're talking about the days of FTPing PHP files on an Apache-based server for some simple websites with trivial interactivity. In fact, if you're as old as I am (my first browser was Mosaic), you'd agree that we started with some basic HTML and gradually increased the use of JavaScript, which would make us all front-end developers by today's standards. The situation changed when databases came into play. At the time I could design a relatively small DB and write simple queries using mostly visual drag-n-drop tools (MS Access style). But as complexity and size of data grew, writing efficient SQL queries or choosing the proper normalization and indices for your DB tables became an art of its own, just like writing proper, semantically correct HTML, CSS, and JavaScript. In other words, the division between back-end and front-end developers emerged from the growing complexity of our Web applications, which remains today and will remain for the foreseeable future. The suggestion that front-end development will be replaced by no-code solutions or AI anytime soon is simply laughable. If/when that happens, all developers, front and back-end, will share the same fate.
Another point which is out of touch with reality, especially in the corporate sector where I work, is common back/front-end stacks, especially for JS on both sides. In my line of work, no IT architect wanting to keep their job would ever suggest using JavaScript in the back-end. Even SSR is not happening. We have APIs written in Java running on Weblogic and connecting to Oracle databases, or the equivalent MS .NET/SQL Server stack. Python/Django and PHP/Laravel are more likely, but JS in the back-end? I'd bet it's in less than 5% of corporate/enterprise applications.
Came here to say this. I’m about as old as you are, and you’re spot on.
I’ve hired about 50 devs in my career and I can tell you, I won’t hire anyone that’s not full stack. And that means they can build a feature from the front end all the way through to the back end. They understand the architecture and can also optimise their SQL accordingly, for the most part.
And this is born of the same sort of experience where we had to be able to do the lot. So, I get the people I work with able to do just that.
That’s the point. We use angular in frontend because it’s better scaleable for corporate usage and net core backend with mssql (because we are gold partner and licenses are free for us).
Separating both with different stacks is pretty vital.
We are just going in circles. From generalists to specialized devs, to generalists again. 10 years ago people were saying the same thing, but about what you are saying is kind of new (server-side generated pages) :D I wouldn't be surprised if in several years dev community will decide to go back to more specialized roles again.
I would also like to notice that the initial version of Angular looked really similar to the current version of HTMX, it blew up later, when more users started to develop in it (similar story with React).
To me, realistically PHP + HTML + Turbo/Stimulus (from Basecamp) is perfectly enough for most projects. People only started to notice that again because of fatigue with overcomplicated frontend framework stacks.
+1 for your opinion about "To me, realistically PHP + HTML + Turbo/Stimulus (from Basecamp) is perfectly enough for most projects."
lol how old are you?
sounds all too familiar except for the latest "AI" buzz fad
Just like the serverside method didn't really die at any time, the spa + backend architecture will stay. The SPA approach works better with serverless, and SSR is not always a requirement, especially in authenticated parts of business applications. But your argument for pure frontend devs is of course valid. The split to pure FE/BE should have never existed in the first place.
Without splitting FE/BE roles and responsibilities you are just opting for mediocre results..especially when working on multiple or big projects
Responsibilities and skills are two different things.
-- Why frontend developers eat alone?
-- Because they don't know how to join tables...
Same as saying that civic engineers should also be architects and vice-versa.
I love the sense of humor and disagree respectfully.
There is a specialization in pure ux/ui aspect of frontends, so is there in games or hardware embedded dev, but at the heart of all of it are the same principles. When we started with Mosaic and Netscape we had html styling properties and no css, and a whole forum app could be a single perl script, all pages output as a single string. This is no longer viable and everything got much more structured and architectured, we created and learned backend and frontend frameworks. But when the whole history of this development is intertwined with your (my) personal and professional growth, for me anything web, react/redux and their alternatives, web components, apis, integrations, databases, docker, ansible, serverless, you name it are just different pieces of the full-stack/web/cloud puzzle.
Re your comparison, I think the relationship is more like math to physics than civil engineering to architecture. But both comparisons are somewhat vague.
Jokes aside, I agree on this, it's all part of the same world but the ecosystem is so massive right now that, in my case, I would never be able to excel in both backend and frontend. That's the only simple reason I am in favour of focusing on one of the two fields. It's rare to find people who excel on both but I agree a basic knowledge of everything helps to have a better understanding the big picture.
Backend devs will never create the complex, interactive FE components that require a lot of JS.
I agree. I can say Im 80%FE and 20%BE, in my 10+ years experience almost 97% of BE devs I have work with want to do ONLY BE tasks.
They all did some FE tasks but you can see the mediocre results. Same way if FE devs will do BE work.
I think only a few percentage of devs that can do good both FE/BE.
just my opinion and some experience.
Interestingly the task did not change too much over the years. Developers are forced to solve the same problems again and again, and the path became increasingly rocky.
Programmers had integrated development environments in the past, giving them as much help as possible. They could use graphical interfaces to build their UI´s, that did not limit them like many no-code solutions do.
It seems all this is long forgotten and people are back in the stone age of programming, building their UI´s using ASCII-editors like VS-code as a standard. I suppose, if fist wedges where the standard, they would use them too.
That's true! Now that I think about it, when I was a kid (in the previous century!), I used some visual tool with drag & drop to build my first web pages. I don't even remember how it was called.
... And now, pick the latest serverless tool chain, from typescript to edge, and you might not even be able to set break points for debugging. 😂
It was probably Geocities or Angelfire. Those were the big ones back then.
Edit: And if you were doing it professionally, you were probably using Macromedia Dreamweaver or Microsoft Frontpage.
... Yep... Frontpage! I somehow got a license although I was just in high school.
Yep, but this is pretty much what we have with "WIX" or "Nicepages" now. But we had the same comfort in our development environments. Why is web development so different?
What a gut punch of nostalgia. 🥹
But what is cool about doing anything in VScode? Waiting minutes for a page to build? Digging deep in configuration files to find out why a dependency is broken? We had all this, but I don't get any nostalgic feelings about it. It´s simply inefficient.
Well... VSCode does significantly more than just JavaScript. I'm somewhat of a polyglot and it's an IDE across multiple language stacks. Java, Go, Python, etc. It's an appliance for writing code. That's really all VSCode is. What you choose to create with it is up to you.
Front-end development stacks are severely fractured and VSCode just happens to be the one of the best tools for working within them.
Most websites are still multisite and not react or vue. I am still coding "normal" sites in 5 percent of the time, other agencies need with a frontend team and a backend team, a scrum team,... This is just burning a lot of money and the results sometimes suck because it is often too unflexible if something must be changed. I can add a feature in a few hours, these teams need 3 sprints and 50k. This is just one example and not all projects are like that. But the "old" way is not dead.
You are totally wrong on the frontend development.
The Web Application Sites are totally different from Web Content Sites.
If your sites generate contents and resources and needs to be searched, you should not use react, angular, vue from the beginning.
If your sites are web applications, you don't need to be searched.
It is stupid to use react to create content indensive sites and vise vesa.
The htmx is no more than the original html, let alone react, vue, angular
Web application development won't die if web applications are needed by users.
Web content/resource development won't die either.
You should first know the web, then create a tool to fix, not to mix one thing from another.
Frontend is a standalone thing by itself, it's easy to understand it if you truly watch the trends in frontend and read the internet.
It's unprofessional to claim that frontend or backend were the same thing before or that they will merge in future.
There are no tools that just dying, they are either being replaced by the most maintainable and modern ones or just not widely discussed anymore but they exist and used.
The example here is jQuery.
We're all still in experiments, some libraries are tried and being like by developers, some not. But the fact is that we're still seeking for better ways to do something efficiently.
So something is not just dying, it's being transformed into something better, though we might not like it at a particular point of time.
Everything old is new again.
Everything that you were happy with and very productive using you were told was old fashioned and you had to chuck it out and replace it with a new approach which required you to effectively write two separate apps: one in JS (of course) and the other in your backend language (in my case Java). You'll have backend domain objects like Person, Address, Account etc., in Java and you'll replicate all these in JS for the browser.
You'll then migrate your app through a series of different "best practice" (r)evolutionary technologies used to marshal these objects back and forth between the browser and the back end.
I've watched the web dev world go through this horror story and even had to take part in the slow train wreck in various roles.
However, for my own work, I'm just glad I ignored all that B.S. and kept using Apache Wicket which is Java a based, component oriented, MVC architecture framework that allows you to write AJAX powered, partial updating, highly interactive, event driven web apps without writing a single line of JS code - the JS is definitely present to support the same type of interactive, event driven funkiness you get from any AngularJS, React, Vue based application but typically you, as a user of Wicket, never have to write the JS: The Wicket components available in the framework and third party libraries do all of the JS magic for you so you can just write your app once, in one language - what a revolutionary concept!
It's just sooo good to be able to write your app, including your craftily designed domain model etc., just once in one single backend language and never have to be concerned about marshaling objects to and from your UI - Wicket is MVC based and it seamlessly and transparently manages all the transfer of data and events between your code and the Wicket JS components running in the browser.
For those of you who remember GWT it's important to stress that Wicket is nothing like GWT with it's big compile/deploy phase that effectively compiled your Java code to "JS" to run in the browser. Yeah, hardly anyone uses GWT anymore for that and other reasons. Wicket has an extremely fast compile/deploy phase because it's not doing any Java -> JS transcompilation.
I've worked on massive applications in both pure Java via Apache Wicket and also Java backend/(insert latest flavour of the month JS framework) frontend.
The developer productivity of the Wicket solution was always at least 2x better, but often way more because whenever you go from one simple single language "app" to effectively two "apps" (the second one being the one running in JS in the browser) with the need for them to interact, it's typically not just a simple 2x jump in complexity - you now have to accommodate the interactions, state management, staleness issues - the difference in complexity for non trivial applications between using something like Wicket and using the JS UI 'fad of the month' approach can be an exponential difference.
Not to mention that I've heard of teams that always followed the latest shiny JS UI fad and so rewrote their app multiple times: initially AngularJS 1.x then they contemplated AngularJS 2.x but while deliberating over that React came along so they rewrote the entire UI in React ... but then Vue looked tempting ...
Clearly dev teams following these trends has got nothing to do with delivering value to their end users.
It's just satisfying the need for someone on the team to be using the latest shiny thing.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.