Rendering templates obsolete

https://gist.github.com/3916350

by jedschmidt • 14 years ago

23 7 14 years ago

gist.github.com

mithras• 14 years ago

How do you use this when different people are responsible for the layout/design and the js?

jedschmidt2• 14 years ago

You can still preserve modularity by pulling styles and markup into their own JavaScript modules and requiring them as you would any other module.

ajitk• 14 years ago

I like it. Saw a similar approach in Firebug's domplate. dom-o looks cleaner.

I really like the pitch to "Reduce the number of moving parts" at the cost of small learning curve.

moocow01• 14 years ago

I think there is some value here but I also think its too heavy handed - the bads I see are...

- Performance - complex DOM structures will inevitably lead to many function calls. Some might argue that it is probably minor but there are going to be many many instances where a dom element is being reconstructed on every render where it could simply have been just a plain string.

- Readability - perhaps its personal but I find the readability of what is essentially going to be an extremely long statement in JS to be inferior to well formatted XML/CSS

- Error recovery / exception handling - seemingly if one of your elements/function calls goes bad your whole template is likely dead. Perhaps this could be seen as a feature.

- Namespacing - to cover all of the features of HTML you'll likely have to have quite a few functions declared and there is potential for an inadvertent overwrite. ex. var VIDEO = function() { return "Ooops, I just killed my video elements"; } On top of it there is risk of not being backwards compatible with older created templates as the HTML spec progresses and new functions need to be added. The simple solution is to namespace all your HTML functions but this is another layer of stuff and detracts from the simplicity.

jedschmidt2• 14 years ago

These are definitely good concerns.

- Performance: It's about half of Underscore.js on Webkit[1], so it's not so horrible, and has yet to be optimized at all (such as by using document fragments, etc.)

- Readability: The JS statement here is only long to show a unified example. Since the inputs and outputs of each call are DOM nodes, everything is trivially composable, something not possible with XML/CSS.

- Error recovery: Yes, having seen the error output of things like LESS, I see this as a feature.

- Namespacing: Absolutely agree. I think this is best solved the way jQuery and other libraries do it: pollute by default, and then let the developer "opt out" using noConflict.

[1] http://jsperf.com/underscore-vs-domo/

powatom• 14 years ago

This is a maintainability nightmare.

sylvainpv• 14 years ago

That's really interesting for HTML, as DOM manipulation in JS became essential. But I'm less convinced about putting CSS here (just as I won't do with any other templating system). What about media queries, browser or device specific stylesheets ? And readability, after all

Also, I suggest namespacing all of your functions and using with(YOUR_DOM-O_NAMESPACE) { your dom construction here }

Rendering templates obsolete

Related Stories