At the Meteor meetup last week, David Greenspan outlined an interesting approach to how Meteor UI separates the "template-parsing" logic from the "rendering" lo

At the Meteor meetup last week, David Greenspan outlined an interesting approach to how Meteor UI separates the "template-parsing" logic from the "rendering" logic with an intermediate representation (in Javascript) of the steps you need to take to produce that HTML. Check out the video (relevant slide is at 16:47, but the entire talk is awesome): http://www.meteor.com/blog/2013/11/06/david-greenspan-at-devshop-9-meteors-new-rendering-model http://www.meteor.com/blog/2013/11/06/david-greenspan-at-dev... The cool thing is, other template languages (like Handlebars, Jade, etc.) can compile to this intermediate representation, which then gets rendered on any updates. If the front-end community could agree on a protocol for how to represent these steps in, say, JSON, then we could be on our way to a world where you could use any rendering engine with any template library, on the client or the server. That is, if the community could agree on a representation :)