I’ve lately taken an interest in understanding the tradeoffs involved in string-based vs. DOM-based templating, especially related to Ember. I’m still quite a noob at this domain, so some of my questions might not even make sense
Taking my first cue from Tom Dale’s Quora reply to “Why Ember.js?”, it seemed to me that string-based templating has more things going for it than against it, namely:
- String-based templates can be precompiled on the server
- There is no need to run a browser environment (e.g PhantomJS) on the server to reap SEO benefits
- Faster boot up time
Another blog post that does a comparison between string- and DOM-based templating engines have reinforced these advantages.
The disadvantage of using a string-based templating engine (Handlebars) is that it has no awareness of the DOM and thus:
- Needs extra markup (the enclosing metamorph script tags for each bound property, in Ember’s case)
- Slower client-side rendering because of not being able to perform DOM optimizations (not sure that this is the reason)
I also read @wycats’s htmlbars doc which focuses more on the design philosophy behind HTMLBars so I am aware that there are other advantages to using HTMLBars down the line but specifically I would like to comprehend the tradefoffs involved in switching to DOM-based HTMLBars. So, in summary:
- Will server-side rendering be possible without running a browser environment? (@ebryn seems to confirm this here but I’m not sure about the specifics)
- Will initial app loading not be slower because of the DOM-based model?
If someone has more bandwidth, and could explain the “change of heart” that prompted the decision of moving to HTMLBars, that would be awesome. Again, to clarify, I’m quite excited about HTMLBars and I don’t want to argue against it, I’d just like to gain a somewhat deeper knowledge about the question.