Hacker News Reader

Comment by ricardobeat | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com