4

I'm jumping back into ASP.NET development after spending the past 7 years playing manager, dba, and winforms developer. I've dabbled with a few things web related, primarily maintenance of existing webforms apps, but I haven't done anything with newer technologies. My, how things have changed!

After watching a lot of videos, reading a lot of articles, and messing around with some of the new tools, I think I must be looking at things the wrong way. I tend to think in terms of writing web apps using C# and server-side processing rather than client-side processing. I never used much JavaScript and depended on things like Infragistics NetAdvantage controls and their asynchronous refresh panel.

Is it reasonable to assume that "modern" web developers think in terms of JavaScript and client-side coding, only hitting the server via a service for data processing, retrieveal, and storage?

Improve this question
2
  • Large swaths of HTML are still rendered on the server side. But it's true that the focus has shifted to the client side for more "interactive" behavior. Wait 'till you see what you can do with HTML5. Commented May 7, 2013 at 17:16
  • 4
    It depends a lot on what type of application you're using, what you're doing, what the security concerns are, what the performance concerns are, how large your user base is, etc. Some things inherently just need to be done on a full server postback. Some things can be done in either location, and some will be more effective if they are primarily handled in browser. Commented May 7, 2013 at 17:27

1 Answer 1

Reset to default
1

As some of the commenters have mentioned, it really depends on what you're doing. Take validation--all validation that can be done on the client should be done there. It's more responsive and there's little hostility towards the developer (having a blank form returned with an error message mentioning required data was missing angered even the most docile users). Just because you have client-side validation doesn't mean the server can trust the input, though. Always remember that you don't control the client, no matter what you develop. Take special care with strings that are eventually destined for the database (you are using stored procedures/parameterized queries, right?).

As much power as there is in the client, there's a lot more in the server. Complex data processing belongs on the server. So do database queries, which get performance and security benefits from running behind the walled garden. When the client needs to interact with the server, think about AJAX and using light-weight responses (.ashx handlers rather than .aspx pages) to return just what's necessary.

Summing up the answer, a "modern" web developer knows the advantages of client-side and server-side programming and makes a decision balancing all of the concerns.

Improve this answer