Applications vs. W3C DOM

Lotus K-station (Portal Application)

Fetch an HTML skeleton, decide what content you need, fetch that as XML, and cache it wherever you get a chance. Render incrementally.

Database <-> XML <--> Javascript Object Bindings <--> UI Bindings (HTML) + UI management code

Spreadsheet Editor

Presentation Editor

Data model is JavaScript array; leverages the browser's layout primitives to layout pages of elements. Very much like the spreadsheet in architecture except it skips the XML and uses JavaScript array as persistent file format.

I'll also mention Oddpost.com as a great DOM application (since Oddpost is genetically related to the spreadsheet and presentation editors). This is the browser-based Outlook clone, MSIE only at the moment. The widgetry and UI experience is great in my opinion. As far as I can tell, they now mostly use IE's XMLHTTP to pass data to/from client to server.

I give these examples to simply make the point that you can implement even the richest traditional productivity applications using the DOM. This is not a comment on whether any of these applications are any good or if they'll survive. For example, K-station was a sacrificial lamb in a company (IBM) that only really understands server-side middleware. The outcome for the spreadsheet and presentation editors (like OpenOffice) will obviously depend on the accuracy of the document converters to/from Office file formats.

1. The DOM is not screen-oriented.

   This is more a historical concern and obviously the DOM is document-oriented by design. But we should realize that we're building applications on a platform where the presentation was consciously treated as an afterthought (a correct separation in my opinion, but one that has hurt app developers). As an example, it took a (long) while before Mozilla implemented a full scroll model (things like scrollTop etc) and cloned a lot of the Microsoft model; the initial reason being that these properties were not part of the W3C DOM and were MS-proprietary.

   When working on the presentation editor, I kept coming across instances where the DOM Level 2 Range spec could deal with a little more screen-orienting or standardization. I wanted the equivalent of TextRange.moveTo(x, y) in Mozilla and event.rangeParent/Offset in MSIE.

   All this to say that screen-oriented functionality is needed in user-facing applications and that the few gaps in some cases has raised the cross-browser compatibility issue. (Contrast the DOM to the richness of the primitives in Swing, MFC, Cocoa or other UI layers).

2. High learning curve for writing cross-browser code

   There are great tutorials and resources on the DOM (e.g. PPK's site, Mozilla' references, DevEdge Sidebars, JavaScript Faqs, WebFx, David Flanagan and Danny Goodman's books, usenet groups, this mailing list, even MSDN etc). Despite all this, there is clearly a lot to learn before a developer is comfortable writing DOM code. It is not necessarily getting started that's a problem; it is getting comfortable with the coding idioms that's the issue. The learning curve needs to be lowered and that's where you need more tutorials, more education etc rather than the patchwork we have. I think the J2EE and .Net ecosystems are better in this respect.

3. Historically poorer developer tooling for DOM applications

   I mention this only to contrast with the plethora and maturity of the tooling for server-side code (whether J2EE, .Net, PHP etc) and also that of more traditional client apps. It is only now with tools like Venkman and DOM Inspector (absolutely indispensable in my mind) that I can say that the tooling is good enough. This is not to knock Microsoft's Script Debugger or InterDev, but they haven't been maintained/ or enhanced. I'll talk separately about JavaScript the language.

4. It's the Latency, stupid

   When dealing with distributed applications, its the issue of latency that will determine which applications will rule. Users ultimately want applications that are
   1. fast to load
   2. capable and
   3. intuitive.
   They want all these at the same time. This is where making increased use of the DOM should shine compared to most simple html based UIs.

   There was a recent note on this list about patterns for building multiple form based UIs and that's a good start, but it's not what developers think of instinctively.

   You have to work hard when writing DOM apps to figure out where in your architecture you can do things incrementally and where to cache.

5. How to get the data model to/from the client.

   This is closely related to latency and I think is one of the biggest issues in DOM development. There hasn't really been a 'standard' good and reliable enough means of passing data back and forth between client. I've used things like hidden iframes, dynamic iframes, XMLHTTP, ActiveX, XML data islands, expando attributes on HTML elements, XHTML, behaviours, XBL, DOM Level 3 load and store etc. XML is increasingly the persistent storage format; we all like the fact that xml support in browsers is now relatively robust but there have been cross-browser compatibility issues in the past.

   One way of avoiding XML compatibility issues on the client is to bypass them and simply passing Javascript objects or arrays around. I know there are folks looking at going from UML straight to Javascript data objects.

   Suffice to say that patterns in this area are often ad-hoc and ripe for improvement.

6. The CSS Box Model requires a little imaginative leap.

   This comes down to what Mozilla has codified in its -moz-box-sizing css attribute. border-box is simply more intuitive than content-box which is what the CSS 2 spec uses. There, I've said it: content-box may be logical, and internally consistent, and obviously this is what we'll live with, but it's not intuitive. I can't count the number of times I've had a developer scratch his head when I note the "width" refers to the "content width".

   Huh? The IE 4/5 border-box model may be buggy, poorly implemented etc, but in this aspect at least is closer to 'average Joe thinking'. In any case, this requires constant education/reinforcement even for me.

7. JavaScript is too flexible

   It requires tremendous discipline to develop any moderately-sized DOM application in a team environment that is easily maintained in the long run. The fault is JavaScript: I love the language for its fast prototyping and flexibility but sometimes hate it with a passion as a development environment.

   I've spent the past 6 months trying to 'port' the spreadsheet and presentation editors to Mozilla and I would say that like Perl, Javascript can quickly become unmaintainable. In the 60,000 lines of Javascript I've been dealing with, I've sometimes found up to 7 ways to solve the same issue in the code; some approaches being incredibly powerful, 'smart' and idiosyncratic but when it come down to it incomprehensible in the long run.

   The initial cost of developing an application is much less than the cost of maintaining and enhancing it.

   As a community, we haven't codified the canonical JavaScript style guide and the language and environment isn't helping. Writing more object-oriented javascript could be an answer but it is too tempting to go with global variables and all sorts of hacks that add complexity and cause maintenance nightmares in the long run.

   I find myself wishing for build-time tools, a compiler to catch typos in variable names, to catch syntax errors earlier rather than runtime checking. By contrast, Java/C# codified a set of design patterns and constrained environment that allows developers to leverage tools more effectively.

   I've become a big fan of test-driven programming of late and I wish the Javascript equivalents of JUnit were more mature. As it is, it is down to developer discipline and constant runtime retesting.

   Not to get into language wars but I'll offer a bounty for whoever solves this issue. I want to be spoilt as much as a J2EE or .Net programmer is spoilt.

8. Do the users even want richer applications?

   Tim Bray mentions the following:

   "I can remember like yesterday a Content Management conference about 1997, a woman from a big computer company talking about how great it was when they switched their CM system over from custom clients to the browser: "It's so great! The browser is so limited, so they had to throw away three-quarters of the buttons and sliders and pulldowns and options, and just do it with hyperlinks and simple forms... it was so much easier to use."

   This I think captures a dilemma about trying to develop DOM apps. It is all well wanting menus, progress bars, standardized modal dialogs (not Javascript alert/confirm) and the whole of set of widgetry that WinForms, XForms, XUL etc are promising. Often times standard HTML components could be as effective if much uglier. I would guess that a third of my time is spent trying to deal with implementing richer widgets. Is this worth it?

9. Browser compatibility is a big hindrance to W3C DOM applications

   I think this speaks for itself, as a developer you want you application to target the widest audience and compatibility matters immensely. A side, but significant, issue in all this is whether Microsoft will compete in the DOM implementation market in the future or whether they will change the game.

   It matters that the platform with the most users has been getting crusty for the past 2 years. The users ultimately pay the bills of us developers.

10. It's not just the client

    All the apps that I've built had server-side componentry, backends can be JSP/Servlet, ASP, PHP etc. It requires a lot of foresight to move beyond the server-side and decide to go with a richer DOM application implementation. I'm always pushing colleagues at IBM who quote MVC chapter and verse to me, that if they really believed their rhetoric they shouldn't care that someone implements a DOM application view rather than the typical approach (very flat, back-and-forth refresh from the server after every user decision). In fact, having richer DOM apps often reveals problems with the underlying implementation of the architecture.

    At the same time they also make the point about cost/benefits of building DOM applications rather than either traditional html driven apps or full blown client apps. I could throw 10 entry level engineers at a Swing based spreadsheet editor and they can be immediately productive, use the same tooling as they would have used developing server side code, leverage the compiler, write JUnit tests etc. Compare that with the expertise required in implement the spreadsheet using the DOM. There's a trade-off here and its unclear which is more compelling...

• The DOM is "Good Enough".
• The tools are now mature enough (especially Mozilla's tooling). They could be improved however.
• What matters most is the ecosystem around the DOM as a platform, the tutorials, the canonical applications etc. There's a lot of work needed here before a CTO would bet a company on a DOM version of the next big thing.

Napster could have been a DOM application but wasn't, Why wasn't it?

Posted on Thu Jul 24, 2003 4:07 pm to the wdf-dom mailing list