10

I want to be able to define templates once and use them to render html from both the server-side as well as the client-side. (DRY principle and all that)

The API that I'm envisioning is simply this: render(JSON, template) --> html.

I'm using a java-framework (actually Play framwork, but I don't think this is framework specific).

I've read a lot of similar questions, the latest, and most helpful being: Templating language for both client-side and server-side rendering.

I pretty much agree with the author that obvious contenders like: Mustache and Google Closure Templates are not going to cut it. (for reasons see that post)

Requirements:

  • MUST: client-side rendering
  • MUST: client-side caching of template-files
  • NICE: client-side 'compile-once execute many times' of template-file to fast javascript-code
  • MUST: server-side rendering
  • NICE: native java implementation

I've seen a bunch of posts suggesting the use of Node.js for server-side templating. Although this would definitely work (underscore templates, Handlebarsjs, EJS would all work just fine) I'm struggeling to see how to communicate/combine/integrate Node.js with java, after all it's still the java framework that needs to output the JSON

I've seen posts mentioning some proof-of-concept communicating between a JVM and node.js (over http or using JNDI) . However, no library, let alone battle-tested, seems to be available at the moment.

So to round things up, what client-side templating engine would you suggest that would run in java as well (or with some hoops, can be called from a jvm) ? And if that 'hoop' happens to be Node.js, what ways of communication/ library would you suggest to use?

Community
  • 1
  • 1
Geert-Jan
  • 18,623
  • 16
  • 75
  • 137
  • Why not use node.js instead of Play? There are plenty of SSJS systems running on the JVM like Rhino and ringojs – Raynos Jul 26 '11 at 16:23
  • Because I'm from a java background and I'm dealing with an existing application. I 'just' want to refactor the presentation-part of it. Concerning ringojs, I've looked into it but Node.js seems to perform far better than ringojs (from what I've read). Perhaps I shouldn't worry about that when the alternative would be to connect over http to Node.js because of the network latency, but that's one of the things I'm trying to find out. – Geert-Jan Jul 26 '11 at 16:54
  • Are you sure you need the server side rendering? I'm guessing that after applying the template on the server you won't be doing anything else with the resulting HTML except spit it out in the response... On the other hand you could run a JavaScript templating language inside the JVM with a JavaScript-2-JVM runtime. Generate the JSON code on Java side, pass it to the JS side and collect the output. I have only done that on .NET with JScript.NET compiled dynamically but you should also be able to get it working in Java in a similar way. – miguelv Aug 02 '11 at 18:54
  • In any case, I want to generate html on the server-side which is going to be identical to subsequent rendering on the client-side. So having the same template (and staying DRY in the process) just makes a lot of sense to me. Just generating JSON on the serverside, spitting it out, and let the client-side template take care of rendering in all cases CAN be an option in some circumstances. However, I need javascript-less browsers (think SEO) to work as well. – Geert-Jan Aug 05 '11 at 17:37

1 Answers1

1

I'm going for Mustache for now and anticipating a java implementation for Handlebars.js. Once that exists, the refactoring-path shouldn't be that steep.

EDIT - april 2012

Ok, updating this for future reference:

  • I'm outsourcing server-side templating to Node.js.
  • communication between java and node.js implemented using sockets. (see: Sending data from node.js to Java using sockets for where I got the idea)
  • Since now I only need a client-lib (or better one that runs in javascript on both client and server-side using node) I can choose more freely. Having become accustomed to Mustache, I've chosen the Hogan parser (by the Twitter guys) ( http://twitter.github.com/hogan.js/ )

100% DRY (even the client-side mixins and i18N-bundles come from the same source. Moreover, Hogan can precompile the templates server-side and open a connection to the client so the client doesn't have to parse the template anymore on first connect.

Is it fast? Lightning...

Community
  • 1
  • 1
Geert-Jan
  • 18,623
  • 16
  • 75
  • 137
  • your solution sounds interesting. the cons i see here that your server side must run nodejs as well.. – oak Oct 24 '14 at 07:51