Ask HN: Is back end dev generally easier than front end?
178 comments
No, Backend is not easier than Frontend. Both are equally hard, since you will always be pushed to get the most out of what is currently available in terms of technology & tooling, no matter of your niche. If not, your job will become worth less since you are going to be automated away at some point.
A fallacy that I found many frontend-developers have is that they believe Backend is the same as Frontend, just that you don't have to deal with browsers, can work in one language and just do some data conversion.
Even if this is true in some cases, they forget the most important thing: the data. On the frontend, you can pretty much always just create a new version of your software, deploy it and then you are done. The only thing you need to be careful about is that you use the backend APIs correctly. If you mess up, you roll back to the version before and you are good.
Not so on the Backend. If there are changes in how the data is stored, structured/formatted and processed, then there is also the chance that you might screw up data. Potentially you cannot revert this and the damage is permanent. Sometimes you can but it is very painful and needs to be done with extreme care. This is one of the reasons why Backend seems to be more stable - because the impact of errors is higher and will put more stress on you.
Therefore, I find backend less rewarding - it takes longer for you to see results, because you must be more careful.
Disclaimer: of course it can also be that it's the other way around, but usually it is like I described.
A fallacy that I found many frontend-developers have is that they believe Backend is the same as Frontend, just that you don't have to deal with browsers, can work in one language and just do some data conversion.
Even if this is true in some cases, they forget the most important thing: the data. On the frontend, you can pretty much always just create a new version of your software, deploy it and then you are done. The only thing you need to be careful about is that you use the backend APIs correctly. If you mess up, you roll back to the version before and you are good.
Not so on the Backend. If there are changes in how the data is stored, structured/formatted and processed, then there is also the chance that you might screw up data. Potentially you cannot revert this and the damage is permanent. Sometimes you can but it is very painful and needs to be done with extreme care. This is one of the reasons why Backend seems to be more stable - because the impact of errors is higher and will put more stress on you.
Therefore, I find backend less rewarding - it takes longer for you to see results, because you must be more careful.
Disclaimer: of course it can also be that it's the other way around, but usually it is like I described.
Data / API / DB design will take 10%-20% of your time at most (unless you’re a DBA), maybe as low as 1% on a large company where almost everything you touch was made by someone else.
In my experience (10+ years) backend is almost always faster when it comes to building apps. Not running your code on 300 different devices and OSs, or having to deal with 20 years of backwards compatibility is a big advantage. Plus the library churn as mentioned, I don’t know any ecosystem that comes close to JS (cue the Remix announcement from yesterday…)
At $currentJob, backend features (go + pgsql) are usually done in hours while the FE/app development (React) goes on for days / weeks. It’s a bit unnerving.
So, is backend easier? It depends, but it can certainly be a lot less stressful.
In my experience (10+ years) backend is almost always faster when it comes to building apps. Not running your code on 300 different devices and OSs, or having to deal with 20 years of backwards compatibility is a big advantage. Plus the library churn as mentioned, I don’t know any ecosystem that comes close to JS (cue the Remix announcement from yesterday…)
At $currentJob, backend features (go + pgsql) are usually done in hours while the FE/app development (React) goes on for days / weeks. It’s a bit unnerving.
So, is backend easier? It depends, but it can certainly be a lot less stressful.
I have the impression that your experience is mostly limited to creating new applications, from scratch up.
But in reality, most backend-work is maintaining and extending existing backends and then things become much more difficult. And that's also why backend is different from frontend: it's easy to throw a frontend away and replace it with a new one - try to do that with a backend - usually much much harder.
But in reality, most backend-work is maintaining and extending existing backends and then things become much more difficult. And that's also why backend is different from frontend: it's easy to throw a frontend away and replace it with a new one - try to do that with a backend - usually much much harder.
> it's easy to throw a frontend away and replace it with a new one - try to do that with a backend - usually much much harder.
Untrue. I work at a company that's swapped out the frontend and then later the backend. I had to work on both of the projects because, and I can tell you without a any doubt in my mind that they were both equally challenging (for different reasons, but that's beyond the point).
In my experience frontend-only (or frontend-focues) devs tend to underestimate backend work, and the the backend devs are equally guilty of doing the same about frontend work. Everyone thinks they've got it the harderst. ¯\_(ツ)_/¯
Untrue. I work at a company that's swapped out the frontend and then later the backend. I had to work on both of the projects because, and I can tell you without a any doubt in my mind that they were both equally challenging (for different reasons, but that's beyond the point).
In my experience frontend-only (or frontend-focues) devs tend to underestimate backend work, and the the backend devs are equally guilty of doing the same about frontend work. Everyone thinks they've got it the harderst. ¯\_(ツ)_/¯
I'm sure that this also happens sometimes and that there are products where the frontend is the main part and requires more work than the backend.
But I still believe that it's usually easier and more valuable to recreate the frontend, and the reason is that Backend is (on average) more stable, grows over a longer time. The reason is also that the risk of replacing the backend is higher, since for a frontend, you can usually use two of them in parallel (think AB testing) without much problems. But if you do the same with the backend and the new backend writes incorrect data into the db, then the old backend also starts to behave incorrect. Hence harder to change.
But I still believe that it's usually easier and more valuable to recreate the frontend, and the reason is that Backend is (on average) more stable, grows over a longer time. The reason is also that the risk of replacing the backend is higher, since for a frontend, you can usually use two of them in parallel (think AB testing) without much problems. But if you do the same with the backend and the new backend writes incorrect data into the db, then the old backend also starts to behave incorrect. Hence harder to change.
Even new stuff has challenges. Integrating API's for other devices and services that your app uses. Working with analytics and reporting.
It depends. If the backend is done well, yes.
But how often is it the case that you're called to work on a well-designed back end?
But how often is it the case that you're called to work on a well-designed back end?
Building an MVP backend is a lot easier, but there is no limit to how much work you can put into a backend to a typical app. Frontend is a pretty much solved problem, getting to that state takes longer than the backend MVP but after that there isn't that much more to do. Or do you think that reddit, twitter, facebook or google put more work into their frontends than everything that goes on in their backends? Recreating their frontends isn't that much work, recreating their backends however...
Found the backend dev.
Really, this is very dependent on the kind of software you work in and what the focus of that software is. There's a wide world of software out there, with all different kinds of priorities and challenges.
Really, this is very dependent on the kind of software you work in and what the focus of that software is. There's a wide world of software out there, with all different kinds of priorities and challenges.
> Really, this is very dependent on the kind of software you work in and what the focus of that software is. There's a wide world of software out there, with all different kinds of priorities and challenges.
That is included in what I said, many projects are fine with an MVP, that is why it is called MVP.
If your frontend is a game or some creator tool like photoshop then they will be complicated, but usually you don't call those frontends, and most frontend developers doesn't have the skills to make such products.
> Found the backend dev.
I've spent roughly equal time in both domains. Creating a frontend with the same quality as Google or Facebook isn't particularly hard (if you assume another guy did the UX design), it is tedious though. And that is basically all you have to be able to do to work as a frontend dev.
That is included in what I said, many projects are fine with an MVP, that is why it is called MVP.
If your frontend is a game or some creator tool like photoshop then they will be complicated, but usually you don't call those frontends, and most frontend developers doesn't have the skills to make such products.
> Found the backend dev.
I've spent roughly equal time in both domains. Creating a frontend with the same quality as Google or Facebook isn't particularly hard (if you assume another guy did the UX design), it is tedious though. And that is basically all you have to be able to do to work as a frontend dev.
This might sound shocking, but there is a lot going on behind the scenes at Facebook, Google, and any big player really, on the frontend. Like, a lot. Think a thousand A/B tests at once. Hundreds of independent products and internal tools. Each one with dozens of minor, but necessary pages that most users will never see. Facebook’s frontend passed 10 million lines of code back in 2013. Someone wrote all of that. Yes, we did that to ourselves…
Most product teams for these companies have more frontend than backend devs. They’re building new features, sometimes multiple versions in parallel, fixing bugs and creating more of them, running experiments, and with modern frameworks, a whole lot of plumbing. You can basically generate infinite amounts of product work, and that’s what companies do.
Most product teams for these companies have more frontend than backend devs. They’re building new features, sometimes multiple versions in parallel, fixing bugs and creating more of them, running experiments, and with modern frameworks, a whole lot of plumbing. You can basically generate infinite amounts of product work, and that’s what companies do.
> Frontend is a pretty much solved problem
I don't think so. Just see the progress of frameworks like react/angular etc. over the recent years. We also see concurrency being embraced more. There is still a lot of things to be improved in frontend, I wouldn't call that a solved problem, even though the problem space is narrower than backend/infra.
I don't think so. Just see the progress of frameworks like react/angular etc. over the recent years. We also see concurrency being embraced more. There is still a lot of things to be improved in frontend, I wouldn't call that a solved problem, even though the problem space is narrower than backend/infra.
Those are changes in libraries, not changes in capabilities or what it means for a frontend to be good. How to make a good frontend framework isn't a solved problem, no, but how to make a good frontend is a solved problem. The exception is UX design, but frontend developers typically aren't UX experts, that isn't on their plate.
Problem is, on a FE you cannot simply build an MVP. An MVP would mean black/white colors, no responsive, no design, no styling etc. It would look like shit, even if it could handle all the requirements perfectly. You always want a good looking FE, and it has to work and (continuously) be tested on a wide set of Browsers, Devices and Screen resolutions.
It can, but only on new projects. I had to deal with codebases old up to 15 years, once on a project developed in java 3 and run on jvm 8.
> you will always be pushed to get the most out of what is currently available in terms of technology & tooling, no matter of your niche
Disagreed. Maybe in large companies that work at huge scales, but below that there's plenty of business value that can be delivered with what is essentially CRUD and there's still money to be made.
I'd say that if anything, the $$$ per unit of effort is much higher working for small businesses building CRUD-like apps than working at let's say Google or Netflix where all the low-hanging fruits have already been taken.
To go back to frontend vs backend, the frontend world is always changing and you're often pushing the limits in what's possible, where as for backend, CRUD is a solved problem, the ecosystem moves much slower and there's a lot of mature frameworks to take care of the boilerplate.
Disagreed. Maybe in large companies that work at huge scales, but below that there's plenty of business value that can be delivered with what is essentially CRUD and there's still money to be made.
I'd say that if anything, the $$$ per unit of effort is much higher working for small businesses building CRUD-like apps than working at let's say Google or Netflix where all the low-hanging fruits have already been taken.
To go back to frontend vs backend, the frontend world is always changing and you're often pushing the limits in what's possible, where as for backend, CRUD is a solved problem, the ecosystem moves much slower and there's a lot of mature frameworks to take care of the boilerplate.
> Disagreed. Maybe in large companies that work at huge scales, but below that there's plenty of business value that can be delivered with what is essentially CRUD and there's still money to be made.
But that's exactly what I'm saying!
Just continue the thought: if CRUD is so easy, but money can be made then it will be automated away by frameworks or even commercial products. So less people will be needed and hence people will lose their jobs.
Of course, the demand also increases, but still, think about it: 25 years ago, you could earn a lot of money by simply creating basic websites for people. This has become much easier/faster to do now, but making a lot of money with it has gotten much harder as well.
But that's exactly what I'm saying!
Just continue the thought: if CRUD is so easy, but money can be made then it will be automated away by frameworks or even commercial products. So less people will be needed and hence people will lose their jobs.
Of course, the demand also increases, but still, think about it: 25 years ago, you could earn a lot of money by simply creating basic websites for people. This has become much easier/faster to do now, but making a lot of money with it has gotten much harder as well.
> Just continue the thought: if CRUD is so easy, but money can be made then it will be automated away by frameworks or even commercial products. So less people will be needed and hence people will lose their jobs.
CRUD are just the basic backend operations for persisting data and frameworks provide the facilities to make this happen. Processing web forms via CRUD operations is just a subset of backend development. Companies hire software engineers to solve domain problems which are unique to the company and/or industry. Eventually things will get automated away where they can but there will always be new domain problems to work on for the foreseeable future.
> 25 years ago, you could earn a lot of money by simply creating basic websites for people. This has become much easier/faster to do now, but making a lot of money with it has gotten much harder as well.
No, 25 years ago no one was making money designing websites. In the late nineties, web sites were often just cobbled together by whomever in the company took an interest in the new medium. Also, aside from some outliers perhaps, no one was making the kind of salaries engineers can get these days.
CRUD are just the basic backend operations for persisting data and frameworks provide the facilities to make this happen. Processing web forms via CRUD operations is just a subset of backend development. Companies hire software engineers to solve domain problems which are unique to the company and/or industry. Eventually things will get automated away where they can but there will always be new domain problems to work on for the foreseeable future.
> 25 years ago, you could earn a lot of money by simply creating basic websites for people. This has become much easier/faster to do now, but making a lot of money with it has gotten much harder as well.
No, 25 years ago no one was making money designing websites. In the late nineties, web sites were often just cobbled together by whomever in the company took an interest in the new medium. Also, aside from some outliers perhaps, no one was making the kind of salaries engineers can get these days.
CRUD is 'wierdly hard', in that 15 years ago, it was very easy to make a windows CRUD app in Visual Basic 6. An unskilled person could build such functionality at the same or faster speed than a quite skilled web developer.
Modern web appears to have made the simple hard. Where you could once just draw a GUI (a responsive GUI), now you need to know CSS, and a simple multi column layout in CSS is something that takes a beginner days to understand. Then you need to write javascript - but not simple javascript. You 'need' to use a framework like React which takes a newbie months to 'fully' understand.
What exactly do we get for all this new complexity?
This is a solved problem made unsolved.
There are a bunch of no-code or less-code solutions for this. Already basic ecomerce is achieved by just using these . But why not you app, front end dev reading this. Some will have good reasons, but many will not. I think you are writing it in react because you put a lot of effort into learning react and you are unable to even think of making a few low impact compromises and no-coding your next years work in a week. Why would an employee do that?
Modern web appears to have made the simple hard. Where you could once just draw a GUI (a responsive GUI), now you need to know CSS, and a simple multi column layout in CSS is something that takes a beginner days to understand. Then you need to write javascript - but not simple javascript. You 'need' to use a framework like React which takes a newbie months to 'fully' understand.
What exactly do we get for all this new complexity?
This is a solved problem made unsolved.
There are a bunch of no-code or less-code solutions for this. Already basic ecomerce is achieved by just using these . But why not you app, front end dev reading this. Some will have good reasons, but many will not. I think you are writing it in react because you put a lot of effort into learning react and you are unable to even think of making a few low impact compromises and no-coding your next years work in a week. Why would an employee do that?
To be fair, you can still make a VB6 (or <insert favourite desktop app framework here>) app.
The problem is that for legitimate reasons, most of the processing no longer happens on the client device, so there’s suddenly a lot more complexity.
Making a desktop app that owns its data and is its the sole user is still easy. But most business requirements nowadays want a consumer product where people can interact with a subset of the data with a web UI or mobile app. That’s where the complexity comes in compared to VB6.
The problem is that for legitimate reasons, most of the processing no longer happens on the client device, so there’s suddenly a lot more complexity.
Making a desktop app that owns its data and is its the sole user is still easy. But most business requirements nowadays want a consumer product where people can interact with a subset of the data with a web UI or mobile app. That’s where the complexity comes in compared to VB6.
Well, 80% of my job is CRUD. But the 20% remaining is custom logic attached to some objects being modified. That’s where the money is made and what prevents it from being automated away entirely.
> the frontend world is always changing and you're often pushing the limits in what's possible
What limits are there in the frontend world? Modern frontends could run on hardware from 20 years ago unless you are talking about games. Libraries and clients change etc, but the problems you can solve using them doesn't. 20 years ago you had to build your frontend as a desktop app if it did complex things, 10 years ago you could build that in the web. But it is still the same thing.
What limits are there in the frontend world? Modern frontends could run on hardware from 20 years ago unless you are talking about games. Libraries and clients change etc, but the problems you can solve using them doesn't. 20 years ago you had to build your frontend as a desktop app if it did complex things, 10 years ago you could build that in the web. But it is still the same thing.
> What limits are there in the frontend world?
Like making that new scroll hijacking feature that a marketing guy saw on Apple’s website work on IE11 or something.
Again, none of these features are essential, but from the business perspective they are still requirements.
In comparison, most of what you’d do on the backend is a solved problem and there’s existing reliable & battle-tested tooling such as frameworks and relational databases that you can offload the hard work to.
Like making that new scroll hijacking feature that a marketing guy saw on Apple’s website work on IE11 or something.
Again, none of these features are essential, but from the business perspective they are still requirements.
In comparison, most of what you’d do on the backend is a solved problem and there’s existing reliable & battle-tested tooling such as frameworks and relational databases that you can offload the hard work to.
[deleted]
thanks that's very insightful
My experience is that in backend you spend 80% of your time on problems that are rightfully hard and 20% on bullshit.
In the frontend you spend 20% of your time on things that are hard because they need to and 80% on things that simply should be easier. This includes everything from browsers to desktop resolutions to needless churn in your framework.
I'm not saying one of them easier, especially in 2021 as I am a bit out of the picture in frontend but it seems it's the same type of problems in 2021 than it was 5/10/even 20 years ago.
In backend you choose your stack and who to interface with. Sure, people can write all sorts of clients to talk to you, but you are the one who decides most parameters (except amount of traffic, and for that there's rate limiting).
In frontend you are closest to the end user and are the only one who is not only speaking to machines, but that's only one end.
So personally I'd say frontend is more thankless, and you often need to know more about specific edge cases, whereas in backend you need to know more about unspecific classes of edge cases.
Also one point is that the barrier of frontend and backend has shifted. For a long time when we as backend developers worked with frontend developers that meant we did PHP/Python/Java/Ruby and some basic HTML and they did HTML/CSS/some JS.
Nowadays frontend basically means JavaScript and even the meaning of full stack has shifted.
In the frontend you spend 20% of your time on things that are hard because they need to and 80% on things that simply should be easier. This includes everything from browsers to desktop resolutions to needless churn in your framework.
I'm not saying one of them easier, especially in 2021 as I am a bit out of the picture in frontend but it seems it's the same type of problems in 2021 than it was 5/10/even 20 years ago.
In backend you choose your stack and who to interface with. Sure, people can write all sorts of clients to talk to you, but you are the one who decides most parameters (except amount of traffic, and for that there's rate limiting).
In frontend you are closest to the end user and are the only one who is not only speaking to machines, but that's only one end.
So personally I'd say frontend is more thankless, and you often need to know more about specific edge cases, whereas in backend you need to know more about unspecific classes of edge cases.
Also one point is that the barrier of frontend and backend has shifted. For a long time when we as backend developers worked with frontend developers that meant we did PHP/Python/Java/Ruby and some basic HTML and they did HTML/CSS/some JS.
Nowadays frontend basically means JavaScript and even the meaning of full stack has shifted.
Easier in some ways, harder in others.
Easier:
+ You don't need to write a thousand edge case code to cover different devices
+ There's less "trial and error" trying to figure out what sequence of CSS properties is needed to adjust some of the simplest of designs
+ More choices of languages available (should Javascript / Typescript not float your boat)
+ More consistency in that you only need to worry about your backend language and maybe SQL (if you're not using an ORM -- which frankly developers shouldn't imo)
+ Easier to write unit tests
Harder:
- Lazy code becomes more than just an annoyance, it will have performance impacts on your servers thus directly costing your company more money
- You can no longer rely on other people to deal with security for you. Mistakes aren't just going to be rendering bugs
- You don't have something immediate that you demo if there isn't already a UI mocked up
- You need to rely more heavily on unit tests
And if your back end developers are also doubling as DevOps then your job will get exponentially harder still as you then have to manage infrastructure as well. But a lot of places will have dedicated infrastructure guys.
Personally I much prefer backend development to frontend development. I (personally) find it more predictable and easier to reason. However a lot of people prefer frontend development if just because you get to see instant results of your code
Easier:
+ You don't need to write a thousand edge case code to cover different devices
+ There's less "trial and error" trying to figure out what sequence of CSS properties is needed to adjust some of the simplest of designs
+ More choices of languages available (should Javascript / Typescript not float your boat)
+ More consistency in that you only need to worry about your backend language and maybe SQL (if you're not using an ORM -- which frankly developers shouldn't imo)
+ Easier to write unit tests
Harder:
- Lazy code becomes more than just an annoyance, it will have performance impacts on your servers thus directly costing your company more money
- You can no longer rely on other people to deal with security for you. Mistakes aren't just going to be rendering bugs
- You don't have something immediate that you demo if there isn't already a UI mocked up
- You need to rely more heavily on unit tests
And if your back end developers are also doubling as DevOps then your job will get exponentially harder still as you then have to manage infrastructure as well. But a lot of places will have dedicated infrastructure guys.
Personally I much prefer backend development to frontend development. I (personally) find it more predictable and easier to reason. However a lot of people prefer frontend development if just because you get to see instant results of your code
Back End owns more of the infrastructure, including the admin, pipeline, and networking chores.
But the UX seems the 20% of the system eating 80% of the time, yes.
But the UX seems the 20% of the system eating 80% of the time, yes.
I was once doing good work at a dysfunctional company. We had a good application backend with a poor frontend. Another team, rivals, came in with a great frontend and barely enough backend to support it. They won so much support and mindshare with their prettier UI that our project was canceled, and they years working on backend features we had from the beginning.
To most people, the UI is the application.
https://blog.codinghorror.com/the-user-interface-is-the-appl...
To most people, the UI is the application.
https://blog.codinghorror.com/the-user-interface-is-the-appl...
That is the ratio thank you! From the 5+ years experience I have, BE tasks always consume less time than FE tasks. One of the reasons for it is that, BE works get commented by technical people and technical people easy to get along well and understand each other and the decisions. However FE works get commented by a larger audience either technical or non-technical. Each comment delays the acceptance of the work done. And mostly it is harder to persuade a non-tech person about the limitations of the current technology.
Totally agree.
This has also been my experience having recently transitioned from FE to BE.
Even if FE is easier to demo, there's less appreciation for the underlying complexity.
This has also been my experience having recently transitioned from FE to BE.
Even if FE is easier to demo, there's less appreciation for the underlying complexity.
thanks for the breakdown.
> You can no longer rely on other people to deal with security for you. Mistakes aren't just going to be rendering bugs
this is the one that concerns me most. i was thinking maybe php with wordpress to leverage my existing skills but even then is that really backend or maybe not.
> You can no longer rely on other people to deal with security for you. Mistakes aren't just going to be rendering bugs
this is the one that concerns me most. i was thinking maybe php with wordpress to leverage my existing skills but even then is that really backend or maybe not.
I'm a full-stack engineer, but my main focus has always been frontend, so to give my perspective.
Frontend is really hard, writing re-usable HTML and CSS is almost as hard as writing re-usable backend modules. I get annoyed by backend engineers brushing off frontend, as it's a piece of cake for them. But when you actually ask them to write some, they struggle, because they have no idea how to make it reusable.
Frontend especially requires you to stay up-to-date, even more so than backend technologies. The ecosystem changes so much, that it can become an annoyance, but the key is to stick to what you think is best. For example, I still use Gulp for tasks, just because it works, and it's far easier to configure than Webpack or any other bundler.
But on the backend, I've found that there are far more interesting problems to solve. The design behind it is far more complex, especially when you start dealing with databases and message queues. But then you also need to start looking at how to deploy your backend, and how to scale it up, etc...
So when I made the move from frontend to backend, it wasn't easy. But it also wasn't particularly hard, if you know JS/TS, moving to a node backend is fairly straight forward. Once you have enough experience there, moving to Java or Python is just learning whatever framework you're using. What I found much more difficult, was moving back to frontend, after doing backend for a couple of months, I felt like many things had changed, and it was hard to switch my mindset back to frontend.
Frontend is really hard, writing re-usable HTML and CSS is almost as hard as writing re-usable backend modules. I get annoyed by backend engineers brushing off frontend, as it's a piece of cake for them. But when you actually ask them to write some, they struggle, because they have no idea how to make it reusable.
Frontend especially requires you to stay up-to-date, even more so than backend technologies. The ecosystem changes so much, that it can become an annoyance, but the key is to stick to what you think is best. For example, I still use Gulp for tasks, just because it works, and it's far easier to configure than Webpack or any other bundler.
But on the backend, I've found that there are far more interesting problems to solve. The design behind it is far more complex, especially when you start dealing with databases and message queues. But then you also need to start looking at how to deploy your backend, and how to scale it up, etc...
So when I made the move from frontend to backend, it wasn't easy. But it also wasn't particularly hard, if you know JS/TS, moving to a node backend is fairly straight forward. Once you have enough experience there, moving to Java or Python is just learning whatever framework you're using. What I found much more difficult, was moving back to frontend, after doing backend for a couple of months, I felt like many things had changed, and it was hard to switch my mindset back to frontend.
I would suggest that you try out for yourself. Try to follow a Django tutorial from beginning to the end, and if that's something you might enjoy doing.
Backend work is not "easier" than frontend, it's a different world where you have to learn to deal with other type of problems.
But I'm surprised that you think your job pool is becoming smaller, there is multiple magnitudes way more demand for frontend work now than in 2007. And it doesn't take much to learn about responsive layouts and React/Vue/whatever if you already have 14 years of experience working on frontend projects. Have you considered looking for a developer group with people who could help you get started with npm and other more modern tools? Nowadays you can get access to a lot of support by joining a Discord server, people are generally supportive and can ease your learning.
Backend work is not "easier" than frontend, it's a different world where you have to learn to deal with other type of problems.
But I'm surprised that you think your job pool is becoming smaller, there is multiple magnitudes way more demand for frontend work now than in 2007. And it doesn't take much to learn about responsive layouts and React/Vue/whatever if you already have 14 years of experience working on frontend projects. Have you considered looking for a developer group with people who could help you get started with npm and other more modern tools? Nowadays you can get access to a lot of support by joining a Discord server, people are generally supportive and can ease your learning.
I have so much empathy for people in this kind of situation. There's a brutal inhumanity about the tech hype cycle and how it deprecates and discards skills that humans poured their soul into learning in good faith. What should be rich and rewarding careers building on experience and knowledge, continuously gaining over time, become more like a mouse wheel ... constantly running just to keep up... until you eventually fall off and are cast aside.
The only advice that I have is learn the crap out of the fundamentals - they are the only things that won't change. Then use that deep strength to make surfing the hype cycle less exhausting. Use that to "lean in" and embrace change.
The only advice that I have is learn the crap out of the fundamentals - they are the only things that won't change. Then use that deep strength to make surfing the hype cycle less exhausting. Use that to "lean in" and embrace change.
+1 to all this. :) Absolutely, learn the fundamentals. Also, detecting which tech is here to stay, and which is here today gone tomorrow, is itself a skill, that's essential for survival in this industry. Such a skill tends to come with age and experience (a.k.a getting burnt by working hard to learn something that's then discarded). The earlier this skill is developed the better. Then, one must be ruthless about quitting jobs, shunning higher pay or seniority, when that's necessary in order to keep working on stuff that maintains long-term skills. No good getting paid a fortune if 3 yrs later you're unemployable. I know someone that literally happened to, made a fortune as a contractor paid off his mortgage, then became a postman for a bit, eventually became an accountant as he saw that those skills would have long term value. (He couldn't stay in tech cos his skills were out of date.)
yes, i often think about what really drives this constant cycle of change.
I find it easier, simply because backend is typically the one language. It's easier to understand when there are fewer layers to everything. All I have to do is ensure the routes correctly serve/receive JSON and that's where my worries end.
Honestly, if you're resonably comptent in JS you can make the jump to backend, or even systems programming. Linus Groth is the second-in-command of SerenityOS, and he has come from only writing JavaScript to writing parts of a JS virtual machine. (ref: https://linus.dev/posts/my-journey-with-serenityos/)
Honestly, if you're resonably comptent in JS you can make the jump to backend, or even systems programming. Linus Groth is the second-in-command of SerenityOS, and he has come from only writing JavaScript to writing parts of a JS virtual machine. (ref: https://linus.dev/posts/my-journey-with-serenityos/)
i have experience with php. so was thinking maybe php with a focus on wordpress.
I've tried native mobile dev, web frontend and backend dev.
The nuance of frontend dev is that you need to pack a lot of things into one process, so it requires more sophisticated coding skills. reactive patterns or stream based approach is a good-to-go knowledge to have.
backend is easier to code, however the nuance is to split and scale it once you getting more traffic, proper configurations, dependency management, deployment etc.
based on my subjective perspective obviously, there are far more things to consider.
in general, do what you love ^_^
The is only true at a small scale. The frontend is often like the tip of the iceberg - it hides an enormous amount of complexity.
I've worked on a lot of systems in my career and I have found there to be a lot more complex and interesting problems in the "backend" than in "frontend".
With backend development, there are very real consequences for making mistakes, and you have a high chance of being punished for making them. When I have front-enders moving down the stack I have to invest significant effort into this. Particularly around secure development, proper automated testing etc, they are fairly uncommon in the frontend but absolutely vital in the backend.
I do get more enjoyment - more feeling of having "made" something when I've worked on the frontend. There's just something about being able to interact tangibly with your work which gives me a big sense of accomplishment. That, and if you're working on a game/native code then the optimisation work is more immediately rewarding.
I've worked on a lot of systems in my career and I have found there to be a lot more complex and interesting problems in the "backend" than in "frontend".
With backend development, there are very real consequences for making mistakes, and you have a high chance of being punished for making them. When I have front-enders moving down the stack I have to invest significant effort into this. Particularly around secure development, proper automated testing etc, they are fairly uncommon in the frontend but absolutely vital in the backend.
I do get more enjoyment - more feeling of having "made" something when I've worked on the frontend. There's just something about being able to interact tangibly with your work which gives me a big sense of accomplishment. That, and if you're working on a game/native code then the optimisation work is more immediately rewarding.
Oh: and I must say that modern frameworks have made frontend development much easier than it used to be. With Angular, Vue, React you can actually apply the good engineering practises to structure your code in a way that makes it more manageable than it was in the past (with JQuery + server-side templates).
The testing frameworks are also pretty good, helped a lot by the frameworks being built properly (inversion of control :drools:).
The testing frameworks are also pretty good, helped a lot by the frameworks being built properly (inversion of control :drools:).
definitely, frameworks are great for a lot of use cases.
I was as well touching a little bit mobile dev, which is still in some sense hard. You need in each app write a little "browser engine" with websockets, rest api with http cache, image caching and a lot of other things that the classical browser environment gives web developers for free.
> I'm not good at animations, responsive layouts, pixel perfection, es6
> The simplest task now so complicated, many edge cases.
> Things get deprecated (or sunsetted) so fast.
> When I open the chrome inspector there's 10 new features which I ignore. It's too much.
I don't do web development at all, but from the outside it always seemed to me that most of those problems are completely self-inflicted by front end dev community that seems to be hellbent on turning even most trivial things into Rube Goldberg machines.
> The simplest task now so complicated, many edge cases.
> Things get deprecated (or sunsetted) so fast.
> When I open the chrome inspector there's 10 new features which I ignore. It's too much.
I don't do web development at all, but from the outside it always seemed to me that most of those problems are completely self-inflicted by front end dev community that seems to be hellbent on turning even most trivial things into Rube Goldberg machines.
from my experience, it's the expectations of the client has changed so much. and it's very difficult to deliver on their ambitions with the web browser as your platform.
i feel like its impossible to get anything right because often the final solution is kind of nebulous existing in the clients mind only and often they dont have an appreciation for complexity. a simple adjustment for them may be hours or more of work.
i feel like its impossible to get anything right because often the final solution is kind of nebulous existing in the clients mind only and often they dont have an appreciation for complexity. a simple adjustment for them may be hours or more of work.
IMHO, back-end is a better long-term career investment, as it changes slower, less faddish, and you learn skills applicable to many situations. Its not easier, if anything actually harder, but more satisfying in my experience. I've noticed many early-to mid 20s devs love front-end, the new and shiny, it feels creative and "cool" to them. However, they can crash at age 30+ when those front-end skills aren't cool anymore, if that's all they have. Whereas, had they learned lots of back-end and dev-ops-y stuff, bash scripting , linux etc, those are longer value skills. I write this as basically a full-stack dev, although much stronger on backend and devops than the latest JS libraries. As someone well the wrong side of 40, this particular skills choice has served me well in terms of still being marketable despite being older. So my advice = invest in back-end skills whatever you do
> learned lots of back-end and dev-ops-y stuff, bash scripting , linux etc
I use shell scripts and Linux for front end every day. Modern frontend is quite programmatic.
> However, they can crash at age 30+ when those front-end skills aren't cool anymore
You've seen a lot of front enders age out of it? Why would this be? My whole team are frontenders in their 30s.
I use shell scripts and Linux for front end every day. Modern frontend is quite programmatic.
> However, they can crash at age 30+ when those front-end skills aren't cool anymore
You've seen a lot of front enders age out of it? Why would this be? My whole team are frontenders in their 30s.
Possibly you answered your own Q there? ;). Using scripts, Linux plentifully in a front-end job, might indicate being a bit more full-stack than you call yourselves, and hence, you've got some long-life skills alongside the Angular/React/whatever. I'm not saying everyone ages out of it, just I'd seen it as a thing for some people. I speak as someone now a bit old for tech (late 40s) , yet somehow managing to have a marketable skillset, some of which is ancient yet always applicable. Maybe being a purely front-end dev is safe as long as you become a vim expert in the process. ;). (not entirely joking here actually!)
Any chance you could list the skills/knowledge you feel have kept you marketable?
Asking as I'm just about to reach mid forties and I'm a Frontender who feels the same as the OP.
If I have a go at moving to backend one concern I have is that I wouldn't know what skills are just nice to have's and what's an essential skill so I could waste too much time learning the wrong things.
Asking as I'm just about to reach mid forties and I'm a Frontender who feels the same as the OP.
If I have a go at moving to backend one concern I have is that I wouldn't know what skills are just nice to have's and what's an essential skill so I could waste too much time learning the wrong things.
Sure. Glad to help :). Bash/zsh/scripting in general, combined with nice productivity tools like fzf, vim (really speeds up your work when you know it well and you can get vim plugins for VSCode/PHPStorm/InteliiJ etc). However, don't sweat not knowing vim if you at least have one very good editor available everywhere that you know well. Docker, (which often just amounts to knowing what shell script to put in a dockerfile), fair amount of exposure to AWS, short-cutted by using the command line cli combined with jq. (AWS is a beast, so don't try to keep on top of it all, but master the basics like e:g how to list S3 bucket from command line), some exposure to Terraform, wouldn't say I really know it, but I could edit some tf files and add stuff then go in the AWS console and look what it created (but I'm really a dev, not an infrastructure eng, so this works out to be enough). Python (lots and lots of it). Python is super useful for knocking out stuff quickly. Python will always be useful IMHO, for decades I believe. PHP I don't know fantastically but I can scrape by. Java ditto although I really don't like Java. C++ I did years ago , for years, don't really do it now much but occasionally comes up. Makefiles = a truly ancient but v useful skill. Soft skills like being pedantic about nailing down requirements precisely. Being nice to other team members and easy to work with (but I'll let them be the judge of that ;) ). One key thing I think is I always adored the command line, and shunned GUIs , not a massive fan of IDEs. Guess which one of those stays current and guess which one gets completely changed around and/or falls out of fashion. ; git- make sure you know that reasonably well especially the command line (sure its a PITA to get to grips with, but worth it). In general, mess about with Linux a little bit in your spare time (within reason, not letting it get in the way of family time.). See if your partner will switch to Linux even if not a geek. My wife has, and MS Windows drives her nuts compared to it. ;). Even our daughter messed about with some terminal commands like cowsay etc. ;). why is that even relevant here, well it keeps you in that groove of discovery and enjoyment. IMHO anyway. ;). running C sharp/dot-net core on Linux is something I enjoyed , nice language on a nice platform..
"Modern" web frontend work involves a lot of chasing after new tooling, frameworks, and libraries.
In your thirties, you're more likely to have a stable relationship and kids to care for.
If the tools you learned in your twenties age out of relevance, then you may well have a hard time retraining to new tools while raising small kids.
In your thirties, you're more likely to have a stable relationship and kids to care for.
If the tools you learned in your twenties age out of relevance, then you may well have a hard time retraining to new tools while raising small kids.
> If the tools you learned in your twenties age out of relevance
If someone learned React in your 20s and then "aged out", they must have been an early adopter. React is only 9 years old and most developers didn't start learning it in 2013. And it's far from irrelevant: https://trends.builtwith.com/javascript/React
> "Modern" web frontend work involves a lot of chasing after new tooling, frameworks, and libraries.
Le meme never gets old.
If someone learned React in your 20s and then "aged out", they must have been an early adopter. React is only 9 years old and most developers didn't start learning it in 2013. And it's far from irrelevant: https://trends.builtwith.com/javascript/React
> "Modern" web frontend work involves a lot of chasing after new tooling, frameworks, and libraries.
Le meme never gets old.
Yes, if you learned React you'd have a decent shelf life still.
What if you learned classic AngularJS, due to go unsupported in a month and a half? What if you threw in with ExtJS ages ago and the enterprise corp you've been using it for just downsized and outsourced your project? Maybe you were an EmberJS aficionado but can't find new gigs using it. I worked on a greenfield project in Backbone/Thorax/Mustache a number of years back but haven't seen any of those in the wild since. Maybe you love Elm but can't find any places that will hire you to use it. Ditto using Clojure on the frontend.
Picking the winner is a great trick, but my point was that if you didn't (or just the companies you worked for didn't), you may find yourself in a bit of a hole, specifically if you have a lot of other responsibilities in your life.
What if you learned classic AngularJS, due to go unsupported in a month and a half? What if you threw in with ExtJS ages ago and the enterprise corp you've been using it for just downsized and outsourced your project? Maybe you were an EmberJS aficionado but can't find new gigs using it. I worked on a greenfield project in Backbone/Thorax/Mustache a number of years back but haven't seen any of those in the wild since. Maybe you love Elm but can't find any places that will hire you to use it. Ditto using Clojure on the frontend.
Picking the winner is a great trick, but my point was that if you didn't (or just the companies you worked for didn't), you may find yourself in a bit of a hole, specifically if you have a lot of other responsibilities in your life.
Skills transfer across frameworks and even languages. If you're good at Elm or Clojure, you would be great at React. Vue owes a lot of its structure to the original Angular (or at least it did when I learned it forever ago).
Sure, skills do apply across frameworks and languages. The hundred stupid things you need to know about any given framework don't, though.
To be clear, I'm not thinking about people who've used lots of languages and tools here. I've done time working for huge corporations for whom software is a cost center, and it's easy to find people in those contexts who are competent with the tools they know but have narrow enough experience that moving to something else is difficult for them.
The "average Joe" programmer's experience is what I'm thinking of here.
To be clear, I'm not thinking about people who've used lots of languages and tools here. I've done time working for huge corporations for whom software is a cost center, and it's easy to find people in those contexts who are competent with the tools they know but have narrow enough experience that moving to something else is difficult for them.
The "average Joe" programmer's experience is what I'm thinking of here.
Aside from what NateEag said, React is one thing, but the tooling is a completely different topic. When it comes to building your frontend, there was grunt and gulp (that I'm aware of), now the tools that get most love are I think webpack and esbuild. I didn't do anything with esbuild yet, but the way that applications are built changed a lot during the years, and webpack is much different that whatever there was before.
Also, all of those tools are massive pains in your ass if something breaks, because debugging what actually broke is hard when your build process becomes more complicated.
Front-end is awful in (large) part because of the tooling IMO. In the backend world, you need to make sure your _vertical_ (aka scale) is respected. It's a matter of your code, your infra plus the tooling to help you. If you're good at what you do, use the correct engineering approaches to have an efficient program and use up to date infrastructure or platforms, and use an up to date language (Rust, Python, Java is excellent here, whatever) you'll have all the tools.
Your ground won't move as long as you didn't ask him to move. So, For me, it's easier to maintain (but still requires a loooot of care and attention to not fall apart)
In the frontend world, as you said, it's movement everywhere. Browsers, JS, JS package managers, CSS and so on. Even if your code don't move, the platform under will. Your code performance is not only dependent of you, making you tied to the evolution if you want to be up to date. That's so hard, and ungrateful...
If you want to stay in the frontend world, you should definitely increase your knowledge in CSS + Responsive, I think it's the best skill. In JS, stay on par with the language spec. Libraries will come and go, you can learn one (Vue or React, whatever it's the same) to understand the foundations, and it can land you a job basically everywhere.
Backend is easier because it's vertically aligned: performance and stability on a given system that you own. Frontend is horizontally aligned: acceptable performance and rendering on a shitload of systems which enslave you.
What interested me those last months is another path: Mobile dev, especially with Flutter. You keep some stability of a fixed OS (you still have the different versions + screen size, but you choose which one to support), and have the tooling of something close to the backend (compiled languages, package manager, big community). I think you should take a look there if you still want to keep a feet in "client" software, plus you'll never get out of job offers!
In the frontend world, as you said, it's movement everywhere. Browsers, JS, JS package managers, CSS and so on. Even if your code don't move, the platform under will. Your code performance is not only dependent of you, making you tied to the evolution if you want to be up to date. That's so hard, and ungrateful...
If you want to stay in the frontend world, you should definitely increase your knowledge in CSS + Responsive, I think it's the best skill. In JS, stay on par with the language spec. Libraries will come and go, you can learn one (Vue or React, whatever it's the same) to understand the foundations, and it can land you a job basically everywhere.
Backend is easier because it's vertically aligned: performance and stability on a given system that you own. Frontend is horizontally aligned: acceptable performance and rendering on a shitload of systems which enslave you.
What interested me those last months is another path: Mobile dev, especially with Flutter. You keep some stability of a fixed OS (you still have the different versions + screen size, but you choose which one to support), and have the tooling of something close to the backend (compiled languages, package manager, big community). I think you should take a look there if you still want to keep a feet in "client" software, plus you'll never get out of job offers!
i feel like with backend the problems are more concrete and discrete. kind of like 1 + 1 = 2. there is only one correct answer.
with front end things get way more complicated. so many browsers, viewports and you can never be 100% the client will see the same thing that you've been working on for X hours because of the unpredictable environment they test on.
with front end things get way more complicated. so many browsers, viewports and you can never be 100% the client will see the same thing that you've been working on for X hours because of the unpredictable environment they test on.
A big issue I'm having learning back-end coming from front-end was to gauge if my implementations were correct at all. With front-end you usually get immediate feedback: CSS mistakes and infinite rendering loops are easy to spot. With back-end, poorly optimized code can run great in development and even beyond because stacks these days are very forgiving, up to a certain point where you have no idea why things are slowing down/crashes. In a sense: I find back-end to be more abstract, you have to visualize possible issues more and develop skills to stress-test and identify bottlenecks.
A thing that helped me so far was to demystify databases a bit – looking at you, Designing Data-Intensive Applications – but I'm still seriously struggling to be confident in deploying in production.
A thing that helped me so far was to demystify databases a bit – looking at you, Designing Data-Intensive Applications – but I'm still seriously struggling to be confident in deploying in production.
Write automated tests for your code as you're writing it. Hitting the entire system is fine. If your code is properly factored then it should be easy to do. If not, then you get to learn how to factor your code.
Test your backend with real data, not playsets. So use millions of records instead of 3-4.
If you're touching database, then learn SQL, and learn the tooling for your database. Learn how to read a query plan, use the optimiser and design indexes.
Test your backend with real data, not playsets. So use millions of records instead of 3-4.
If you're touching database, then learn SQL, and learn the tooling for your database. Learn how to read a query plan, use the optimiser and design indexes.
Thanks a lot for the advice, really appreciate it!
My pleasure. Hope that it helps. If you check out some of the "TDD with .Net guides" or "TDD with Java" (Pluralsight, Youtube) then you can see the flow in action.
Backenders struggle with the same thing in the frontend but in reverse. For frontend, you need to be interacting constantly - the shorter the loop between code and frontend, the better.
Backenders struggle with the same thing in the frontend but in reverse. For frontend, you need to be interacting constantly - the shorter the loop between code and frontend, the better.
If you had asked this question around 2007, I would have said front end is easier. But, as an experienced full stack solo consultant who runs production sites for his clients with millions of visitors, I can tell you backend is super easy in 2021 compared to frontend. I use Elixir/Phoenix framework.
Frontend has become this complex massive spaghetti mess of an ecosystem with something or the other constantly breaking all the time. almost all my projects involving frontend code has become extremely tedious to maintain because Babel has fucked up something or the old library that was supposed to do some simple function is kicked out of NPM or has renamed it’s package name to something without hyphens. You can’t even escape upgrading those libraries as your Webpack build will fail all of a sudden.
In contrast, I’ve switched to using Phoenix LiveView which has made me skip frontend development altogether (using JS frameworks like React, I mean) and my life has become so much easier.
My code is easier to reason about even after 6-8 months and stuff doesn’t break randomly.
Frontend has become this complex massive spaghetti mess of an ecosystem with something or the other constantly breaking all the time. almost all my projects involving frontend code has become extremely tedious to maintain because Babel has fucked up something or the old library that was supposed to do some simple function is kicked out of NPM or has renamed it’s package name to something without hyphens. You can’t even escape upgrading those libraries as your Webpack build will fail all of a sudden.
In contrast, I’ve switched to using Phoenix LiveView which has made me skip frontend development altogether (using JS frameworks like React, I mean) and my life has become so much easier.
My code is easier to reason about even after 6-8 months and stuff doesn’t break randomly.
Both are hard but the shape of that hardness differs.
The frontend problemspace didn't feel like it was depth, more breadth... it's a constantly moving surface and lots of unreasonable demands were created (pixel perfect layouts being the most telling of them). However the number of things you really need to know are few and it's the tooling that changes often.
The backend problemspace is typically not as wide, but far deeper... the depth looks like still dark waters, they run very deep, you think it's smooth sailing but it's not. The tooling changes seldom and things are a lot more deterministic and within your control... but now you've exposed yourself to a lot of things you didn't previously have to be concerned about, the kernel, networking, memory allocations, distributed systems, algorithms, etc. The tools may remain the same for time spans of decades, but the depth means in your entire career you will not exhaust going deeper still.
Both are hard, but the shape of that differs.
The frontend problemspace didn't feel like it was depth, more breadth... it's a constantly moving surface and lots of unreasonable demands were created (pixel perfect layouts being the most telling of them). However the number of things you really need to know are few and it's the tooling that changes often.
The backend problemspace is typically not as wide, but far deeper... the depth looks like still dark waters, they run very deep, you think it's smooth sailing but it's not. The tooling changes seldom and things are a lot more deterministic and within your control... but now you've exposed yourself to a lot of things you didn't previously have to be concerned about, the kernel, networking, memory allocations, distributed systems, algorithms, etc. The tools may remain the same for time spans of decades, but the depth means in your entire career you will not exhaust going deeper still.
Both are hard, but the shape of that differs.
Frontend isn't so much more difficult as it is more annoying. The difficult parts of backend development might take a lot of research, design, and even experimentation but it is usually roughly logical. Frontend is often a case of wrangling cats in the form of dozens of libraries, all with different design paradigms. Due to release velocity, these designs are often poorly thought out. You spend lots of time editing configurations, often poorly documented, to get everything to work together. Much of it is trial and error instead of logical deduction.
My biggest challenge on the backend has been poorly documented systems with arbitrary design choices. This sounds a lot like the frontend but the difference is that on the backend, these quirks are relatively static. Once you figure the system out, you can build upon it. With the frontend you never know when some library is going to send a tidal wave through everything.
My biggest challenge on the backend has been poorly documented systems with arbitrary design choices. This sounds a lot like the frontend but the difference is that on the backend, these quirks are relatively static. Once you figure the system out, you can build upon it. With the frontend you never know when some library is going to send a tidal wave through everything.
Depends on the backend I guess.
It can be very easy: Call an API/ORM, validate, format then return a JSON.
As everything, it can also be more complex: SQL optimisation, DB schema migrations and rollbacks (liquibase is a good start), micro-services, CQRS, DDD, kafka, monitoring, observability etc..
Both frontend and backend can be easy or hard.
It can be very easy: Call an API/ORM, validate, format then return a JSON.
As everything, it can also be more complex: SQL optimisation, DB schema migrations and rollbacks (liquibase is a good start), micro-services, CQRS, DDD, kafka, monitoring, observability etc..
Both frontend and backend can be easy or hard.
I made the move from pure back-end to full-stack some years ago. I find that backend paradigms tend to not evolve as quickly, so perhaps this pace suits you better.
The consumer of a back-end is either a front-end under management, or via public APIs, and both usually live a lot longer than most JS frameworks and website designs.
Still, if you don’t mind drawing things in browsers and just don’t like the pace of things, you could pick a front-end framework designed to have a low rate of sudden changes, e.g. Elm.
Either way, if you’d prefer not to have to learn too many new things, learning how to make back-ends with Node and ES6 probably provides you with most value in the shortest time. Just say no to new dependencies all the time. ;)
The consumer of a back-end is either a front-end under management, or via public APIs, and both usually live a lot longer than most JS frameworks and website designs.
Still, if you don’t mind drawing things in browsers and just don’t like the pace of things, you could pick a front-end framework designed to have a low rate of sudden changes, e.g. Elm.
Either way, if you’d prefer not to have to learn too many new things, learning how to make back-ends with Node and ES6 probably provides you with most value in the shortest time. Just say no to new dependencies all the time. ;)
> you could pick a front-end framework designed to have a low rate of sudden changes, e.g. Elm.
React barely changes at all. The last major change was 3 years ago when they introduced hooks, which was not sudden. Even then they didn't deprecate the old way of doing things. You can write React today the same as you did in 2018 if you want.
React barely changes at all. The last major change was 3 years ago when they introduced hooks, which was not sudden. Even then they didn't deprecate the old way of doing things. You can write React today the same as you did in 2018 if you want.
React is a prime example of fast-change (even though not so fast as angular did). Since 2014, they changed their main programming paradigm 3 times (mixins/make*, real ES6 classes, now hooks). Then there was state management; first Flux, later Redux, then MobX became fashionably while today I start React projects without any state library and just use the stable context API + hooks. And let alone the plentheora of major changes in ReactRouter, which only became somewhat stable at version 4.
> Then there was state management; first Flux, later Redux, then MobX
Redux and Mobx are not part of React. The Flux pattern is still valid and is an inherent part of writing React code?
> ReactRouter
This is also not part of React.
> today I start React projects without any state library
Is this a hot take? The creator of Redux literally said "Don't use Redux until you have problems with vanilla React." https://twitter.com/dan_abramov/status/699241546248536064
Redux and Mobx are not part of React. The Flux pattern is still valid and is an inherent part of writing React code?
> ReactRouter
This is also not part of React.
> today I start React projects without any state library
Is this a hot take? The creator of Redux literally said "Don't use Redux until you have problems with vanilla React." https://twitter.com/dan_abramov/status/699241546248536064
Not sure if you are trolling or just not long enough into the game, but pre-hooks/stable context era you'd hit the problems with vanilla React pretty quickly. From my experience back in the day, everbody was using some sort of state container and to some extend today, still is right from the get go.
Yes, I know, none of the libs are part of React and react is not a framework, but by now everybody knows that and uses React as a synonym for the React ecosystem. I have yet to see the enterprise project that didn't use either a state container or other parts from the react ecosystem such as react-router, react-intl, material-ui, CRA and the likes. Like it or not, React is an ecosystem, and fast changing one if you are in the field.
Yes, I know, none of the libs are part of React and react is not a framework, but by now everybody knows that and uses React as a synonym for the React ecosystem. I have yet to see the enterprise project that didn't use either a state container or other parts from the react ecosystem such as react-router, react-intl, material-ui, CRA and the likes. Like it or not, React is an ecosystem, and fast changing one if you are in the field.
It's not easier, just a very different environment to work with, it all depends on the technology choice to be honest.
I've worked for some larger-ish tech companies the past 6 years and the choice for backend technologies is simply more mature than the hodge-podge of changes in the frontend, there has been some consolidation on backend frameworks/technologies/patterns over the past decade that has helped me a lot.
I think you can say that backend engineering with some technologies is much more mature than the current environment on the web frontend. Not easier, just that you don't have to care about swapping major parts of your build infrastructure every 3 years anymore.
I've worked for some larger-ish tech companies the past 6 years and the choice for backend technologies is simply more mature than the hodge-podge of changes in the frontend, there has been some consolidation on backend frameworks/technologies/patterns over the past decade that has helped me a lot.
I think you can say that backend engineering with some technologies is much more mature than the current environment on the web frontend. Not easier, just that you don't have to care about swapping major parts of your build infrastructure every 3 years anymore.
Backend is hard like building a beautiful and complex watch mechanism.
Frontend is hard like training a dozen cats to perform a dance to a song played on half-broken 8-track player.
They’re both hard, but one makes you question your own sanity more often.
Frontend is hard like training a dozen cats to perform a dance to a song played on half-broken 8-track player.
They’re both hard, but one makes you question your own sanity more often.
I am a frontend developer, but from afar, backend looks harder.
I think the challenge is being able to look at all things that are new and choosing the ones that matter. From your post, I think you are failing hard at this.
I safely ignore Chrome inspector new features until it happens to be relevant enough for a coworker to mention to me. I don’t know much about animation, but probably could Google my way into it if required in a task.
Now, responsive layout and ES6? These are essential for frontend development for some time already. It is not like those are new hyped frameworks that some early adopters are jumping into, those are required knowledge since, idk, five years ago.
So there is this aspect of development work where you have to study new things. You don’t have to study all things all the time. But ES6 you are already a good few years late to learn it, there is no way around it. You don’t need to know about Vue and Svelte, but you have to know well at least one framework, and React is the most popular by far, so it is an obvious choice. And you have to keep up with most relevant new things of your framework of choice. React Hooks is starting to enter that zone of required things to know.
If you don’t have the will to study everything (most people don’t) choose wisely what you must know. But if you don’t have the will to study anything new, there is no way you can have a career in any aspect of software development.
I think the challenge is being able to look at all things that are new and choosing the ones that matter. From your post, I think you are failing hard at this.
I safely ignore Chrome inspector new features until it happens to be relevant enough for a coworker to mention to me. I don’t know much about animation, but probably could Google my way into it if required in a task.
Now, responsive layout and ES6? These are essential for frontend development for some time already. It is not like those are new hyped frameworks that some early adopters are jumping into, those are required knowledge since, idk, five years ago.
So there is this aspect of development work where you have to study new things. You don’t have to study all things all the time. But ES6 you are already a good few years late to learn it, there is no way around it. You don’t need to know about Vue and Svelte, but you have to know well at least one framework, and React is the most popular by far, so it is an obvious choice. And you have to keep up with most relevant new things of your framework of choice. React Hooks is starting to enter that zone of required things to know.
If you don’t have the will to study everything (most people don’t) choose wisely what you must know. But if you don’t have the will to study anything new, there is no way you can have a career in any aspect of software development.
Personally, I do find back-end easier to reason about than FE, although it will almost certainly depend on your choice of language/framework to a greater or lesser extent.
In C# MVC (Or PHP MVC like Yii which is very similar), you have a very clear separation of what is what. A single action is where most functionality will sit or be called from. A view is where most front-end code sits (and if writing APIs, this is largely not relevant). Models are for the most part just data properties, perhaps with atributes for validation. Debugging it for the complicated cases is still very easy.
My experience in front-end is that debugging is very difficult. It is not easy to follow the path of execution, partly because of the large complexity of libraries/web-packing type stuff and partly probably depends on the tools you use. You have to consider a LOT of state in anything other than easy applications. I guess these might get better over time as people learn what works and what really doesn't but most of the larger FE frameworks have all had large changes to their patterns/opinions in a relatively short space of time.
I also don't why but I find C# much easier to read and understand than JS even though JS is based on the same syntax style. Again, might be the tooling, coding style or just the complexity of things like Vue classes but I can't easily review JS (or TS) code whereas I can spot mistakes in C# from miles away.
Like other have said though ymmv and whatever you do, you always need to keep up, keep learning and believe in yourself.
In C# MVC (Or PHP MVC like Yii which is very similar), you have a very clear separation of what is what. A single action is where most functionality will sit or be called from. A view is where most front-end code sits (and if writing APIs, this is largely not relevant). Models are for the most part just data properties, perhaps with atributes for validation. Debugging it for the complicated cases is still very easy.
My experience in front-end is that debugging is very difficult. It is not easy to follow the path of execution, partly because of the large complexity of libraries/web-packing type stuff and partly probably depends on the tools you use. You have to consider a LOT of state in anything other than easy applications. I guess these might get better over time as people learn what works and what really doesn't but most of the larger FE frameworks have all had large changes to their patterns/opinions in a relatively short space of time.
I also don't why but I find C# much easier to read and understand than JS even though JS is based on the same syntax style. Again, might be the tooling, coding style or just the complexity of things like Vue classes but I can't easily review JS (or TS) code whereas I can spot mistakes in C# from miles away.
Like other have said though ymmv and whatever you do, you always need to keep up, keep learning and believe in yourself.
Having done backend and now moving to frontend, I would not say either one of them is harder than the other. They're completely different. Having said that, my backend experience can help with taking relevant context into account when solving frontend problems. Things like security, API design and usage, etc, are always on my mind. Likewise, your current frontend experience might give you greater context when working on backend services.
As someone else mentioned, data management and API backwards compatibility is a bigger thing in backend that a frontend dev might find challenging to move to. It's just a different set of problems, but very interesting in its own right.
An example of something that might be easier is not having to worry about browser and device compatibility like you do with frontend (right now a point of frustration for me!)
Both can be very fun and quick to iterate on (microservices written in Go were extremely fun to write and maintain for me!)
Right now I have no preference for either one: both have been providing very fun challenges and learning experiences. I would not move to backend just because you think it's easier, unless your brain is just better wired to handle the types of hard backend problems you would encounter rather than the types of hard frontend problems you encounter now.
As someone else mentioned, data management and API backwards compatibility is a bigger thing in backend that a frontend dev might find challenging to move to. It's just a different set of problems, but very interesting in its own right.
An example of something that might be easier is not having to worry about browser and device compatibility like you do with frontend (right now a point of frustration for me!)
Both can be very fun and quick to iterate on (microservices written in Go were extremely fun to write and maintain for me!)
Right now I have no preference for either one: both have been providing very fun challenges and learning experiences. I would not move to backend just because you think it's easier, unless your brain is just better wired to handle the types of hard backend problems you would encounter rather than the types of hard frontend problems you encounter now.
When I was hiring for a new startup I asked my old boss how to hire frontend people because he was exceptional at both and had built great teams which were frontend focused.
He told me don’t fall into the trap of hiring frontend skills only. Hire software engineers who happen to really know JavaScript.
This has served me really well. Every aspect of applications that we build has needs to structure code, to collaborate in teams, to build abstraction, to ship with an acceptable level of brokenness, and to have mechanisms for continuous improvement.
I’ve worked in several frontend and backend codebases and they all had aspects of difficulty and toil. However talking to lots of people about this I find that certain parts of the stack work better for your personality and talents.
I used to think of frontend as lessor because the hard things seemed to be on the backend. But then I met high caliber JavaScript engineers.
It is sort of like abstract art. Great artists have a solid foundation and then choose their own path.
It is good to get a feel for both and see what resonates with you. Also spending time on the backend can give you empathy to make you better at the frontend; and vice versa.
He told me don’t fall into the trap of hiring frontend skills only. Hire software engineers who happen to really know JavaScript.
This has served me really well. Every aspect of applications that we build has needs to structure code, to collaborate in teams, to build abstraction, to ship with an acceptable level of brokenness, and to have mechanisms for continuous improvement.
I’ve worked in several frontend and backend codebases and they all had aspects of difficulty and toil. However talking to lots of people about this I find that certain parts of the stack work better for your personality and talents.
I used to think of frontend as lessor because the hard things seemed to be on the backend. But then I met high caliber JavaScript engineers.
It is sort of like abstract art. Great artists have a solid foundation and then choose their own path.
It is good to get a feel for both and see what resonates with you. Also spending time on the backend can give you empathy to make you better at the frontend; and vice versa.
The front end is much more difficult. Why? Because that's what the users see - it is the application as far as the users are concerned. Difficult in this context isn't referring to technical difficulty, it's the difficulty of having to deal with the end users and all the problems that entails. From a technical perspective the front end is also moving faster, so there's more churn and more things to keep up with. Finally, there's less research. Front end development hasn't benefited from decades of academic research. It's a mess.
The back end? That's classic computer science. Decades of research, many classes of problems solved, a much slower evolving landscape. That doesn't mean the back end is easy, but at least it's well-known and can be mastered.
Which should you do? That's entirely up to you. Some people enjoy the messiness of the front end and the constant technology churn. Some people prefer the stability of the technology stack on the back end and not having to deal so much with end users.
The back end? That's classic computer science. Decades of research, many classes of problems solved, a much slower evolving landscape. That doesn't mean the back end is easy, but at least it's well-known and can be mastered.
Which should you do? That's entirely up to you. Some people enjoy the messiness of the front end and the constant technology churn. Some people prefer the stability of the technology stack on the back end and not having to deal so much with end users.
In my view backend dev "done well" is easier than "frontend dev done well" for a few reasons, and spoiler - they mostly have to do with people aspects of software:
* Frontend is UI development. UI is hard (race conditions, hard to test, way more edge cases) _and_ a lot of the work you do is valuing, judging, reasoning about and improving aesthetics. You have to be comfortable (and kind) operating in fields where aesthetics and taste are a driver
* Frontend is way, way closer to stakeholders who will (often unfairly) judge what you make and express their opinions which you are going to have to take into account and balance. It is much easier for the pointy haired boss to see that the button is "off shade of green" than it is for them to see that a specific transaction is not guaranteed to be atomic.
* Frontend is much closer to the end users, with a variety of configurations hard to anticipate for (screen resolutions, browser versions, browser extensions, draconian MITM proxies and restrictions) but also just much more variety of _people_ who your product has to satisfy
* Frontend is UI development. UI is hard (race conditions, hard to test, way more edge cases) _and_ a lot of the work you do is valuing, judging, reasoning about and improving aesthetics. You have to be comfortable (and kind) operating in fields where aesthetics and taste are a driver
* Frontend is way, way closer to stakeholders who will (often unfairly) judge what you make and express their opinions which you are going to have to take into account and balance. It is much easier for the pointy haired boss to see that the button is "off shade of green" than it is for them to see that a specific transaction is not guaranteed to be atomic.
* Frontend is much closer to the end users, with a variety of configurations hard to anticipate for (screen resolutions, browser versions, browser extensions, draconian MITM proxies and restrictions) but also just much more variety of _people_ who your product has to satisfy
It depends.
If you write a small app that is only used by a few dozens to maybe hundreds of users, then the backend can be easier than frontend. You can simply code one backend and put it on a fast VM and be done with it.
If you need to scale to thousands or millions of users, things can get messy, because you need to scale horizontally, which leads you into distributed systems territory, which is quite complicated stuff.
If you write a small app that is only used by a few dozens to maybe hundreds of users, then the backend can be easier than frontend. You can simply code one backend and put it on a fast VM and be done with it.
If you need to scale to thousands or millions of users, things can get messy, because you need to scale horizontally, which leads you into distributed systems territory, which is quite complicated stuff.
I have done both over the years. I started out primarily frontend but have gravitated towards backend. I try to keep up with frontend, but it does change very quickly. To your point, backend changes far less frequently, but it does change. I feel like its slower pace of change makes it a more sustainable career path. Time will tell.
A lot of people are saying they’re similar in difficulty, but I believe backend is simpler largely because it’s easier to model. You have a much simpler more defined picture of these are my inputs, this is my output. You also have control over the exact environment your software runs under. Frontend often feels less like a science and more like managing chaos. Backend just has so many less variables outside your control overall.
I feel like backend can be a little thankless at time, at least from outside. People care a lot more about some new widget than the transparent background changes that took months to roll out seamlessly and kept the whole thing running.
A lot of people are saying they’re similar in difficulty, but I believe backend is simpler largely because it’s easier to model. You have a much simpler more defined picture of these are my inputs, this is my output. You also have control over the exact environment your software runs under. Frontend often feels less like a science and more like managing chaos. Backend just has so many less variables outside your control overall.
I feel like backend can be a little thankless at time, at least from outside. People care a lot more about some new widget than the transparent background changes that took months to roll out seamlessly and kept the whole thing running.
I don't feel it is easier or harder, just different.
Back-end coders will code in complex business logic that isn't appropriate for the front end. Algorithms and data structures become more important to your job. So does understanding which layer is the best place to solve a problem - understanding the power and strength of your API layer vs. your database layer vs. any other business layers you might have. You have to deal with the underlying architecture more - if you have a cluster of databases, their replication and conflict management can impact your data. You may have different languages to know for different pieces of the stack. There is also no lack of strongly held beliefs about how apps should be architected. And that doesn't even get into refactoring to handle major app changes, data changes, structure and data migrations.
All of that is still just doing the work - but it is neither inherently easier or harder. It all depends on where your strengths lie.
Back-end coders will code in complex business logic that isn't appropriate for the front end. Algorithms and data structures become more important to your job. So does understanding which layer is the best place to solve a problem - understanding the power and strength of your API layer vs. your database layer vs. any other business layers you might have. You have to deal with the underlying architecture more - if you have a cluster of databases, their replication and conflict management can impact your data. You may have different languages to know for different pieces of the stack. There is also no lack of strongly held beliefs about how apps should be architected. And that doesn't even get into refactoring to handle major app changes, data changes, structure and data migrations.
All of that is still just doing the work - but it is neither inherently easier or harder. It all depends on where your strengths lie.
Front-end is more noisy and fast changing while backend may not be like that. I would say difficulty is very subjective thing. In backend you can trust your tools and they are mostly reliable. The tooling is good and documentation is nicer. It may seem less punk but it is the backbone of the web, in many cases.
Front-end, on the other hand is more precarious. Things change all the time, so it is way more iterative and it needs tooling that respects that (like CI/CD). There is also compatibility issues due to devices. Plus, these days everyone wants to be a front end person and live a life of freedom. Its the new nirvana. Very noisy.
Consider an imperfect analogy of a face and the body. People care about the face a lot. There are tons of makeups for the face. It can be changed fast. This is what I feel about the front end.
The body is more like the backend. It takes a bit more time to change it and investments in it provides value over time.
Hence, they are equally difficult and easy.
Front-end, on the other hand is more precarious. Things change all the time, so it is way more iterative and it needs tooling that respects that (like CI/CD). There is also compatibility issues due to devices. Plus, these days everyone wants to be a front end person and live a life of freedom. Its the new nirvana. Very noisy.
Consider an imperfect analogy of a face and the body. People care about the face a lot. There are tons of makeups for the face. It can be changed fast. This is what I feel about the front end.
The body is more like the backend. It takes a bit more time to change it and investments in it provides value over time.
Hence, they are equally difficult and easy.
Currently in the process of pivoting to backend/fullstack after 10 years of mostly frontend and here are some thoughts:
- If what you're doing is some corporate glorified database explorer with forms, then frontend is easier - especially in(gasp!) Angular. I've seen people pull two jobs doing just that. Backends of such applications tend to have actual challenges, like pulling data out of literally a dozen of sources, complex business logic etc., although once taken care of they're not an issue anymore - requirements don't tend to change significantly over the life-cycle of such an application.
- On the other hand if your app is a product of some hip-SV-startup then there's no end to what clients can come up with to make your life harder.
I guess it all boils down to the type of user the app is catering to.
I want to say backend is more predictable, but I'm doing Node.js at the moment, so nope(looking at you npm versions 7, 8).
- If what you're doing is some corporate glorified database explorer with forms, then frontend is easier - especially in(gasp!) Angular. I've seen people pull two jobs doing just that. Backends of such applications tend to have actual challenges, like pulling data out of literally a dozen of sources, complex business logic etc., although once taken care of they're not an issue anymore - requirements don't tend to change significantly over the life-cycle of such an application.
- On the other hand if your app is a product of some hip-SV-startup then there's no end to what clients can come up with to make your life harder.
I guess it all boils down to the type of user the app is catering to.
I want to say backend is more predictable, but I'm doing Node.js at the moment, so nope(looking at you npm versions 7, 8).
I think that depends a lot on how you define "backend". Writing code to take requests, verify inputs, put things in databases, pull things out of databases, work with third party APIs, etc isn't too bad and the tech isn't moving particularly fast, so it's easier to keep up than frontend. The way backend code takes in requests and handles them and returns responses hasn't really changed that much in the last 10 years.
But if your definition of "backend" includes devOps and cloud computing like edge functions and building using hosting-provider-specific features like AWS's featureset, then "backend" is moving significantly faster than frontend, and it's a hell of a lot harder to learn as you go.
But if your definition of "backend" includes devOps and cloud computing like edge functions and building using hosting-provider-specific features like AWS's featureset, then "backend" is moving significantly faster than frontend, and it's a hell of a lot harder to learn as you go.
There is a bias in software: if you can see it visually it’s worth less.
That bias has generally resulted in lower compensation for front end work irrespective of inherent technical challenges. The result of that bias impacts hiring and trust which then dictate approach and implementation.
That bias has generally resulted in lower compensation for front end work irrespective of inherent technical challenges. The result of that bias impacts hiring and trust which then dictate approach and implementation.
I think this could be reformulated: the result of backend development has less immediately visible consequences, thus more potential for catastrophic errors hence requires more testing and planning in advance (whereas UI testing in the limit is difficult).
Also, if anything, the last couple of years have shown that front end development, and web dev in particular, is highly prone to churn. Hence managers might be tempted to think of a front end as a throw-away component that needs to be redone anyway a couple years down the road when no web dev wants to touch legacy code not using the latest and greatest tech stack, and the relative difficulty of UI testing adds to that. Now why there's so much churn in web dev is another question. One hypothesis is that it's a field seeing lots of freshman; as such, the wealth of frameworks we're seeing is left as a trail of those younger devs learning to make sense of webdev ;) But maybe it's simply that requirements and expectations are changing all the time.
Personally, I'm not at all of the opinion that frontend coding is or should be less valuable than backend.
Also, if anything, the last couple of years have shown that front end development, and web dev in particular, is highly prone to churn. Hence managers might be tempted to think of a front end as a throw-away component that needs to be redone anyway a couple years down the road when no web dev wants to touch legacy code not using the latest and greatest tech stack, and the relative difficulty of UI testing adds to that. Now why there's so much churn in web dev is another question. One hypothesis is that it's a field seeing lots of freshman; as such, the wealth of frameworks we're seeing is left as a trail of those younger devs learning to make sense of webdev ;) But maybe it's simply that requirements and expectations are changing all the time.
Personally, I'm not at all of the opinion that frontend coding is or should be less valuable than backend.
It's the other way around. What you can't see is harder to sell.
However, because people like to see things, there are more people wanting to do frontend and hence the compensation is lower.
The same with game developing. This is definitely not easier than frontend or backend, probably harder. But still paid less, because it's so popular and many people want to do it.
However, because people like to see things, there are more people wanting to do frontend and hence the compensation is lower.
The same with game developing. This is definitely not easier than frontend or backend, probably harder. But still paid less, because it's so popular and many people want to do it.
In web development the average wage for frontend work was lower because the skill level required was lower. You don't need a lot of knowledge to be effective at building websites with HTML/CSS/Photoshop and a sprinkling of javascript/PHP.
During the same time wages for people building frontends which needed more engineering knowledge (early mobiles, WinForms, those horrible old Java frontends) were higher because there were less people capable of doing the world.
In 2021 web development has moved on to the point that we're often building websites in fully features programming languages with heavyweight frameworks (React/Angular). They are paid well. You still see people who work with HTML/CSS/Photoshop and they are generally paid less.
See: Quality Assurance and the different between people who can test manually and who can automate their work.
During the same time wages for people building frontends which needed more engineering knowledge (early mobiles, WinForms, those horrible old Java frontends) were higher because there were less people capable of doing the world.
In 2021 web development has moved on to the point that we're often building websites in fully features programming languages with heavyweight frameworks (React/Angular). They are paid well. You still see people who work with HTML/CSS/Photoshop and they are generally paid less.
See: Quality Assurance and the different between people who can test manually and who can automate their work.
The negatives of being on being the backend engineer ( by backend I am assuming it means gathering and santizing data as well I may add )
+ 60% work is straight forward , he 40% with respect to data cleansing (especially big-data flows) is painful. Be it other systems that feed data or field devices that produce data , there is so much to handle + A new aggregate report may throw existing designs to the trenches + Doing a wild chase for 1 abhorrent row of data and painfully digging that up. I love the slickness for UI where you make a fix and refresh to see what happens + Lot of plumbing , the frontend uses a standard transport. The Backend API may be anything between Sockets to Webscrapers whose uptimes are always under the pump
+ 60% work is straight forward , he 40% with respect to data cleansing (especially big-data flows) is painful. Be it other systems that feed data or field devices that produce data , there is so much to handle + A new aggregate report may throw existing designs to the trenches + Doing a wild chase for 1 abhorrent row of data and painfully digging that up. I love the slickness for UI where you make a fix and refresh to see what happens + Lot of plumbing , the frontend uses a standard transport. The Backend API may be anything between Sockets to Webscrapers whose uptimes are always under the pump
Perhaps you should focus on what you would enjoy being challenged by, rather than what is easiest. The easy stuff get automated or abstracted away, so software development will always be challenging and require learning new things.
I changed from frontend to backend since I did not enjoy browser bugs and fighting to get a page to look the same in different browsers. Backend had different challenges (like integrating with legacy systems), but challenges I enjoyed more.
> I'm not good at animations, responsive layouts, pixel perfection, es6
If you are not good at something, then you have to study and practice to get good. This will be the same with backend. All these things are learnable. You have to enjoy learning to be developer.
I changed from frontend to backend since I did not enjoy browser bugs and fighting to get a page to look the same in different browsers. Backend had different challenges (like integrating with legacy systems), but challenges I enjoyed more.
> I'm not good at animations, responsive layouts, pixel perfection, es6
If you are not good at something, then you have to study and practice to get good. This will be the same with backend. All these things are learnable. You have to enjoy learning to be developer.
Depends. If backend = writing controllers, some basic db interactions (querying, storing), and more or less writing modular code then I would say it's just like frontend. On the other side if backend also includes: handling more complex db interactions (your simple query does not work performant enough anymore when your table has more than N rows), sync/async communication between multiple services, splitting monolithic applications into decoupled services, going beyond the basic of SOLID, handle critical backend stuff like payments, checkouts... then I think backend is more difficult than frontend.
I think that backend can feel less chaotic. It has its complexities but my personal opinion is that the things you use are less prone to deprecation. Ways of doing things change and that can require you to learn new things. Some examples of change are:
A few years ago I had never heard of Kubernetes, but now it’s one of the most in demand things. Cloud formation was the cool kid at one point and then it changed to terraform and to a lesser degree cloud formation SDK
But that still feels more stable to me than what people deal with on the front end where people can’t even agree on a framework to use (how many are there now for JavaScript?) lol
A few years ago I had never heard of Kubernetes, but now it’s one of the most in demand things. Cloud formation was the cool kid at one point and then it changed to terraform and to a lesser degree cloud formation SDK
But that still feels more stable to me than what people deal with on the front end where people can’t even agree on a framework to use (how many are there now for JavaScript?) lol
Backend code talks via APIs. Things need to be well-defined so that machines can communicate.
Frontend code has that but has to talk UI, too. That's a much looser-defined interface relying on human nature and perception to work. Meaningful performance is based on that perception and never in the areas that were well-designed. Frontend security is something you can't just hide behind your DMZ. And the design much more susceptible to changing fashions and the whims of PMs and execs. And those people and more think they know how to do your job because it's something they can see.
Yes, backend is easier.
Frontend code has that but has to talk UI, too. That's a much looser-defined interface relying on human nature and perception to work. Meaningful performance is based on that perception and never in the areas that were well-designed. Frontend security is something you can't just hide behind your DMZ. And the design much more susceptible to changing fashions and the whims of PMs and execs. And those people and more think they know how to do your job because it's something they can see.
Yes, backend is easier.
The same issues that make frontend harder to do to certain degrees of “right” also make it fuzzier – with backend, if its not done right it (perhaps intermittently) definitely, undeniably doesn’t work.
Frontend not done right is often fuzzier and debatable, so it is simultaneously harder to do frontend optimally and easier to do frontend well-enough to get away with.
This is, perhaps, why pure front-end work tends to pay less well. Quite a lot of the time, good enough to get away with is, well, good enough to get away with.
Frontend not done right is often fuzzier and debatable, so it is simultaneously harder to do frontend optimally and easier to do frontend well-enough to get away with.
This is, perhaps, why pure front-end work tends to pay less well. Quite a lot of the time, good enough to get away with is, well, good enough to get away with.
Saying that either one is easier or harder would not make much sense. Back-end deals with different problems than front-end, and is "easier" in some aspects but "harder" in others.
Backend tends to be a bit slower and less hype-driven. You certainly won't get anything close to the almost half-yearly hype loops of javascript where you basically have to append "2021" to every search to get an up-to-date result. Of course things still change, otherwise we'd still be using COBOL, but it happens at a much slower pace.
Backend tends to be a bit slower and less hype-driven. You certainly won't get anything close to the almost half-yearly hype loops of javascript where you basically have to append "2021" to every search to get an up-to-date result. Of course things still change, otherwise we'd still be using COBOL, but it happens at a much slower pace.
In my experience one of the big differences between backend and frontend (and even app development) is that frontend development has an incredibly fast rate of change.
What are best practices now might be considered code smell in 3 months. The tempo, in which the technologies are being swapped out and the number different general directions (react vs vue vs angular vs traditional server side rendered,...) make frontend hard in the sense that keeping up with the fast pace of changes takes up quite some time and energy.
I think that the pace of change in the underlying technologies is a lot slower on the backend and that you can even get away with being an expert for "legacy" technology for quite a while.
Another huge difference is your impact on the UI/UX. Working on frontend always means that the developer has direct impact - and responsibility - about many details of the final product that noone else might have thought about.
If you're into this type of work perfect, but if this stresses you out frontend might not be the right fit for you.
What are best practices now might be considered code smell in 3 months. The tempo, in which the technologies are being swapped out and the number different general directions (react vs vue vs angular vs traditional server side rendered,...) make frontend hard in the sense that keeping up with the fast pace of changes takes up quite some time and energy.
I think that the pace of change in the underlying technologies is a lot slower on the backend and that you can even get away with being an expert for "legacy" technology for quite a while.
Another huge difference is your impact on the UI/UX. Working on frontend always means that the developer has direct impact - and responsibility - about many details of the final product that noone else might have thought about.
If you're into this type of work perfect, but if this stresses you out frontend might not be the right fit for you.
[deleted]
Definitely backend easier than frontend. On backend you just write code and only machines interact with that. On frontend you are building interfaces that are accessed by thousands of different devices with different screens, different components and different users which may require different accesibility options.
I'd say, yes.. Backend can be as little as one or two languages on one well-controlled platform, with a primary focus on maintainability and performance.
Frontend is three languages on multiple slightly different platforms (browsers), in addition to maintainability and performance, it also has to look subjectively good.
I'm a backend dev.
Frontend is three languages on multiple slightly different platforms (browsers), in addition to maintainability and performance, it also has to look subjectively good.
I'm a backend dev.
You shouldn't look for easier things. Your value comes from your ability to do things others can't do, i.e. hard things.
So your question should be instead: "what are the hard problems in back end dev that I think I will be good at dealing with?".
Generally I think the hard part of back end dev is all about data, which I consider to be the most important part of any software system, which means you have to do it right. If you are the kind of dev who don't really understand what he is doing, with good common sense and a bit of artistic skills, you can make decent front ends, but back end dev is not for you. If on the other hand, you like to get to the bottom of things but feel overwhelmed by all the mess browsers throw at you, you will be better at the back than on the front.
Really, is is not about easy or hard, it is about finding something you are good at.
So your question should be instead: "what are the hard problems in back end dev that I think I will be good at dealing with?".
Generally I think the hard part of back end dev is all about data, which I consider to be the most important part of any software system, which means you have to do it right. If you are the kind of dev who don't really understand what he is doing, with good common sense and a bit of artistic skills, you can make decent front ends, but back end dev is not for you. If on the other hand, you like to get to the bottom of things but feel overwhelmed by all the mess browsers throw at you, you will be better at the back than on the front.
Really, is is not about easy or hard, it is about finding something you are good at.
I've started developing websites in the 90s - when you developed on IE3, send them to Geocities over my 56k modem etc. I've been a web developer ever since, FullStack first of course, later when the BE/FE break happened I focused more on FE but still do Fullstack work, while in the last couple of years I contract as a FE dev only.
My conclusion is: todays FE is harder than BE.
- You have to test your code not only on a single VM (like when using C# or Java), but on a multitude of browsers, on various screen resolutions (there are no FE projects today that can afford to not be responsive)
- Automated testing is hard; in Backend (or regular systems programming) you usually would test a single function/class by comparing its output. But the output of a Frontend is not HTML, its an interactive piece of pixel graphic which only makes sense to a human eye. Yes, there are HTML assertions, but they will not find bugs like hidden elements due to false CSS breakpoints. Yes, there are pixel-matching testing frameworks that make sure your output looks the same to the last pixel but practical application is almost impossible because
- There is too much change. Besides the framework churn in FE space everybody is aware of, UI is something immediately visible and critiqued to every end user and PO in the process. I have sat through a lot of sprint reviews where non-technical POs/PMs raised their feedback on the UI ("can we have the button in the other corner and in blue?"). Never ever in a sprint review did anybody critique my REST API definition, my internal DB layout or my choice of ORM. On top of that, fashion is a thing. You could easily have a rock-solid, slowly evolved Backend from the early 2000s running and actively selling to a customer. Try to sell any product with the look of a 2008 website to any customer today - good luck.
There is loads more reasons, and I do not say Backend is trivial or easy, but to me FE just requires more effort. I must admit, ever since the last 2 years I did no longer have to support IE11 - which took a big burden off my daily work.
- You have to test your code not only on a single VM (like when using C# or Java), but on a multitude of browsers, on various screen resolutions (there are no FE projects today that can afford to not be responsive)
- Automated testing is hard; in Backend (or regular systems programming) you usually would test a single function/class by comparing its output. But the output of a Frontend is not HTML, its an interactive piece of pixel graphic which only makes sense to a human eye. Yes, there are HTML assertions, but they will not find bugs like hidden elements due to false CSS breakpoints. Yes, there are pixel-matching testing frameworks that make sure your output looks the same to the last pixel but practical application is almost impossible because
- There is too much change. Besides the framework churn in FE space everybody is aware of, UI is something immediately visible and critiqued to every end user and PO in the process. I have sat through a lot of sprint reviews where non-technical POs/PMs raised their feedback on the UI ("can we have the button in the other corner and in blue?"). Never ever in a sprint review did anybody critique my REST API definition, my internal DB layout or my choice of ORM. On top of that, fashion is a thing. You could easily have a rock-solid, slowly evolved Backend from the early 2000s running and actively selling to a customer. Try to sell any product with the look of a 2008 website to any customer today - good luck.
There is loads more reasons, and I do not say Backend is trivial or easy, but to me FE just requires more effort. I must admit, ever since the last 2 years I did no longer have to support IE11 - which took a big burden off my daily work.
I find it easier anyway, mostly because I can write most code (for a specific endpoint) in my head and when I type it in, it works. With frontend, not so much. And with the visual feedback trial and error loop that frontend often ends up in, I often would not call it programming at all.
The annoying things (to me) about frontend are of course apples and pears; architecting for frontend, writing logic and fetching data is comparable with backend dev and similarly straightforward imho. While we are all fullstack, we have a few seniors who do 90% frontend and a few 90% backend; the 10% overlap that backend spends on frontend is writing logic and data fetching: after that it moves to frontend to do the rest.
The annoying things (to me) about frontend are of course apples and pears; architecting for frontend, writing logic and fetching data is comparable with backend dev and similarly straightforward imho. While we are all fullstack, we have a few seniors who do 90% frontend and a few 90% backend; the 10% overlap that backend spends on frontend is writing logic and data fetching: after that it moves to frontend to do the rest.
As a front-ender I also have this feeling. The key to overcome this feeling of being overwhelmed is to specialize.
Some people like building whole thing from scratch and gluing a bazillion of technologies, but this is not for me. I prefer to own a small area and specialize in it.
There's many sub-specializations in front-end that are not about UX/tweaking UI/animations/architecture/mashing up libs: internationalization; performance; accessibility; build and deployment; security etc.
Those specialized jobs happen mostly in bigger companies though, small companies simply don't have that much resources and prefer do-all people. And of course doing a specialized thing for too long can wear you too.
Some people like building whole thing from scratch and gluing a bazillion of technologies, but this is not for me. I prefer to own a small area and specialize in it.
There's many sub-specializations in front-end that are not about UX/tweaking UI/animations/architecture/mashing up libs: internationalization; performance; accessibility; build and deployment; security etc.
Those specialized jobs happen mostly in bigger companies though, small companies simply don't have that much resources and prefer do-all people. And of course doing a specialized thing for too long can wear you too.
Back-end things get complicated and with a lot of edge cases really fast. I mean, running something locally is easy enough; now make it work in a Kubernetes cluster. You have one service with one database; now you need to run that database worldwide over a thousand services. You have a REST API, now build a GraphQL interface, now replace them with a Protocol Buffers interface. You inherit a 10 year old PHP 5.x codebase and are told to update it to 2021 standards. You inherit a codebase built for x86/x64, but we want to add support for ARM CPU's.
Just a bunch of examples I can think of offhand as to why back-end development isn't necessarily easier than front-end.
Just a bunch of examples I can think of offhand as to why back-end development isn't necessarily easier than front-end.
On FE side, a lot of stuff gets complicated because nowadays everyone wants to use tools designed for building SPAs.
On BE side, a lot of stuff gets complicated because nowadays everyone wants to use tools designed for building microservices.
I'm oversimplifying, of course.
On BE side, a lot of stuff gets complicated because nowadays everyone wants to use tools designed for building microservices.
I'm oversimplifying, of course.
I believe it largely depends on the business domain. I worked for many years in fintech, for banks and insurances.
Consider the following examples. Insurance: Given 10 input fields about a potential customer, produce a quotation and an illustration for a life insurance policy. At the UI level you create a form or a set of pages to collect birthdate, gender, job, hobbies, smoker/non smoker and so on. At the back-end level the above reflects in countless queries against trivial decision tables, and a lot of business logic and maths to be applied for each year/month of the policy duration in order to create a projection of the insurace coverage, taxation and many many more. The front-end will eventually display a nice table with all the numbers.
Fintech, financial planning. Collect your client needs (buy a house in 10 years, buy a car in 5, pay college for kids), propose an investment plan that starts with some initial investments in specific investment products with monthly installments, add some occasional big investments, project investments growth over the years using different mathematical and statistical formulas, produce a numeric data series that the front-end will eventually use to draw a plot chart.
In both above examples front-end work is way less complex than back-end. Technology could also imply complexity: at the back-end you may have to learn Java, Spring, Database, RESTful, some queue API (Kafka), big data for reports (Hadoop, Spark) and so on. All this complexity is hidden to the front-end developer.
On the other hand, if you are building a blogging platform, probably the complexity is the same at the back-end and the front-end or is higher at the front-end.
So in my opinion there is no correct answer if you don't take into account the business domain. Having worked in fintech, insurance, document management, few more in my career, in all these domains in my experience back-end was more difficult or at least not easier than front-end. Especially if you work in a product company, and every implementation needs to be carefully designed to provide stable API, design for changes, security, code optimised for large numbers of users (hardly a problem in front-end since JS is running on each user's browser).
Consider the following examples. Insurance: Given 10 input fields about a potential customer, produce a quotation and an illustration for a life insurance policy. At the UI level you create a form or a set of pages to collect birthdate, gender, job, hobbies, smoker/non smoker and so on. At the back-end level the above reflects in countless queries against trivial decision tables, and a lot of business logic and maths to be applied for each year/month of the policy duration in order to create a projection of the insurace coverage, taxation and many many more. The front-end will eventually display a nice table with all the numbers.
Fintech, financial planning. Collect your client needs (buy a house in 10 years, buy a car in 5, pay college for kids), propose an investment plan that starts with some initial investments in specific investment products with monthly installments, add some occasional big investments, project investments growth over the years using different mathematical and statistical formulas, produce a numeric data series that the front-end will eventually use to draw a plot chart.
In both above examples front-end work is way less complex than back-end. Technology could also imply complexity: at the back-end you may have to learn Java, Spring, Database, RESTful, some queue API (Kafka), big data for reports (Hadoop, Spark) and so on. All this complexity is hidden to the front-end developer.
On the other hand, if you are building a blogging platform, probably the complexity is the same at the back-end and the front-end or is higher at the front-end.
So in my opinion there is no correct answer if you don't take into account the business domain. Having worked in fintech, insurance, document management, few more in my career, in all these domains in my experience back-end was more difficult or at least not easier than front-end. Especially if you work in a product company, and every implementation needs to be carefully designed to provide stable API, design for changes, security, code optimised for large numbers of users (hardly a problem in front-end since JS is running on each user's browser).
The complexity and the need to update your methology does not depend on being front or back-end. It depends on the specific project you are working on. You can be working on an desktop-only internal system or on a system that should support vr, mobile and desktop at the same time.
But without the willingness to update your knowhow in the IT (after a mere 14 years of approximately 45 years you have to work) you better think carefully if software development is the right area for you. The rate of change will accelerate even more in the future. The times where you learned in school and worked the same way 45 years is long gone.
But without the willingness to update your knowhow in the IT (after a mere 14 years of approximately 45 years you have to work) you better think carefully if software development is the right area for you. The rate of change will accelerate even more in the future. The times where you learned in school and worked the same way 45 years is long gone.
I'm a bit of a jack of all trades developer (front/back end web, desktop/native/mobile, a little embedded), and if I were to point out the main issue here, it _sounds_ like the projects/jobs you've worked haven't either given you opportunities to be mentored in newer tech/work-flows, or haven't given you opportunities to learn on your own. These issues could be your own fault, too, I don't know. For reference, I've been a hobbyist developer since 2001, professional since 2010.
The thing about working in tech, is no matter what you work on, technology is always advancing. There will always be newer, better, and more accepted ways than what you're doing now.
For instance, in 2007, it was perfectly reasonable to use bootstrap and jquery, and boom, you have your responsive layouts, animations, etc. You can still do that today, but I think that would be considered legacy by most developers. Now you need to have a decent grasp of raw css (v3, which has a lot more layout-related directives), and vanilla javascript.
Having knowledge on core fundamentals has a lot more value than knowledge in libraries, and that's been the case well before 2007. If you invested a lot of time in bootstrap+jquery (or whatever tech you/your company chose in 2007), those skills aren't completely wasted, but the investment in how javascript, as a language, works, or modern layouts in css are much higher value.
If you've lost your confidence/will to apply to newer jobs, that's a deeper issue than just switching from front-end to back-end. Working in software is literally having to learn and re-learn the same things over and over as technology improves, or the ways languages do tasks change. The only thing back-end may give you is slightly more stability, but even that isn't guaranteed.
So before you go all-in on switching from a front-end only to back-end only, maybe there are some questions we, as a community, can help you resolve.
- Do you have anyone mentoring/guiding you through all the changes that have happened in web tech since 2007?
- Does your job give you any opportunities to grow?
- What is the single biggest pain-point daily for you, and is that something we can help you solve?
- Are you disinterested in front-end technology, or just overwhelmed?
- What is so appealing about back-end over front-end?
I hope I haven't come across as uncaring, I truly hope we can sort out the issue you're having <3
The thing about working in tech, is no matter what you work on, technology is always advancing. There will always be newer, better, and more accepted ways than what you're doing now.
For instance, in 2007, it was perfectly reasonable to use bootstrap and jquery, and boom, you have your responsive layouts, animations, etc. You can still do that today, but I think that would be considered legacy by most developers. Now you need to have a decent grasp of raw css (v3, which has a lot more layout-related directives), and vanilla javascript.
Having knowledge on core fundamentals has a lot more value than knowledge in libraries, and that's been the case well before 2007. If you invested a lot of time in bootstrap+jquery (or whatever tech you/your company chose in 2007), those skills aren't completely wasted, but the investment in how javascript, as a language, works, or modern layouts in css are much higher value.
If you've lost your confidence/will to apply to newer jobs, that's a deeper issue than just switching from front-end to back-end. Working in software is literally having to learn and re-learn the same things over and over as technology improves, or the ways languages do tasks change. The only thing back-end may give you is slightly more stability, but even that isn't guaranteed.
So before you go all-in on switching from a front-end only to back-end only, maybe there are some questions we, as a community, can help you resolve.
- Do you have anyone mentoring/guiding you through all the changes that have happened in web tech since 2007?
- Does your job give you any opportunities to grow?
- What is the single biggest pain-point daily for you, and is that something we can help you solve?
- Are you disinterested in front-end technology, or just overwhelmed?
- What is so appealing about back-end over front-end?
I hope I haven't come across as uncaring, I truly hope we can sort out the issue you're having <3
I moved from being a frontend guy to full stack.
What I learned is that being a front or back end guy is an artificial constraint. If you know frontend JS, working with NodeJS is not that hard. If you know NodeJS, django is doable. In the end, it's all about solving problems, not tools.
If you are a decent engineer, you will able to solve problems in almost any environment. It might not be the best or most elegant solution in the beginning, but that comes with time.
A good first step for a front end guy to branch out is to learn how to write the APIs yourself. Then you have your foot in the door.
What I learned is that being a front or back end guy is an artificial constraint. If you know frontend JS, working with NodeJS is not that hard. If you know NodeJS, django is doable. In the end, it's all about solving problems, not tools.
If you are a decent engineer, you will able to solve problems in almost any environment. It might not be the best or most elegant solution in the beginning, but that comes with time.
A good first step for a front end guy to branch out is to learn how to write the APIs yourself. Then you have your foot in the door.
In my opinion the major difference is dealing with Databases. I'm a 'backend' only engineer, although I play with svelte/vue in my free time. I feel confident in my ability to solve almost any issue, except a database one. To the point where I don't accept jobs where I have to manage a db.
I personally found CSS harder to learn than backend (retrieving things from DB, adding few lines to expose it as API). Putting things in certain places on the browser screen is still tough for me.
I find front end much easier because of hot reloading and recent stuff like vite which instantly reflects whatever you're doing. This definitely helps to increase the speed of development.
Also there have been some recent developments like "Liveview" (1) which make it look like in future the distinction between back and front will be rather blurred.
(1) https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html
Also there have been some recent developments like "Liveview" (1) which make it look like in future the distinction between back and front will be rather blurred.
(1) https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html
You can't learn things? I don't think "since 2007" is that long to be honest. I'm a bit confused how you can't be "good at ES6" in a way where you wouldn't struggle with gradual advancements in every other programming language.
Maybe you just don't like frontend development, and would prefer backend, but I wouldn't say one is easier than the other. Backend development can go through churn and change and unreliability all the same. It has its own annoying problems to work through.
Maybe you just don't like frontend development, and would prefer backend, but I wouldn't say one is easier than the other. Backend development can go through churn and change and unreliability all the same. It has its own annoying problems to work through.
at some point, one becomes exhausted from learning things that are so short lived that they're effectively useless the next year.
There's a fatigue in knowing that what you're working hard to master today will be laughed at tomorrow, it makes you cynical, or at least tired..
It's not like that with most things in the world, learn math, the new stuff will only gradually creep in, the foundational concepts and ideas don't shift overnight. Even medicine, with constant advantages are not replacing huge amounts of ideas every year, only adjusting and adding some.
Learn C, and you're good to go for the next 200 years. Learn JavaScript, probably too. Learn React or Angular or whatever, and you'll have, if you're lucky the next two years to polish and make use of that knowledge before it goes out..
Don't get me wrong, advancement is good, but most of the frontend stuff we see coming and going is just grind, not advancement.
There's a fatigue in knowing that what you're working hard to master today will be laughed at tomorrow, it makes you cynical, or at least tired..
It's not like that with most things in the world, learn math, the new stuff will only gradually creep in, the foundational concepts and ideas don't shift overnight. Even medicine, with constant advantages are not replacing huge amounts of ideas every year, only adjusting and adding some.
Learn C, and you're good to go for the next 200 years. Learn JavaScript, probably too. Learn React or Angular or whatever, and you'll have, if you're lucky the next two years to polish and make use of that knowledge before it goes out..
Don't get me wrong, advancement is good, but most of the frontend stuff we see coming and going is just grind, not advancement.
> Learn React or Angular or whatever, and you'll have, if you're lucky the next two years to polish and make use of that knowledge before it goes out..
This is just a meme. React and angular aren't going anywhere. Especially React is too big to disappear. Even if it falls out of fashion, there would be 1000s of apps built in it that need maintenance.
Whatever DOES end up replacing React is going to share more with it than not. Data-driven UIs that are a pure function of their state ain't going out of style.
This is just a meme. React and angular aren't going anywhere. Especially React is too big to disappear. Even if it falls out of fashion, there would be 1000s of apps built in it that need maintenance.
Whatever DOES end up replacing React is going to share more with it than not. Data-driven UIs that are a pure function of their state ain't going out of style.
well, I didn't read it anywhere, just my personal experience from being in the industry, so if it's a meme, it's probably not without a reason.
Also, I've personally suffered through multiple frameworks, anything I've learnt have been a waste of time, I have nothing to show for it, but some applications with outdated UIs, you're welcome to blame me for "chosing the wrong ones, just tell me a modern, currently popular UI framework that's existed for more than 10 years.
Don't be mean. It is perfectly normal to be overwhelmed by missing knowledge, if there is no clear learning path that lets you understand things one-by-one. There are knowledge-dependencies between different technologies.
Experienced full stack here. Neither are easier, but front-end is more annoying to me. It's the only part of the software that non-coders can understand - thus there are endless battles on certain designs and why they won't work, etc.
These days, a lot of front-end is also "back-end". If you are managing state client side in a SPA, you have a back-end - it's in the browser.
I'd be wary of anyone that can definitively tell you one is harder than the other. They don't know what they're talking about.
These days, a lot of front-end is also "back-end". If you are managing state client side in a SPA, you have a back-end - it's in the browser.
I'd be wary of anyone that can definitively tell you one is harder than the other. They don't know what they're talking about.
It's different. Complexity lies elsewhere.
Transition is definitely possible, but, as always with stack changes, get ready to be in heavy learning mode again.
At many places (I'd say the right ones, but I'm biased) when backend engs talk about ownership they mean end-to-end ownership, meaning undestanding how to run and operate their services, meaning you'd need to learn about infrastructure as well (the famous 'devops' thing, but don't get me started on terminology).
I would guess at least 50% of jobs are working on some internal facing app at a large boring company. You don't need to do animations, or pixel perfect layouts for most of those. Most places don't need responsive layouts, but they aren't that bad. Es6 is for the most part a big step up. Meh idk, this seems like perfectionism. If you want to be a great frontend developer you need those, but most people are average and many are below average. They are still getting jobs.
Backend context is more in your control
Frontend context not so much.
A backend engineer usually does not write code to run on multiple different versions of CPU. A frontend engineer has to support multiple browsers. A backend engineer worries about scale, a frontend engineer not so much. https://ashishb.net/tech/server-vs-mobile-development-where-...
A backend engineer usually does not write code to run on multiple different versions of CPU. A frontend engineer has to support multiple browsers. A backend engineer worries about scale, a frontend engineer not so much. https://ashishb.net/tech/server-vs-mobile-development-where-...
If by backend you mean web backend. I would say that backend development is slower moving in terms of changes to technologies and frameworks used than front end.
But you'll need to understand what's going on at a deeper level (Data design/Caching/SQL/scaleability etc) so there will be things to learn - but they are much more transferable across technologies than the front end, and at the start you can rely on tech lead/senior devs to have that knowledge for you.
But you'll need to understand what's going on at a deeper level (Data design/Caching/SQL/scaleability etc) so there will be things to learn - but they are much more transferable across technologies than the front end, and at the start you can rely on tech lead/senior devs to have that knowledge for you.
The part of it being slower moving is definitively true from my point of view. Things I learn 10 years ago is still useful and relevant today, and I can easily build "backend" application knowing what I learn in 2011. Sure there are updates, better patterns, and new feature, but the JavaScript frameworks we used then are obsolete, legacy or unmaintained.
Different setups will come with vastly differing requirements for their backends and frontends.
So, depending on how your project works, what tech-stack is being used etc., it might be that either backend OR frontend is "easier" for that one specific case. But I don't think you can generalize that.
In general, backend is definitely different - and comes with a different set of difficulties. But I really don't feel confident declaring it harder or easier than frontend overall.
So, depending on how your project works, what tech-stack is being used etc., it might be that either backend OR frontend is "easier" for that one specific case. But I don't think you can generalize that.
In general, backend is definitely different - and comes with a different set of difficulties. But I really don't feel confident declaring it harder or easier than frontend overall.
What I haven't seen mentioned here is that as a backend dev you're usually much closer to the business people. You'll have to talk to them, understand their needs and translated them from their language into code. You'll have to come up with a design and implement it. Business logic is more common to be found in backends than frontends in my experience unless you do something with really sophisticated UIs.
Probably the part of the system where more of the business logic lives will be more difficult and interesting to develop. In modern projects, this probably starts in the front-end. These days, it is possible to develop quite a bit of business logic in the front-end, and it’s arguably delivered faster. In a mature project with significant scale, interesting parts of the business logic have to be implemented in the back-end.
> Is back end dev generally easier than front end?
Generally easier? No.
Different domains, different problems.
Also "back end dev" is almost certainly not javascript or typescript on node, but I suspect that's what you're referring to.
It's likely to be Java, C#, C++ and so on. Then you have frameworks, patterns, and idioms to learn. And threading. And databases. And failover. And load balancing. And infrastructure. The list goes on.
Generally easier? No.
Different domains, different problems.
Also "back end dev" is almost certainly not javascript or typescript on node, but I suspect that's what you're referring to.
It's likely to be Java, C#, C++ and so on. Then you have frameworks, patterns, and idioms to learn. And threading. And databases. And failover. And load balancing. And infrastructure. The list goes on.
If you remove all unnecessary complication, then front-end is probably easier in general. But, front-end is usually rife with complication.
I simply don't understand why there are 500 tools for everything and why FE jobs want you to know their specific stack as if it's impossible to get up to speed with if you already know JS.
Non-techs really emphasize specialists because they think it will save them money.
As a backend engineer, I would say yes, backend is easier. But also you'll be concerned with completely different things.
Interviewing is pretty hit or miss. You regularly get to meet teams who think you have to already deeply know their exact tech to do the job, which they somehow couldn't communicate to the recruiter or anyone else prior to your full-day onside
Interviewing is pretty hit or miss. You regularly get to meet teams who think you have to already deeply know their exact tech to do the job, which they somehow couldn't communicate to the recruiter or anyone else prior to your full-day onside
IMO the frontend is easier to understand and develop but really really hard to deliver, as compared to backend. Reason being multiple form factors, viewports and platforms to consider and the ever changing frameworks. People end up working on the same problem again and again from a different perspective which gets frustrating really fast.
While frontend always deals with the visual aspect of stuff, backend can mean different things to different people.
For some cases, backend is simply to load an object from a DB, convert to JSON and send it the client.
But backend can also mean "provide a list of movie recommendations against what user has already seen and convert that list to JSON".
For some cases, backend is simply to load an object from a DB, convert to JSON and send it the client.
But backend can also mean "provide a list of movie recommendations against what user has already seen and convert that list to JSON".
Backend is generally easier to reason about when you're proficient, but harder to actually be proficient with. Frontend is a jungle of frameworks, ideologues, soapboxing and bloat - it really isn't all that complicated to understand, it's just been over-engineered beyond recognition.
It seems to me you want something more stable, not something easier. Speaking as someone working mostly on backend (Scala codebase) but having to touch a Typescript codebase from time to time: backend is certainly not easier, but it feels way more stable to me and it's easier to keep current.
Doing any backend or other real development work at a good level requires deep understanding of the problems you are trying to solve. It's a completely different depth.
Also, your solution can impact the whole organization and your work carries responsibilities.
Also, your solution can impact the whole organization and your work carries responsibilities.
One significant difference is that frontend today focus a lot on how to do things in framework X whereas in backend you focus more on what is a reasonable technical solution for a specific problem and that is most of the time language agnostic.
You can make back-end work be as fiddly and churny as front-end, but it's really hard to do so. There's so much more stability, and the things you learn about the frameworks and technologies don't have a half-life of mere months.
I feel like the title of your post asks one thing and your description asks something else.
If you're concerned about employability, isn't it easier for you to get up to date on front-end which you do already rather than learn something completely new?
If you're concerned about employability, isn't it easier for you to get up to date on front-end which you do already rather than learn something completely new?
20+ years doing more backend initially, then more (SPA) frontend. It’s all hard in different ways. Bonus of frontend is you get to think about human-centric problems. Bonus with backend is you don’t have to think about human-centric problems.
Your primary skill in any role should be distilling the simplicity from all the noise. Without that, frontend and backend will both be a disaster (though IME backend is significantly less ridiculous, it really depends on where you work).
I moved from back to front and I can confidently say for me the backend is much easier. But it probably has something to do with doing it so long. I imagine given time I'd decide they're about the same difficulty.
I think backend is easier because you can write “passable” code and develop a passable architecture and nobody would be any the wiser whereas the Frontend is right in your users faces and it’s a high bar you’re competing with!
The median web frontend is broken in dozens of ways and, when rendered on recent cutting-edge hardware, performs like molasses flowing uphill in the winter. It's seriously difficult for the things your output would be compared to to get any worse.
As a backend developer I think it's easier than frontend, but at the same time my company can (over time) hire frontend developers, but good backend developers are basically impossible to hire, at least here in London.
Why so?
It's a combination of:
* Less applicants for backend positions * The applicants we do have, for whatever reason don't pass interview at the rate frontend developers do * The backend devs that do pass interview, ask for too much money.
We know where the problems are, and that third point especially is causing our hiring manager no end of pain. But convincing our execs to significantly up the budget of the probably-already-most expensive department in the company is a tough sell.
* Less applicants for backend positions * The applicants we do have, for whatever reason don't pass interview at the rate frontend developers do * The backend devs that do pass interview, ask for too much money.
We know where the problems are, and that third point especially is causing our hiring manager no end of pain. But convincing our execs to significantly up the budget of the probably-already-most expensive department in the company is a tough sell.
What do your interviews consist of for backend and for frontend devs?
First stage is a chat with a technical manager, second is a 1-2 hour technical interview with some live coding, then a final chat with our CEO.
I haven't joined any FE interviews,but I understand they're structured in a similar way.
I haven't joined any FE interviews,but I understand they're structured in a similar way.
Nothing is easy if you don't have understanding.
Nothing is hard if you have the knowledge.
Learn what you like to love what you do. But you won't like it if you don't learn it. It looks to me you are tired of increasing your knowledge.
Nothing is hard if you have the knowledge.
Learn what you like to love what you do. But you won't like it if you don't learn it. It looks to me you are tired of increasing your knowledge.
I moved the other way. Frontend is perhaps overly complicated, but it is what users see, you get to demo things that people will actually interact with. Backend work is more invisible and felt less rewarding to me.
No. Backend development has a required skillset that differs from frontend development (although, obviously, there is an enormous overlap in that Venn diagram). It is not easier, nor harder. It is different.
Backend easy? Only if you do easy and simple stuff.
Dozens of microservices, k8s, data pipelines, dbms migrations, multi db type, concurrency, stateful stream processing...
try to focus on the things you are good at and enjoy doing. It seems that you don’t enjoy the more design side of things (animations, layout, pixel perfect) and perhaps nor the infra part (setting up es6 libs), but what do you enjoy? Do you like the actual code part? The more core javascript bits, building business logic? Then standard backend might be a fit for you, if not, there is still much more areas you can go to, share with us what you enjoy doing
Depends on the person. I've run a team of devs for over 15 years. Some people are happy to tackle either but most people have a preference for front end or back end.
Yes. Backend dev is “clean” relatively speaking, which is why most devs prefer it. Frontend you will always be dealing with someone else’s obscure framework.
It's less about 'hard' and more about what you enjoy. There are many jobs out there which aren't pure back- or frontend. And within frontend, there is space for people who excel at writing idiomatic, elegant code, can cope with typesystems etc.
Branching out to backend programming won't hurt. But an alternative might be to become an expert in Typescript, or one of the more exotic technologies like ClojureScript, F# (Fable), Elm...
To learn more backend programming I'd recommend Django. It's popular, productive, and as a dynamic language very close to typescript.
Branching out to backend programming won't hurt. But an alternative might be to become an expert in Typescript, or one of the more exotic technologies like ClojureScript, F# (Fable), Elm...
To learn more backend programming I'd recommend Django. It's popular, productive, and as a dynamic language very close to typescript.
I'd say the opposite because of responsibility. A bug in the BE can cost a lot of money and time to your business, not so much (usually) in the FE.
Wouldn't that mean that both have the exact same responsibility? A bug in the FE, would essentially render the BE unusable, and therefore would cost a lot of money and time as well.
For example; if Amazon's checkout button somehow broke, and prevent users from checking out, it would also cost a lot of money.
EDIT: to give a more visual example, if Amazon changed their checkout button to a different color and style. It could potentially cost them millions, because it might not entice users to click it.
For example; if Amazon's checkout button somehow broke, and prevent users from checking out, it would also cost a lot of money.
EDIT: to give a more visual example, if Amazon changed their checkout button to a different color and style. It could potentially cost them millions, because it might not entice users to click it.
Much easier to fix a button then dive deep into why your algorithms which should work, don't work.
[deleted]
How so? If that button is part of a complex frontend, with multiple stylings who might inherit from each other, it could be quite a task to fix it correctly.
It's not as simple as just looking into your developer tools, and adding some CSS to it.
It's not as simple as just looking into your developer tools, and adding some CSS to it.
My job now is in localisation. Basically all the real front end work done by the main company and i'm a contractor just tweaking basic things.
I've done both, though not lately. I don't think one or the other is easier, but they definitely have different challenges.
Backend is not easier. However, it will be easier to stay up to date given that most concepts are not changing for each frameworks.
One weird trick to get good at ES6: Stop searching "JavaScript how to ...", start searching "ES6 how to ...".
Programming is hard. Learn to do both - don't pigeon-hole yourself. You will be drowning in job offers after 5 years.
Generally Frontend is complex, Backend is simple. Both can be easy or hard depending on the project.
A big NO.
IMHO no matter end at which you work, it takes time to truely master necessary skills.
Find a mentor. He/she may show you the way.
Btw, I find this book interesting: "So Good They Can't Ignore You: Why Skills Trump Passion in the Quest for Work You Love" [1]
[1] https://www.amazon.com/Good-They-Cant-Ignore-You/dp/14555091...
IMHO no matter end at which you work, it takes time to truely master necessary skills.
Find a mentor. He/she may show you the way.
Btw, I find this book interesting: "So Good They Can't Ignore You: Why Skills Trump Passion in the Quest for Work You Love" [1]
[1] https://www.amazon.com/Good-They-Cant-Ignore-You/dp/14555091...
Back-end usually requires more thinking while front-end requires more fiddling.
Tl;dr: Nothing is easier, both have their own sets of issues.
I have been at all sorts of Backend/Frontend combinations. An app or service with Good UI/UX and animation can't survive if they don't get required data in time from their servers. And a good scalable backend is useless without a UI/UX conveying clear messages & indication to users.
If something goes wrong at frontend, it affects only one (or one set of) user(s). If something goes wrong in backend, entire system messes up. The joy of showing beutiful apps and the joy of serving something to millions of users without hiccups are equal in my mind.
And after spending almost a decade in frontend (Android mobile to be precise), I find backend has more interesting. I have written about my journey here[1]. And I want to spend my tech career handling things at scale.
[1]:https://prashamhtrivedi.in/from-mobile-to-backend.html
I have been at all sorts of Backend/Frontend combinations. An app or service with Good UI/UX and animation can't survive if they don't get required data in time from their servers. And a good scalable backend is useless without a UI/UX conveying clear messages & indication to users.
If something goes wrong at frontend, it affects only one (or one set of) user(s). If something goes wrong in backend, entire system messes up. The joy of showing beutiful apps and the joy of serving something to millions of users without hiccups are equal in my mind.
And after spending almost a decade in frontend (Android mobile to be precise), I find backend has more interesting. I have written about my journey here[1]. And I want to spend my tech career handling things at scale.
[1]:https://prashamhtrivedi.in/from-mobile-to-backend.html
Easy. Back end is a lot more exciting. Your job got replaced by Squarespace.
Yes, backend is easier.
Your job got replaced by Squarespace. Backend is easy.
I think backend is bit more stable.
At this particular moment in time, I think so.
I'm not good at animations, responsive layouts, pixel perfection, es6
The simplest task now so complicated, many edge cases.
Things get deprecated (or sunsetted) so fast.
When I open the chrome inspector there's 10 new features which I ignore. It's too much.
I spend so much time googling obscure npm error to fix my local dev environment with each OS or package update.
I lost confidence to apply for jobs because I don't have the will to study the things they will test me for.
Has anyone made that move from front to back, do you feel it's easier?