I cant even finish reading an article before another is posted with something new and "must know".
TLDR: you can't learn everything, so learn things that help you grow towards the life you want.
I'd start by looking at who says something is "must know" and what they know about you and your career :) Give it the "will it matter in a month... a year... ten years" treatment.
Other thoughts...
Current role skills are usually pretty obvious and naturally expanded on the job; but it's good to stop and check that's actually happening.
Career direction skills may not be obvious at all and tend to need more training/mentoring/time. It helps if your boss knows what opportunities you are looking for, too (so they can steer the right opportunities your way).
On the purely technical...
I like to keep a rough mapping of interesting concepts and implementations that implement some variants of that concept.
For example Component encapsulation is a concept, Polymer, React etc. are implementations. Virtual DOM is a concept, React, mithril, vdom etc. are implementations. Unit testing is a concept, mocha, rspec etc. are implementations, Homoiconic syntax is a concept, clojure is an implementation etc.
I can not keep track of details of all implementations of all concepts, so I keep track of which implementations have the most community traction (in Hashnode, hacker news, echo js etc.) and which concepts are relevant to the problem domains that I am working on or am likely to work on in the next 1-2 months. I also usually restrict my catalog to the implementations that are available in languages I am familiar with or am planning to gain familiarity with, unless the implementation is so good that it's existence in itself would be a compelling reason to learn a language.
Based on the above I prioritize my learning list. I usually defer going deep into the implementation details until I actually have a problem at hand where I can apply the same - but having a basic overview of the use case helps me associate a concept with a problem as it becomes available and then I would figure out which is the best implementation, what are the cons of the implementations which have less traction etc.
Most of the things in web and mobile development has moved from hard engineering to fads. That is because the focus is more on UI. Just like content can be produced out of thin air, fads can be produced out of thin air. Better approach is to participate by creating content than just reading it.
I would say don't try to learn everything at once. Pick a thing learn it well move on :) Don't get caught up in the hype (yes that's hard).
es2015 brought a ton of new features all at once but won't be the case for future versions. This site http://es6katas.org has been helpful for me.
Take 15-30min a day if you can to learn something new. Over time that adds up to a ton of learning.
Most of it isn't important. I used to keep up with the bleeding edge but it was exhausting and 95% of what is "new" is also irrelevant. It just ended up giving me anxiety because I felt like my skills were months away from being deprecated.
There are really only a handful of meaningful new things that stick. Off the top of my head, Docker, Angular, React, and Node are the big new projects in web development over the past few years that have stuck around. Even then, these are still relatively new, don't have huge penetration and are far from "must know" at this point.
If something really becomes huge, you will hear about it without having to seek it out, and it will happen over a decade, not overnight. Everything else is probably just noise.
That's only a problem in the JavaScript world - the Java, Kotlin, Dart and many other languages have well defined ways of doing certain things and any new things are often designed first with a consortium of engineers and then built once which means things are generally released in such a way, that staying up to date is fairly doable and the solutions are generally complete.
Whereas in the JavaScript world everybody builds their own solution for problems that are often not even well defined, everybody wants to be THE expert spewing article after article on how things should be done, everybody wants to build the next big framework that often just overlaps existing solutions and and there's generally a gazillion different ways of doing the same things.
How many build tools are there in Java? Maven and Gradle are almost the defacto standards and they do everything (gradle uses maven packages). Same in Dart, one build tool, Pub, which does everything. How many tools do you need to do everything in JavaScript?
Grunt or Gulp or Broccoli or Brunch or Feri or Mimosa or Angus or Lineman or let's throw in some Babel, Webpack, Browserify, you've got NPN as package manager instead of NPN doing what all the other tools are doing ... then there's Bower trying to do what NPN is doing, Jam, Ender, volo, Component, JSPM, ... this is madness !
PS, try this Tool.JS thing I'm building, it solves all the above problems I've mentioned with the above tools.
Learn and practice only software architecture and engineering principles, they never changes. Learn languages you use in a highest level, don't use libraries or frameworks, try to build them yourself.
Frontend today is overcomplicated, you can easily ignore most of these "must know" articles. Don't look for companies which can't explain anything and require from you to use a lot of frameworks because it's popular, cool, modern or anything else.
Information today is blowing the Internet and is impossible for human brain to process so much and because of that it starts ignoring most of the information. Keep only small focus and be very good at it. Learning another framework, library, tool won't help you to build business apps or make your own architecture, frameworks, however by learning the core you will be able to write a good maintainable code very fast and it will be simple, you will be able to write another framework, library, tool and write another article yourself.
That's the main reason I started solving this problem with BunnyJS.
I think the trick is to move from "must know all" to "what is the problem at hand". What is your current pain? That is where your research and read efforts should go I think, for the rest it should suffice to do some headline scanning.
For example: I originally started out with browserify because I found it simpler to setup then webpack. After a while I run into some limits of browserify and researched whether webpack could address those (only started really reading about it at that point, before it I just knew the name). Now there is quite some buzz about rollup. It might be better, feature wise or conceptually. Yet I don't invest time in it at this point because I don't have any urgent pains with webpack and I'm comfortable with it. If I would start on a green field, long term project, I would probably invest time in reading about rollup because it might be a better investment in the long term.
TL;DR: pick your battles, focus on your current pains. Nobody expects you to know everything.
(... and if you are desperate to learn new things, try MobX ;-))
aravind
ceo
yah!!Thank you so much for sharing. Recover android messages