the jTemplates experiment

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..

Recent posts on the live version of this blog

is it me or are we going backward? February 23, 2012

Maybe it’s just me, but it feels like lately diversity is falling out of fashion as a goal in this industry. I made a tweet seeking sponsors for All-Girl Hack Night’s SXSW event earlier and was surprised by some of the responses. It seems like recent conferences have fewer female speakers, or are more defensive [...]

the $150k solution December 11, 2011

An article was published yesterday in one of Austin’s local papers about Austin’s tech talent shortage. I was job hunting just a couple months ago and get a lot of calls from recruiters and hear about friends’ companies who are hiring and I think it’s pretty damned accurate. And by accurate I mean that it [...]

“girl” power November 16, 2011

I just watched a short video called How to Get More Women in Tech in Under a Minute. The speaker, Caroline Drucker, is making a point about the toxicity of the word “girl” and how it hurts the cause of women in technology. Her argument is that every time we refer to ourselves as girls, [...]

calling the github API with node.js September 4, 2011

Updated: when I originally posted this, I wasn’t able to connect to the github v3 API. That’s fixed now, and several pieces of code are different as a result. Namely: removed http.createClient() – that’s deprecated, oops require the https module save the oauth token in the session completely change the way the API gets called [...]

widgets for third-party sites July 4, 2011

For the past couple weeks or so I’ve been driving myself crazy researching the ways people are developing widgets to run on other people’s sites. I’ve been writing and rewriting the same piece of JavaScript on the daily as I find new information or start to doubt the information I’d decided previously was The Right [...]

no country for old hackers July 2, 2011

This was actually a presentation that I was hoping to submit to a conference I really wanted to speak at. The reason I didn’t ultimately submit anything is the same as the topic of the presentation/post, in part. How’s that for meta? And since I’ve been thinking of it as a presentation, I’m just going [...]

separation of concerns is a bunch of bull June 25, 2011

A couple days ago I was booking myself some air travel. I finished filling out all the forms and submitted my payment info and finally it dropped me on the confirmation page. The confirmation itself was tiny, and the rest of the page was taken up by hotel offers, several of which were stupid expensive [...]

nested callbacks in jquery begone!! June 2, 2011

A week or two ago I noticed a bunch of people having trouble because of their nested callbacks, or with flow control in general, in jQuery. I said something about this on twitter, saying people should use jQuery’s Deferred object, and several people commented that Deferred is a really difficult concept to explain. I kind [...]

things that actually matter May 8, 2011

I had just gotten some very relevant facts about this and was about to update with corrections, when Alex Sexton posted his comment below. Please scroll down and read that before taking this without a giant grain of salt. I definitely jumped to some incorrect conclusions, and he’s got the real story down in the [...]

keyboards April 4, 2011

When I was in college, I worked in the computer lab. One of the very first things they told us during training is perhaps the best thing I’ve ever learned in my entire career working with computers: never touch someone else’s keyboard. It doesn’t matter if the keyboard involved is actually yours, and someone else [...]

garann means