Javatech

All of us at iCentris have currently embarked upon a torrid love affair with Freemarker templates. I admit that I, too, have been very excited about having them around. A freemarker template has quickly become the knee-jerk, defacto response to generating output – which is great for readability and maintainability. But lately, after repeated profiling sessions with all the top offenders coming from freemarker packages, I’ve come to realize that we’re using them way too much. And here’s why…

When should a template engine be used? There seem to be two answers to this question which both carry equal weight with developers. They are:

1. You want to have an easily editable version of your dynamic view. This will allow easy customization.
2. You want the representation to be easily readable to future developers. This will keep it understandable and maintainable.

Now, this might seem like a minor point to pick at. But bear with me…

So, how much faster is pure java than freemarker templates? Well, this is going to depend largely on the complexity of the template. As an example, I’m going to pick a template of medium complexity that renders an HTML button tag in a consistent fashion. The output will be very simple and we’ll have a lot of HTML attributes that can be set within the template. Here’s the ftl file:

button.ftl

————————————–
[source:xml]
<@compress single_line=true>
<button <#if id?exists>
id=”${id}”
</#if>

<#if name?exists>
name=”${name}”
</#if>

<#if value?exists>
value=”${value}”
</#if>

<#if accesskey?exists>
accesskey=”${accesskey}”
</#if>

<#if classname?exists>
class=”${classname}”
</#if>

<#if style?exists>
style=”${style}”
</#if>

<#if title?exists>
title=”${title}”
</#if>

<#if href?exists || onclick?exists >
onclick=”
<#if href?exists>document.location.href=’${href}’;</#if>
<#if onclick?exists>${onclick}</#if>
”
</#if>

<#if ondblclick?exists>
ondblclick=”${ondblclick}”
</#if>

<#if onmouseout?exists>
onmouseout=”${onmouseout}”
</#if>

<#if type?exists>
type=”${type}”
<#else>
type=”button”
</#if>

<#if disabled?exists && disabled == ‘true’ >
disabled=”disabled”
</#if>
>
<div>
<div>
<#if icon?exists>${icon}</#if>

<span>
${content}
</span>
</div>
</div>

</button>
</@compress>
[/source]
It outputs something along the lines of :
[source:xml]
<button id=”buttonId” style=”buttonStyle” onclick=” alert(’hi’); ” type=”button” > <div> <div> <img src=’pretty.jpg’> <span> This is required </span> </div> </div> </button>
[/source]

Now, is this a good place to use a template like the above? The answer is Yes. But, as with most things, only in moderation. Or perhaps the answer is actually a definite maybe?

So, what can the downside be?

Speed.

Having just benchmarked this I have an unfair advantage, but the raw Java implementation that spits out the same exact templating logic presented above in button.ftl runs over 15 times faster.

Running 1000 trials of button.ftl (FTL) vs ButtonTemplate.java (Class) gives me the following results ( in microsecond timing ):

FTL 419033 micros
Class 31828 micros
Class is 13 times faster!

With only 100 trials:

FTL 15888 micros
Class 834 micros
Class is 19 times faster!

So, back to the moderation. Nobody is going to notice if a couple of buttons are rendered in 1 microSecond instead of 15 microSeconds, that’s for sure. But, if your entire page, overtime, has been rewritten to do absolutely everything using FTL, and the page ends up taking a second to load. Well, then, a 15x speed increase would get that page out in less than a tenth of a second.

I ran these tests with Freemarker 2.3.10 and then again with 2.3.12 and got the same results, so the optimization they added in 2.3.11 doesn’t seem to affect this type of simple usage ( using maps ).

Here is a screenshot showing the intense framework supporting the Freemarker template engine. Notice how the pure java class ( highlighted in blue ) just goes about its business directly.

So, back to the two reasons to use an FTL template.

1. You want to have an easily editable version of your dynamic view.
2. You want the representation to be easily readable to future developers.

Well, in regards to #1, I don’t think we really need to have an easily editable version of our <button> tag. I mean, really, a button’s a button’s a button. It might keep growing for a while, gathering more attributes and complexity over time, but I don’t think we’ll ever need to plug in a custom version for a different client.

As for #2, I don’t think the java code is really that much more difficult to read, and since we won’t be needing to change this (because it’s a button, for christ’s sake!) template that often, why take the speed hit here?

Here, btw, is the code for ButtonTemplate.java ( w/o Javabean boilerplate )
————————————————————————-
[source:Java]
public void render( Writer out ) throws IOException {
out.write( “<button” );
if ( id != null ) writeAttribute( out, “id”, id );
if ( name != null ) writeAttribute( out, “name”, name );
if ( value != null ) writeAttribute( out, “value”, value );
if ( accessKey != null ) writeAttribute( out, “accesskey”, accessKey );
if ( className != null ) writeAttribute( out, “class”, className );
if ( style != null ) writeAttribute( out, “style”, style );
if ( title != null ) writeAttribute( out, “title”, title );

if ( href != null || onClick != null ) {
out.write( ” onclick=\”" );
if ( href != null ) {
out.write( “document.location.href=’” );
out.write(href);
out.write(”‘;”);
}
if ( onClick != null ) {
out.write( onClick );
}
out.write( “\”" );
}

if ( onDblClick != null ) writeAttribute( out, “ondblclick”, onDblClick );
if ( onMouseOut != null ) writeAttribute( out, “onmouseout”, onMouseOut );
if ( type != null ) {
writeAttribute( out, “type”, type );
} else {
writeAttribute( out, “type”, “button” );
}
if ( disabled ) {
writeAttribute( out, “disabled”, “disabled” );
}

out.write( ” > <div> <div> ” );

if ( icon != null ) {
out.write( icon );
out.write( ” ” );
}
out.write( “<span> ” );
out.write( content );
out.write( ” </span> </div> </div> </button>” );
}

[/source]
Now, I mentioned the torrid love affair we’re in at work. Well, we are using a whole lot more FTL to simply render HTML elements : inputs, labels, selects, buttons, checkboxes, creditCards, datePickers, dropDowns, addresses ( which use the previous elements ) and even style and javascript includes. So, in conclusion, since Freemarker is the artsy smartsy way to do things and it will be used wherever and whenever possible once it takes root – I implore you to only use it where/when it is truly needed. That is, for large views that are truly complex and for views that will be frequently customized. For the simple cases, it’s just not worth the hit.

Time to go refactoring…perhaps…

Afterthough::: If only the freemarker templates would compile into java bytecode, then this would probably be a nonfactor. JSP’s can do it. Is anyone up to the task?