Posts Tagged 'javascript'

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

MVC in Javascript

Nothing against Ajaxian, but I don’t usually look to them for pithy wisdom – mostly I look to them for clever jQuery plugins and stuff. However, the paragraph at the end of this post on MVC for Javascript sums up my feelings pretty well:

If you think that view source / semantic markup is a great feature of the Web platform, then this kind of world is a touch worrying, but major apps have been doing this for years.

Once I worked on this project with a lot of contractors from IBM, and they were the ones defining the architecture. They had a very literal approach to MVC. As in, every single link went through a controller. Home link? Ask the controller. About Us link? Ask the controller. I’ve implemented MVC in C# (back before they had the framework for it, which from what I gather is pretty cool) and had it be useful, don’t get me wrong.

MVC to me is one of those FUD problems, though. Even the experts can’t quite agree on how it should be implemented. Reminds me of the not-Agile-enough or not-semantic-enough debates that seem to eat up a lot of valuable time that would be better spent coding. This is why I want MVC to keep its white-gloved, mechanically precise fingers off my Javascript.

As far as I’m concerned, there is no good pattern except the one that is obvious. The one that makes you smack your head, exclaiming, “Of course!” because it is perfectly suited to your problem and its application is absolutely clear. I think of the Factory pattern as a good example. What it does and why you need it aren’t up for debate. MVC, on the other hand, is subject to interpretation once you try to apply it to environments it didn’t grow up in. Javascript is a language for manipulating CSS and HTML. Manipulating the View. There is no single, clear answer to the question of how to apply MVC to Javascript because MVC in Javascript doesn’t answer a need. Forgive me because – again – MVC has been very useful to me in the past (on the backend), but in this context MVC is nothing more than a buzzword.

pull the thread, it all falls apart

Oh what I would not give for a Thread object in Javascript. I have a tidy little dynamic Javascript loader that’s working in all browsers, IE6 and up, with the exception of Safari 3 (and, presumably, its predecessors). The problem is that none of my attempts to pause the execution of the function that needs the dynamically added scripts seems to work. While other browsers wait for an interval I’ve set to clear, Safari merrily continues to execute while my interval is repeating, whether this happens in the same function or elsewhere.

Here’s what would have been the loader, which I will now attempt to bury and forget:

UPDATE: Now works nicely in all browsers IE6 and up. I love having this blog. It’s like a magic box I drop my code into that makes it suddenly work. I don’t know the mechanations behind that, but I’m a fan.

var myLoadedScripts = [];
function loadScript(path,requiringScript,callback) {
	var requiring = null;
	if (myLoadedScripts.length < 1) {
		myLoadedScripts = document.getElementsByTagName("script");
	}
	for (var i=0; i  -1) requiring = tag;
		if (tag.src && tag.src === path) {
			return;
		}
	}
	var newScript = document.createElement("script");
	newScript.type = "text/javascript";
	newScript.src = path;
	
	if (newScript.onreadystatechange) {
		newScript.onreadystatechange = function() {
			if (this.readyState === "loaded") {
				callback();
			}
		}
	} else {	
		newScript.onload = callback;
	}
	
	if (requiring === null) {
		document.getElementsByTagName("head")[0].appendChild(newScript);
	} else {
		// insert before the script requiring this
		document.body.insertBefore(newScript,requiring);
	}
	
}

var myLoadedCSS = [];
function loadCSS(path) {
	if (myLoadedCSS.length < 1) {
		myLoadedCSS = $('link[rel=stylesheet]');
	}
	for (var i=0; i < myLoadedCSS.length; i++) {
		var tag = myLoadedCSS[i];
		if (tag.href === path) return;
	}
	var newScript = document.createElement("link");
	newScript.rel = "stylesheet";
	newScript.type = "text/css";
	newScript.href = path;	
	
	if (myLoadedCSS.length < 2) {
		document.getElementsByTagName("head")[0].appendChild(newScript);
	} else {
		// insert above other CSS to prevent overrides
		document.body.insertBefore(newScript,myLoadedCSS[0]);
	}
}

this self-documenting stuff is better in theory

I used to work in a Java shop where we had all kinds of documentation. We had a full-on API. It was very useful, and even in the cases where it needed a little updating, it helped you figure out where to begin looking for whatever you were looking for. I remember there was some fancy thing in Eclipse that would even create the javadoc code for you if you were willing to add a new method via some contrived WYSIWYG method. I’ve never worked with anything like that in .NET, but that’s ok, it’s pretty easy to work backward in the latest version of Visual Studio.

Javascript, to the best of my knowledge, lacks any ‘Find All References’ abilities no matter which editor you’re using, and thus is a place I’d like to see more javadoc-style commenting. Any Javascript library spanning more than three files needs API documentation, or you’re just going to end up rewriting what someone else wrote before. All for lack of documentation. The problem’s exacerbated as it becomes more fashionable to move all Javascript off the page. Without good documentation, it can be nigh impossible to find out where script is called in those scenarios.

Apparently there’s something called JSDoc which provides javadoc functionality for Javascript. It appears the results have all the visual appeal of javadocs, too. There’s also something called HeaderDoc that I’m inclined to trust further because of the nice documentation and that fact that it’s from Apple. (Terrible reason, I know, but if I weren’t a sucker for a good interface I wouldn’t be in this line of work.)

Looking for others..


RSS Recent posts on the live version of this blog

  • An error has occurred; the feed is probably down. Try again later.