The fundamentals of the language are never going to change that dramatically, so being super knowledgeable about the ins and outs of it can only help you.
I also really appreciate this comment:
I agree about having more fundamental JS knowledge coming in handy. I see JS frameworks having a multiplier effect - the more JS you know beforehand, the more the benefits of a JS framework will be multiplied.
One recent example is my work with the Ember framework at work. The framework gives good patterns for managing component state and related data to this state in their "controllers." But foundational JS knowledge helped me better see the limits in these controllers. A coworker used a combination of import/export, JS classes, and object-oriented programming to better abstract and manage some data complexity in a way that split the code more and made it reusable. It was standard JS used to make even better use of that framework.
I appreciate Dan Abramov's You May Not Need Redux -- I think more libraries and frameworks should have their co-founder be explicit that their tool isn't always the right tool for the job! It's the truth.
Shiny object syndrome is when you see a new thing and immediately want to drop everything and focus on that shiny object. In tech, that may mean that you re-write your applications every time a new library is on the horizon.
I am super guilty of this -- I used to write my blog posts themed around writing an app with a new library or framework each week. I've also worked with JQuery, Angular.js, Angular, Vue, Elm, and React at some level for work. But, that shouldn't be normal or encouraged.
I think my best shiny object syndrome story was when I worked on a team that was using a Chinese library whose documentation hadn't been fully translated to English yet. I remember running Google Translate to try and figure it out. It wasn't productive and Google Translate isn't great with technical docs in case anyone was wondering. Though the library looked cool, using one that was available in the language we spoke would have been a lot better.
So let's talk about how to overcome "shiny object syndrome."
In large part due to imposter's syndrome, a lot of developers feel the need to know everything about everything -- but that's not even possible! There's way too much to know, and nobody knows everything! Keep reminding yourself about that, and don't feel the need to know everything -- even though it's hard.
To quote Dan Abramov about the new React Hooks API:
Hooks are an experimental proposal to React. You don’t need to learn about them right now.
The same is true about everything -- even though it might not feel like it.
Once you know one framework or library, it is so much easier to move to the next one. If you understand the component architecture, you are already a quarter way through learning React, Angular, and Vue! You don't need to know all of them. Sure, they're all cool and have different features, but chances are you only need one.
Also, when you're picking a stack for your project, don't be the first adopter. Sure it may be cool, you may get a blog post out of it, and maybe it will make some pieces of your code easier. But -- then you get stuck on some bug in the library, and you can't progress until it's fixed. Or documentation for what you're trying to do doesn't exist, and it isn't realistic to bring anyone but expert level developers onto your team.
Let somebody else find the bugs first; then you can start using that cool new tool!
Since you can't learn or use every new framework or library that comes out, you have to also figure out how to choose your tech wisely. A couple of key questions when you are deciding what tool to use for a project or to learn:
- Is it well used? If it has a community behind it then it's more likely to have contributors and frequent iteration on features and bug solving. Also, it's more likely to have staying power.
- Who is the community behind the project? Is it a large company? Do they have a code of conduct? How do they treat new users?
- Is it frequently updated? You don't want to be stuck with bugs that aren't being fixed.
- Are there frequent breaking changes? You don't want to have to make major code updates to keep the tool up to date. Also, it may make researching the tool difficult. Looking at you Elm and Angular.
- What features make this tool better than the alternatives? Does it do something extra? Or solve some problem other tools don't?
- Does it fit your team? If your team is mostly junior developers, for example, does the framework have good learning resources and documentation? If you have mostly functional programmers does the tool fit that paradigm?
- Is the documentation good? This is so important for being able to use the technology easily.
- How does the code look? Does the codebase look well written and maintainable?
- Is the library performant?
There's no singular right answer here -- if the technology works well for your team, it’s the right solution no matter what some thought leader says on Twitter.
Okay -- so now that we've discussed shiny object syndrome -- how can you stay up to date on the latest updates in a reasonable way?
For future readers this was written for a Halloween talk, hence the spooky theming!