image by Christos Loufopoulos
I could go on all day, and by the time I complete this post, there will be a few more frameworks. So why am I not diving in head-first? Here are a few of my concerns.
As a developer, I have a pretty beefy machine, but my users most likely have commodity devices. Also, most users don't have the same machine and browsers I am running. Any testing that I do locally is most likely not going to be representative of even a fraction of my user base. This client fragmentation of devices, browsers, and performance will most likely lead to a support nightmare.
Too Much Flux
Re-inventing The Wheel
As a web development community we have solved a ton of problems on the server: Validation, Security, Caching, Data Storage, etc. These were not easy problems to solve, with some taking close to 20 years to get right. The issue is that more and more SPA devs want it all on the client-side, which potentially could cause headaches for all. Don't store sensitive data in the browser. The browser is not secure.
Chatty / Request Heavy
SPA applications can be chatty, especially if they are using generic APIs that were not optimized for the interaction on the front end (Healthcare.gov).
This is one of my biggest pet peeves. I might be possibly doing it wrong, but I constantly find myself duplicating validation logic on the server and client side. With ASP.NET MVC, the client-side validation rules were just generated based on my server side definitions. This might be a tooling issue more than a SPA issue, but the tooling isn't there yet and for that reason I will take my frustration out on SPA.