Perhaps not, but plenty of us write them using a lightweight framework like Flask rather than heavyweights like Django, and even in a relatively mature field like ORMs, there are downsides to using them that sometimes outweigh the advantages.
For a tiny app, sure, maybe it's not so bad to just use jQuery.
I've got ~100,000 lines (before minimising etc.) and ~5 years of successful maintenance "just using jQuery" for one web app that I can quickly check from here that is still going strong. I think most of us would agree that's not a tiny single page application.
IME any application which grows that large without using a framework ends up inventing its own. If the code's maintainable by people other than its original author you've presumably separated the routing code from the template rendering code (and have a module that's effectively a generic template renderer) from the backend service access (and again, probably have a module that's some kind of generic service access layer). You'll have a set of utility functions that's more or less equivalent to underscore. And so on.
I don't know. That project has no direct equivalent to any of the current frameworks, other than approximately following MVC for its overall architecture and using message passing/publish-subscribe in various places to keep things modular and testable.
I imagine you could achieve some of the same behaviour using data binding tools in modern frameworks, but either way you're typically looking at a little boilerplate to connect things up in the first place and then one-liners to connect individual fields from a model to the corresponding parts of the DOM. It's not clear whether there would be any savings at all, but if there were, they wouldn't be significant for any framework I've considered so far. In any case, that represents a tiny fraction of the overall code base for this application.
IME any application which grows that large without using a framework ends up inventing its own.
All software has an architecture, sure. As with any framework vs. library debate, you're trading off the benefits of having some of that architecture predetermined for you and having some of the laborious plumbing work dealt with automatically against the overhead of managing a major external dependency and any extra costs you incur if you need to do something that goes against its natural capabilities. Sometimes using a framework is a win, and sometimes it isn't.
If the code's maintainable by people other than its original author you've presumably ...
You've made some assumptions there about how web apps work, but they aren't necessarily true.
For example, much of the complexity in this particular UI comes from providing many views of the same underlying model. Some of them are graphical rather than text/form based. Some of those rely on intermediate cached data structures for their source data because rerendering an entire view from the raw data in the model can be prohibitively slow. We have an efficient and simple architecture using the same basic principles as MVC for dealing with this kind of caching. We'd derive very little benefit here from the kinds of data-binding and template-rendering functionality found in the major frameworks.
Just to be clear, libraries designed to render interactive graphical page elements efficiently, allowing for portability across browsers and different image/scene formats, are another question entirely. I'm not arguing for reinventing the wheel or arguing against using tried-and-tested code from external sources. I'm just arguing that it should only be done when the benefits outweigh the costs, and that this won't necessarily be the case when considering whether or not to use one of the modern JS frameworks as the foundation for your web app.
Why? I've worked on non-web software projects 1-2 orders of magnitude bigger that didn't need anyone's magical framework to develop and maintain a sound architecture. How come we can't just use good design that fits the project if the software we're writing happens to be the front end for a web app?
It's about picking the right tool for the job, the same as always. For some projects and some development teams, I'm sure these modern JS frameworks and tools have proved valuable and will continue to do so. On the other hand, we're currently planning another web app that is expected to grow at least as big as the one I described earlier, and no-one on the team is seriously considering using any of the current crop of front-end frameworks. That's not because we don't know what they do or how they work. It's simply because none of us thinks it's a smart idea to build such a large and hopefully long-running project with a fundamental dependency on the kind of technology that typically measures its time at the top in months.
