Hacker News Reader

Comment by Raed667 | Hacker News Reader

There are 3 aspects in my opinion:

1- Companies understanding that a good user-interface is a must for their product. HN crowd are known for being anti-JavaScript, but modern web-apps are incredibly powerful and useful. This means you can't make your back-end developer glue together a JSP and call it a day anymore. So front-end overall is in high demand.

2- React helped standardize the way we do front-end. Yes Svelt, Vue and Solid are all great. But the ecosystem and the ability to hire from a large pool of talent without needing to train developers on your niche stack is a huge benefit.

3- React is easy to start, hard to master. When interviewing you'll likely be seeing a 10:1 ratio of boot-camp grads vs developers who have dealt with complex React apps at scale. This means an experienced React developer can ask for a higher salary.

View on HN

Full agree. And further I think frontend complexity has grown quite a bit lately. People love to go on about framework churn etc. when it's just a difficult domain in general. As someone who used to have snobbish opinions on frontend work, I've completely come around since diving into it. For modern fullstack applications I believe the frontend often has more complexity to it than the backend.

Of course it does. The entire concept of 'state' doesn't even exist on the backend (okay, outside the concept of a user session, but then that barely adds any complexity; perhaps you use the user's ID and that's it). Frontend you've got to think about async calls, which automatically brings three states: loading, success, and error. You may have multiple of these calls and each combination of all of them leads to some crazy complex rendering. It's turtles all the way down if you're a junior (or to be honest, just a lazy dev), it's very easy to make a mess and abuse a library as flexible as React.

From my experience the better you can compose your components, the happier you'll be. And there's nearly always a dead simple way to design something even if from the outside the functionality seems very complex, like this for example: https://codesandbox.io/s/react-text-highlight-2h0kvu?file=/s...

I believe it's not really that frontend is more complex than backend. It's a matter of maturity.

My work involves more FE than BE nowadays and I do think FE is more challenging at the moment.

But it's mostly because all these problems are very new. FE never used to store a lot of state. Now that interactivity is expected, we do. Users expect polish so we add transitions. As we add more things, performance becomes something to keep in mind, and so on.

In a decade or so, I think these issues will be very trivial to solve. Standardized solutions will emerge. Browser support will get better and JS will improve (hopefully). We'll be solving entirely different class of problems.

It's what has happened to BE. Nowadays you can expect an ORM, a cache layer, and queue systems among others to be standard to any BE installation/framework. The traditional RDBMS in itself is a sight to behold. Imagine working on BE before these things became the default.

Many things are abstracted and a lot of people aren't even aware of them. For example, I don't know when's the last time I heard about SQL injection. They are all automatically handled.

> The entire concept of 'state' doesn't even exist on the backend

No. Are you saying e.g. TLS is not stateful? I don't even know where to start to give you more examples. Sorry but that came off really ignorant when you're trying to sell the idea that frontend is hard.

I'm speaking from an application level perspective (REST or GraphQL APIs and the like). Of course at deeper levels of networking there needs to be a concept of state. But the only reason I can think of somebody having to hand roll anything todo with TLS nowadays is that they are doing something very very specialized, or have gone down a very wrong path.

Though that did remind me, if you're doing websocket stuff I suppose there could be a considerable amount of 'state' to handle on the backend.

Funnily, I find one reason React gets adopted is that it looks the most like traditional desktop application UI programming, which is a benefit to large companies with workforces full of people who have written such apps in the past. It's only after you've already committed that you find out it doesn't get you out of needing to understand HTML and state persistence.

Reply on news.ycombinator.com