

Rendering templates obsolete - jedschmidt
https://gist.github.com/3916350

======
moocow01
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.

~~~
jedschmidt
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/>

------
ajitk
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.

------
sylvainpv
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 }

------
powatom
This is a maintainability nightmare.

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

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

