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.
- 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.
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 }
[+] [-] moocow01|13 years ago|reply
- 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|13 years ago|reply
- 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|13 years ago|reply
I really like the pitch to "Reduce the number of moving parts" at the cost of small learning curve.
[+] [-] sylvainpv|13 years ago|reply
Also, I suggest namespacing all of your functions and using with(YOUR_DOM-O_NAMESPACE) { your dom construction here }
[+] [-] powatom|13 years ago|reply
[+] [-] mithras|13 years ago|reply
[+] [-] jedschmidt|13 years ago|reply