JavaScript developers know the DOM API sucks: very verbose, and hairy across browsers. Some JavaScript library developers have chosen an innerHTML— approach for dynamically writing markup (DHTML). I’d argue this is just as crazy as trying to use the native DOM API.
Some [including me] are fed up with either alternative and decide to create a new API for writing markup in JavaScript:
Jeethu: “One of the sweetest parts of Mochikit IMO has been Mochikit.DOM. This is something which I’ve always missed with YUI. innerHTML is fast, but icky and it feels a little inelegant. So, I ended up writing something like Mochikit.DOM for YUI while writing Tagz. Thought it might be useful to others as well. So, here’s the mercurial repo with the code.”
Jeethu has something here; but I’m not psyched about the API design. The simple example on his blog post lacks clarity; the nested tree structure feels overly complicated. When creating a document in (X)HTML, nesting makes sense, you’re authoring the document as a whole thing. When programatically outputting (X)HTML, there isn’t a clear vision of the document as a whole. I prefer to keep with the semantics of programming when generating markup by writing meaningful statements.
At Oddnut Software, my small company (just two of us), we’re thinking about this issue with a broader vision: a unified API for writing XHTML on the server (Java) and on the client (JavaScript). We plan to open-source our project once it’s ready; we’re working out some of the final features.