The Dream: Unified Web Development (Part 1)

I’ve been tinkering with advanced web development at work (HTML5/Google Gears – stuff that not a lot of people are currently using). I’ve come to the realization that if I really want to do this right, I’m probably going to be expending a lot of effort to code things twice. It would be great if there was some sort of unified development system that would have a place for everything and put everything in the right place.

So we begin with the data storage system. For the past 10 years its been a database of some sort that stores all your information, to display or update. With HTML5 this isn’t the case anymore – the web browser can now store data (local storage, either name/value pairs or a SQL table with select/insert/update/delete commands). So now I have to manage two sets of data storage – both in the database and in each web browser. Things like database version management start to come in to play. A script is needed to migrate a web browser from version 1 to 2 of their local database while preserving any local data.

Built on top of the data is the business logic. Things like relation management (one work order with many activities), error checking, etc. But now I’m coding this in two different places – in the server language (VB.NET/C#, PHP, ColdFusion) as well as in JavaScript. I have to code it again in JavaScript because if the network, web server, or database is down, I’m going to store the data locally in the browser until all the back end elements are up and running. I don’t want the user to stop using the application – though they will enter a limited usability mode since the dataset they have access to will be limited to what they have on hand when the server went down.

Next is the rendering of the data. Turning tabular data into the pretty words, pictures and widgets you see on the screen. Again, we’re stuck with dual paths – your rendering system must work on the server, as well as in JavaScript and produce the same output. This can make code management a headache, and generally its a bad idea to duplicate functional blocks of code  (much like relational databases, you only want to code something once so you don’t end up with conflicts down the road).

Finally is the testing. Doubling the amount of code means that you’ll need to more than double the amount of testing you do. Things just aren’t linear in software programming – put another way, 9 women cant make a baby in one month.

So what would make this much easier? Well, the ability of the server to convert the code it would otherwise run into JavaScript so that rendering routines and business logic can be generated once (and then cached) for the browser. This gets tricky however, since on the server you’re dealing with bits of atomic data (several strings, numbers, etc) while in the browser you’re dealing with a HTML form or set of inputs. Wiring things up properly is another stumbling block that must be overcome.

Failing that, the system I’m developing (for a project at work) is basically a pipeline. We start out with getting data from the database and rendering it, then through a JavaScript processor that will disable all the HTMLish features (posts/link clicks) for AJAX-like behavior. I’m still stuck writing code twice, but organizing the JavaScript to behave like the server side code, I can hopefully reduce or eliminate logic errors.

Part 2 will be posted after I start fleshing out the pipeline and get Google Gears up and running.