This article about client-side templating by Henrik Joreteg was quite interesting. In summary, it says don't send templates to the browser to be compiled and executed ... convert them to JavaScript functions that can be efficiently transfered to the browser and directly executed there.
Currently, Tapestry does virtually all of its markup rendering on the server ... but with the upcoming changes to Tapestry for 5.4, that may start to shift, with increasing amounts of the presentation being rendered in-browser.
I'm already mid-way through building a module structure for Tapestry and I'm quite pleased with what I have so far. Part of that infrastructure is the ability to compile CoffeeScript to JavaScript on the fly. The tapestry-core module will provide the basic infrastructure, and a new module will provide the actual runtime compiler.
I prefer for these kind of compilations and transformations to occur at runtime, rather than build time. It means no special build rules (in Maven or Gradle), no extra step when changing a file and reloading it in the browser, and it makes it easier in many ways for Tapestry to deliver the optimum bundle of compiled, aggregated, minified, and GZip-compressed JavaScript to the browser ... without having awkward conditionals and naming conventions to choose the correct version of each JavaScript file (not to mention ensuring that the minified version is derived from the correct non-minified version). Yes, there's a one-time startup cost, but that's always been a tradeoff I'm willing to make ... balanced by how much of Tapestry is lazy-loaded as needed.
However, the infrastructure is actually more flexible than that; it would be quite reasonable to do something like Henrick's solution: there's no reason why the infrastructure could not be used to read a template file and convert it to JavaScript source that can be exposed on the client as a module.
That raises another interesting idea; a template-as-a-module would then be a uniform way to package pure data (a JSON object bundle of properties) with the name of a module that renders that specific data into markup. That also opens up some terrific ways to have the server efficiently deliver updates to the client, in a data-focused way (rather than the markup-focused way provided by the Zone component). Combine that with server-push, and you have something really powerful brewing together!
I loved Google Closure Templates for the reasons you wrote.
ReplyDeleteSee https://developers.google.com/closure/templates/
A few other tools do that, like Dust which has been chosen by LinkedIn. See http://engineering.linkedin.com/frontend/client-side-templating-throwdown-mustache-handlebars-dustjs-and-more
Thanks for the updates on your progress to 5.4 - it's really imortant for us to know the direction because we're also moving more and more stuff to the client with MVC frameworks.
ReplyDeleteWe're currentry integrating AngularJS because it feels a lot like Tapestry on the client - it has dependency injection, I18N is included and the templates look nearly as Tapestry templates. AngularJS is definitely worth a look if you want to use JS MVC.
I think the preprocessing of the templates on the server can be integrated since you can change internal AngularJS components by overwriting them. You would still have to write the conversion from HTML templates to JS code (I guess this could be done by calling the relevant AngularJS code with Rhino).
If anybody wants to use CoffeScript and/or LessCSS with Tapestry 5.3 an Tapestry 5.2, I recommend my T5Conduit library.
ReplyDeleteThe library offers fully transparent integration of CoffeeScript and LessCSS, all compilations are performed on the server with results cached. It allows for example usage of original Bootstrap files.