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.
