Just like you, I have quite a bit of experience in UI design in Javascript now. The HTML DOM provides a very neat platform for producing nice UI interfaces, although it also has its disadvantages because of browser differences. But, as you surely have found out as well, it is doable to support the most commonly used browser by sensible and careful usage of the HTML DOM, even in standards compliance mode.

The idea that you have shown here is really a framework which is built on the most general concepts of state machines. It may be handy for a beginner as an educative example, but I feel that, as general and low-level as it is, it’s still not well applicable to very advanced user interfaces. For example the action interface; it presumes that it should be undoable. But sometimes, it might save you a whole lot of work to let the undo-work be done by simply cloning the document. I know, it’s inefficient but in many occasions a better idea than putting the responsibility in an action. Especially if you expect more actions to come in newer versions.. It’s a trade-off, but in your framework there is no room for this.

Also, putting the parameters in a single attribute doesn’t feel right. It degrades code quality; I’d say it’s better to pass them into a well defined action-specific method on the object on which the action takes place, and use design by contract and careful code documentation to increase code readability.

My personal experience is that such a framework is overkill. Every UI is different, and designing them is a black art. Every time you have to puzzle with the bits and pieces of knowledge that you have obtained previous projects.

What I think would be more interesting, is to wrap up the DOM into commonly-used datamodel elements, for instance a Table, Select or List class. These can contain methods which are likely to be used (createExtraColumn(), addOption(option), selectOption(option), sortList(), etc.) by GUIs, and maintain their own references to the DOM tree. This is a bit like having a UI wrapping around a DOM branch, but using this framework you could hide away some of the cumbersome tasks for elements of the UI which are general and not standardly supported by the DOM.