Why I think we’ll soon be back to where we started.
Introduction
Before the advent of SPA, web applications were typically multi-page...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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.
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.
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.
We are so many levels deep in abstractions of abstractions that I just wrote 5000 lines of code (in various languages and scripting languages) to terraform up a k8s, deploy mongo and node clustered deployments with high observability, through my CI/CD. (Another 500 YAML lines) images get stored and artifacts get saved.
The website is pretty awesome. It says “hello, world!” In bright blue letters. I’m gonna nap now.
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.
Nothing is dying. This is only evolution where new things solve another problem or make it more efficient the way you are walking towards your goal. It’s pretty clickbait to call something is dying. No it’s not. It’s only not that popular anymore. For example: jquery.
In that time it was ground breaking. Today you didn’t need it anymore but some folks love it. Other example: lodash. Pretty much anything can be done without libs in newer ja standards but some folks love it. And that’s fine.
The landscape is changing and shifting, yes, but frontend as specialization is not dying. On the contrary.
I'd rather say it's a fad that you don't need specialists, that there is this magical class of full-stack devs who can solve all the problems with the right tools. They can in the beginning, sure, until things become complex. Tools like HTMX and Next.js bring really interesting features to the table and they solve a lot of problems we had struggled with in the past. But they bring a lot of their own problems and learning curves too, but more importantly, they don't remove the need for a great craftsmanship and understanding of the various areas of product development.
If you want to create a product that users will love, which will be easy to use, performant, resilient, secure and maintainable, you need specialists, and among them frontend devs. It's a very complex undertaking and thinking the need for frontend and backend specialists will evaporate thanks to HTMX or Next.js & React is naive (talking from my own experience here).
As such, your statements remind me of the myth of the rock star programmer, who alone can pull off a great product. Well, this hasn't been true for at least the past 20 years, and saying full-stack is the silver bullet, if she only uses HTMX, sounds similar to me.
Takeaway from me is "build products, solve user problems, provide them value and learn along the way, and the place this process will take you to will be your specialization".
I think we are looking at an evolving situation not so sure I can make sense of it all yet but it’s clear that maybe a unification of ends COULD happen, however, talking to many humans that I know, plenty of devs who wouldn’t go near a browser even with the AI in place and vice versa… that, the human is still the bottle neck and it’s not likely to change any time soon.
An AI still can’t replace a skill issue, it can lead you astray and this is coming from a fan.
I think it is not just about the changes in web development, but the IT paradigm shift in general from demanding "I-shaped people" (experts in just one area) to "T-shaped people" (capable of doing "everything" while profiling a bit more in a few things).
Because it is harder to utilize experts, you might not have so much special tasks for them at the moment, while you may need reliable everyday development. It is better to have more dev teams of "full-stacks" who get the job done most of the time. If they occasionally get stuck, you either have your own expert somewhere insidie the company, you can call for help, or you may even look for external consultants, but it will still be cheaper and more flexible than trying to have "expert css desiger" or "expert database admin" in every dev team.
This is why mere "frontend/backend developer" isn't such a good deal on the IT job market.
I'm torn. On the one hand I get the comments about frontend devs not falling away. On the other hand as a full stack developer with decades of experience - and with one hand in the pie that is HTMX - I totally get the impression that we might be moving back to a simpler time. HTMX and a lightweight js library like stimulus or Alpine do the same for most applications as react or angular, without the bloat.
I tend to believe that while our js frameworks aren't going away (same for the jobs around those frameworks), I also think that there may well be a move towards server side rendering of plain HTML. As I said - for most web apps, particularly internal apps - they do the job, and they deliver on speed of development. In this day and age, that is critical.
I would also disagree. In general, it could be or is valid that the front-end development will change and in change yes. But on the other hand, if we take the specialised parts of a front-end development, there are several new branches. Like:
So I would say that it is indeed in a change of era, but it would be more and more complex to be a full-stack developer if so. Against the market I would still say that if you have a deep knowledge of a certain area that you are really good at, "stay busy" even if the trends are not always going that way.
Also, AI is blowing away these fields and considerations of the way of working and thinking in front-end development. But still it does not cover human needs in terms of quality. This means that if you have a preferred style or UX, AI will not handle it well, not only now but also later. Creating something new is not really relying on existing things, it is just a small part, but there is a reason when we say "cutting-edge design", which is a completely different way of design thinking.
So no offence, I really liked your post and the way you thought about how you discovered the topic! 👌
Frontend is not dying and I don't see it happening anytime soon. Showing a normal html/css website would have worked a decade before, but now most users demand a fancy UI, neat and swift UX and minimal loading time.
Yeah, AI and code generators would create a website for you. But do you really think, such websites would appeal to your users?
We have shorter attention spans now and I believe performance and an appealing UI will always be the differentiating factor.
Frontend dev is not dying at all
Most of your conclusions are wrong I won't explain any of it , but I think your LLM hallucinated, because this article doesn't have much in common with the real world 😐
Are you saying that backend devs now need to know complex JavaScript to create all the complex components that require visual effects, transitions etc. Backend devs would rather stay away from JavaScript. Creating a responsive calendar widget, drag & drop components in JS etc. in JavaScript can become very complex. That's the job for frontend devs.
I seriously have to ask what makes you think backend devs don't like/understand/whatever JavaScript, and what you consider complex. Is it about knowing how to add an event listener for the drop event and adding a class with some transition css? Or is it about higher order functions, streams or actually understanding how promises work? I switched to nodejs at v0.6, mostly to save the mental burden of switching languages between FE/BE (did c#, python and perl among others - yes perl for backend over CGI), and did most of backend work in js/ts ever since. Some backend devs indeed would stay away out of some principle but it's just as narrow minded as the other way around.
Check the book "JavaScript alongee" for my idea of advanced. Or "The little lisper" if you feel adventurous.
Imagine you own a business, and you are successful 🎉 Your main audience consumes your business from mobile devices, predominately smartphones, right? And so, your mobile app is stored on users' devices and this app fetches all relevant data from Server "A". So far so good, hope you're following...
You also want to have a web-based app, because why not 😄 The problem, however, that the browser doesn't store it (at least initially) and your web app needs a home 🏠
Now you have 2 options:
Option A: squeeze a view layer into the Server "A" and have some kind of switch logic deciding when to serve JSON/Protobuf and when to serve HTML/HTMX
Option B: spin up just one extra Next.js server that will host your frontend app and fetch data from Server "A" just like your mobile app does
I personally will never choose Option A, but both options are fine with me and neither makes frontend dying!
Am in agreement with fullstack making more sense in the current landscape but this glosses over why the shift from server rendered html pages + jQuery for interactivity was abandoned in favor of SPAs , ( native apps) once people got a taste of that UX they wanted it on the web which inspired JavaScript to mature and deliver. The UX delivered by SPAs is not easy to replicate and tools like HTMX might be a game changer but it'll have issues catching on with the popular fullstack web alternatives (Laravel, RoR, Django) who all have their own alternatives with differing levels of UX , the JavaScript ecosystem has also matured and delivers better UX and site performance with new tricks some of which are possible due to their ability to take full advantage of the browser .
The reasons why JavaScript took over web development is
All that combined with a framework for any niche application you have in mind creates and ecosystem that beats out the alternatives , anti JavaScript sentiment is counterproductive and mostly based on idealistic recollections of a past era
What a waste of time reading this. Where is the down vote button
People say this every single year, and hey it never actually happens
a nostalgic summary of a development that has been evolving and will continue to grow with or without A.I., totally accurate step by step description of what was "simple" what is "complex" and how "practical" it is becoming .....
-----||||------
todo un resumen nostálgico de un desarrollo que ha venido evolucionando y que seguirá creciendo con I.A o sin ella, totalmente acertado la descripción paso a paso de lo que era "sencillo" de lo que es "complejo" y de lo "practico" que se esta volviendo.....
Firstly, Indeed is not the ultimate solution for job searching. LinkedIn has emerged as a new and effective job marketplace.
In the realm of Frontend Apps, there has been a shift from CSR to SSR/SSG/ISR. Clients nowadays are well-informed about tech stacks. Using plain React/Vue for web apps is no longer preferred. Next/Nuxt Js developers are in high demand due to their expertise in performance optimization.
There is a new trend called htmx, but it has gained limited popularity. The idea behind it is to reduce reliance on JavaScript for building applications.
Regarding AI, there are already various tools available in the market to convert Figma designs into functional code. However, these tools require a proper system. Figma designs often consist of multiple screens, many of which require interactions, API/3rd party service integrations, and more. Therefore, a systematic approach is necessary to handle such complexities.
Moreover, it's worth noting that AI can be expensive. Most services rely on OpenAI, although there are a few alternatives. However, by 2024, the cost of AI is expected to surpass that of human resources.
I am literally the guy in this article. I'm focusing on transiting from front end to full stack right now. I've been comfortable in my job for a long time but wanted more, only to look out at the landscape of the current job market to realize there is a lot of frameworks I do not know now in demand. Do you have any additional resources suggestions that you've used in the past that really helped you gain the knowledge of a particular framework/s or you still use to stay focused on framework trends?
After almost 10 years of working as a frontend developer and time to time as full-stack (with short episode in mobile development), I would say that the discussion about tools, frameworks, relation between frontend and backend (or where the line which separates them is) is a bit overthinking. It doesn't matter how we called this or that, what tools we use, as a developers we should be focusing more on problem solving. At the end the most important thing is to choose tools wisely, coding as good as we can and be responsible for what we are doing. Everything else is a matter of semantics or taxonomy of IT tools.
Of cource the discussion was always present and still will be because there are some trends in dev community or market which we need to observe and evaluate but let's be honest: even if something is valid today, after couple of years might be not and we shouldn't be so excited about that. Let's focus on basics and IT craftsmanship. Event if blacksmith use different hammer, he knows that metal behave same way no matter what tool he uses and how other blacksmith calls it.
I am currently Learning...😊😊😊
You forgot to mention Ruby and Ruby On Rails
What about micro frontends?
Dang, what should I do then ? I am just starting
The article was helpful. Thanks Maksim.
Hi Maksim Dolgih,
Excellent content, very useful.
Thanks for sharing.
The golden rule is, please keep learning and always equip yourself with the latest technologies.
For websites there is no need for BE/FE separation
For web applications, however, it is fundamental