Your hacker biases are showing.
The sites where 95% of people spend most of their time (Twitter, Facebook, Instagram, etc.) are all built as single page "applications." Users expect rich interactivity from websites these days and are usually not tolerant of UI refreshes.
The comparison is not to "desktop" applications but to mobile apps. Users expect a mobile app level of interaction. Plus, if you're building mobile apps then it's a lot easier to just reuse those same APIs for a web app.
That being said, if your site doesn't have any interactivity then it does make sense to just render it statically.
The app may have been slower to load the first time (hopefully not by much) but from then on, they get the perception of instant feedback even if they have to wait a round trip for the backing data sometimes.
SPA frameworks make this sort of interaction very easy to design and reason about as a developer.
If you are going to argue that this is about "hacker bias" you will have to show user studies, not poll JS developers.
They're fantastic for forcing people to buy new hardware just to look at information :|
I've done of a few of these types, and now have moved onto mixed environments. Where most is rendered server sided, then only updates requested client side. Of course you're doing things twice for same queries.
Serious question: are people so touchy these days that you have to assure them that you are not being hostile before even saying something?
For me it has the opposite effect, it makes everything sound less genuine. But hey, I'm just some guy, if people like it...
I find unnecessary clichéd phrases very annoying (e.g "going forward"). Maybe I'm alone in this. It's not because of pretentiousness or language puritanism, it's that it makes me feel that I'm reading something created by corporate PR or some other soulless entity with ulterior motives. My rule of thumb: if you have nothing creative to add, just be simple.
Of course all that goes away when your boss says you need to support JS-disabled browsers.
Well seeing as this release of angular offers some form of server side rendering, as well as Ember with fastboot, & being implementable in React or something like that. It's more approachable these days, there's some tweaking that's required, but very much doable.
Unless of course you're dealing with an interaction heavy UI.
In any event, if you're making a real Web application (as opposed to just a Web site that's primarily static content) the experience is much better.
Classic websites have CMS, things like Wordpress, and a ton of MVC frameworks that have been tweaked over the last decade, like Rails, Django, ASP.NET MVC, etc. When it wasn't a solved problem, a new one like this was popping up in the news every other week.
Now, that that's done, people are trying to do other things, like complex web apps...and so that's where the brain time is being spent.
React is super good to take control of a small piece of the page and build a complexe widget on it (can't speak about angular, I only used it twice without getting very far).
However, in b2b use cases where SEO isn't an issue, SPA frameworks are ideal for coordinating a static-site<->dynamic-api system.
Most websites and web apps have use AJAX to dynamically update certain parts of the site. Even though few sites would need to use it for everything, once you introduce good tools for dynamically updating the DOM and hire some Javascript developers, it's easy to say "Let's just use this approach to everything".
It's fair to say it's a lazy approach. I've built many SPAs that probably would have been better as static sites, and would have benefited from better SEO. But hey, we got then shipped fast.
I don't think that's entirely true, they allow for building experiences that weren't really possible with the previous model of rendering entire pages server side on every action but they aren't easier in all respect to that. If you site is mostly static data, it's probably still easier to use the older model. SPA frameworks start to make more sense when you want to build interactive pages with components that you want to individually update etc...
But they do add complexity that can't be ignored. that's why tooling and frameworks are hugely important as they smooth out that complexity.
So, I guess I'm saying that it allows for much shorter iteration times, ability to experiment with solutions in the production environment without requiring complicated server solutions.
Granted, that also lets me build experiences that weren't possible, because I can experiment more and have a faster feedback loop, but for me, it's because I can DEV better.
Websites are static documents.
Web Apps use the browser as a runtime for a UI application.
HTML5, CSS3, and Javascript have matured to the point where they are very powerful and flexible. I don't always see the point of over-complicating things with frameworks.
All-told, it took 20 hours, 7 of which was me getting used to the intricacies of developing a full-screen "App" (no scrolling) with flexbox and implementing the designs. I'm good with vanilla JS, but there's no way I could have done all of the coding (three 'game' pages, three 'admin' pages) in less than two days.
I guess the point is, a framework that you know and are familiar with can halve the time you spend on a project. I find that to be especially true with Ember because of the CLI tools and all of the various addons.
"Premature optimization is the root of all evil."
- Donald Knuth
Simplify server logic
Use less bandwidth
But when I look at how are built the sites I like and visit frequently, I'd say 95% of them are not SPA, they are classic sites where the server generate each page (sometimes with one or two Ajax requests)!
The Single Page pattern is great for desktop-like applications such as Gmail, it's obvious. But otherwise, I don't know... I think I still prefere the "feel" of classic websites.