I don’t know about you, but I grew up doing image rollovers in JS and other groundbreaking “dhtml” stuff. Since then CSS has evolved, web standards and browsers have evolved, and things are much much nicer than before.
One thing that is starting to change is the way we fundamentally approach javascript. Not simply the recent popularity of libraries such as jQuery, allowing us to literally “change the way we write javascript”, but also there’s now much more awareness of the power that javascript has, and we’re doing more mission-critical stuff with JS. We’re moving from favouring simple procedural snippets of javascript that add twinkles to the page to fully object oriented JS applications, exporting great swathes of functionality away from the servers and onto the client.
This is a great thing. In fact it’s little short of a miracle; the servers are running faster and so are the clients! There seems to be no trade-off; by deeply integrating JavaScript into our web applications we’ve gained speed at both ends!
Not quite though.
JavaScript uses garbage collection to keep the memory usage down – if a variable is never referenced again in the code, it can safely be deleted from memory, freeing the resources associated with it. But there are various techniques to automatic memory management, and there are some pitfalls. For example, a common way to determine whether a variable is safe to delete is to count the references to that variable in the forward path of the code; when there are no more references, it can be deleted. But when two variables reference each other, that can create a circular reference from which there is no escape.
An article on Mozilla’s developer site explains how memory leaks are created, and how to avoid them. The trick is understanding when a specific type of circular reference is created. From the article:
function leakMemory() {
var el = document.getElementById('el');
var o = { 'el': el };
el.o = o;
}
The circular reference formed above creates a memory leak; IE will not free the memory used by el and o until the browser is completely restarted.
Yes, you read that right, completely restarted. Not just when the tab is closed, that memory will stay locked until you restart IE. This is so crazy I’m actually a little dubious as to whether it’s still true.
Ok you may be thinking, but surely this doesn’t happen that often in practice? Consider this example:
function addHandler() {
var el = document.getElementById('el');
el.onclick = function() {
this.style.backgroundColor = 'red';
}
}
The article goes into some detail about how these examples leak, and how to spot and fix them, and I highly recommend reading the entire page, not just the memory leaks section.
I’m currently in the middle of “Javascript: The Good Parts” by Douglas Crockford and highly recommend it, it’s pretty thin at 100 pages not including the appendices, but it is of exceptionally high quality – you’ll start understanding and writing better javascript from day one. Crockford also has a great page on memory leaks in JavaScript.
Recent Comments