There are points in this article that go beyond SPA. In fact, I'd drop "for your SPA" from the title, and just use SPAs as an example. The author didn't, becaus

There are points in this article that go beyond SPA. In fact, I'd drop "for your SPA" from the title, and just use SPAs as an example. The author didn't, because, you know, he has a book to sell on SPAs, but let's let that slide. ;) All the arguments he makes can be made about any framework, including server-side. Every point of pain he cites I can relate to from use of frameworks like Rails, Symfony, hell the abuse of Wordpress might qualify here. Rails in particular: I was coding in Rails pre-1.0. Every major version upgrade has been hellish at some level. Often developers don't quite know what's going on only to find that callbacks or validations aren't working as expected. We can still write awesome Ruby applications using all the libraries that make up Rails, but would I start with Rails these days? I'm not sure I would unless I was going to be working with a team that was quite junior where the gains from conventional layouts and inner workings might give us some gains. That said, I'd also be transparent with them and myself about the costs of choosing a framework, any framework, and Rails is cheap in the short-term but I've seen it get expensive in the long term. Not because it's Rails or Ruby, but because it's a framework. I used to think the lack of a decent CQRS framework in most languages was a problem. I now think it might be an advantage. As that pattern becomes more popular for complex domains, it's forcing developers to write better software, and I think somehow most of them are realising this is the way to go. Perhaps that's just my bias. And it's also why Go is refreshing to me, personally. Frameworks are resisted by the community, primarily for performance reasons, but I actually think the author's arguments apply there too: with good enough library support we can get reuse whilst also not suffering IoC issues.