|
A lot of this is a direct result of feeling that one always needs to be on the bleeding edge, which is both unnecessary and also a recipe for wasting time on fads. As an analogy, consider fiction. Imagine reading as many new novels as possible as they're released. Well, most of these novels will be completely irrelevant 5 years from now. The good ones stand the test of time. So you might as well only read novels that are 5+ years old, yet are still relevant and receive acclaim. If you worry that taking this approach with JavaScript will make you fall behind, my question is: Behind whom, exactly? There's no way many in the industry can keep up with all the changes you listed as fast as they're coming out. Therefore, it follows that a great many of your JS developer peers are "behind." Therefore, it's okay for you to be, too. What happens to me, personally, is I start on some new project or company using a pretty recent stack at the time. Over the course of the next few years, that stack becomes "outdated" as new things are released. However, it also matures as its documentation improves and its community grows. Eventually, after 2-5 years, I move on to another project, and just take that time to catch up on the latest. The result is that I end up skipping a lot of the fads that die on the vine. For example, I largely missed CoffeeScript. I think a lot of pain from JS comes from the expectation that one can and should keep up, when you probably can't, and definitely shouldn't. |
The problem with this is that everyone jumps on new fads so quickly that, if you don't, you're likely to endup with a bug-ridden, half-baked, vulnerability-riddled, unmaintained/abandoned, slowly collapsing, termite-infested framework as the basis of your entire SAAS business, or whatever it is you're trying to run on something that even the creators abandoned for the next fad.
> What happens to me, personally, is I start on some new project or company using a pretty recent stack at the time. Over the course of the next few years, that stack becomes "outdated" as new things are released. However, it also matures as its documentation improves and its community grows.
You have to be very, very lucky to accidentally end up with a "pretty recent stack" that will still be maintained in five years. On the other hand, the next part shows that you don't actually go with the 5+ year old "stood the test of time" tools:
> Eventually, after 2-5 years, I move on to another project, and just take that time to catch up on the latest.
Having to learn a whole new sub-ecosystem in as little as two years is exactly the kind of mind-destroying grind everyone's complaining about. I don't think anyone's just jumping on the newest thing that appears every six months; they're all just having to move to some new toolset every two to five years and burning out ten years into a career because otherwise they'll end up having to be the new maintainers of whatever tools they're using due to the fact nobody else is using them (and thus no one else is maintaining them) any longer.