At the moment I'm supposed to be evaluating a set of asp.net pages that a third party has developed as tools for one of our clients. I'm pretty new to asp.net, so while I understand the theory there may be some practical limitations I don't understand yet. Like things that sound good in textbooks but don't work in the real world. So here's my question:

Do people use post back in the real world?

The reason I ask is that almost the entire application is written using JavaScript with not one "runat=server" anywhere. This has the effect of making all the common code used by multiple applications (of which is most of it since it's a generic "tool" and not an end application) very convoluted. Instead of being able to inherit functionality and encapsulate the code properly, everything ends up in these really long JavaScript functions with switch statements spanning hundreds of lines. At the very least this seems to me to be poor design, and more than that it appears to be functionality that could be handled server side rather than in the client (thus leveraging the object-oriented nature of vb.net or c#.net rather than the limited nature of JavaScript). When I asked the developers about this they waived me off as naive and said that they did it this way to "limit trips to the server". However, limiting trips to the server is not (to my knowledge) one of the requirements of the application and the developers using the tools are tripping all over each other trying to edit the common files because they’re so big and convoluted.

The assertion is, however, that post back and server-side coding is a nice dream but no one really uses it because it's inefficient. Is this true, or are they just trying to justify a poor design? I just don't want to take a hard line stance saying that they need to move stuff server side and then find out that this brings in some problems a more experienced developer would have known to avoid.

It really depends on the exact usage. If it is to be run on a Internet website with lowish traffic or lots of hardware to throw at it then post back is fine.

However if it is a high volume Intranet application then it can make sense to push as much code to the client side as possible. In an Intranet you have control over the client, so don't need to worry about Javascript/DHTML compatibility problems. Moving code to the client side cuts down round trips to the server and can really help things scale better to thousands of users.

I personally don't like the postback design of ASP.NET, it is aimed at people who don't know any better. It fine for small stuff, but you need to be careful if you want it to scale, you can make a real mess if you don't understand the implications of repeated postbacks.

That said you can also create a steaming pile of poo with client side Javascript...

I write big Intranet apps, targeted at IE6, using lots of Javascript and XMLHTTP calls to send data back and forth to the server.

The problem I see with Javascript is headache of making it work with all browsers/future browsers. Even in a single browser world, things like popup blockers and other ad blocking can wreck havok on javascript.

It also is all client side, meaning you trust the clients not to tamper with the code to do some weird things. Is the server side trusting what comes back 100%? It shouldn't. With all the effort of maintaining javascript and checks, you have now lost most of the benefit of trying to be client side.

Good feedback so far guys. This stuff really helps. Coming from a thick client background means I know a lot about the languages and principles, but there are some concepts I've still got so much to learn about in the world of web programming.

So far it sounds like my concerns are probably valid, though perhaps not my first guess at a solution. To that end, how would you handle the problem? To state it specifically: there are huge chunks of JavaScript in the common files where the code has to distinguish between appications in order to function properly. This is difficult to maintain and has (along with good dose of non-testing) resulted with applications in production being broken due to changes made in other applications.

An example of this is
if thisapp ...
else if thatapp ...
else if someotherapp ...
repeate a few dozen times.

Then do it again for various functions. This goes on for about 3000 lines of JavaScript in one instance all to draw the correct options on a toolbar.

Now normally in the thick client world I would create a class for the generic behavor and then seperate classes for each app so that code is grouped together logically. That would keep people from messing with the main base file all the time and blowing up other applications (which is happening). In the toolbar example you'd have a generic object that can contain buttons and might even have a few generic ones (close, load document), but each inherited toolbar could then add whatever buttons safely without affecting any of the other applications' toolbars. I know this could be done by moving all of the code server side, but are there other options or things to think about?

Thanks again in advance. With a little more help I might actually sound intelligent when I make my recommendataions on all this!

Oh, and let me add that these applications are large but mostly used in controlled environments. They are not public accessable, though the users are not all located locally (they are spread out across the US).

That does sound like a fairly poor implementation. If you had given the same developers ASP.NET to use instead they would have turned out the same poor design though.

There is nothing fundamental in Javascript that makes people code like this. Javascript is actually a very flexible language. It might not be obvious at first, but you can actually build "proper" classes in Javascript (at least as "proper" as you can in things like Visual Basic). There is even a form of implementation inheritance that you can use.

If you want to find out about the classes and OOP-ish features of Javascript, take a look here:

http://mckoss.com/jscript/object.htm
http://www.codeproject.com/aspnet/JsOOP1.asp?df=100&forumid=29873&exp=0&select=686931

Even in a single browser world, things like popup blockers and other ad blocking can wreck havok on javascript.

Too true, we have been patch Intranet apps recently to make them work with WinXP SP2.

It also is all client side, meaning you trust the clients not to tamper with the code to do some weird things. Is the server side trusting what comes back 100%? It shouldn't.

This is no different though to the position with a tradition forms based postback app though. In both cases unless you can trust the users (which you can in some Intranet apps) you have to validate the data on the server side.

It can be very difficult to convince customers that server side checking is needed and to be honest I have yet to come across a malcious user of any of the Intranet apps I have been involved with.

I do remember those early days of Internet commerce, where lots of websites' shopping baskets trusted the data coming back from the client. I often found sites where you could chose what price you paid for goods. I sent a few friendly emails to website owners pointing this out, rarely got a response. Good job I'm honest...

Those are good links. I'm not sold on client side scripting for this yet, but those articles do offer a different perspective and illustrate some features of JavaScript I didn't know about.

When you combine decent Javascript with calls to the Microsoft MSXML component (or the equivalent one in Mozilla) to make web service calls to the server you end up with completely static client side DHTML pages that fetch their data in to form of XML from the server. This means you end up only downloading the UI layout once and then fetching the data to go in it. Much better than dragging the data and the UI layout down to the client every time the page reloads.

It also provides a nice clean break between your UI code and the web service data access code. A side benefit is that other apps can then call the web service code as well.

Another thing it does is allows you to cache large data sets on the client side. For example one of our apps has a hierachical tree of users, which on some customer sites is 10s of thousands of nodes in size. Because we use the client side Javascript approach we can pull across the part of the tree we need and cache it in the client side pages so we don't need to get it again (we have timed caches that expire after a certain time).

With just a handful of server side pages to call to access data it also makes i easy if you find you have to use HTTPS to encrypt your data, because then you only need to encypt the pages that serve out the data and leave the rest in the clear.

In our apps the web service calls all tend to use the same common code, allowing us to piggy back debug and performance metric data when we need to monitor how things are performing.

N.B. the web services don't have to be fancy, most of the time there is no need to go as far as using something like SOAP.

The end result (as long as everyone has half decent client machines) is a faster responding app that puts far less load on the server than a tradition "post, post and post again" app.

At one point I planned to design a framework of ASP.NET controls that generated code like this by just placing the controls on the form, but I never got round to do it.