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

giving greenfield stuff to newbs May 23, 2012

I’m coming up on two months at my new job (feels like a lot less), and with the amount of code we have, that means there’s still plenty I haven’t seen or worked with. There are certain processes (e.g., deploying) that have become automatic, but others I haven’t yet done. I still get automated emails [...]

javascript hotline May 17, 2012

I don’t know Rails, and that may be why I hadn’t heard of Rails Hotline before last week. If you’re not a Rails dev and are also unfamiliar, it’s pretty much what it sounds like: developers volunteer to take a shift answering the phone if anyone calls, and other developers can call in and ask [...]

authority and paying your dues May 11, 2012

I’ve tried consulting a couple times. The most recent of those, I tried it with a partner. He didn’t know much about web development. I had to teach him a lot. He got significantly better, but he was still what I’d consider junior. At some point after we gave up on consulting, he was applying [...]

from mockup to code (efficiently) May 1, 2012

Lately I find myself in the once-familiar position of taking mockups and converting them to markup and CSS. This is generally a pretty simple task, one you could optionally pass off to a junior dev. But that assumes there’s a clear process for it. Obvious divisions of labor, patterns, and best practices, I’m finding, make [...]

girl ghettos April 13, 2012

The double-edged sword of trying to address the lack of women in technology as a woman is that, if you manage to get a group of technical women together, you’re going to end up creating what’s called a girl ghetto. A girl ghetto is where you stick the women you’re keeping around to show you’re [...]

a retirement fund for your javascript April 9, 2012

You ever find yourself feeling unreasonably protective of JavaScript? I do. For a long time, JS lacked a lot of sophistication. It was vulnerable to being trampled over by bigger, more powerful technologies like Java applets or Flash. There was nothing to really commend it to anyone who didn’t, for whatever crazy reason, already love [...]

choosing template engines March 3, 2012

The first presentation I ever gave at a conference was on templates. jQuery templates, specifically. It’s weird – it’s a topic I’ve never presented about again yet one that, if anything, I’ve become more obsessed with. So it stands to reason then that I still find myself in conversations about templates with other JavaScript dev […]

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, [...]

garann means