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.
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 :)
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.
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.
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?
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...)
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.
johnpapa
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.
johnpapa
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.
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.
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.
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.
Member
2 Points
8 Posts
When not to SPA?
Mar 20, 2013 04:16 AM|TridyDotNet|LINK
Hi.
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? :)
Thanks
Member
160 Points
10 Posts
MVP
Re: When not to SPA?
Mar 21, 2013 08:29 AM|johnpapa|LINK
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!
None
0 Points
1 Post
Re: When not to SPA?
Mar 21, 2013 08:45 AM|jwcarroll|LINK
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.
Member
160 Points
10 Posts
MVP
Re: When not to SPA?
Mar 21, 2013 08:54 AM|johnpapa|LINK
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.
Member
10 Points
9 Posts
Re: When not to SPA?
Mar 21, 2013 09:16 AM|mike.c|LINK
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?
Member
160 Points
10 Posts
MVP
Re: When not to SPA?
Mar 21, 2013 09:17 AM|johnpapa|LINK
Razor is awesome.
We pull in the client libraires because they keep the user on the client instead of posting back and forth.
Member
10 Points
9 Posts
Re: When not to SPA?
Mar 21, 2013 09:21 AM|mike.c|LINK
Wouldn't you just use caching to limit the round trips?
BTW - I have enjoyed all your courses on Pluralsight.
Member
7 Points
13 Posts
Re: When not to SPA?
Mar 21, 2013 10:28 AM|tfalkins|LINK
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...)
Member
2 Points
8 Posts
Re: When not to SPA?
Mar 21, 2013 12:15 PM|TridyDotNet|LINK
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.
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.
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.
Member
160 Points
10 Posts
MVP
Re: When not to SPA?
Mar 21, 2013 06:39 PM|johnpapa|LINK
Caching helps for postbacks, but its not nearly as effective as SPA.
Thanks for watching my courses :)
Member
160 Points
10 Posts
MVP
Re: When not to SPA?
Mar 21, 2013 06:41 PM|johnpapa|LINK
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 :)
None
0 Points
1 Post
Re: When not to SPA?
Mar 22, 2013 03:40 PM|DapperDanH|LINK
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.
Thoughts?
@DanielKHickman
www.dansgreenshoes.com
None
0 Points
1 Post
Re: When not to SPA?
Mar 24, 2013 11:08 AM|BBGONE|LINK
Hi.
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.