First, he cites the Google Trends report:
This suggests that over the last five years, Ember.js has had no significance. And therefore, you should not learn it (it isn't on his list). The problem is Ember.js is far from dead. It has had a significant impact on other frameworks (both the router and ember-cli project have been ported to other projects). The community is extremely active, and very high quality work comes out of it. Major companies are moving to it. But we look at this graph and think that all that work, and all that community, is about to disappear. That, my friends, is superstition and nonsense.
What we have is a problem of numbers. The numbers represented on this graph are not on any human scale. It's like trying to imagine the distance to the nearest star, Alpha Centauri, which is 4.2 light years away. A light year is the distance light travels in one year, or 9.4607 × 1012 km (nearly 6 trillion miles). We use light years to make that number comprehensible, which belies the fact that we still don't comprehend it (nobody has ever traveled a light year.) The number of searches for jQuery, or AngularJS, or React, don't translate to a reasonable number. They really don't mean anything on a human scale.
We could make a similar comparison to the most sold automobiles. The Toyota Corolla easily tops the list as the most sold car ever. To conclude that, therefore, we should all buy this car is to ignore many other factors: Is suitable for who or what you must carry? Can it navigate the conditions you drive in? Is it the kind of car you want to drive?
What is also missing is why these searches are made. A search can be made because of interest, but also because the library creates a need to search for documentation. We need more than just a search volume. We need to know if there are problems. Today, on stackoverflow.com, there are 820K jQuery questions, 221K Angular questions, 34k React questions, and 20k Ember questions. But this still doesn't help. Both popularity and difficulties affect these numbers. Once again, the numbers don't help you choose a framework. You would have to dive into the relevant community to find out.
Instead, let's ask questions at our scale: how many people do you really need for your framework to be active? When does a framework really die? Backbone.js was very popular around 2012 and 2013. If you add it to the graph above, it also comes out at zero, even during its peak. I expect most would consider it past its time, yet at this writing the GitHub repo had a commit two months ago, 11 issues closed in the last two months, and a release came out less than a year ago. I've done work recently with Backbone.js, and it has a legitimate place still. There is nothing like it for a lightweight data framework. Should we call this dead because Google has no Trend for it? No.
Indeed You Need a Job
Eric also produces another graph from Indeed.com:
Angular and React are clearly dominating (while we ignore jQuery because it is so ubiquitous). But lets ask again about these numbers. How many jobs did you apply for the last time you looked for work? And, more importantly, how many jobs did you accept? Even though we are used to thinking in these large numbers, we forget that we apply one job at a time (usually), and especially we work at one job at a time. If all I need is one job, as far as I am concerned even vue.js is a possibility. And it may be my dream job.
It is also worth nothing that businesses don't usually follow trends. About five years ago I wrote a gem for Rails that serves spreadsheets. Rails is definitely considered passé. And yet in the last year, this gem has seen more downloads and more stars than in its entire past history. Not only is Rails not dead, it is really taking off. In the business world, products often hit their stride after they become boring and stable, after the Google Trend peak. In my current job I'm still dealing with ASP classic! (gasp of horror)
Rather than using trends or job statistics, here are my suggestions for learning a framework:
- Look for a lively, supportive community.
- Look for a dynamic codebase that is improving.
- Look for a library that has something to teach you.
- Look for something you enjoy using!
To be sure, Eric was writing an article on what to learn next, and the list was a quality curated list. It was only indirectly how to survive your next interview. But for the reasons I've stated above, I propose search trends are a terrible way to choose what to learn. They should only suggest a direction to choose. You don't operate on the scale of those numbers. When it comes down to it, you must choose a single framework to learn in a given moment, which relates to your life, your job, your circumstance. Or you must apply for a single job. A search engine can't tell you how to do any of that.