Attention: We are retiring the ASP.NET Community Blogs. Learn more >

Towards more processing at the client-side

Note: this entry has moved.

Currently at my day-job, we’re architecting a framework to make ASP.NET a better ASP.NET. Basically, this fx is being used by developers to port just too many intranet/internet web applications to the .NET universe, for a just too big worldwide company. One of our key goals while architecting it  was to move as much processing to the client as possible; we did a lot of work in this regard, which involved providing a client-side framework and lots of enhancements at the server-side to actually take advantage of it.

Current versions of ASP.NET don’t really make the browser do much JavaScript stuff at all which translates to writing all your code at the server-side and having to cause a postback for almost anything you want to process. But life would be much better if -whenever possible- no postback occurred, or at least just a “soft” one (more on this later).

Do you think you really know JavaScript? Take a look at the inner workings of a project like Tibet, and think again. It would be really useful to count with some base library at the client-side to make interaction between the different controls and the page simpler (abstracting you from browser-specific related issues) and cut as much as possible the dependency on posting back to the server. Of course this would require developers to have some understanding of JavaScript beyond the alert function… but it would definitively pay in the long run.

Moreover, the Microsoft XMLHTTP component (or Netscape’s verbatim XMLHttpRequest) can really help in avoiding entire postbacks and ugly UI refreshes at the browser to happen (yes this is what I previously referred as a “soft” postback). Keep in mind that today every control that fires a postback, causes the entire form collection to be posted and lots of processing to happen at the server-side; two particular expensive things that are really not necessary all the time.

 

5 Comments

  • I was the architect for a client-side Javascript library for my company that grew into something really cool - theoretically. A preprocessor would allow the use of classes, inheritance, events, etc. The whole OOP stuff, translated into Javascript code (Javascript objects and the prototype mechanism can be very powerful).





    We had e.g. classes for buttons, input fields, a combo box (yes, in HTML) and everything worked in almost any browser. The source code of an app was really cool to read, too.





    But in the end we ran into too many problems. Every browser sub-version, bugfix release, would break something in the least expected way. The use of the back/forward would break things, too. We managed to solve this and other problems (e.g. the infamous Netscape resize bug) with more and more technology, but as the amount of clever code grew, the application got less robust if people did what they were used to in the web: stop loading a page because they got impatient, going back, press reload, etc. Timing became an issue too.





    We now have a rock-solid technology. Even very critical customers who try a lot of things to break the app acknowledge the robustness. We're completely server-based now (no it's not ASP[.NET]) and most importantly, NO CLIENT SIDE CODE.





    Trust me. Client code in the browser? Don't do it. Things may be fine in the beginning. But at some point in time things start to go wrong, very wrong...





    Roland


  • Roland, the failures of DHTML don't necessarily mean that all clientside work will similarly fail, true...?





    Victor, do you think you'll handle this client/server balancing by waiting for CLR to be widespread, or will you use something current like specifying IE6/Win or the Macromedia Flash Player? Or are you actually doing complex scripting to the visitor's choice of browser...?





    Regards,


    John Dowdell


    Macromedia Support

  • Roland, thanks for your comments. My experience has been all good. We've our fx up and running pretty well and it is stable. Of course there are quite a few gotchas to watch out for, but I'm a firm believer than code should take advantage of rich browsers.

  • John, actually we're using just JavaScript code (complex one!) and it is working very well. We're supporting IE4+, Mozilla and NS4.06+. We've base classes to support control and page interactions (whenever possible we tried to follow the current ASP.NET model to ease the learning curve), a "soft" callback mechanism, JS-rendering adapters, I18N support, etc.





    Re: the CLR being available on every desktop/device -- that would open up to brand new possibilities, but its just not available today.





    Re: Flash player -- I've to admit I'm a bit ignorant of that techonology to really have some useful thinking about its chances.

  • victor, i identify with you on the need for more client-side processing... i've been working on that with flash lately.... on tibet though, it looks|sounds like flash wrapped in a new name|platform to me :)

Comments have been disabled for this content.