Comment by simonw | Hacker News Reader

Comment by simonw | Hacker News Reader

Templating by manipulating the DOM is one of those bad ideas that just keeps on turning up. At first glance it seems like a eureka-moment flash of purity, but the practical realities of it are pretty horrible.

For any change to the page more complex than tweaking copy or maybe changing an element (a ul to an ol for example) you'll have to update both the HTML and the DOM manipulation code - killing your separation of concerns.

Even worse, you have to have a complete understanding of how what the DOM manipulation code does before you can edit any of the HTML at all - otherwise you might accidentally kill the page by changing the order of two seemingly unimportant elements, or deleting an unused div.

You'll also be forced to make all sorts of compromises in your markup to accommodate the templating layer, which will drive your front-end engineers crazy.

Finally, there are extremely useful aspects of regular template languages (like template inheritance and includes) which don't map at all neatly to a DOM manipulation engine - so you'll probably have to compromise on those and end up inventing your own weird attribute-driven template engine.

I'd suggest approaching this idea with caution. There's a reason most popular template engines are designed the way they are: practicality beats purity.

Actually, my suggestions is just to encourage template implementation and refactoring with impugnity. There are perhaps ways of refining workflow to ensure that ids and classes are perhaps changed less than other aspects of the markup and used as hooks to "animate" the templates, but any time lost fixing broken templates as a result of an incompatible change pales in comparison to the time spent going back and forth between designers and developers to fix a problem where the scope happens to fall in between 2 skillsets (particularly when dealing with people in different timezones).

I remain skeptical, but I'd love to hear about a collaborative project that used this technique succesfully

Yes I have to put my money where my mouth is. I'm thinking the best way to do this will be to take a relatively simple application and have it built entirely through outsourced labour, then I can publish a more objective (and factual :) assessment of the merits of the method.

I've never had problems with the traditional method of the developer enhancing the designer's static HTML file to make them dynamic. further down the road, it's pretty rare presentation tweaks will break the tempting logic.

However, the biggest problem I've had with any designer is the refactoring of html ids and class that breaks AJAX or jQuery code. So the remaining problem, which is the biggest in my opinion, isn't addressed in your approach. Designers still need to be aware of jQuery/AJAX application logic to avoid breaking stuff. My approach to this problem is to use and document custom HTML properties for your jQuery/AJAX hooks. However, it doesn't solve the problem of updating part of the presentation which still relies on the markup structure.

EDIT:

But you still can rely on custom HTML properties to define updatable sections. While I find this approach better, a designer can still screw this by refactoring and omitting these custom properties.

So, relying on IDs and classes through server-side DOM manipulation further acerbates the problem. It's an approach of relying on markup on the server side instead of simply rendering. It adds an additional layer of possible breakage.

Reply on news.ycombinator.com