gistfile1.txt

Exiting the dark ages of strongly coupled templating. 

Remember "Classic ASP" or "Java Beans"? they never really understood the concept of the DOM.
They chose to ignore it and just stub in some placeholders like <%=myVariable%> for server
generated content then just rewrite the file.

These days, not much has changed, there are lots of templating engines. I think choosing a
templating engine with JS these days is like choosing between a fast car and a fast car. IMHO,
the most important thing to look at is the concept, not the performance. Sure you could go to 
JSPerf and test how many milliseconds of difference there is between their compile times. But
with the advancements of JS implementations, compile time is becoming irrelevant. Also, if it 
takes too long to compile, there is probably too much templating happening and not enough 
semantic HTML, too much logic, maybe even some over-abstraction. We need to think less about 
~milliseconds and more about the big picture.

Enter the "Separation Of Concerns" principal. As soon as you take something thats non-standard 
like ${x} or <%=x%> and put it in the markup, you have mixed metaphors, you've muddied the 
water.

It doesn't matter what rock-star developer created it or how optimized it is, if it's 
sprinkled into the markup, its going to become problematic. Try handing your new brand of 
markup back to the potentially confused designer and say, "re-hash this with your whiz-bang-
brand-x-awesome-IDE and get it back to me by noon". Most likely your if-else logic and 
variables are hosed. The idea is that presentation and logic live separately and safely. 


Enter Node.JS and server side JavaScript. One of my favorite projects to use with node has to 
be JSDOM. With a few simple lines of javascript and a single require, I can use jQuery to 
manipulate an HTML file on the server side before it gets served up! Since I can access #myDiv 
with out needing a ${placeholder} then I don't ever need to trash the markup.

I think you kind of touched on the reason I'd disagree with you when you said, "[Classic ASP and JavaBeans] never really understood the concept of the DOM." To my mind, that's exactly right and exactly as it should be. The server's picture of the document should be as close to "this is a giant string I don't care about" as possible.

As long as webpages are used to display data, I don't think there's any perfect separation of concerns possible. Say you're using the DOM to insert your data, instead of a template. When you hand your code to the same designer and they mess up all your IDs, nesting, and other selectors, your logic is still hosed.

Finally, I don't think adding template logic to HTML is trashing it. On the contrary, I think it makes that code self-documenting and provides a clearer picture of how the page will actually render. In the end, though, how you approach the problem of rendering data ultimately depends on the needs of your application. You may have a situation I've never encountered where it makes sense. But for the use cases I've seen, I still prefer templates. :)

@garann Thanks for the response!! This is a fascinating debate that yields a wide gamut of strong opinions. I have a few counter-points on your thoughts though. I'm not aware of any framework that treats a document as a "string", most store the document on the file system along with the "template-cruft" intertwined in the markup. Not caring about the purity of a markup document by adding foreign (especially non-standard) syntax is Obtrusive, something that I think we agree on when it comes to something like this:

<div onclick="myfunction(this)"></div>

You're second point can be contended as well since HTML using IDs and Classes can be rearranged with programmatic impact limited to the selectors that reference it. The benefit of unobtrusive interjection being that all logic is isolated to it's own layer and all presentation stays at the presentation layer.

I absolutely agree that self-describing code equates to long term happiness and quick ramp up. For this reason especially I think separating logic and presentation is paramount. I recently talked to a startup that was having a hard time ramping up their JR developers because they were confused by all the django-templating code intertwined in the markup, they feel challenged in leveraging the low overhead of the entry level developer because of this.

But it's so true that there is always the right tool for the job, I just feel like developers have had hammers for a long time and to a lot of them, everything still looks like a nail.

I think we have different ideas about what constitutes obtrusiveness. I'd exempt template code from being considered obtrusive because it exists pre-rendering, whereas the onclick example you gave will exist post-render. I absolutely agree that what the client will eventually see as the HTML, CSS, and JS should be nicely partitioned. However, I see templates as a fourth category not intended for the browser to consume where it's ok to blur those lines.

And you're probably right that exactly how self-documenting template code is is mostly personal preference/comfort level. I can definitely see Junior devs being confused by it if the concept of templates was new and they didn't understand what the engine was going to do behind the scenes. It's a fair point.

I do like the idea of keeping html html - no extra templating stuff making its way into the presentation layer code. In my mind it leads to a very clear division of labor in terms of a team with varied capabilities. One extra thing I like about the node.js approach is the ability to create the response document in a manner separate from the flow of the document. Rather than having tokens or rendering calls within the template - flowing in DOM order of elements, beginning to finish - one could organize his/her code in a variety of ways perhaps more logically and semantically suited to whatever application piece, list response, database query, etc is being handed back as the response.

In the end, I think it's as hij1nx mentioned - the difference between engines/frameworks/whatevs today is not primarily performance or stability, but the coder's preference. And that could go either way; in some work environments or certain types of applications, one approach may be favored over the other, regardless of the coder's preference. It doesn't strike me that this discussion flows on right/wrong continuum. I think the most important part of using ANY framework/engine/etc is choosing the right one for the application and environment.

This is all i have to say, http://github.com/tmpvar/unobtrusive.jsdom.org. FACE =)