In the previous post I gave an overview of what a SPA is. However, why would you want to use a SPA? They certainly aren’t right for every app but I believe they are a good option for many line of business apps. Here’s why …

Web rather than native

There’s more than Windows

Lots of line of business apps target windows desktop. This is because windows has been dominant for many years and technologies like .NET windows forms and WPF have allowed rich windows apps to be built at relatively low cost. The landscape has changed though - you can’t just target windows in many situations and you have to cater for Mac, iOS, Android, … A web app of course is platform independent and can be built to target desktop, tablets and potentially smartphones.

Tooling is getting better

The cost of building a SPA is probably still greater than building a .NET windows forms app - the tooling for windows forms is great! However, the tooling around SPAs is getting better and with so many big companies in the software industry investing in this area, I can see it rapidly continuing to improve.

Free / low cost tooling

The functionality that exists in Chrome dev tools today is already amazing with functionality like memory profiling that I am used to being in a paid for tool. I am used to paying for 3rd party UI components for windows desktop apps but in the web world you can get a lot for free with components like Bootstrap and some parts of KendoUI. UI Automated testing is another great example where there are lots of free options in the web world such as selenium but the tooling in the windows desktop world tends to be expensive.

SPA rather than server driven

So, building a web app is a good option, but why a SPA and why not a traditional server driven web app? It goes back to one of the reasons why so many line of business windows desktop apps have been built over the years - performance is important. Critical line of business windows desktop apps have users constantly using them throughout the day and so the user experience has to be fluid and fast. Users having to wait for a full page refresh to do the next thing wouldn’t be acceptable in many situations. Of course a server driven web app can use ajax to avoid full page refreshes which can work very well but that can lead to code that can be tricky to maintain because things like UI logic are placed sometimes on the server and sometimes on the client. This often happens when the developers are more comfortable with the server technology.

I also think that SPA’s are great for windows desktop developers transitioning to web development because the architectural patterns are similar with the client maintaining the state rather than the server. When I started developing server driven web apps, the difference in where the state was stored was a constant battle for me.

But why weren’t we doing SPAs years ago?

In simple terms, it was too costly because the tooling wasn’t there and browsers had very poor JavaScript engines in comparison to what we have now. IE 6, 7 and 8 have been very sticky as well which all have poor JavaScript engines. However, today only a very small percentage of users use those browsers today. Google obviously had the resources to build SPAs like Gmail many years ago when the majority of other companies didn’t.