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.
I think there are some misconceptions here about what htmlbars is. The templates are still string based. Precompilation still happens. There won’t be metamorph tags any longer. It’s more of an internal change than a user facing change.
This is pretty much not true anyway. It is practically impossible to build an ember app using progressive enhancement techniques, and I haven’t seen it done in practice.
In short, you will likely notice very little difference when using htmlbars apart from getting rid of metamorph tags and speed increases.
Alex talks a little bit about HTMLBars here, but the takeaways are better performance and the removal of the metamorph lib.
Since HTMLBars is an additional layer to Handlebars, you should still be able to pre-compile and render from the server. I believe since HTMLBars gives DOM fragments, loading should be faster, since there’s no work needed to convert the template for use with the DOM.
As I can recall HTMLBars will come with no addition to the Handlebars syntax, so you’re still parsing against the Handlebars spec - and that can be done with the current Handlebars lib.
Yes. There will be constraints if you don’t want to use something ala jsdom. For example, you can’t expect jQuery code to be executed. This likely means we’ll suspend didInsertElement from executing until the app has booted up in the browser. Basically we’ll have a very small “fake DOM” that just builds a string. Kinda like our current RenderBuffer.
It’s actually going to be faster because we don’t have to go from HTML string → DOM. We go straight to DOM without an intermediate representation. We also won’t create large amounts of string garbage, which will lead to less GC churn.
If you ever want to render your app on the server (for indexing by
Google crawlers or to make first loads display faster), Angular
requires you to boot an entire browser environment like PhantomJS,
which is resource-intensive. Handlebars is 100% JavaScript strings so
all you need is something like node.js or Rhino.
It might not be the same thing that I stated but it does seem to say that Ember can render on the server-side, too, but probably only theoretically.
