Drupal at least provides you with a fast prototyping experience. Data fields for everything, and connectors to all kinds of external services, validated in some cases by years of production grade usage. Caching, databases, clustering, high-availability... All solved and mature.
The only thing you don't get for free with Drupal is a backend which you can speak to if you're deciding to go the SPA route later on.
Which, in my personal opinion, is a pretty stupid trend anyway. SPAs tend to grow to Java Enterprise levels of complexity very very fast, and things break All. The. Time. Not to mention you're putting huge amounts of work to the frontend, where you virtually cannot account for cross-browser behavior, people with multiple-year-old browsers... and people with devices older than two years!
Leave a Drupal project idle and unmaintained for a year, and you'll be able to pick up where you left it. Good luck doing the same with an AngularJS SPA - you might get away if you used npm shrinkwrap when you left, but the first npm update WILL kill your code with a billion possible places to fix.
Drupal is mature, and maturity is something that the entire Javascript development and tooling community is missing unless you stick to plain jQuery.
Stability and reliability IS a thing, especially in enterprise.
Go the hipster way when your target audience is hipsters, go the proven, old-school way when your target audience is enterprise.
edit: ad maturity of Drupal and support... D6 got released in 2008-Q1 and support ended in 2016-Q1. That's EIGHT YEARS of continuous support and security fixes, and I expect similar if not better support timeframes for D7.
Good luck finding a Backbone.js or Ember.js (and maybe even AngularJS) developer in four years from now; not to mention that during the entire D6/7 lifetime backwards-compatibility-breaking changes were a rarity in Drupal when all of the mentioned JS frameworks have had more than their fair share of clusterfucks stemming from bad design. Or just the tooling environment, breaking changes everywhere and (gut feeling) every month there's a new tool to learn or best practices revamped.
Wonder why PHP, server-side rendering and SQL is so prevalent? You can rely on buying a solution and having support and developers even in multiple years from now. Enterprise doesn't want ever-changing piles of crap layered in more piles of crap, enterprise wants stability and maintainability. And enterprise is where the money is, not some SV startup only surviving on VC or with 90% of its customers startups only surviving on VC.
I have a turbogears app from 2008 that I still occasionally maintain. It's not officially supported, but it works, and I find Python to be nicer than PHP by enough to be worthwhile. I wouldn't use Javascript because it's awful, but if a small, immature framework suits your needs I wouldn't avoid it just because it's small/immature. Either your app won't be terribly important, or it will be; in either case you're sorted.
If you want to ever have a safe upgrade path that doesn't involve months of testing then you absolutely need a type system, IMO. The only framework I've felt completely safe doing major upgrades on is Wicket - which, not coincidentally, is the only framework I've ever known to make extensive use of final classes and final methods (Java), to enforce that it's only possible to use it in supported ways.
Javascript SPA applications get less respect from business owners than they deserve.
People see JS and throw their JQuery & some CSS developers at it. Or they use their backend PHP devs who've never written code that runs for longer than one request.
Either way you end up with code written by people who don't understand some of the fundamentals of UI programming.
Angular gets the worst of it because it's the most popular framework. It's exacerbated by the fact that Angular doesn't offer suggestions for a lot of common problems.
I live and breathe Angular SPA applications -- the vast majority of developers that work with it cannot comprehend a well-designed and usable Angular application.
Proper error handling, sane state management, and keeping the codepaths short and easily grok'd is very difficult with Angular -- especially for larger applications. This results in blackholes where users find themselves in strange spots that are inescapable other than a full page refresh.
These are either developers dipping their toe into the front end after living in the back end of things their whole career, jQuery dudes hastily breaking into SPA development to stay afloat in an environment the submitted article exactly mentions, or simply lazy developers that couldn't be bothered due to tight deadlines/budget/whatever.
Angular is popular enough that someone who could distill a reasonable set of concepts and practices for working with it could probably reap some significant rewards in the education/training marketplace.
But if proper error handling, sane state management, and keeping codepaths short are actually "very difficult with Angular," maybe it's not the comprehension powers of the developers using it that are falling short.
A framework should be actively making those things easy.
Exactly. Server-side rendering is incredibly fast with modern browsers which makes a bunch of SPA sites completely infuriating. There are a few things that make sense like little button actions using AJAX but most of the page should just stay as a normal HTTP HTML request.
Leave a Drupal project idle and unmaintained for a year, and a new, non-backwards-compatible Druoal version has been released and you'll need to rewrite everything.
I don't have experience with Drupal, but it says "plan for periodic upgrades of their project to the latest major release (every 6 years or so)". So, even if a new release comes out, you have _literally several years_ to decide when to make a switch. For perspective, Backbone.js was released 5 years ago!
But the "old" major version will still be supported for a very long time frame. In the case of D6, it was supported over five years after the release of D7.
Just coming here to give Backbone.js some credit. It is one of the most mature of the frontend frameworks, because it does almost nothing. It's what I'd call feature complete, its core probably will not change or grow much from here (in a good way). jQuery and Underscore back it, which also aren't changing or going anywhere. And as another commenter point out, it's 5 years old already, still in production all over the place.
What do you suppose you should do when people start demanding interactive features and capabilities that can only be done client side? For a lot of us the alternative of doing things on the server is a significantly worse UX.
> What do you suppose you should do when people start demanding interactive features and capabilities that can only be done client side
You are free to use jQuery in your theme (aka frontend code), or D3 for visualization, or any other JS stuff you may need. On a private project, I'm using a current jQuery, D3, and SCSS and it works quite fine for me.
The only thing in D7 that can be a major PITA is proper multi-language support, because it's a bit sparsely documented.
The only thing you don't get for free with Drupal is a backend which you can speak to if you're deciding to go the SPA route later on.
Which, in my personal opinion, is a pretty stupid trend anyway. SPAs tend to grow to Java Enterprise levels of complexity very very fast, and things break All. The. Time. Not to mention you're putting huge amounts of work to the frontend, where you virtually cannot account for cross-browser behavior, people with multiple-year-old browsers... and people with devices older than two years!
Leave a Drupal project idle and unmaintained for a year, and you'll be able to pick up where you left it. Good luck doing the same with an AngularJS SPA - you might get away if you used npm shrinkwrap when you left, but the first npm update WILL kill your code with a billion possible places to fix.
Drupal is mature, and maturity is something that the entire Javascript development and tooling community is missing unless you stick to plain jQuery.
Stability and reliability IS a thing, especially in enterprise.
Go the hipster way when your target audience is hipsters, go the proven, old-school way when your target audience is enterprise.
edit: ad maturity of Drupal and support... D6 got released in 2008-Q1 and support ended in 2016-Q1. That's EIGHT YEARS of continuous support and security fixes, and I expect similar if not better support timeframes for D7.
Good luck finding a Backbone.js or Ember.js (and maybe even AngularJS) developer in four years from now; not to mention that during the entire D6/7 lifetime backwards-compatibility-breaking changes were a rarity in Drupal when all of the mentioned JS frameworks have had more than their fair share of clusterfucks stemming from bad design. Or just the tooling environment, breaking changes everywhere and (gut feeling) every month there's a new tool to learn or best practices revamped.
Wonder why PHP, server-side rendering and SQL is so prevalent? You can rely on buying a solution and having support and developers even in multiple years from now. Enterprise doesn't want ever-changing piles of crap layered in more piles of crap, enterprise wants stability and maintainability. And enterprise is where the money is, not some SV startup only surviving on VC or with 90% of its customers startups only surviving on VC.