These new tools and frameworks are becoming numerous and popular precisely because for large, complicated front-end applications you can't just get away with using "plain JS with Jquery" without it becoming an unmaintainable mess and writing boilerplate DOM manipulation code all over the place.
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.
> 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.
No, they are aimed at people who have worked in front-end development for a long time and whose backgrounds are in programming precisely because they are sick of reinventing the wheel every time they start a new project and are able to understand the technical value behind concepts modern frameworks give us like dependency injection, unit/e2e testing, modularity, and separation of concerns. The myth that front-end developers are not "necessarily from a programming background" is poisonous thinking and it unfortunately usually comes from older programmers or non-front-end developers; the very people who could help guide the front-end world into maturity.
sick of reinventing the wheel every time they start a new project and are able to understand the technical value behind concepts modern frameworks give us like dependency injection, unit/e2e testing, modularity, and separation of concerns.
You write as if we didn't understand the technical value of those things before a couple of years ago when the current crop of JS frameworks arrived, and as if using one of those frameworks is somehow necessary to achieve them.
In reality, everything you mentioned has been widespread in other software development fields for decades. It's stuff the junior guy on the team learns in his first few months.
Moreover, I think there is a reasonable argument that of your chosen examples, testing is the only one that has sufficiently common requirements for building large but general tools to be worthwhile. The other design principles are valuable, but how best to use them will be highly project-specific, and therefore any widely useful framework will tend to be over-engineered and over-generalised for most applications. See also the Java nightmare I mentioned previously, the trend toward lightweight frameworks on the server side, etc.
Edited to add:
The myth that front-end developers are not "necessarily from a programming background" is poisonous thinking and it unfortunately usually comes from older programmers or non-front-end developers; the very people who could help guide the front-end world into maturity.
There is a difficulty in the industry that significant numbers of people are coming into this kind of front-end development from some sort of HTML/CSS and/or design background. They used to use a bit of JS here and there that they copied off a demo site to get their buttons to animate, and now they're being asked to move into more of a mainstream programming role, but neither they nor the people asking them necessarily appreciate what that involves.
That's not anyone's fault. It will be fixed over time as the industry matures, both because knowledge will spread and because more specialised roles than "front end developer" will probably evolve. But right now, today, it is the situation in large parts of the industry.
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. :-)