Episode 15: JavaScript Zombies

Javascript zombies preview

Watch The Free Preview For “JavaScript Zombies”

 

Subscribe now to watch the full episode!

Get All The Episodes For $14/mo »


 

Stop Writing Apps That Eat Memory And Kill Browsers

 As you develop, if you care about memory usage and performance, you should be aware of some of what’s going on in your user’s browser’s JavaScript engine behind the scenes.

- Addy Osmani 

Have you ever seen a browser using hundreds of megs of memory? Or gigs of memory? Are you tired of your JavaScript web apps crawling too a stop after a while?

Memory management in JavaScript is a necessary and under-valued part of building scalable web apps in browsers. If you don’t take care to release your objects and data, then you’re essentially causing memory leaks. This will wreak havoc on your app and your users’ browser.

In less than 40 minutes, this high-quality, downloadable screencast will show you:

  • the fundamentals of memory allocation and garbage collection
  • yet another reason why global variables are bad for your app
  • the proper use of of the delete keyword, and why you shouldn’t use it.
  • how to identify and clean up most memory leaks
  • what a “zombie object” is, and how to prevent them
  • why Backbone.js added a listenTo and stopListening method to its event system

If you’re a developer building Single Page Applications (SPAs), writing a lot of JavaScript in a browser, you need to understand the basics of memory management. You need to know when JavaScript’s garbage collector will be allowed to clean up your data and objects. Your apps and your users will thank you.

 

P.S. Want to follow along with the code, tweak it and see what happens? You can grab the code for this episode on Github!

  • davilious

    Thank you very much for this episode, it is very well explained and also very good structured. So useful.

  • David Tang

    Definitely my favorite video of them all. Hope a part 2 is coming!

  • lukewendling

    ~12 min: did myObject.largeArray really go out of scope or did u just set its content to [] ? seems like the latter.

    • http://mutedsolutions.com Derick Bailey

      Hey Luke,nnnthe original contents of largeArray are falling out of scope when we point the largeArray attribute at a new, empty array.nnnfor examplennnfunction foo(){n var arr;n arr = [1, 2, 3];n arr = [4, 5, 6];n return arr;n}nnnwhen the second assignment of “arr” runs here, the original [1, 2, 3] array is now allowed to fall out of scope because nothing else references it. The actual array value is what falls out of scope when the variable is assigned to something else.nnnSo the answer to your question is really: both. I pointed the “myObject.largeArray” attribute at an empty [] array… and that allowed the old value of that attribute to fall out of scope and be garbage collected.

      • http://twitter.com/lukewendling Luke W

        ok. i think of ‘scope’ in terms of variable availability, not the variable’s value, but I get your point. perhaps just semantics. Thanks. Great screencast. (fwiw, it would be awesome-er to have snippets of the code on the page (or linked to github, maybe as successive commits) so we can listen and browse at the same time)

        • http://mutedsolutions.com Derick Bailey

          #facepalm – i have the code available on github… but i forgot to put that in the page description! i added the link just now, and it’s available here: https://github.com/watchmecode/javascript-zombies

        • http://mutedsolutions.com Derick Bailey

          yeah, i generally agree with your idea of scope… but it can be an important distinction to make at times, and get picky about semantics when i see an important distinction between words or meanings. nnnwhen we talk about “variable scope”, we are really talking about two things… the variable definition and availability like you were thinking, but also the availability of the value that the variable is pointing to. it’s the lifetime of the value that causes memory leaks, not the variable definition.nnn :)