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.
Hi Eric,
I totally agree that the example on my blog post lacks clarity. its something I’d whipped up in 5 minutes just before posting the entry. As far as the API design goes, I think it stems from my interest in functional programming and the server side language I’m using. I’m using python on the server side which is a little more amiable towards FP than say something like Java. So, the way I look at it, there are only 2 ways to do client side html templating, either render your templates as text and resort to innerHTML, or use DOM. And from what I’ve found, the Mochikit.DOM approach has the nicest api of all the other DOM based approches. The real beauty of this is the ability to have functions which generate individual template fragments all of which could be stitched together transparently at runtime.
Now, I understand the need for a common templating system on both the client side and the server side. And I take exactly this approach (Its relatively easy to represent the whole tree in JSON) on my project. This wouldn’t work for you on the server side, because Java isn’t as FP friendly as it could be (the lack of closures), So that pretty much constrains you to stick to the text based templating.
@Jeethu You nailed it with your point here:
With our API(s) we’re also taking this approach; having all templating being a series statements consisting of [chained] method calls. This allows us to write methods which we can delegate a particular part of the rendering to. We’re not doing any traditional text-based templating (e.g. PHP, JSP, or ASP— style), but we also don’t have an idea of a DOM or document representing the data in our templates; we’re taking a procedural approach with the ability to pass-off rendering tasks to delegated methods. Not having a DOM structure in memory to deal with holding the dynamic data saves resources and the need to translate between data structures.
When we release our APIs publicly I’ll definitely ping you to get your opinions on our approach; I feel you’re interests and way of thinking in this area are lined up with ours.