launchpad-dev team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

On Oct 17, 2011, at 1:55 PM, Robert Collins wrote:

> On Sat, Oct 15, 2011 at 10:13 AM, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> Hi all,
>> 
>> I've just given Launchpad the ability to render a given template either
>> server-side or client-side.  I've done this because the
>> CustomBugListings feature means we'll want to render bug listings on the
>> client and server sides, and we have a new design for them.
>> 
>> Here's a screenshot of the current work:
>> http://people.canonical.com/~abentley/mustache-listings.png
>> 
>> I've used the Mustache templating language for this.  The Python
>> implementation is called "Pystache", and the JavaScript implementation
>> is called "mustache.js".
>> 
>> In either language, the inputs are a string and a JSON-compatible
>> mapping (a dict in Python, an object in JavaScript).  In Javascript, you
>> render a template like so: "Mustache.to_html(template, data)".  In
>> Python, it's "pystache.render(template, data)".
> 
> This is pretty cool. I a question to help me (and perhaps others)
> choose when to use *stache templates:
> 
> - how does the server side generation compare to TAL performance? We
> have pages that spend extraordinary amounts of time in TAL (and
> have/are trying things like new TAL engines to improve on this).

Heh, if it is not loads faster, that will be sad.  I expect TAL has a lot more functionality than mustache, for better or worse.

For apples-to-apples, though, we ought to compare dict rendering of TAL versus *stache

> 
> And an observation: the discipline of having a plain ol mapping will
> help us develop eager-loaded datasets rather than just-in-time
> evaluation, which I think will help with our query counts and server
> rendering performance.

Yeah.

Gary