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?
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.
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:
+ 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
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.
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.
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.
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/)
> 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.
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!
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.
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.
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.
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.
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.
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. ;)
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.
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 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.
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.
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.
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 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.
* 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
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.
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.
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, 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.
- 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).
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.
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.
+ 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
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.
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
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.
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.
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.
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.
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.
- 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.
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.
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.
Just a bunch of examples I can think of offhand as to why back-end development isn't necessarily easier than front-end.
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.
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).
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.
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
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.
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
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.
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.
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-...
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.
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.
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.
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
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".
Also, your solution can impact the whole organization and your work carries responsibilities.
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?
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.
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.
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...
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.