I've written front end for nearly all of my 13 years in this field. I've written some absolute dumpster fires in my time and have also written some very large and complex UI's successfully. I would like to think I have some insight to add here. I agree with a lot of the points brought up in this article. I'd like to add a few more points about why I think FE can be such a pain to get right:
1. Mixed concerns and a lack of application layering. In React code bases and others like them, its not uncommon for me to find business logic embedded directly inside the components themselves. This makes the component inherently coupled to the specific implementation its being used and can only be re-usable in other contexts by passing in modifier flags to the props etc. In my opinion, components should be mostly of the stateless flavor and delegate anything not directly related to their immediate UI concerns elsewhere. This increases the likelihood of re-usability of your components and makes testing business and component logic much much more straight forward.
2. This might just be my personal experience, but I've noticed a bit of a dismissive attitude around design patterns and traditional computer science principles among my front end brethren. YAGNI and all that. While I think its fair that the UI != to the back end, I think frequently the baby gets thrown out with the bath water. For instance, I frequently leverage dependency injection in my front end work as a way to make my code more flexible and testable. It's hard to sell the benefits of something like DI until your application grows in complexity to the point that you are dealing with things like nested mocks in your tests and/or need to make a non trivial change to some piece of functionality. I've been seeing the winds start to shift a bit on this which is encouraging.
3. Most of the time there is little to no overall _conceptual integrity_ to a given front end code base. Its uncommon for me to come into an existing code base and have anyone be able to tell me what the architecture is comprised of. Things like what logic lives where and why. I'm not saying people _don't_ do this, but in the more gnarly code bases I've encountered, this "accidental architecture" is more common.
4. Front end is still see as "easy" and the place you stick the less experienced engineers first. I sincerely hope this doesn't come off like I am gatekeeping or anything. I work with some absolutely brilliant people who are only a year or two into their career and much smarter than me. IMO its less about skill and more about having been burned enough times to know where unexpected complexity lie.
I love front end. Its challenging and interesting and maddening. My hope is that it will continue to mature and grow to the point that it gets the same respect as other disciplines within this field. These days I work full stack so its not all I do, but it will always be my favorite. :)
You're absolutely right, I see all the same things as you. I think there are a number of factors
1. Library authors optimize aggressively for the beginner. They specifically sell their tools as being all in one and you can do everything in the view layer. Maybe its because they legitimately want to set their users up for success or maybe they'd rather gain users even if they are setting them up for issues in the long run
2. The kind of people working on web frontend aren't necessary coming from a programming background. You have the web designer/developer types who were doing a great job when they were building out static templates that got integrated into some server rendering back end. Now that everything has become an app, the idea of handling all the associated complexity is daunting. A lot of self taught developers also come in through web UI and the last thing they want to think about is proper architecture.
I'd go so far as to say there is a current of anti-intellectualism in terms of frontend application design. There is a large section of developers who want a small number of tools to do everything for them and it seems they are unwilling to even consider creating their own architecture of which individual libraries are their own self contained piece.
> I'd go so far as to say there is a current of anti-intellectualism in terms of frontend application design
I try to walk a line here between relying on my experience and being open to the idea that there is possibly a better way to do things that is just unfamiliar to me. "Beginner mindset" and all that. React hooks are a great example. At first I hated them because I didn't really understand what problems they solved well. To my eyes they encouraged mixing concerns in the component layer in ways that made testing and re-usability way harder. It was when I started considering hooks as "headless components" that I started understanding where they fit into a front end architecture. I think they solve a specific class of problem that react had no answer for previously. I don't use them for everything but now that I consider them as a special kind of component, they fit into a larger set of tools that I have at my disposal.
I also think there are different kinds of front end developers and we all get lumped into the same bucket right now. There are those that work on flashy UI stuff (which I suck at) and those that do more "middle tier" type stuff where they are building out web apps that solve business problems (more my sweet spot). Those two skill sets are way way way different from one another to the point that I think they should be classified as different disciplines.
I would say I have the same strengths as you. I kind of see it like a "mid-stack engineer" or "middle tier" like you say. It's a lot of data wrangling. It can happen on the "back" of the client or the "front" of the server. I'm no good at design or meticulously tweaking animations. Neither am I interested in configuring Kubernetes or setting up a complex architecture of interacting backend services.
I get what you mean about hooks, I was initially apprehensive and like you I realized the problem they solved. I think the problem we have now, is they are the answer to everything, along with Context. Code that could have been a plain Javascript module is a hook that uses Context to pass refs between components.
I think a big issue is reactivity outside of a reactive view library isn't talked about much. You have libraries like RXJS and Effector, which I'm a big of, that let you handle reactivity separately from a view but they're still full black boxes themselves. I'm not sure many people think about reactivity as a quality separate from any library.
The libraries react-query and svelte-query are an interesting manifestation of this. I haven't diffed the code or anything but they share a core that is essentially the same. Observer based reactivity to handle async calls. Yet there are two different repos with duplicated code providing different frontends based on React and Svelte. I don't want to pick on how the code architecture or anything but it feels like the reason there isn't just a base "query" library that exposes its own Observer API with bindings to React and Svelte is because of the general refusal to accept splitting out responsibilities and there should be a "React way" of doing things.
I'm hoping the TC-39 Observer proposal along with Svelte's idea of a store contract might open a few eyes and show people that the frontend doesn't have to be the closed off black box that it currently is but a lot of people already seem set on the idea that Observers are some RXJS stream based thing that they want no part of.
Anyway sorry for the long reply. I've been thinking about this stuff a lot in trying to establish my course through all this.
1. Mixed concerns and a lack of application layering. In React code bases and others like them, its not uncommon for me to find business logic embedded directly inside the components themselves. This makes the component inherently coupled to the specific implementation its being used and can only be re-usable in other contexts by passing in modifier flags to the props etc. In my opinion, components should be mostly of the stateless flavor and delegate anything not directly related to their immediate UI concerns elsewhere. This increases the likelihood of re-usability of your components and makes testing business and component logic much much more straight forward.
2. This might just be my personal experience, but I've noticed a bit of a dismissive attitude around design patterns and traditional computer science principles among my front end brethren. YAGNI and all that. While I think its fair that the UI != to the back end, I think frequently the baby gets thrown out with the bath water. For instance, I frequently leverage dependency injection in my front end work as a way to make my code more flexible and testable. It's hard to sell the benefits of something like DI until your application grows in complexity to the point that you are dealing with things like nested mocks in your tests and/or need to make a non trivial change to some piece of functionality. I've been seeing the winds start to shift a bit on this which is encouraging.
3. Most of the time there is little to no overall _conceptual integrity_ to a given front end code base. Its uncommon for me to come into an existing code base and have anyone be able to tell me what the architecture is comprised of. Things like what logic lives where and why. I'm not saying people _don't_ do this, but in the more gnarly code bases I've encountered, this "accidental architecture" is more common.
4. Front end is still see as "easy" and the place you stick the less experienced engineers first. I sincerely hope this doesn't come off like I am gatekeeping or anything. I work with some absolutely brilliant people who are only a year or two into their career and much smarter than me. IMO its less about skill and more about having been burned enough times to know where unexpected complexity lie.
I love front end. Its challenging and interesting and maddening. My hope is that it will continue to mature and grow to the point that it gets the same respect as other disciplines within this field. These days I work full stack so its not all I do, but it will always be my favorite. :)