And to confuse things further, we'll provide examples in Coffeescript?

To be fair, they do link to some JS conversion thing, but I'd prefer to read the examples right in the article - "don't make me think" and all that.

Yeah, especially because Coffeescript can be very liberal with creating objects if you don't know exactly what you (and coffeescript) are doing.

edit: Disclaimer: I have written and am still occasionally writing canvas rendering stuff in coffeescript and after some meddling around with some annoying bits it has been quite pleasant. For example you should make sure that functions that don't need to return anything, return false or null or undefined. Otherwise coffeescript will return whatever your last statement evaluates to. This is especially bad if the last thing is a loop.

CoffeeScript doesn't actually create any objects you're not telling it to do so. It does return the value of the final expression, but you placed that expression there to be executed. Its value will be returned and that might cause it to remain reachable for some additional time, but the value was created by your expression, not by CoffeeScript's return semantics.

This was my first thought as well. If you're discussing Javascript memory management, write the code in Javascript please.

Managing memory in ECMAscript is hard.

These are the same problems from Actionscript (I know the crowd here has no love for AS though).

Most folks probably write JavaScript for the browser.

Not only should you consider using object pooling for JS objects (like the author describes), but you also want to think about DOM element pooling, especially when you are dealing with large lists.

DOM element reference cacheing (and pooling) can significantly improve the responsiveness of very busy browser UI code (particularly in loops that make many DOM queries and/or updates) and can make the code more readable too, but be careful as you can create memory leaks especially in "classic" IE. Such leaks only tend to last as long as until the user navigates away, but they can become significant for single-page applications.

In many cases they can exist until the iexplore browser process terminates.

When using Object pooling, be sure that it causes an improvement, it can invoke pathologically bad performance from certain garbage collectors.

I would love to know if using emscripten will make memory usage more deterministic.

I still have nightmares about memory management in JavaScript following an unfortunate project involving a very media-rich application running on Vizio TVs with "Yahoo Widgets for Connected TVs" (a non-HTML JavaScript app framework that derives from the old Konfabulator).

Not only do you have all the usual issues with JavaScript and memory, but the amount of RAM available is tiny and the garbage collector is run on a set timer and if you blow your memory budget between these timed calls to the garbage collector, the program soft crashes (you'd think an emergency gc would be scheduled if memory pressure were that high -- you'd be wrong!). Even if you were very careful to set unused objects to undefined or explicitly delete them, the memory those objects took still counted against you because of the timed gc system. Object pooling was absolutely required but even then you had to be very careful not to blow your memory budget.

The 'soft crash' would result in a situation where the app and overall runtime is still running but the state of the software is no longer reliable until you reboot the TV. And none of this stuff (the timed gc, etc) was documented at all, and there's little to no active community for "Yahoo Widgets" so you basically had to figure this all out on your own.