The real problem here is that not enough developers understand that "just because you can, doesn't mean you should." Once more of us get a handle on that, life will be better.
You can and I do. However, I am thinking of using polymer or vue.js as I think they are a much lighter candidate than react.js & angular.
The power of marketing is underrated in the developer circles.
Promise I'm not giving you a hard time. I'm honestly curious if there's something I'm overlooking.
I just like to think that I'm developing a mobile app with front-end javascript framework....it's just the tooling and prerequisite knowledge is quite chaotic. Finding the right articles (up to date) is half the battle, as it's scattered in endless git repo pages.
If you are using jQuery to build a big SPA with multiple devs, you can certainly do it, but it's not enough. At the same time I'm against over engineered frameworks that imposes high cognitive friction on developers. Vue.js and Polymer hits the right notes for me. I feel that Vue.js is a reaction to React & Redux (seems like the trend is to use it when we don't need it). There will be use cases that makes one more favorable then the other but not many shops are employing 1000+ teams working on FB, therefore the premium you pay to mitigate complexity that you don't have results in loss of productivity, is how I like to think about it.
I won't use something because everyone else is. Often, the majority is wrong and easily influenced by marketing and authority (especially if you are good at lighting billions of dollars on fire to build an elusive monopoly). It happens all the time in dev communities but what makes it worse are the complete lack of insight into why you are not FB or Google. We blindly emulate them hoping to be like them.
I say, approach the problem with a blank sheet of paper. Figure out and evaluate what works for you and your team while watching out for marketing myths and other disinformation from the unicorns.
Frequently, I do store metadata in a DOM element because the next event I will react to is a click on that DOM element, so I already have a handle on it from the ui element jQuery gives me... I do not have to traverse the DOM. But if the future use of the data is NOT going to be a response to a click on a specific DOM element, then no, I will do something else with the data.
Again, just because everyone else does it doesn't mean you have to, and doesn't mean it is inherent in the tools. I'm not saying jQuery is the best tool out there... I'm saying that complexity in an SPA doesn't come from jQuery itself, but from design choices made with it.