3 ms·

Front end development is a 90% self-induced hell. There are real challenges like accessibility, processing data from service calls, architecture, and more. Th

Front end development is a 90% self-induced hell. There are real challenges like accessibility, processing data from service calls, architecture, and more. Those aren't the things most developers complain about. Most front end developers spend their energy on concerns of code style, tools, build steps, framework madness, state management, and more. Those are fashion concerns. A decent programmer can solve for most of those themselves without external tooling in a fraction of the time and code size, but not everybody that does this work is confident writing original code.

Etheryte 2y ago
I can't even begin to count the number of codebases I've seen where developers rolled with this idea and ended up with royal spaghetti. Everyone thinks they can build these frameworks from scratch, but they overlook the unknown unknowns. Nearly every custom implementation of state management, complex forms, async flow management, etc I've seen in the wild is riddled with countless bugs that could've been avoided if they just picked a boring and widely used library. And I've seen plenty, because I'm usually the guy that gets called up when no one else can untangle it anymore.
- austin-cheney 2y ago
  Yes, I have seen that countless times too. Developers that have no idea how to write original software think they can go without a framework and then write a framework. That is stupid, and its because those developers know something about frameworks but never learned to program. Stop toying with irrelevant nonsense and actually release a product for users that solves from some real business requirement, which is certainly not a framework.
johnfn 2y ago
State management is absolutely a real front end concern. That's what you're going to be spending a lot of your time on; you better make sure you do it well. Code style is roughly a solved problem thanks to Prettier, as is build steps with Vite. And I don't know what you mean that "framework madness" is a fashion concern. You have to pick a framework, you can't just avoid that part.
- austin-cheney 2y ago
  Yes, it is a real concern, but its supremely trivial to solve for. Frameworks make this into chaos madness because frameworks have to solve for both the goal of state management in addition to their own divisible component concerns that come and go with user interactions.
  - johnfn 2y ago
    I'd be very interested to hear how state management is supremely trivial to solve for.
    - austin-cheney 2y ago
      Ummm, no. I have been through this before and its always a paradox. The paradox works like this: If you were capable of writing your own software the triviality of state management becomes self evident. If you are not capable of writing your own software, such as full eternal reliance on some tool set or framework, then the answer doesn't matter.
      - johnfn 2y ago
        I've written my own software, both with and without state management frameworks. To be honest, I didn't find state management to be particularly "trivial", except when I worked on trivial applications.
- skydhash 2y ago
  > State management is absolutely a real front end concern That’s because most SPAs are duplicating backend logic.
  - johnfn 2y ago
    A certain subset of SPAs need to duplicate backend logic because they necessarily and unavoidably have local state. For instance, optimistic updates require some redundancy with backend logic.
mlsu 2y ago
In many cases this is true (typical CRUD apps), the tools (react etc) are too way too heavyweight for the job. It may even be some large % the case that it is a self-induced hell. However, I think frontend is often quite underrated in its essential complexity. I don't share the opinion that state management is a fashion, it's often tightly intertwined with the UX requirements, which can be varied and have all kinds of difficult essential complexity of their own (often complexity that is under-specified, and up to the programmer to discover). The lack of experience of many frontend devs, combined with the limitations of dynamically typed Javascript, is a recipe for a lot of very gnarly code. Maybe it would be fair to say that this is self-inflicted, but I am sympathetic. It's quite a difficult problem. When I think of 'total own-goal', completely pointless self-inflicted hell, I think of Python package management.
npn 2y ago
I'm so tired of those comments. It's almost always come from those who refuse to research before they talk, only echo what they learned from other people. Do you know why there are new frameworks, new versions every time? Because web is a moving target. New js/css/html5 features are released every day and the libraries have to update to adopt them. Back in the day you do not have css variables, so you have either use sass and do all the math inside the preprocessing process, or crazier, using those shitty css-in-js libraries to calculate css properties on the fly. Nowadays you can pass around the variables and it can cover almost all the case. In able to pass the css property to the component, you need to improve your framework. Another example is html5 history API, back in the old days people implemented link components in SPA with buttons (hilarious but it happened), only after History API is introduced there raised the need to manipulate the history properly, thus another rewrite issued. before that, ES5 introduced `class`, proving yet another way to write js code, which in some situation make cleaner code than the plain old js functions. everything in the web is moving, new nice things are introduced every month, if you want to create a modern and performant web application, you need to keep up with the new fancy things, frameworks are no exception for that.

Etheryte 2y ago

I can't even begin to count the number of codebases I've seen where developers rolled with this idea and ended up with royal spaghetti. Everyone thinks they can build these frameworks from scratch, but they overlook the unknown unknowns. Nearly every custom implementation of state management, complex forms, async flow management, etc I've seen in the wild is riddled with countless bugs that could've been avoided if they just picked a boring and widely used library. And I've seen plenty, because I'm usually the guy that gets called up when no one else can untangle it anymore.

austin-cheney 2y ago
Yes, I have seen that countless times too. Developers that have no idea how to write original software think they can go without a framework and then write a framework. That is stupid, and its because those developers know something about frameworks but never learned to program. Stop toying with irrelevant nonsense and actually release a product for users that solves from some real business requirement, which is certainly not a framework.

johnfn 2y ago

State management is absolutely a real front end concern. That's what you're going to be spending a lot of your time on; you better make sure you do it well. Code style is roughly a solved problem thanks to Prettier, as is build steps with Vite. And I don't know what you mean that "framework madness" is a fashion concern. You have to pick a framework, you can't just avoid that part.

austin-cheney 2y ago
Yes, it is a real concern, but its supremely trivial to solve for. Frameworks make this into chaos madness because frameworks have to solve for both the goal of state management in addition to their own divisible component concerns that come and go with user interactions.
- johnfn 2y ago
  I'd be very interested to hear how state management is supremely trivial to solve for.
  - austin-cheney 2y ago
    Ummm, no. I have been through this before and its always a paradox. The paradox works like this: If you were capable of writing your own software the triviality of state management becomes self evident. If you are not capable of writing your own software, such as full eternal reliance on some tool set or framework, then the answer doesn't matter.
    - johnfn 2y ago
      I've written my own software, both with and without state management frameworks. To be honest, I didn't find state management to be particularly "trivial", except when I worked on trivial applications.
skydhash 2y ago
> State management is absolutely a real front end concern That’s because most SPAs are duplicating backend logic.
- johnfn 2y ago
  A certain subset of SPAs need to duplicate backend logic because they necessarily and unavoidably have local state. For instance, optimistic updates require some redundancy with backend logic.

mlsu 2y ago

In many cases this is true (typical CRUD apps), the tools (react etc) are too way too heavyweight for the job. It may even be some large % the case that it is a self-induced hell. However, I think frontend is often quite underrated in its essential complexity. I don't share the opinion that state management is a fashion, it's often tightly intertwined with the UX requirements, which can be varied and have all kinds of difficult essential complexity of their own (often complexity that is under-specified, and up to the programmer to discover). The lack of experience of many frontend devs, combined with the limitations of dynamically typed Javascript, is a recipe for a lot of very gnarly code. Maybe it would be fair to say that this is self-inflicted, but I am sympathetic. It's quite a difficult problem. When I think of 'total own-goal', completely pointless self-inflicted hell, I think of Python package management.

npn 2y ago

I'm so tired of those comments. It's almost always come from those who refuse to research before they talk, only echo what they learned from other people. Do you know why there are new frameworks, new versions every time? Because web is a moving target. New js/css/html5 features are released every day and the libraries have to update to adopt them. Back in the day you do not have css variables, so you have either use sass and do all the math inside the preprocessing process, or crazier, using those shitty css-in-js libraries to calculate css properties on the fly. Nowadays you can pass around the variables and it can cover almost all the case. In able to pass the css property to the component, you need to improve your framework. Another example is html5 history API, back in the old days people implemented link components in SPA with buttons (hilarious but it happened), only after History API is introduced there raised the need to manipulate the history properly, thus another rewrite issued. before that, ES5 introduced `class`, proving yet another way to write js code, which in some situation make cleaner code than the plain old js functions. everything in the web is moving, new nice things are introduced every month, if you want to create a modern and performant web application, you need to keep up with the new fancy things, frameworks are no exception for that.