A Rant on the State of Web Development (Part 1)

You know... the web world is beginning to surprise me- and not along the lines of how far it has come, but rather along the lines of how far it hasn't. As you may have gathered from my earlier blogs, I'm coming into this web development world fresh with only a minor taste of prior experience ending around 2000... and honestly, where are we now? It seems like we've layered hack (css) upon hack (javascript) upon hack (flash) over an existing system (html) which was clearly never meant to do what it's being forced to do today.

I mean, take any 'modern' website and look at the hodgepodge of overlapping technologies thrown together in an impressively complex manner in order to offer the minimal level of usability and convenience modern websites offer.

Feast your eyes on my old-school ascii art diagram: (which likely took less time then drawing a diagram up in visio, saving it as a gif, uploading it to this blog, and modifying the blog html not to resize it, only to realize I need the diagram at an appropriate level of zoom in order to naturally fit in the blog width, thus necessitating a few more roundtrips just to get it right... you get the point.)

**Data Sources**      ** Server Side **       **Client Side**
                                --------        ---------
-----------------                 | CSS  |        | Ajax  |
|   SQL, Oracle |                 ---/----       /---------
-----------------\  ----------- ----/----   ----/-------
                }-| Asp/Php |-| "HTML"|---|JavaScript|
-----------------/  ----------- ---------   -----\------
| Webservices   |                             ----------------
-----------------                             | Flash/S.Light|
                                            ---------------- 

You've likely got a massive amount of Asp.Net or Php on the server side just to provide the architecture, those technologies are backed by databases and datasources on the back-end, and they barf out "html" on the front end. I put html in quotes because the html is really only there as a legacy and a formality in order to provide a loose structure around the data. Numerous html elements are tagged with class and name attributes for the purposes of supporting css (to be discussed next) and tagged with 'ids' and reference points for the purposes of working with javascript.

Once you've got said data, you then use CSS to "style" the html. This 'styling' includes coloring the html elements, rearranging them (often intentionally ignoring the structure provided by the underlying html), and even hiding some html for the purposes of later unhiding it via javascript.

Javascript is the ultimate hack's delight. With javascript you can completely change any portion of the html/css beast you've generated. Need a last minute fix? Want to move some elements around or hide/unhide them? Want to open up a new window and hide it under the existing window to display an obnoxious ad? Javascript is the answer.

Theoretically, you dont even really need the html or the css in the first place- provided you got the data to the client's browser somehow you could just build it on the fly... which brings me to Ajax.

Ajax is actually pretty darn cool- it's the best misuse of a quirky javascript feature to happen to the web world hands down, and it's the closest thing that exists to where the web is headed... the only problem with Ajax is that it still needs to spit out html, css, and/or even more javascript in order to get its job accomplished. It's difficult to accomplish anything truly revolutionary in ajax without going through enormous efforts in complexity.

And then you have Flash, Silverlight, ActiveX controls (still not dead), and the other stabs at embedding little pieces of flair into the aforementioned technological mess which is the meat of the web. Proprietary quasi-standalone languages developed to be built into a web architecture which didn't really want to have them in the first place.

Looking at so many overlapping layers of legacy adding so much complexity, the obvious answer is to throw it all away in exchange for a solution which is designed to provide rich content from the get-go... and in my next blog I'll take a stab at what I think a better approach would be.