Creator of the Apache Tapestry web application framework and the Apache HiveMind dependency injection container. Howard has been an active member of the Java community since 1997. He specializes in all things Tapestry, including on-site Tapestry training and mentoring, but has lately been spreading out into fun new areas including functional programming (with Clojure), and NodeJS. Howard is a DZone MVB and is not an employee of DZone and has posted 80 posts at DZone. You can read more from them at their website. View Full User Profile

Stop Sending Template Engines to the Browser!

  • submit to reddit

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 cos, 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!

Published at DZone with permission of Howard Lewis Ship, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)