Are Single Page Applications (SPAs) for everybody and everything?

Take a look at these two statements. Which is true?

  • “To say that SPA development is the future is an extreme understatement.”
  • “SPAs are how some of the best applications on the Web offer fluid UX and responsiveness, while minimizing payloads and round-trips to the server.”

The interesting thing is, both of these are from the same article (March 2014 MSDN Magazine). I think the second statement is demonstrably true – but the first statement is an exaggeration. Over time Single Page Applications (SPAs) will become ONE way of writing applications – maybe even the default way – but far from the only way. And it’s safe to say that the way we write SPAs now will change dramatically over the next five years. Let me explain why.

Migrations are usually gradual

If you’re starting from scratch, a SPA is a great way to go. However, the typical migration I see in the enterprise isn’t all at once, but more of a shallow-end-of-the-pool kind of adoption that allows teams to grow into client-side development:

  • An existing Webforms app starts to use some Javascript/jQuery functionality.
  • Over time, this becomes more complex and more jQuery plugins start appearing, where jQuery/JS usage starts significantly changing the page structure
  • Pieces or the entire application starts migrating to the MVC framework for communicating with the server and presenting views
  • The app starts becoming a mini-SPA. Most pieces are still served up using views/controllers, but some critical pathways are served up client-side with asynchronous data requests. This is done one baby step at a time, and most of the application remains straight up MVC/webforms.
  • Migration to full SPA. There’s a login and a forgot password request page, but all other client interactions are handled within a SPA framework.

Why is this?

SPAs aren’t a silver bullet for your development woes

Too often we don’t take into account the maturity or size of a development team in making architecture recommendations. For example, a while ago I was involved in a development effort where the team looked at SPAs/WebAPI and abandoned it as “too expensive”, in favor of a prototype approach with ASP.NET webforms. Seeing as how we had a very crude SDLC and a nonexistent peer/code review and release management strategy, I had to agree with this decision. Maturity wise, the team wasn’t where we could have leveraged the best aspects of MVVM and AngularJS – we just didn’t have the pieces in place without a team commitment to testing, reuse and code quality. It’s pointless to make the leap to client-side development without taking care of the essentials first.

No one is arguing here that client-side JS frontend doesn’t offer a potentially fantastic Ux experience and more maintainable/testable code in the long run. The downside is a very sharp learning curve, sometimes spotty documentation, and a plethora of rapidly changing JS libraries to choose from. If the dev team has only MVC/webform experience, you’ll need to invest in specific training and experience, and the tooling for JS libraries is not nearly as good as what you can get with webforms/MVC. It’s well worth it – if you are able to accept those costs and commit to the longer ramp-up that implies.

Not all applications will fit the SPA model

I don’t feel that all applications need or should be SPAs. If you’re writing an app that will have most of the heavy lifting done server-side with a sprinkling of jQuery/JS, going to a MV* framework could be overkill. If the app design calls for a lot of data manipulation and presentation happening browser-side – for example an app that could download all the scripts, styles and markup a client could need in one payload and then perform additional behavior in the background – well, that’s a SPA. In that case a JS MV* framework will pay off.

What’s the future?

As we’ve grown from classic icky ASP => ASP.NET webforms => MVC => SPAs with MVVM, each time we’re refining our approaches and the challenges have made us better programmers. So, this is a sea change – thinking in terms of a rich UI and the user experience. Even for internal apps – users now have an elevated set of expectations from Ux-forward apps they use on their tablets and smart-phones. We have to embrace this change, with both arms. It’s no longer about Java vs C#/.NET, Eclipse vs Visual Studio. JS and the client experience will hold sway. I’m thinking in the next few years we’ll see MSFT really fill in the gaps when it comes to JS development tooling – we already are with the 4.5 release

I remember when XML came out, and then MVC – there was a kind of sharp “everything we have must be converted to this now” reaction, followed by a reset where it became a new tool in our library. I think SPAs will follow the same path, where they’ll be used sometimes, where appropriate – where Ux is king, where the dev team can handle it, and where everything can be done client-side.

Maybe you agree with this – maybe you don’t. And as I continue exploring AngularJS and other frameworks maybe I’ll change my mind and talk about how foolish I was in my prophecies. More importantly, maybe the market will disagree – and agree more with the author at the start of this writeup about SPAs being the future, the be-all, the everything. In that case, maybe 80-90% of the code we’ll be writing in six years will be JS – and some new way-cool JS library, the great-great-grandkid of AngularJS, will rule supreme. But for now, I’m going to advocate with my clients a really careful look at what the SPA frameworks they’re looking at can deliver – and whether the benefits of that client-side emphasis outweighs the disadvantages of a rapidly-morphing paradigm.


 Resource Links:




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.