21–30 of 41 posts
Earlier quoted context omitted.
React is still in, but it's definitely not the "cool new thing" now. Svelte and Solidjs seem to be the "cool new things" now on the front-end
You’d be hard pushed to find any production applications of any scale using either Svelte or Solid.
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,…
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.
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...
Earlier quoted context omitted.
I would say it's not so much about good or bad design, and more about which kinds of decisions, how many moving parts, and what consequences they have down the line. Like on backend you will have a choice of database, choice of language, and the design of the Schema/API, most of which are easy to detach and replace at some point. While on Frontend from the beginning, specially i you are working with a team, you will…
I would argue that any HTML + CSS framework stack is inherently flawed once you move beyond the most basic of UI components. I have yet to work on a React + Tailwind codebase in the wild where the margin/padding metrics aren't hardcoded and repeated across tens of different components. We've traded the elegance of well-written SCSS for improved developer ergonomics and faster build times because webpack is so slow at…
A lot of organizations bet the farm on React ~5 years ago because it was the cool new thing. It is very likely that many of the original developers have since moved on to the next cool new thing, and now companies need maintenance work done on their (now unwieldy) codebase. Another reason: The trend today seems to be to offload most of the data processing to the client side, only using the server as a glorified datab…
Earlier quoted context omitted.
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 som…
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.
Earlier quoted context omitted.
As a frontend dev there are definitely well designed frontends. I've seen a lot of bad backends too. It just depends on how much engineers are able to plan ahead and also keep tech debt under control.
I would say it's not so much about good or bad design, and more about which kinds of decisions, how many moving parts, and what consequences they have down the line. Like on backend you will have a choice of database, choice of language, and the design of the Schema/API, most of which are easy to detach and replace at some point. While on Frontend from the beginning, specially i you are working with a team, you will…
Memory is cheap.
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,…