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.

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.

> 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. ¯\_(ツ)_/¯

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.

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?

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.

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.

> 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.

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.

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 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?

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.

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?

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.

thanks that's very insightful