Do Not Follow JavaScript Trends

Have followed the trends and I now know Ember, Angular(both legacy and new), Vue(with and without typescript), and React(both classes and hooks). I've also used Svelte, and Stencil JS in my personal projects. In addition, I've also dived headfirst into GraphQL and Typescript pretty heavily lately.

Do I regret investing time in learning any of those frameworks or technologies?

Not at all. It was fun and interesting at the time I learned something different from each of them. Perhaps the most valuable thing I learned was that it is worthwhile to evaluate new technologies and to continue learning new things.

Does it devalue me as an Engineer to learn many things as opposed to becoming an expert in a single tech stack?

Much the opposite. A lot of the underlying principles and architecture remain the same and yet, I find each framework offers something new. Whether it's questioning some convention, or approaching a problem with a different paradigm, or just being heavily opinionated, I feel like I gained some value from each of these and had fun while doing so.

This lustrates a problem I've encountered on a few recent projects - we are suffering an embarrassment of riches when it comes to front end technology.

I found myself slipping in the architect role on a few recent projects with various employers and being forced to make the call on which front end framework to use. The problem is that there are so many to choose from and it very hard to predict what you will need in terms of features from your chosen framework six months or longer after making your decision.

Plus, your fellow devs will probably be arguing with you over which one is better based on their experience. All the emails and messages pointing me to various websites claiming React/Vue/Angular etc is best with stats and graphs I really don't have to the time to get my head around.

It's that fear of making the wrong choice that bothers me. The idea a year down the line the front end seems a bit sluggish and someone then points out that {other_framework} would be flying with the same workload.

Don't get me wrong choice is good, but with so much going on in the world of front-end right now coupled with all the hype and shouts about which is best it is hard to just pick one and run with it. Especially in the metric driven world we live in where a manager who doesn't get tech will berate you for choosing the wrong framework or wonder why you aren't buying in the latest hyped up framework.

That being said my preference is to use a framework to prototype and then convert to plain old JS where possible.

The downside probably being that an employer paid you during that time of learning and didn't get much work product out of it.

Learning for the sake of learning is an infinite endeavour.

I try to practice strategic learning - learning skills/frameworks/topics that will have a high likelihood of being used in the course of my current project.

There's just so so much out there... focus is everything.

As I said in that issue, I'm not completely against having Enzyme info in that page. However, we're not obligated to have the Redux docs show information on _every_ other tool that exists in the ecosystem, and our own recommendations may change over time.

Right now, we have an entire docs page on how to use Immutable.js with Redux [0]. That page was submitted by a user who cared about Immutable.js. They took the time and effort to write it, and the information is useful.

However, at this point we now actively recommend _against_ using Immutable.js [1], and _do_ recommend using Immer [2]. So, that docs page will be removed in the near future, because it now goes against our recommendations.

As I said in that thread, I personally would not recommend Enzyme at this point. Doesn't mean it's useless, or that people shouldn't use it at all, but it's not something I would use or tell people to use. Given the focus of that specific Redux testing docs page, I also don't see a _need_ to show both methods at once.

I agree that the ecosystem shouldn't just chase new shiny, but there's also a lot to be said for actually keeping docs and recommendations up to date. I understand your concern in this particular case, but it also feels like you're extrapolating rather broadly from one specific issue.

It's also the case that sometimes creating _new_ tools is the right answer. Yarn's release forced NPM to wake up from stagnation. There were dozens of Flux libraries when Redux came out. In the case of RTL, Kent created something because he saw a need, the community has seen that it's useful, and he's well within his rights to promote the tool that he created.

[0] https://redux.js.org/recipes/using-immutablejs-with-redux

[1] https://redux.js.org/style-guide/style-guide#use-plain-javas...

[2] https://redux.js.org/style-guide/style-guide#use-immer-for-w...

> it doesn't really embrace JS itself, just sort of acknowledges that you will be forced to use it in the web so you may as well at least learn the "good" parts.

I'm sure you know this, so I'm just pointing it out for completeness sake: that was indeed the only sensible approach to JavaScript back when that book was written.