Tuesday, January 8th, 2008

Beyond DOM

Category: Editorial, JavaScript

Neil 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 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?

Neil is looking to cycle back and see how we can put pieces together to get to a better place. I think that 2008 is the year for this. We are seeing many rich Ajax applications which need more than simple XHR requests, and feel the pain that ensues. There is room for solutions that nicely tie the client and the server in a smart way.

Posted by Dion Almaer at 6:11 am
8 Comments

+++--
3.7 rating from 15 votes

8 Comments »

Comments feed TrackBack URI

I agree, it becomes a real problem, when your UI is too complicated…

Comment by Snowcore — January 8, 2008

html state management?

Comment by Ben — January 8, 2008

This is the hard problem we run into, regardless of language… they are cross cutting concerns ;-)

Comment by Dale Asberry — January 8, 2008

I’m working on gara a eclipse swt/jface clone for javascript. So jsface is maybe the thing you want. It’s about representing javascript objects in widgets. Saving and updating is just a XHR request. Updating the UI is done by just one refresh(); method. I will send this to ajaxian soon as more can be seen, so prepared ;)

There you go: http://gara.creative2.net

Comment by gossi — January 8, 2008

A higher level DOM abstraction is EXACTLY the way in which TIBCO GI is architected so as to handle increasingly feature rich, full featured Ajax apps. Instead of working directly with the HTML DOM, TIBCO GI provides an “AOM” — Application Object Model with which you work. Then in a MVC pattern, the Model of the application is used to generate the View — and it’s the View that’s rendered via the HTML DOM. There are TIBCO GI apps out there with over 180 modules in them that run over full-workday long sessions. The abstraction to an Application Object Model makes full featured apps easier to build and manage and serves to assist with better memory management via automated garbage collection when components and data are removed. The full source of TIBCO GI is @ http://gi.tibco.com.

Comment by khakman — January 8, 2008

The XML runtime of widgetplus apps represents the state of the app at any given time, and that runtime sits on the server, and this is why the apps data remains persistent from one session to another.
http://www.widgetplus.com

Comment by Mikael Bergkvist — January 8, 2008

Yeah, this gets very annoying, but I have my own workarounds I use. Recently I have been using (and pretty impressed by) the mootools library. It’s events class is great for handling this sort of thing. Just write some simple functions to update/manipulate the DOM in accordance with custom events. So when new data is received from the server, I can have all necassary objects fire a “onDataChange” event, then just use a simple event listener to handle it.

Comment by tj111 — January 8, 2008

Recently I have been using (and pretty impressed by) the mootools library. It’s events class is great for handling this sort of thing. Just write some simple functions to update/manipulate the DOM in accordance with custom events.

@tj111:
The idea of the post is to go “beyond DOM” which is why MooTools is the kind of tool which the author wants to get rid of. No offence to MooTools.

Comment by Jordan — January 8, 2008

Leave a comment

You must be logged in to post a comment.