JavaScript: The Right Way

That's a rather negative view, and I don't think it's entirely realistic. I am involved with multiple long-running web projects that have been using things like (real) MVC architectures and single-page applications since long before any of these trendy JS frameworks existed. The projects have been built using sound software development principles and usually a small number of carefully chosen supporting tools and libraries. They are still doing their jobs just fine, and they have stood the test of time in terms of maintainability.

The only people I meet who have an aversion to these modern JS frameworks are front-end devs who refuse to learn them or server-side devs who hate javascript.

Please consider that there is at least one more option, which I imagine applies to many of the older readers here. Some of us have seen before the rapid evolution of an ecosystem as a programming language takes off, and we simply don't buy the hype.

We saw the arrival of Java, with all its garbage collected wonder. Then we saw the nightmarish descent into over-engineered hell that followed.

We saw the arrival of Boost for C++ and the potential of community-developed, peer-reviewed libraries. Then we noticed that in 2014, C++ still doesn't even have basic features for working with filesystems or rendering a simple UI as standard.

We saw the evolution of very dynamic "scripting" languages like Python and Ruby into widely used server-side languages for real applications. Then we saw people trying to maintain those applications a few years later, when they weren't prototypes any more and when quality and performance mattered.

More recently, we've seen front-end web development shift toward JavaScript and move away from the likes of ActiveX controls, Flash plug-ins and Java applets, as language support became more consistent across browsers and some real effort went into improving performance. Today we are also seeing the inevitable explosion of the surrounding ecosystem as JS becomes a tool for building more heavyweight software, signalled by the arrival of vast numbers of different automation tools and libraries and frameworks.

But with the cynicism of the industry veteran, we also see that many of these new tools will do 80% of a job easily but make the last 20% much more painful. We know that some are merely short cuts aimed at people who now work in front-end development but whose backgrounds aren't necessarily in programming and who haven't yet developed their general software development skills in that way; there's nothing wrong with that, of course, but such tools have no (or negative) value to those who have moved beyond the level where they are helpful. Most of all, we know that five years from now, as the ecosystem evolves standards and consolidates, it is highly unlikely that most of the currently trendy tools will still be as effective and well maintained as they are today, but that like the five-year-old projects some of us work with today, someone will still have to maintain those projects after all the hypesters have moved on.

This doesn't mean that we somehow refuse to learn new technologies. It just means that if I can see what looks like a fire, and it feels as warm as I expect when I get close enough to examine it, I'm not still going to jump in for a few minutes just to see if it's really as hot as it looks because I read on a web site somewhere that all the cool kids were doing it.

Now get off my lawn. :-)

Well, not a valid usage either given the context. From the examples you give, the only fitting one is Backbone, and even that it's stretching it a little (nobody uses the ES6 monitoring/reacting facilities directly atm, so it's not like Backbone gives them compatibility for them, it's like it provides them in the first place).