Also it's probably worth to mention that manipulation of DOM is not that fast. Every performance optimization article starts with "don't manipulate DOM directly, make a batch of your changes and then inject them in one step".

I don't see any reason for JSDOM in the server to be slow, the object tree being manipulated isn't all that complicated. They aren't suggesting the typical mess of putting useless markup on the wire and then conducting massive repairs to it in the browser's DOM, all while a rendering engine tries to repaint each change.

Seems like the complexity of the client-side code comes from rendering the DOM tree based on the CSS and constraints of the drawing area, hardware, etc. So yeah, just manipulating the tree would seem to be pretty fast.

Of course, it's being compared to spitting out an arbitrary stream of characters to the client without the need to parse HTML on the server side, which is probably faster. Years of experience with the string rendering approach tells us it's definitely more error prone. For example it's impossible to tell whether the character stream is well formed HTML without traversing all the code paths.

that's subjective (unless you can post tests). for example, one of the primary deficiencies of the dom is live node lists, which is an optimization option in jsdom. (also, we do create a fragment and then attach, as perf opts state)

I'd argue that this isn't really that dissimilar from most simple template engines. It's basically substituting class names for placeholder syntax, though with a bit less flexibility for things like repetitions or conditionals. Though I'd agree that I'd rather just use something like Mustache than this.

I think he just wants to separate the presentation from the logic, which might be good when you don't trust designers re-jiggling things, and you want clean code. Plus, if you're working with a lot of AJAX, it's nice to be able to reproduce the presentation on the server the same way you do it on the client. I suppose keeping the two in sync can be difficult, which is why you probably would only want to render on the server on the initial page request.

How do you rationalize including logic in the markup?

Presentation logic requires logic. If a designer decides to display a bunch of items as three columns rather than two columns, or to switch the display for a single item vs a number of different items, that's presentation logic. Ideally it should go in the template, if that's where you've chosen to keep it.

With Django, I often find myself writing view logic to support specific presentation tasks (regrouping items in a manner more complicated than Django's {% regroup %} template tag allows, for example). This used to bother me, but then I decided that pragmatism beats purity if you actually want to ship anything.

I'd have to agree with you, for most traditional web applications.

When you start to build single page applications with lots and lots of states ( that are bound to a DOM ), this approach actually can become favorable since your "presentation logic" is browser-side JavaScript.

To my understanding, the server-side rendering aspect of this approach is really just an after-thought. You have your single page application, but you can still render a server-side snapshot of various UI states without requiring a browser.

While I wouldn't necessarily dive straight into DOM-based templating, I think there is a lot of room for interesting improvements in this area. I'm glad to see JSDOM maturing.