Fetch an HTML skeleton, decide what content you need, fetch that as XML, and cache it wherever you get a chance. Render incrementally.The pattern is simple:
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.Anyway on to some comments about developing these DOM applications:
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).
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.
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.
Suffice to say that patterns in this area are often ad-hoc and ripe for improvement.
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.
The initial cost of developing an application is much less than the cost of maintaining and enhancing it.
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.
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.
"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."
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.
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...
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