3 ms·

Here's a few examples of knowledge becoming obsolete: - JSP, JSF and PrimeFaces in Java are essentially dead (server side and hybrid rendering technologies)

Here's a few examples of knowledge becoming obsolete: - JSP, JSF and PrimeFaces in Java are essentially dead (server side and hybrid rendering technologies) - Vaadin and GWT are essentially dead (Java to JS transpilation of sorts) - AngularJS is essentially dead (Angular 2+ are way different) - jQuery is on its way out - class based React is on its way out Each of those have a lot of internal complexity that i'd suggest is more than just a paint job. Of course, it's inevitable that technologies that didn't work out for one reason or another will be sunset and will die out, however at the same time there is definitely churn. For example, we don't know if something like Bulma or TailwindCSS will work out and will be around in their current form in 5 years. You could say the same about how state was managed in React, nowadays we have MobX and Redux, but also the Context API. You can say the same about most languages, approaches, frameworks and libraries - nothing is set in stone. I'm not sure whether that's a bad thing or a good thing, i just personally hope that eventually the more stable approaches will survive and the developer experience will be all the better for it, as opposed to introducing more and more complexity to the point of rivaling that of JSF/PrimeFaces. My personal approach is just vaguely along the lines of: - learn the fundamentals that are unlikely to change much (abstract concepts, architecture etc.) - learn the most common technologies, refresh knowledge every few years (HTML, CSS, JS) - learn the frameworks and libraries to the point where you feel vaguely competent with them (React, Angular, Vue, have a vague idea of how to do stuff with CSS libraries/frameworks like Bootstrap) - maybe pick up a few useful tricks here and there, if you have the time explore a new technology or two in non-prod projects every now and then

chakkepolja 5y ago
Tangential. I don't understand why class based react is disliked. Hooks are complex magic, and don't work like rest of language. Compared to that, class component will do exactly what you say.
- KronisLV 5y ago
  I actually agree with this and liked when you could see the full behaviour of a particular concern within a component, for example, its shouldComponentUpdate() method. But now, with hooks, you might instead have 3 or 4 useState hooks, each of which could cause a component update. Worse yet, with useEffect hooks, you might run into the interdependent dependency array problem, which would cause a refresh loop. Now it feels like your components have now become containers for smaller loosely coupled units of code with their own behaviour and life cycles, all of which may result in lower coherency as well. I actually voiced some of my concerns a while ago in a slightly satirical portion of my blog, called "Everything is Broken": https://blog.kronis.dev/everything%20is%20broken/modern-react-is-broken https://blog.kronis.dev/everything%20is%20broken/modern-reac...
- Chyzwar 5y ago
  Once you grok hooks, they are just better. With hooks, it is easy to create re-usable state controllers than with class based components. Components that use hooks are easier to read, understand and modify. Hooks are also easier to test and annotate with typescript. In classical class based component you would often have complicated code in componentDidUpdate, componentDidMount or getDerivedStateFromProps. Code ended being complex and interaction between lifecycle methods and constructor hard to debug.
  - KronisLV 5y ago
    > Once you grok hooks, they are just better. Disagreed. It's likely that there are factors at play here that we're not considering, such as personal preference or certain people enjoying different patterns more. > Components that use hooks are easier to read, understand and modify. Hard disagree. In my experience, hooks take a single concern within a component (whether it should update, or reacting to a certain event within it) and scatter the logic throughout multiple hooks in any non-trivial application, which leads to the control flow becoming harder to understand and lower overall coherency of the code. > In classical class based component you would often have complicated code in componentDidUpdate, componentDidMount or getDerivedStateFromProps. This feels like an indicator that you should split your components into smaller parts and compose those, as opposed to look for other ways which may or may not be better (because of the aforementioned differing preferences) to express that same level of complexity. > Code ended being complex and interaction between lifecycle methods and constructor hard to debug. I apply this very same quality to hooks.
Tarucho 5y ago
In my case I found that for most web dev jobs I needed to learn the libraries thoroughly or live in constant stress because I was always getting behind my expected velocity. I find most frontend libs code too convoluted to be able to understand what is happening just by taking a glipse at the code. In contrast I've doing backend in .NET since 2008. To catch up with the latest releases I need at most a couple of weekends a year and probably less.
- KronisLV 5y ago
  > I find most frontend libs code too convoluted to be able to understand what is happening just by taking a glipse at the code. This is definitely a valid concern, especially when the authors of some frameworks attempt to be "clever", which unnecessarily increases the cognitive load that one has to deal with. That said, it's also probably a matter of the abstractions that are used, for example, in Java for back end you can use any of the following: Spring, Spring Boot, Dropwizard, Quarkus, Helidon, Vert.x, JSP/JSF with something like PrimeFaces, Apache Struts, Play and others. Whenever you run into a framework that uses MVC or its own way of templating, you're stuck learning all of its specifics and idiosyncrasies, even if the end result that you want to achieve is the same. Thus, i'd posit that if you're not the person making the choice of which framework or library to use (the ones that you're familiar with), on some level you've already lost. If you're used to Angular, for example, but instead get thrown into a project with React, Redux and Tailwind CSS because someone wanted it on their resume, you'll both be less productive and will look less productive compared to everyone else.

chakkepolja 5y ago

Tangential. I don't understand why class based react is disliked. Hooks are complex magic, and don't work like rest of language. Compared to that, class component will do exactly what you say.

KronisLV 5y ago
I actually agree with this and liked when you could see the full behaviour of a particular concern within a component, for example, its shouldComponentUpdate() method. But now, with hooks, you might instead have 3 or 4 useState hooks, each of which could cause a component update. Worse yet, with useEffect hooks, you might run into the interdependent dependency array problem, which would cause a refresh loop. Now it feels like your components have now become containers for smaller loosely coupled units of code with their own behaviour and life cycles, all of which may result in lower coherency as well. I actually voiced some of my concerns a while ago in a slightly satirical portion of my blog, called "Everything is Broken": https://blog.kronis.dev/everything%20is%20broken/modern-react-is-broken https://blog.kronis.dev/everything%20is%20broken/modern-reac...
Chyzwar 5y ago
Once you grok hooks, they are just better. With hooks, it is easy to create re-usable state controllers than with class based components. Components that use hooks are easier to read, understand and modify. Hooks are also easier to test and annotate with typescript. In classical class based component you would often have complicated code in componentDidUpdate, componentDidMount or getDerivedStateFromProps. Code ended being complex and interaction between lifecycle methods and constructor hard to debug.
- KronisLV 5y ago
  > Once you grok hooks, they are just better. Disagreed. It's likely that there are factors at play here that we're not considering, such as personal preference or certain people enjoying different patterns more. > Components that use hooks are easier to read, understand and modify. Hard disagree. In my experience, hooks take a single concern within a component (whether it should update, or reacting to a certain event within it) and scatter the logic throughout multiple hooks in any non-trivial application, which leads to the control flow becoming harder to understand and lower overall coherency of the code. > In classical class based component you would often have complicated code in componentDidUpdate, componentDidMount or getDerivedStateFromProps. This feels like an indicator that you should split your components into smaller parts and compose those, as opposed to look for other ways which may or may not be better (because of the aforementioned differing preferences) to express that same level of complexity. > Code ended being complex and interaction between lifecycle methods and constructor hard to debug. I apply this very same quality to hooks.

Tarucho 5y ago

In my case I found that for most web dev jobs I needed to learn the libraries thoroughly or live in constant stress because I was always getting behind my expected velocity. I find most frontend libs code too convoluted to be able to understand what is happening just by taking a glipse at the code. In contrast I've doing backend in .NET since 2008. To catch up with the latest releases I need at most a couple of weekends a year and probably less.

KronisLV 5y ago
> I find most frontend libs code too convoluted to be able to understand what is happening just by taking a glipse at the code. This is definitely a valid concern, especially when the authors of some frameworks attempt to be "clever", which unnecessarily increases the cognitive load that one has to deal with. That said, it's also probably a matter of the abstractions that are used, for example, in Java for back end you can use any of the following: Spring, Spring Boot, Dropwizard, Quarkus, Helidon, Vert.x, JSP/JSF with something like PrimeFaces, Apache Struts, Play and others. Whenever you run into a framework that uses MVC or its own way of templating, you're stuck learning all of its specifics and idiosyncrasies, even if the end result that you want to achieve is the same. Thus, i'd posit that if you're not the person making the choice of which framework or library to use (the ones that you're familiar with), on some level you've already lost. If you're used to Angular, for example, but instead get thrown into a project with React, Redux and Tailwind CSS because someone wanted it on their resume, you'll both be less productive and will look less productive compared to everyone else.