Hacker News new | ask | show | jobs
by csallen 2256 days ago
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.

3 comments

> 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.

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.

Oh, yeah, and if I have to learn a whole new fucking sub-ecosystem and new version of the language itself with a bunch of breaking changes every two to five years, I don't have any time to spend learning fun things like a whole new language designed around a whole new paradigm.

ECMAScript and everything that touches it has become an actually focused bane for the joy of programming. It was fun just writing some clean plumbing for JavaScript applications in the past, but everything else about the process always ended up involving a bunch of scrambling to catch up with rapidly changing technology, planted on shifting sands even while I'm working with it, any time I start on a new project, where all I'm learning is a new set of persnickety conventions that will punish me if my approach is "wrong", force new work-arounds on me, and generally suck up all my time learning new rules to follow instead of interesting new ways of thinking about things that make me a better programmer and software designer.

Learning the interesting stuff, and figuring out new approaches to new problems based on the needs of those problems (and not the whims of the community), is a lot of what makes programming fun for many of us.

Linux exhausts me similarly.

* ALSA; esound; PulseAudio; etc. Just give me updated OSS or sndio on a BSD Unix system. That shit is stable, well-maintained, and not arbitrarily different every few years.

* SysV; upstart; systemd; etc. Just give me BSD RC. Maybe it's not ideal, but shit, it isn't swallowing 80% of userland with eventual ambitions of conquering the kernel and some of the worst defaults I've ever seen.

I'll just stop now, but I could go on for days in this vein. Maybe some of these tools are great, but I don't expect any of them to remain ascendant for more than five years in a form that is effectively recognizable by any significant measure but its name. The churn drives me insane. One of the reasons I aimed for software development in my professional life, abandoning the system and network administration (aka "ops") side of thing, was to escape all that crap. I want to write quality code, build new things and improve existing things, not participate in a rat-race to remain relevant just to have acquired nothing enduring from decades of effort other than stock options and a nice car.

> 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.

It's also because the JS ecosystem is absolutely massive -- too massive. Instead of consolidating around a good package, people create a new one. You end up with a small number of contributors (often one) per library, and being on the bleeding edge is the only way to make sure your dependencies are maintained.

Javascript's biggest problem is its lack of a standard library. Hence the ridiculous churn of trivial libraries such as leftpad.
Lack of standard library doesn't account for web framework churn, though. Momentarily seemed like we had coalesced around Vue and React, and here comes Svelte, among others. It's incessant.
React was released 7 years ago in may and is definitely the most dominant framework and going very strong, and will be a good career investment for years to come. I think framing that "momentarily" for yourself is making yourself very unhappy - life changes constantly, as we see with this pandemic, and we need to have a little bit or willingness to accept change every five years or so, or perhaps we need to choose a field that has less competition (which is also why we enjoy great benefits and great pay). It should also be noted that both Vue and Svelte are extremely similar paradigms to React, and not at all the big paradigm shift that we saw from Angular to React.
React is its own ecosystem at this point. I can't even keep up with React state management libraries...
That feeling of not having mastery of your tools is part of the problem.