Beyond DOM
January 6th, 2008The title of this article is (of course) referring to the browser DOM. Don’t get me wrong, the DOM abstraction was a great invention. IE4 was incredibly innovative, the progenitor of Ajax as we know it today.
But as the Ajax evolution continues on, I keep waiting for a “killer” UI platform that nudges us back toward the simplicity of HTML markup. Remember that? Back in the early days of the web you wrote server-side “scripts” that generated markup on-the-fly. Some people naively thought that manually generating HTML with C/Perl/whatever was OK. Others realized that you could incorporate read-only processing instructions in the markup, rather than markup in your application code, and thus was born tools like Velocity, TAL, and other such templating systems. It wasn’t hard to see the value of these tools, how much better than the alternative, how much easier than stateful programming.
Eventually the abstractors barged in, tried to change HTML to XML, tried to change templating to XSL. And they had…mixed…success.
And meanwhile we got sick of having to go back to the server and regenerate pages every time our customers did something interesting. We wanted small, nay miniscule, updates that allow us to do more with less. And thus Ajax was born.
But what a diversion! What happened to that simple markup we used to write? The server-side frameworks didn’t have enough time to sort out their differences, to evolve to the right level of simplicity. Yet we’ve already moved on. The clarity of execution flow in generating a web page? Gone. The simplicity of learning curve? Absent.
Am I the only one who yearns to circle back?
Here’s the problem as I see it: the UI I’ve coded, what you see on the screen, is a reflection (some would call it a transformation) of the data sitting in memory in my JavaScript objects. So why is it that every time the data changes I have to go twiddle something in the DOM? Shouldn’t that just happen automagically?
Why should I have to wrap my head around two UI representations, the markup and the DOM? Markup is easy to read but captures a small sliver of the UI gestalt. The DOM captures everything else, but sits in memory. Can’t it all just be markup, so that I don’t have to spend so much time visualizing data structures whose only representation is either in code or in Firebug?
The DOM is hot property, a cool kid these days. So it won’t surprise me if this plea falls on deaf ears. But I believe that the world could use UI that is described rather than commanded, stateless rather than iterative, that puts the V back in MVC.
I can’t help but feel we’re moving inexorably in the wrong direction, bit-by-bit, and no one is noticing.
And so I sit waiting patiently, occasionally scheming…
January 8th, 2008 at 6:42 am
http://blog.phpbuero.de/?page_id=10
;-)
January 8th, 2008 at 7:01 am
[...] Mix is scheming and waiting for someone to go beyond DOM: Here’s the problem as I see it: the UI I’ve coded, what you see on the screen, is a [...]
January 8th, 2008 at 7:29 am
You are not alone…
Very nice said, a must read!
January 8th, 2008 at 8:08 am
[...] Mix is scheming and waiting for someone to go beyond DOM: Here’s the problem as I see it: the UI I’ve coded, what you see on the screen, is a [...]
January 8th, 2008 at 8:27 am
In any UI there will only be certain parts that have a direct relationship to dynamic data in memory. Additionally, this data itself will not contain the logic of how and when to present it. The ‘transformation’ of data to visualisation you speak of will have to be coded regardless if it’s translated to DOM or markup.
Client-side architecture patterns are definitely starting to emerge like they did on the server and it will only get more interesting. This is because of the mix of pure client-side, partial client-side (paged) and pure server-side data. Combine this with the possibility of changes on both sides and the need for swift synchronization and we have some interesting times ahead.
January 8th, 2008 at 10:51 am
The idea of having a transform that was a “live” representation of data, was something I worked on a lot of with my Authenteo project. I was doing client side templating, that would use a template to transform data, and as the transformation was taking place, it would register event handlers from when the data changed. Whenever the data changed, the UI was automatically updated. This was dependent on being able to track any changes to JS objects, which is not possible across browsers with native JavaScript. However, since I was already doing JavaScript precompilation using a JavaScript compiler written by yours truly, I added the ability to intercept all property changes (as with setters), and by monitoring property changes, the transform could be “live”, the UI could change automatically as object properties were modifed. Is this kind of what you are referring to, being able to have a template/markup to describe the layout, without have to readjust it for every data change?
Hopefully some day I will have time to resurrect that in open source form, but it is bummer that it relied on precompilation. If only we had catch-all setters in ES3…
January 8th, 2008 at 10:54 am
seems http://www.devguru.com/technologies/ecmascript/quickref/watch.html could be the key to what you are talking about
I use jQuery quite a bit and just off the top of my head i think it should be possible to write a plugin which allows $(”#foo”).watch(myVar) or something to that affect. If it were used every time an onscreen value is set then once your initial render is complete you could just work with the javascript and “forget” about the UI as it is going to be updating on its own. This is a simplistic example but the idea could be expanded upon.
January 8th, 2008 at 12:01 pm
@Frank: great breakdown, nice analysis.
@Menno: in-memory data structures can consist of more than just application data. In other words, the UI is often a representation of client-side, UI specific in-memory variables. It would be nice if the UI automatically reflected the state of such variables. For example, if gRequiresAuthentication happens to be true, the UI should reflect that by displaying a login dialog. Once you have that, the separation between application logic and display logic cleans up nicely.
Also, transformations can be coded in a stateless way if you’ve abstracted them correctly. Think functional reactive — transformations (animations et al) are a reflection of when the data changed and the current time. There should be no requirement to maintain state. (It’s yet to be seen whether this can be practically and cleanly. I won’t dare say it’s a slam dunk, but I’ll also argue that we haven’t tried hard enough to get there.)
@Kris: Yes, that’s the kind of thing I’m talking about. Agreed about some of the tradeoffs.
@wade: That’s the spirit. ;) Sadly, watch() is no longer supported.
January 8th, 2008 at 12:23 pm
I read this article and Frank’s article and I still don’t see what the problem is with the current system. If you twiddle the DOM objects the UI graphics automatically update. Isn’t that what you are after?
Are you worried that for a something like a table display you have normal JavaScript objects that have your data and then DOM that have the same data being displayed in the UI’s table cells? This duplication may not seem necessary for a small table but for a big table you don’t want all the data in the DOM. A huge table takes too long to render. Pehaps some of the data won’t even be shown if the table is paginated. It is much easier to have the data in JavaScript objects than have a huge DOM and manipulating it. If everything is stored in the DOM then you have to continually go looking for the data. Imagine you want a sortable numeric table. Each time you want to sort you would need to find the correct columns, pehaps use parseFloat and then sort the rows. That is much slower than having the data in JavaScript objects and just sorting those objects and having the “view” layer of the JavaScript redraw the UI.
I may be way off and not know what you are worried about but it seems the current situation of the DOM and JavaScript is pretty good. Each could be more powerful but the distribution of duties is good. Perhaps some concrete code showing the current problem and some imaginary code you want to write would make it clear what you are wishing to write.
January 8th, 2008 at 5:08 pm
You would probably like Exhibit, and vice versa. :-) For advanced use, it is more or less a client side templating engine for rendering a data model you can feed data into, for instant effect.
January 8th, 2008 at 10:27 pm
@Neil: Have you looked at Flapjax?
@Menno: Even if the domain model can’t directly drive the presentation, you can sometimes convert the domain model into another declarative structure (maybe even declaratively!), and bind the presentation to *this*. I put a couple of diagrams about this here.
January 8th, 2008 at 11:54 pm
@Ted: I think the ultimate goal is always the cleanest possible separation between application logic and display logic. People conceive of that in different ways. These days I happen to feel that explicit code to update UI objects ala DOM is unnecessarily complex, that the DOM (in code) shouldn’t be necessary, instead using markup to indicate all display logic (hopefully something that looks as close to HTML as possible). Your request for examples is warranted, I’m sure this is a topic I’ll be discussing again in further detail as time goes on.
@Johan: looks interesting, fairly domain specific. Thanks for the link. Certainly a nice solution for certain problems. The data doesn’t look “live” in the way that I’m seeking, but perhaps I’ve missed it in my (admittedly short) look at it.
@Oliver: Yes, I remember Flapjax’s initial release. Neat stuff, strikes me as theory-driven with a rough syntax. But certainly a great example of reactivity. Something like that with an eye toward productization could make a splash.
January 9th, 2008 at 2:31 am
I am using Trimpath’s JS templating engine. Adobe Spry also has intresting features with Datasets and binding…
January 10th, 2008 at 2:30 pm
If you want to write HTML to update your DOM then what is wrong with using getElementById and innerHTML? Doing this requires you take a different approach to using the id attribute to link together various elements in the page. I´ve tried this style and ended up with many ids like “tab23″, “pane23″, “tab24″, “pane24″ I also used a global delegate (window onclick listener) that looks at the id of the clicked element or used an inline html attribute like onclick=”doSomething(this.id);”. Both of these feel like the flyweight design pattern. It makes some things easier but some things harder.
Overall I prefer the more conventional methods of a regular JavaScript object for each widget in the page that knows all of it’s elements, knows how to update the elements and is registered and listening to the elements.
Both styles will work however.
January 24th, 2008 at 11:44 pm
[...] For a more technical slant on this, you might like Neil Mix’s Beyond Dom [...]
January 30th, 2008 at 6:39 am
you must try data bindings from Adobe Flex!
April 24th, 2008 at 12:09 am
Mmm. Feels to me like what we really need is a transformation engine.