garann means > totes profesh

a defunct web development blog

the jTemplates experiment

Wed, 09 Jun 2010 17:49:53 +0000

So it took a heck of a long time between the first proofs of concept and actually going live, but I rewrote a pretty complex client-based web application to use jTemplates. It started out with 12k+ lines of code (the numbers in that previous post don't reflect various utility files, just the two main ones) and when I totaled it up on Monday, the new count is 3834. I'd been estimating it at about 5k. Less than 4k is better than I'd hoped. Even more impressive is that the previous figure did not include all the HTML templates that provided the pages their basic structure - the 3834 includes the jTemplates (since they're all Javascript), meaning that's it.

Summary: I am now a fanatical jTemplates convert.

However, I had a conversation over the weekend that's got me questioning whether I'm sacrificing too much performance for maintainability. I won't pretend the new application runs a lot faster than the old one. Its issues are different - this takes a long time to load, whereas the old one leaked memory over time - but it's not blazing fast by any means. Part of the problem is the immense data object that the jTemplates process. All the information about a specific object is passed down at once when the page first loads, and then has to be pulled down again whenever the user switches between the four tabs in the application because of some irritating issues with the web services (the only thing they return is error messages, so if a new element is added, for example, it takes an additional XHR to find its ID) and data getting stale. I'm wondering, if I'm pulling down all this data anyway, if there's an argument for putting jTemplates on the server and just getting the markup pre-loaded with the data points.

Of course, this is a .NET environment where I have pretty much no control over the backend, so it's not likely I'll get to try jTemplates on the server. I can't find evidence that anyone's ever tried that, so who knows, maybe it's impossible.. Instead I'm going through all my notes from txjs and applying every performance enhancement I can find to any code I've touched over the past couple days. It's not giving me an improvement so far, and I'm beginning to feel this is a design problem. If there were a way to split up the data being pulled down and lazy load interface elements, I think things would speed up a lot. Sadly, there's (currently) not.

I'm left with 4k lines of Javascript I'm very pleased with having shrunk and no clear path forward, which fucking sucks. But the application is clearer and more well organized. I guess the experiment continues..