Back-ing into Enterprise Web Applications

Sometimes I just don't know what to blog about. Is it just me? So when I don't have anything I feel is new or original, I guess I need to go back to something old. I know I have blogged about building applications in the browser before. Maybe not on this blog, but certainly on one of the many outlets I have had over the years. This topic has come up again as I consider the implications of technologies like Silverlight 2.0 and AJAX on building enterprise applications.

I really like the browser, but I am not sure it makes a great application platform. It makes me wonder why it seems like we need all these “other” technologies to make it a better platform. Take for instance the Back button. When browsing I am a big fan of the Back button (actually I am still a keyboard kind of guy and I use the backspace key - old habits die hard). Whether you like it or not, I think you will agree it is a standard that a lot of people now understand.

So when I host an application in the browser, what does the Back button do? Or perhaps a better question is what does the user expect the Back button to do? Why would they think it would do anything different?

"Hey, I'm in the browser. There's this big, prominent button with "Back" written on it". Why would I not want to press that?"

As it turns out using technologies like Silverlight 2.0 and AJAX seem to totally ignore this. They ignore it to the extent that you lose a lot of navigation context if you use it. For instance, say I am traversing down through a hierarchy. I get some number of levels deep and I want to
back up to a previous level - hit the back button? Better not if that traversal was being done using AJAX!

By the way this is not an entirely new problem; I first encountered this problem when an application I was reviewing for a client made such extensive use of session that the back button did not do what the users expected. So we spent a fair amount of time and energy coming up with ways to preserve the Back button functionality. First we found some hack that essentially
disabled the back button (ironically, by navigating Forward). Secondly we built our screens such that they used the query string to pass some basic context from one screen to the next; so that when you navigated back the browser would pass all the context back (since all it typically saves is the URL). An additional benefit we got from using the query string was that nearly every page was bookmark-able. The only exception was when you were in edit-mode; we not try to “save” transitive or volatile states.

Couple of side notes... It seems that the Back button works much better in ASP.NET even though the context is not stored n the query string. I have not taken the time to figure out the exact details of how this is working; but I imagine it has something to do with the browser caching pages and VIEWSTATE. Noteto self - go figure this out someday. Found this interesting article to a Java Framework to handle the Back / Bookmark problem introduced by AJAX. I have to imagine that some resourceful person has done something similar on Codeplex (or alike).

There is a time reporting application (to remain anonymous) we use at my current job that makes fairly good use of AJAX. That is in the sense that it does improve the response time and interactivity of the application. The downside is that I continuously get burned by use the back button. Argg!!

On the contrary, the MSDN library site does a pretty good job of mixing the two paradigms such
that when I hit back; the “right” thing happens. Sure, neither of these are enterprise applications (in fact comparing them to one another is hardly fair) but the problem remains.

In my mind I am questioning why we are still using the browser for enterprise applications at all. I know why, but I don’t know why. I mean, the reason why it’s so attractive is that it helps in two major areas; distribution and disaster recovery. Distribution is the whole thing that got
us here in the first place. The DR aspect is something I have been realizing more and more in this post Sept 11 world where DR is something I have to consider more and more. It’s just easy to deploy the web application to two physical sites (managed by some content manager); one the primary and the other the secondary. Give a large enough pipe you can load balance between
the two and have a scalable/HA solution to boot.

By why do they have to run in the browser? Why, why why? Here is what I
propose instead…

1. Build an application as a native Windows .NET application based on a 3-tier architecture. No HTML but some technology like WinForms or WPF.


2. For the middle tier I would like to use something the Entity Framework and LINQ. I have a question as to whether I am going to have a marshalling/serialization issues with this technology.


3. The applications are deployed using something like ClickOnce deployment.


4. In addition, I want to get rid of the requirement to have a specific .NET framework installed. I like the direction the Xenocode people are taking. Basically linking the .NET Framework into your application thereby bringing all the code and the dependencies down as part of download / install.

Just thought I would put some thoughts out here and see what if anyone is
actually listening. Hopefully you also were able to hand on until this point.
Regardless it’s a place for me to vent; kind of like my diary.