 Conclusion
The purpose of this article was to show that not all leakage patterns are
easy to find. You may hardly notice some of them, may be due to the small
bookkeeping objects that become obvious only after several thousands of
iterations. Knowing the internals of a process is an undeniable key to
success. Be aware of the leak patterns. Instead of debugging your
application in a brute-force manner, look at your code fragments and check
whether there is any piece that matches a leakage pattern in your arsenal.
Writing defensive code and taking care of all possible leakage issues is
not an over-optimization. To take it simpler, leak-proofness is not a
feature the developer may choose to implement or not depending on his mood.
It is a requirement for creating a stable, consistent and
forward-compatible code. Every web developer should know about it. No
excuses, sorry. There are several solutions proposed for leakage issues
between a JS closure and a DOM object. Here are a few of them:
However, you should be aware of the fact that there are always unique
cases where you may need to craft a solution for yourself. That's it for
now. Although the article is not intended to be the "best practices in
avoiding memory leakage", I hope it has pointed out some of the interesting
issues.
Happy coding!
|
