When not to SPA? RRS feed

  • Question

  • User1287266061 posted


    Could someone think of a scenario for the web project when one will not want to have a Single Page Application?

    It seems that there is always a tendency to go that way. Probably the things that make it harder (at least for me) is that you need extra tools,  like JavaScript, Ajax, it is harder to debug etc. and compared with the plain MVC, for example, it's not that easy.

    All of the browser plugins (Flash, Silverlight) headed that way and now HTML5 seems to be oriented towards SPA as well.

    So, why would one *not* want a SPA? :)


    Wednesday, March 20, 2013 4:16 AM

All replies

  • User-478932704 posted

    One example would be a web site. Lots of static data for presentation in regions or areas. This could be done with client side templating, but then you lose a lot of SEO too, and web sites are often were SEO is important. (In contrast, a SPA for a banking app is not a place you'd want SEO). So there are 2 examples: web sites and any place you need SEO badly. There are ways to do SEO in SPA, but its not a natural fit.

    The big reasons to do SPA are the 3 R's: Reach, Responsive UX and Reducing roundtrip postbacks.

    More reasons to sway to other tech instead ...  If you don't need to reach anything but iOS, writer an iPhone app. If you just need Windows 8 devices, write a Win RT app. If you need WIn 7 device integration, choose WPF. If you need need a web app that has tons of reach, ASP.NET MVC is good too.

    ASP.NET (webforms or MVC depending on your persuation) are excellent choices and compare well with SPA. SPA has the added advantage of being able to run against multiple back ends (PHP, Java, ASP.NET, cloud, etc) and can be more responsive.

    2 places SPA can really improve, IMO: tooling and guidance. Tooling is actually pretty good right now, but its too much of an art and hard to discover how to do it best. There is room for that to become smoother, ideally in the browsers and in Visual Studio (you need both). The guidance is out there, but there are so many ways to skin this cat that it often confuses developers. Many just want the field narrowed for them with a quick pros and cons list of each approach. There are also many who just want to be given a prescriptive path to build a SPA. I'm trying to help with a few different approaches to guidance, but of course if you want that path you have to take for granted that you also get my opinions :)

    Hope this helps!

    Thursday, March 21, 2013 8:29 AM
  • User1546851329 posted

    One approach that doesn't seem to get talked about a lot is a hybrid application.

    A hybrid approach can be used where major areas of functionality are treated like miniature SPA applications within the larger whole. A good place where this can be effective is a corporate/enterprise application. The idea is that each seperate functional area is an entire page refresh, but sub-navigation within that area uses SPA techniques (routing, templating, etc...) to keep the application responsive.

    This eases the burden slightly of a full SPA while still giving you the benefits of a responsive experience to the end user.

    Thursday, March 21, 2013 8:45 AM
  • User-478932704 posted

    jwcarroll - exactly. hybirds are a nice options. This is why I love using ASP.NET with my SPAs: I get the option of using the skills I know well for many years in ASP.NET and its very mature style with the responsiveness and reach of SPA. You can make "mini SPA's" in ASP.NET too.

    One place to be careful of though is when not to do too much model binding and knockout/templating/ajax injection of data in the same page. It gets hairy and really, its just as easy to just use client binding instead of tyring to synch the two in the same spot.

    Thursday, March 21, 2013 8:54 AM
  • User-1227381095 posted

    Since you have to import so many other packages for the UI, is it a stretch to say that the Razor view engine is somehow deficient? Or are you just trying to hit all the different back ends?

    Thursday, March 21, 2013 9:16 AM
  • User-478932704 posted

    Razor is awesome.

    We pull in the client libraires because they keep the user on the client instead of posting back and forth. 

    Thursday, March 21, 2013 9:17 AM
  • User-1227381095 posted

    Wouldn't you just use caching to limit the round trips?

    BTW - I have enjoyed all your courses on Pluralsight.

    Thursday, March 21, 2013 9:21 AM
  • User-703805802 posted

    Do either of your PluralSight courses on SPA talk to this hybrid scenario? Or is there not much to say about it beyond you said here? (Already through the first two modules on the Jump Start but work has gotten in the way...)

    Thursday, March 21, 2013 10:28 AM
  • User1287266061 posted

    I see. Probably a hybrid of MVC with HotTowel looks like a most flexible choice. I do enjoy that John Papa did the homework for me and has put together the libraries and tools needed to build SPA apps with VS.


    The big reasons to do SPA are the 3 R's: Reach, Responsive UX and Reducing roundtrip postbacks.

    I believe that defines one of the (if not the) most important aspects - user experience. So, we probably could say that the majority of the web applications on the web would benefit from that.


    If you don't need to reach anything but iOS, writer an iPhone app. If you just need Windows 8 devices, write a Win RT app. If you need WIn 7 device integration, choose WPF. If you need need a web app that has tons of reach, ASP.NET MVC is good too.

    That's where customers go nuts and want to be able to access everything from everywhere  - Desktop, Citrix, iPad, you name it. There is only one way to go then - Web.

    IMHO, for the enterprise, I believe that building a separate [thin] client for each platform is a better, more flexible (and maybe even faster) way to go, but that's not really related to this topic.

    Thursday, March 21, 2013 12:15 PM
  • User-478932704 posted

    Caching helps for postbacks, but its not nearly as effective as SPA.

    Thanks for watching my courses :)

    Thursday, March 21, 2013 6:39 PM
  • User-478932704 posted

    Both courses cover some ASP.NET and use several features from it. I don't cover creating mini  SPA's in ASP.NET though, as that is a bit more involved than I had time for in the courses. It is on my list of requests though for a future course. But yes, my courses both use ASP.NET with the SPAs.

    Thanks for watching my courses :)

    Thursday, March 21, 2013 6:41 PM
  • User875518210 posted

    This is a great discussion and very timely for my team.  Probably timely for alot of Silverlight teams :-).

    Here are my still learning thoughts and look forward to someone pointing out some flaws in my thinking...

    A large LOB application will contain multiple logically separated modules.  Each module can be a SPA or a traditional ASP.NET MVC4 app or whatever you are good at.

    For my team, we feel a MVC4 app will be easier to maintain and quicker to develop given our experience levels right now.  With time, we feel we can make the development times of SPA versus MVC4 equal to each other.

    Modules that have logic that need to run on the server (Sign In, Registration, complex LOB business rules, etc) are good candidates for NOT being a SPA since you have to go to server anyway.

    Modules that users infrequently use and/or do not demand the speed difference between a SPA and server generated HTML are candidates for NOT being a SPA.

    Modules of a LOB that users spend the most time in make great candidates for being a SPA.




    Friday, March 22, 2013 3:40 PM
  • User-740364976 posted


    I think that after the new framework JRIApp framework have been released you can create HTML5 applications almost like it was done in Microsoft Silverlight. This framework was specially designed for creating Line of business applications. It is more powerfull than Knockout.js and Breeze.js combined. You can watch video on YouTube. It is integrated with server side data service and has very powerful data binding syntax.

    Sunday, March 24, 2013 11:08 AM