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.