> 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.
> 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.