Derick Bailey: Well, the latest trend is definitely Node.js.
Richard Campbell: It is hip, isn't it?
DB: Yeah, I know. It’s crazy.
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: 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.
DB: Oh, yeah. Absolutely.
CF: That some guys are going to sit on maybe for hours and use.
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.
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?
CF: Backbone.js . What can you tell us about that?
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: 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.
There's much more! You can find the full interview at dotnetrocks.com/default.aspx?showNum=743.
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.