> I don't believe this is pointless tech churn, akin to fashion.
This is not pointless, but it is pretty uncontrolled. Basically, there is a natural tendency for engineers to want and rewrite old stuff, once all the flaws of once-cherished yesteryear solutions are glaring. Normally, engineers don't have a freehand in ditching old projects and rewriting from scratch, so they have to maintain what exists.
But with all the startups and the site redesigns, now they can, and they do. Why not--it's fun, it replaces old solutions that showed their limits, and the scope is somewhat limited; it's just a website, after all. Moreover, everyone can jump in and create their foobar.js lib or framework; the core node/JS is pretty easy.
> It really feels to me, at least, that there is a direction that the tooling is heading.
It is quite uncertain. Progress is made when you build on previous work, but here it is mosly about saying that the old solution doesn't work eventually, so let's do it this way instead. It looks a lot like infinite recursion, with pretty thin state.
Just as some examples.... we've moved some pages to vanilla jQuery to Angular and have gained orders of magnitude more stability (read: basically no state-inconsistency bugs in newer pages).
If you're faced with vanilla javascript in the DOM and have any amount of complexity to it, then you should be using angular/react, if not for your sanity than for the sanity of the one who will need to maintain your code (read: you in 3 months).
If you're knowledgable enough to know that your use-case doesn't work with the newer tools, then more power to you. But the productivity gains from moving away from your jQuery spaghetti code to one of the more managed frameworks is well worth the rewrite time.
I don't know much about going from Angular to React, or Backbone to Angular though.... the choice of framework is likely dependent on what kind of user interactions dominate your app and subjective comfort.
But if you're careful, you can actually transition apps slowly over to Angular and I assure you, you could get rid of so much of your custom-written (probably not well tested) DOM management code it's not even funny.
You know, if people approached web programming like actual programming, with layers of abstraction, there wouldn't be spaghetti code in the first place, and one could move to a different framework as needed.
But the problem is nobody stays with anything long enough in the web world to learn it well. 5 years ago, Backbone, Then Knockout. Then Angular. Then Ember. Now React.
Seriously, a dev with 5 years of experience in JS has literally the same 1 year of experience over and over now.
This is not pointless, but it is pretty uncontrolled. Basically, there is a natural tendency for engineers to want and rewrite old stuff, once all the flaws of once-cherished yesteryear solutions are glaring. Normally, engineers don't have a freehand in ditching old projects and rewriting from scratch, so they have to maintain what exists.
But with all the startups and the site redesigns, now they can, and they do. Why not--it's fun, it replaces old solutions that showed their limits, and the scope is somewhat limited; it's just a website, after all. Moreover, everyone can jump in and create their foobar.js lib or framework; the core node/JS is pretty easy.
> It really feels to me, at least, that there is a direction that the tooling is heading.
It is quite uncertain. Progress is made when you build on previous work, but here it is mosly about saying that the old solution doesn't work eventually, so let's do it this way instead. It looks a lot like infinite recursion, with pretty thin state.