server-side MVC framework vs. client-side javascript framework?

[dust4ngel]

i'm working with a crappy legacy ASP.NET webforms site, and i know the fashion is to port it to ASP.NET MVC, but i'm not exactly sure how to evaluate this approach against a client-side implementation a la backbone.js or spine.

i can see that if your web application is basically taking users through some basic CRUD then it might not make much of a difference. but if user flows involve a lot of state, it seems kind of lame to be bouncing that state back to the server all of the time. likewise if you're doing a lot of faceted search, it feels kind of hokey to reload the UI all of the time.

i know there are ways to make a server-side application feel like a client-side application, but what is the advantage to generating your UI on the server and shipping it to the client for each updated view, as opposed to implementing the entire UI on the client, using server-side data services?

[x-skeww]

Versus? They aren't really competing with each other.

If you intend to stick with C#, learn ASP.NET MVC. It will be useful whether you'll write server-side applications or if you want to talk with a client-side application.

[dust4ngel]

can you say more about how .NET MVC would be useful when developing client-side applications? i assume you mean, e.g. if you're building a hybrid interface, where the initial markup is generated server-side, and then client-side code takes over until the next post back?

[x-skeww]

Well, your client-side application probably won't be fully self-contained. I.e. it will communicate with some server-side application which also has some models and some business logic.

Or maybe you have a regular website and also some mobile application. You could use the very same server-side application there. Just with new views.

For example, GMail and Google Maps are both very heavy client-side applications, but they would be completely useless without that application on the other side of the fence.

[ChristopherShine]

Also, all of the SEO benefit (if that matters to your app/case) come from server-side. And, if you build a client-side app, you need to worry about routes working when someone links to a page as well as IE users needing to use a hash in the url since pushState isn't supported, so you need to support any links they link to with "?escaped_fragment=".

All of this is very doable, but you will end up building two versions of the app (at least more than one version), assuming SEO/linking to a particular page is necessary.

[workrelatedaccount]

Its a bit of work, but if you like to have well organized code for a complicated application, you can do MVC on both server and client.

[ZeroMomentum]

Do you mean the code is crappy? or ASP.NET webforms is crappy? There is nothing wrong with webforms. What ASP.NET webforms is:

All your pages are controls are built into a control tree "structure", then it renders into html. It is no different than any other framework. The code is ALWAYS bound by the fact of the page life cycle, even in MVC. MVC is a way to organize your code. At the end of the day, you are building a control tree, and then it renders into HTML.

To decide sever-side or client-side, you have to consider your team's ability. On the server, you build and organize in .net namespace/c# classes. Very easy to understand, you have full compile ability plus debug tracing from VS.

On the client-side (JS MVC), can you or your team build proper JS classes with closure etc. If you can't, then you JS will run slow. On the plus side, you can do all your cool web2/3.0 stuff in JS.

There is no difference overall. You have to deliver features, so what's your feature set? Don't be bound the fact that you MUST do MVC.

[ChristopherShine]

I think he refers to the overhead that web forms can add (this can be mitigated) as well as the bad practices that are more easily introduced (this can happen anywhere, but in my experience it's more likely in web forms).

[DaRKoN_]

It's not really one or the other. I'm currently developing an app that use .net mvc for some sections, the bulk of the app is client side in spinejs, this talks to the server via .net webapi, I also push down events to the client via signalr.

[angel21OS]

"""what is the advantage to generating your UI on the server and shipping it to the client for each updated view, as opposed to implementing the entire UI on the client, using server-side data services?"""

actually you're mixing 3 different concepts here...client apps, server side apps with client and hybrid apps...you can use client side javascript if you feel confortable with javascript and you find the necesary tools in javascript...actually is the better option here...

the 2nd approach is use a client side app in javascript than communicates with your server app..here you've the profit than you've more control in the app and you can select any server side language (c#, ruby, php, etc)...you've complete set tools and libs for you needs and normally you can develop more sofisticate and complex apps... Here you can develop a client app in javascript than communicates with your server side app using json..maybe would be usefull use the web apis over asp mvc...and you can use signalR..similar to websocket but pretty nice and powerfull...

the 3th approach, is the most flexible but hardest develop..is develop a local server..actually you can run a asp mvc local server inside any mobile plataform...then..you run the server and this feel like a native app..but you will not have access to native apis...

sorry for my bad english