Future of template languages?
It seems like the templating mechanisms will continue to evolve. I came with some requirements and will watch how they will play out in future.
We need Javascript as well as Server side templates. Trimpath folks have a templating mechanism for javascript. Their javascript-equivalent of Ruby-on-rails has a good comparison of ruby template with their own templates (RubyRails Vs JavaScriptJunction ). One of good things this engine is the fact that it can be used both on server side (using Rhino) and client side. But my point is different: The same template should be rendered both on server side as well as client side. And that means some things are resolved by server, and some are rendered at client side. So how do we decide how to partition? For e.g. Layout is server side, but the contents in each boxes are necessarily driven by ajax. This in turn require JSON-RPC integration with underlying template mechanism. The objects used within the template need to be added to JSON-RPC bridge automatically. I should be able to simply add "remotehost=xyz.com" as one of the attribute to where the template is hosted, so the client-side template has access to server-side objects using JSON-RPC bridge seamlessly.
As the app devel cycle takes lesser and lesser time, the UI improvements will keep going on continuously. A simple "merge" operation should be sufficient to ensure that the developer-made changes are automatically integrated into next version of UI. This means templates should be designer-friendly and amenable to versioning, diff's and merges. This means that all the "code" part to be within attributes and special tags. Kid template language of Python does this right.
And again, assuming we spend time with UI, we require templates to be managed by content management system - and that means Wiki. And more important, we would like the capability to be uniformly available to end users as well. And this means we need to have "Safe" templates - those which can be edited from web itself. For example, Liquid, a ruby-based templating system, seems to do it.
Widget integration is going to be another interesting area. Dojo, prototype etc. already give us good widget environments. Widgets will probably make it easy to standardize on Layouts - such as 3-column, or 3-pane (like in outlook). How exactly should widgets get integrated with templating languages? In some sense, widgets seem to compete with standard templating approaches: A widget specificaiton is going to be very simple. Remember Dojo's ridiculously simple slideshow widget example specification? And the problem is, the widget is going to take inputs as parameters. Some of them will, well, be widgets. And this means that your template will basically be XML tree, and that's bad. (After all, templates should look like real HTML!) In any case, as long as browser can show this properly without requiring other servers, I think people will come to accept this approach. We would have to see how this will roll out. And not to forget, we are also talking of ajax-enabled widgets which need to integrate well with JSON-RPC or some such scheme.
In any case, javascript is going to be an important ingredient.
-Vinod
