This is an update of a post that originally appeared on January 25, 2013.
I’ve written any number of books that either include JavaScript development directly or indirectly. For example, when you create a web application in C#, there is some JavaScript involved that might ruin your day unless you have some idea of what that code is doing and how it can go wrong. If you enable JavaScript on your Android phone or tablet, then you can also use JavaScript development techniques in that environment. Because JavaScript provides a well-known and standardized environment, you often find it used in places where you may not think to look, which means taking the time to actually review the code that your IDE generates for web-based applications.
One of my goals in writing a book is to introduce you to techniques that produce useful applications in an incredibly short time without writing bad code. The term bad code covers a lot of ground, but one of the more serious issues is one of memory leaks. Applications that have memory leaks will cause the application and everything else on the system to slow down due to a lack of usable memory. In addition, memory leaks can actually cause the application to crash or the system to freeze when all of the available memory is used up. So, it was with great interest that I read an LogRocket article recently entitled, How to escape from memory leaks in JavaScript. The article contains a lot of useful advice in writing good JavaScript code that won’t cause your users heartache.
One of the most important parts of this article is that it covers memory leaks as a process. There is a list of common memory leak types and how to identify them. It also introduces you to tools and techniques for fixing memory errors using Chrome DevTools.
It’s essential to know that this article doesn’t cover everything. A big one is that the memory leak you’re seeing in your application may not be due to your code—it may be caused by the browser. The potential for browser problems is an important one to keep in mind because these issues affect every application that runs, not just yours. However, when your application performs a lot of work that requires heavy memory use, the user may see your application as the culprit. It pays to track browser issues so that you can support your users properly and recommend browser updates for running your application when appropriate. For that matter, you can simply determine whether the user has one of the poorly designed browsers and tell the user to perform an update instead of running the application.
There are other potential sources of memory leaks. For example, using the wrong third party library could cause considerable woe when it comes to memory usage (amongst other issues). Consequently, you need to research any libraries or templates that you use carefully. The libraries, templates, and other tools discussed in my books are chosen with extreme care to ensure you get the best start possible in creating JavaScript applications.
One of the reasons I find JavaScript so compelling as a language is that it has grown to include enough features to create real applications that run in just about any browser on just about any platform. The ability to run applications anywhere at any time has been a long term goal of computer science and it finally seems to be a reality at a certain level. What are your thoughts on JavaScript? Let me know at [email protected].