Skip navigation
A Conversation About JavaScript: Node.js, Backbone.js, and Garbage Collection

A Conversation About JavaScript: Node.js, Backbone.js, and Garbage Collection

RELATED: "How to Structure JavaScript Code, Part 1" and "Enabling a Node.js Server-Side App on Windows Azure."

Editor's note: Welcome to .NETRocks Conversations, excerpts from the .NET Rocks! weekly Internet audio talk show. This month's excerpt is from show 743, with Derick Bailey, an independent software developer, consultant, trainer, and blogger who works with JavaScript, ASP.NET MVC, and other software tools and technologies. Derick joins Carl and Richard in a lively conversation about JavaScript development, discussing Node.js, Backbone.js, JavaScript garbage collection, and JavaScript and Windows 8.

Carl Franklin: JavaScript certainly has come a long way. It seems to get better and better and faster and faster. What are you seeing out there in the JavaScript world as being the latest trend?

Derick Bailey: Well, the latest trend is definitely Node.js.

Richard Campbell: It is hip, isn't it?

DB: It has become the darling framework of the JavaScript world and the web development community in general, recently.

CF: Who knew JavaScript programmers could write server apps?

DB: Yeah, I know. It’s crazy.

CF: So, is Node.js, you think, sparking a new interest for the JavaScript world in more traditional, sort of plumbing, back-end programming outside of Node.js? Or do you think that it's confined to Node.js at the moment?

DB: It's a vibrant and thriving growth. Node.js kind of stepped in at the beginning of this wave that we're seeing and helped push it along, but it's really a reciprocal, cyclical process where all of these other technologies are beginning to use JavaScript. Node is beginning to pick up additional libraries and tools to connect to these other environments, and you're seeing this outgrowth in this very homogenous organic manner of all these tools starting to use JavaScript and the JSON format in order to get things done.

CF: Right. Do you think there's a lot more JavaScript programmers doing stuff on the server now, or do you think that it's server programmers now using WinJS? Like people who have done things typically in PHP or even ASP.NET or Java on the server are now thinking, "Well, let's try this."

DB: My best guess would be about 50/50, honestly. I think a lot of developers who were previously doing back-end stuff are now saying, "This JavaScript, there's actually some cool stuff that I can do with it as a back-end developer."

And then, at the same time, people like me who, you know I've spent a lot of years in the back end, but I always had this JavaScript front-end work that I had been doing. I saw Node come along and these other tools, and I said, "Oh, hey. I can take JavaScript from the front end and start doing it in the back end now. This is pretty cool." This bridges the gap in terms of skill sets, so we're seeing kind of a convergence finally between the front-end developer and the back-end developer with tools like Node.

CF: Is there any march toward standardization or development of practices and things, or is that too much to ask of the JavaScript community at this point?

DB: Oh, it's definitely not too much to ask. There has been a huge push for that recently. There's a number of books that I've read recently in the last year or two that really start heading down that path quite well. One of my favorites -- actually probably my all-time favorite JavaScript book -- is by a guy named Stoyan Stefanov. The book is called JavaScript Patterns, and it's all about good software engineering practices and good patterns for JavaScript to help create better code, more maintainable code, easier to read, high-performance, and things like that.

RC: There's a guy I've also been following. Just a really good thinker about how to write code efficiently. I don't even look at Stoyan as a guy all about JavaScript. He's a really good thinker about programming.

DB: Yeah, absolutely he is. He does a lot of work in PHP and other languages, too.

CF: So, are there any other gurus out there that people are looking to for guidance, even architecturally or pattern development-wise?

DB: There are definitely a good number of JavaScript luminaries who are really pushing things forward and saying, "Look, these things need to be done better. We need to think about architecture and performance and writing good, maintainable software because our language is becoming ubiquitous, and it's really a necessary part of the growth."

CF: Yeah, I just wonder if JavaScript programmers are wondering about optimizing memory management and things like that. Those are things that have been completely foreign to the JavaScript developer. Are you thinking about those kinds of things with Node.js?

DB: Not necessarily with Node. I'm not doing a lot of Node work right now. I'm mostly just playing around with it and learning it, but when I'm doing browser-based JavaScript I am absolutely thinking about memory management.

RC: Hmmm.

DB: Every time I implement an object, for example, I'm thinking about, "OK, what attributes and methods do I need to stick in the constructor function versus in the object prototype?" And a lot of that has to do with memory management.

We also have to think about things like closures and variable scope and making sure that we don't just have closures left and right running amok because the closure almost by definition is a memory leak. So we really have to control those things and make sure that we're keeping everything well encapsulated and closed down tight, so that we don’t create real memory leaks.

CF: It's funny just hearing the words "JavaScript" and "memory leak" in the same sentence, but I mean, think about it, when you're doing an asynchronous JavaScript application, [it] is really a stateful being, isn't it?

DB: Oh, yeah. Absolutely.

CF: That some guys are going to sit on maybe for hours and use.

DB: Right.

RC: But this brings up an interesting question, Derick, because I think that the sophistication of JavaScript and these great frameworks have changed the way we build web pages entirely.

DB: Absolutely.

RC: This whole idea that there is only one page, there's like the single page, and you just keep Ajaxing different content into it, which, to me, feels like the ultimate memory leak.

DB: Well, it's going to be close. You can definitely get down that path, but JavaScript is a garbage-collected, managed language much like .NET or Ruby or other modern languages that we use. So it really behooves a developer to understand how and when some of the basic garbage collection happens in JavaScript. Then you really avoid memory leaks by allowing your objects to be collected when they need to be.

CF: Now, how does the garbage collection work in JavaScript, and is it the same for each browser and each engine? Is there a standard garbage collector?

DB: I don't think there is at this point. I'm pretty sure that each of the browsers does it on their own. There might be some standard in the JavaScript, the ECMAScript standard, but I don't know offhand. My assumption based on some blog posts and other information that I've read recently is that JavaScript garbage collection works much the same way as .NET garbage collection in that it looks for objects that are still in use and still referenced by the application, by the DOM, or by some other means, to say "hey, there is a possibility that this object is still going to be used." And anytime it sees that, it hangs onto the object.

There's a couple of ways that you can force an object to be cleaned up. You can either de-reference it everywhere, just let it fall out of scope, and at some point it will be cleaned up, or you can explicitly call the delete keyword, and the delete keyword essentially says "remove a reference to whatever object this variable or attribute was pointing to." And, of course, I'm over-simplifying everything greatly; there's a lot more technical details behind the scenes, but that's the gist of it.

RC: That brings up this whole idea: If you're just going to stay on one page, you're now responsible for cleaning that stuff up. And how much have we counted on the memory cleanup effects of going to another page?

DB: Right.

CF: Backbone.js . What can you tell us about that?

DB: I'm a huge fan of Backbone. It's actually where the vast majority of my paid work is these days, and my open source projects at that. Backbone is, contrary to popular opinion, not a JavaScript MVC framework. It's actually more of a library of tools that happens to fit into the MV* family, but it's really not MVC.

Number one, there's no controller, but also, philosophically and architecturally, it just doesn't fit into that paradigm where you have controllers that are being called by routers that end up using your models and that kind of frameworky "I'm going to call your code" manner. Backbone is really more of a "hey, here's some great abstractions that have come out of a lot of different ideas and a lot of different experience, and you can go and reuse these abstractions in whatever manner you want." It's just a library of tools.

CF: What's a typical place where this sits in your web stack? Give me an example of an application that would benefit really well from using it.

DB: The most simple place where Backbone is beneficial is anytime you see jQuery code that's having more than a few nested callbacks and more than, I don't know, 20 or 30 lines of code. The Backbone view construct is really there to help us organize and clean up our jQuery code. Of course, it can do a lot more than that when we want it to, but that's most often the first place that I introduce Backbone into a project.

RC: Is when jQuery gets out of hand?

DB: Yeah, yeah. I want to bring some better structure to this jQuery code, so I'm going to bring Backbone into play and start using Backbone to organize that jQuery code.

RC: Interesting.

CF: So, Windows 8 and Metro. Microsoft really did a good thing for JavaScript developers, do you think?

DB: Oh, yeah. Absolutely. I had a chance to play with the Microsoft BUILD Samsung tablet from last year I think it was, or the year before. I really enjoyed that Windows 8/Metro-style tablet experience. It was very unique, but it was also very intuitive. They had some really cool things going on with it, and I was happy to hear that Microsoft was doing the whole HTML5/CSS/JavaScript thing in order to be able to build apps on top of Metro.

CF: Well, here's the big question. Do you personally know anybody who wasn't in the Microsoft camp before and who was doing JavaScript, CSS, HTML5 programming and, because of that, is getting into and excited about Metro?

DB: I don't think I could name any names specifically, but I do have some vague memories and some specific memories of people on Twitter saying, "You know what? This Windows Phone 7 thing is really nice. I like this user interface." And I'm not sure about Windows 8 specifically, but I can't imagine that it wouldn't be happening a little bit more and a little bit more because quite frankly it is a really nice experience. And the ability to write JavaScript hits the hardware level in order to do some really advanced stuff; it's going to be a lot of fun building apps for Windows 8 tablets.

RC: I'm just wondering how much the fact that it's compiled, the customizations for the Chakra engine with the contracts and so forth, are just going to make it such a unique development environment that the skills don't really cross over.

DB: I think we're starting to see some of that fragmentation in the JavaScript world already, honestly. And I'm not sure it's going to be that much of a problem. I think it falls along the lines of C++. You can go write C++ for Windows or for UNIX or for whatever operating system. It's the language and syntax and the general knowledge and experience that you transfer with you, but then you're going to have to learn the specifics of that operating system's APIs and how to really deal with the kernel in that environment.

There's much more! You can find the full interview at

Richard Campbell and Carl Franklin are the voices and brains behind .NET Rocks!. They interview experts to bring you insights into .NET technology and the state of software development.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.