Since today is Friday the 13th I thought I would share my own Web 2.0 horror story.

The Plot

A dinosaur of a mega corporation decided to bring Matt and I in to work on the web component of their forthcoming product. The premise seemed simple enough: create a web view to the product data that was largely CRUD operations. When we arrived the team was already on it's third revision of the web application and it was in pretty bad shape. It was nothing we couldn't handle or so we thought.

My first experience with the app itself was the first red flag. The screen flickered erratically on page load and the layout appeared to vomit itself onto the screen. When I asked what the product was written the answer I received was: Javascript. I shrugged that off and asked what the server side backend was written in only to find that it didn't exist.

The Fight

This web application didn't have a server side backend. It was a one page web app written entirely in Dojo Javascript that communicated to a heavy set of web services for JSON data. This means that the controller and view of the application were both managed within Javascript itself.

The entire app adhered to Dojo's widget framework in a completely asinine way. Everything was a "widget" that contained other widgets that had their own widgets. Widgets in Dojo are more of a design element than they are a reusable entity. In fact, Dojo's stock "widgets" (such as Tree, Table and who can forget that nifty clock) were so terrible that we couldn't even reuse them at all.

The best example I can think of to illustrate how much this development experience sucked is the task of populating a table with results from the web services. A Dojo widget is made of corresponding js, css and html file for the view. Now since we are in Javascript land the html template for the widget is worthless. As a result the view had to be created almost entirely in Javascript using DOM element objects to create the entire TABLE object. So what would have normally been a for loop in a powerful server side view was now ten times the amount of code to just output a simple table of data. Now imagine having to generate the view with Javascript DOM objects at pretty much every point data from the services had to be shown. Another infuriating point is since Dojo dynamically loads everything you literally couldn't debug the application in Venkman or FireBug. Testing was out of the question because at this point it was impossible.

The Horror

So the development story was a complete nightmare but the end product would provide all that AJAXy goodness for the user to munch on right? Not at all. When we left the job the app took 60-90 seconds to load the view from the localhost. Remote calls to the test development server took over two and a half minutes to retrieve and process. Every time you initially tried to access the product it would take so long that the FireFox "Do you really want the script to continue loading?" dialog would come up and you'd have to hit continue. Keep in mind that this is happening on the local machine.

The web services layer that I described earlier was referred to as the REST services but didn't represent the style at all. Heres a day in the life of a data request from our application:

• JSON parameters sent to service layer
• Service layer converts JSON objects to Java object via a 30,000 line marshaller
• Those Java objects are then converted into EMF objects
• Those EMF objects are used to query the database through another layer of abstraction
• The results are put into EMF objects
• The attributes of the EMF objects are converted to Java DTO objects
• Those DTO objects are marshalled to JSON and finally return to the Javascript controller

One day the entire application literally stopped working. The reason: someone on another team decided to add the DOCTYPE tag to the top of the single html file. This bug took days to fix and the solution was to just remove the DOCTYPE altogether. The federation of stylesheets to hundreds of "widgets" we now had provided for fun and unsolvable CSS namespace and alignment issues.

Another cute problem with a one page web application is permalinks. Remember them? Those urls in the address bar that point to resources so Tim Berners Lee could share research documents. Since this app was basically a glorified bug/issue tracker permalinks matter. The workaround: place permalink and variable information after the # sign in the URL. I'm not making this up. It would query the window.location in javascript to check for changes to the url after the # sign and switch to the appropriate view. I think the delay thread slept for 100ms and constantly ran throughout the application. The hack to get the back and forward buttons to work was even more elaborate. Javascript manually inserted entries into the history to the associated permalinks by having an invisible IFRAME "loading" up the right permalink to trick the browser into thinking it went there. For IE an echo server needed to be setup to trigger a round trip to complete the tomfoolery. It took a good 3 months for another team to get these hacks working.

All of this craziness to produce an AJAX app that could have been written in Rails or Django aboard a cross country flight without any Javascript at all. At least then it would have been usable, maintainable and sellable.

The Lesson

The company had committed to an AJAX-ified web product based on pressure from above to be "more like Google." Design decisions and requirements were made by our manager opening up Gmail in a meeting (I wish I was fucking kidding). It took me a long time to finally convince him that what we were doing wasn't like Gmail at all. The kicker to this entire fiasco is that there already was a full featured rich client application and there was no reason to try and emulate that kind "rich" experience.

There is a disturbing trend that I am seeing among older industry types that are just now entering the world of web development. They think that AJAX is not only the way you have to go but a platform rather than a feature. There is so much confusion at the moment as managers are evaluating different AJAX toolkits to bet the next few years of development on. My advice is to not tie yourself to any one toolkit and to abstract javascript away as much as possible. If you don't you'll be like this train-wreck of a project which has committed itself to Dojo and an un-sellable product as a result.