Sunday, May 23, 2004


Unifying HTML and Javascript

BadBlue Web Collaboration and Sharing Tools for Excel SpreadsheetsHave been working on a bunch of new features for BadBlue that relate to Excel collaboration.

The gist of the new features are to allow multiple users -- at different locations -- to modify the same Excel spreadsheet using only their browsers. The users don't have to have copies of Excel (in fact, they don't even need to be running Windows). There are a whole bunch of features related to multi-user conflict resolution, audit logging, cell-by-cell control of who gets to see and edit what, and a bunch of other stuff.

But implementing a rich, browser-based user-interface is challenging. As more and more features were added (based upon explicit requests from users), the amount of Javascript kept going up. Need to pop up an editor window? Javascript. Want to change the colors of a table's cell or its value "on the fly"? Javascript.

The conclusion I've come to is that HTML, as a browser markup language, doesn't have much value without Javascript. Yes, you can put up a static page with HTML and omit Javascript altogether.

But if you're doing a real application, well, you need Javascript.

Why is this important? Think about the HTML and XHTML DTD's. They really have no connection or knowledge of Javascript. Nor does Javascript have a consistent view of the HTML DTD. Need an example?

Consider how you change the contents of a table cell (an instantiated TD tag) on-the-fly:


opener.document.all ? opener.document.all[sCell] // IE4+
: opener.document.getElementById ? opener.document.getElementById(sCell) // NN6
: null;
if (cell != null) {
cell.innerHTML = "something";
}


Of course, if Javascript and the HTML DOM were integrated just a little bit better,


opener.document.table[2].tr[1].td[0] = "something";


or, if the table had a name attribute (doh!):


opener.document.mytable.tr[1].td[0] = "something";


or, if the table and the column each had name attributes:


opener.document.mytable.row[1].labelcolumn = "something";


In other words, why can't the HTML DOM and Javascript be completely integrated?

More importantly, why do we care about this from a strategic sense? Javascript and HTML, each operating in their own vacuum-like silos, benefits only thick-client vendors like Microsoft. The spectrum of user-interfaces available to web application designers ranges from just-plain shitty to a cut above mediocre.

An example of a web app that is pushing the limit is Google's Gmail. It might consist of 80% Javascript and 20% HTML. It is probably the most sophisticated web interface I've seen yet. It is very well done but it still doesn't approach the seamless usability of a desktop app.

A standards-based effort towards integrated HTML and Javascript (i.e., the W3C and ECMA form the necessary committees or initiatives to state what we have... and where we should be going) will bring rich, desktop-like applications to the web.

And who (except, perhaps, Microsoft) would argue against that?

BadBlue Excel Collaboration Tools for the Web

2 comments:

Anonymous said...

But what about Visual Basic Script? Why can't HTML and VBS be integrated? Just think of the power! Ok, so I was not being serious-- but I hope you see the problem. As soon as you start giving preferential treatment to one script camp, all hell is going to break loose in the others. You also brought up another "problem" I see quite a bit these days-- people trying to implement "desktop" applications in the web environment. There are just some things best done through local client code, and no matter how good you are, trying to approximate it using a web browser WILL FAIL.

I offer a different alternative: What about designing your app as an embedable ActiveX or Java application that is simply accessed and downloaded/cached locally-- you still have the ability to control downloads, content/version, etc, and you gain all the benefits of access to a full Win32 API executed locally-- so you can do all those fancy real-time windows-based operations-- and the code can still run "inside" a browser!

About now you're saying "yeah, but my current solution will run on ANY browser, ANYWHERE!" Guess what, you're right, but using the CrossOver plugin for Linux, BSD, and Solaris (all ship it standard now), ActiveX components are compatible with just about every browser on every platform.

directorblue said...

You raise some good points. Regarding the slant towards EMCAScript-262 (oops, I mean Javascript), it's because it seems so widespread. My guess is 93% :-) of scripted pages incorporate JS.

ActiveX has such a bad security rep that it's probably not viable anytime soon. The key is markup and script, flowing together as text, from the server. Nothing hidden inside an executable (or a JVM class)... pure text...