Driving .NET/Server Side applications through strictly Client UX.

Question

I've been developing in the .NET stack for the past five years and with the latest release of MVC3 and .NET 4.0 I feel like the direction I thought things were headed in were further confirmed.

With the innovative steps the client community has in such a short period of time, it seems like the best in class apps have a UX controlled by a majority of client events. For example, facebook.com, stackoverflow.com, google, www.ponched.com :), etc. When I say client events I am not talking about a server side control wrapped in an UpdatePanel to mask the postback. I am talking about doing all events and screen transitions on the client and use full postbacks only when really necessary. That's not to say things like .NET aren't essential tools to help control security, initial page load, routing, middle tier, etc.

I understand when working on a simple application or under aggressive time constraints using the controls and functionality provided by default by .NET (or other web dev frameworks) isn't practical if the project calls for it but it seems like the developers that can set themselves apart are the ones you can get into the trenches of Javascript/jQuery and provide seamless applications that have limited involvement from the (web) server. As developers we may not think our users are getting more sophisticated because of the big name web applications they are using on the reg but I am inclined to think they are.

I am curious if anyone shares this view or if they have another take on this? Some post lunch thoughts I figured I'd fire out there and see what I got back.

Answer 1

The point about the developers who set themselves apart is definitely on target. Developers who understand the underlying technologies and can produce customized solutions for their clients are indeed set apart from developers who can drag and drop framework tools and wire up something that works well enough.

Focusing on web development in this discussion, it's vitally important that developers understand the key technologies in play. I can't count how many times I've encountered "web developers" (primarily in the Microsoft stack, since that's where I primarily work) who patently refuse to learn JavaScript/HTML/CSS simply because they feel that the tooling available to them in Visual Studio does the job just fine.

In many cases it does, but not in all cases. And being able to address the cases where it doesn't is what puts a developer above the rest. Something as simple as exposing a small RESTful JSON API and using AJAX calls to fetch just the necessary data instead of POSTing an entire page and re-processing the entire response means a lot to the overall user experience. Both get the job done, but one is considerably more impressive to the users than the other.

Frameworks are great when what you want to do is fully encapsulated in the feature set of the framework. But when you need to grow beyond the framework, it ends up being limiting. That's where a deeper understanding of the underlying technologies would allow a developer to grow outside of the framework tooling and produce a complete solution to the client.

Answer 2

I share this view. We've ironically moving away from thin client and back to thick client, although this time around everything on the client is distributed on-demand via the server so obviously the maintenance overhead is nothing like it used to be.

Rich client-side functionality not only gives you fluid, responsive, interactive apps, but has the significant advantage for large scale sites and applications of being able to palm off a large chunk of processing resources to client browsers rather than having to process everything at their end. Where tens or hundreds of millions of users are involved, this amounts to a very large saving.

I could say more on the matter but time is short. I'm sure there will be other views (assuming the question isn't closed for being subjective).

Answer 3

You are right in saying that modern web development involves technologies like jQuery (or similar libraries) and JavaScript in general.

Full page reloads are old fashion and Ajax approach is the way to go, just don't think that the web server is less used or involved than before, it still responds to the ajax calls simply it does it asynchronously :)

MVC does not support any post back actually, because there are no web forms and there is not the same model of page life cycle.