I’ve been reading the comments and I think the topic about transforming your data so that it can be used to hydrate a logic less template is very important.

Some people want logic full template because they want to embed that kind of transformation logic into the template, but that violates the SoC. Templates should be used to render HTML (or CSS…) but not to transform data too, they are completely unrelated concerns. That’s why I prefer logic less templates.

It is usually the case you need two different models. A model to use for business logic and another one for template rendering. The transformation between both can be done either in a method of the former, or in an adapter/wrapper for the template. This transformation can take care of formatting issues (currency, dates) and even structural changes. The formatting logic usually have internationalization issues, so it’s not so simple as may appear at first look. Of course if both data structures are exactly the same, and no special formatting is needed, this intermediate transformation layer is not needed. This way we avoid violating SoC and have a more testable system.

Firstly, mostly the frameworks are built, or intended for single page apps as you pointed out. The problems in having maintainable code, templates and resources across a larger site comes down to having strict design guidelines, so the bulk of the JS logic and the templates can be reused. This is minor for a new build, horrible for retrofitting an older larger system that has very little reusable “modules”.

Secondly, as @Kyle pointed out, and in your response to him. There is some inherent logic that needs to be handled in displaying some information. That logic, at least I’ve found, has to be replicated on both the back end and the front end in some cases. This drives me crazy, but I don’t know of way around the issue unless all the rendering gets done either on the front end or the back end. There are pros and cons to either so….whats a guy to do other than cringe and replicate logic? I find that there are more cases where violating SoC, DRY than I feel comfortable with.

I’ve found the roadblocks and issues with client-side rendering to be a huge PITA. I would love a much simpler solution, but have yet to find one that works. Perhaps this approach is truly best suited for a strict design pattern on new sites. IDK.

I am glad to know that what I have done is generally matching your approach. I’m interested to see how this space develops. I would love to see more REAL world examples how others are solving some of these issues. The de facto TODO app examples are worthless in this regard.

I don’t think there’s a single ideal approach. One of my favorite things about using JS on both the front- and back-end is that you can then use the same data transformation layer, in the same file, for each case. If you don’t have that luxury, I think you have to accept that you’re going to violate SoC, DRY, or both. That might be a reason to question whether you need to do rendering on both sides after all.

All the tools do is split up the JSP source into the pure JSP part (which is handled pretty ordinarily by the rest of the server-side code), and then one or more template files. Those are then translated by doT and collected into a single blob for the client. (My app isn’t big enough for me to worry about separate template bundles and require.js or anything like that.)

In the end of the article you talk about having a nice abstraction that accepts the name of the template. Currently I am thinking about taking that a bit further by organizing my client side code in a way that for every view (as in MV* views) there is a folder which contains the view itself, corresponding template and CSS/LESS/whatever. In this approach the template and CSS would be automatically associated with the view. Do you think this is a good approach? I think it will help a lot with maintainability and reduce the time that I spend making boilerplate code but I am a bit afraid that I will run into limitation as my views become more complex.

Thanks!

One thing that I do that’s not really emphasized in your post is to exploit the template system for common application widgets. For example, my site has a convention of marking forms etc. with little [?] buttons (we call them, “what’s this? bubbles”). You click/tap on a question mark button and up pops some explanatory text, often with live data mixed in (“Here’s why your account balance is $123″ etc). Well to do that there’s some boilerplate HTML that’s repeated to set things up for the JavaScript that responds to the clicks – class names, positioning elements, etc. In the JSP world, I used a custom tag, but in doT I just have a template that does the opening and closing markup. That’s good for several reasons: it avoids repeating that markup in template after template, saving some space. It also means that if I need to update the “What’s this?” mechanism, I can do it in just one place.

I realize that “calling a template from inside a template” is heretical to some people, as one could think of it as “logic”. Personally, I don’t think of it like that at all, and even if I did I think that sticking to DRY principles is far more important. (I also realize that not all template systems allow this; in my case it’s one of the main reasons I love doT so much.)

Thanks for the awesome post!