If you speed up your website by 2 seconds, everyone agrees that that’s a good thing with a visible user impact. In terms of actual impact on the business of web development, memory leaks are a funny thing. So why should you, and why shouldn’t you, care about memory leaks? Obviously I’m biased because I have an axe to grind (and a tool I wrote, fuite), but let me try to give an even-handed take. Today, I see a lot more discussion of these topics among SPA developers, and that’s a great sign that our field is starting to take our craft more seriously.
Similarly, five years ago, there was much less concern among SPA authors for accessibility, security, runtime performance, or even ensuring that the back button maintained scroll position (or that the back button worked at all!). I would argue that they do matter, if only because the lack of care (as shown by public-facing SPAs leaking up to 186 MB per interaction) is a sign of the immaturity of our field, and an opportunity for growth. So is it really worth the effort? Do memory leaks actually matter? The effort-to-payoff ratio is disappointingly high, especially compared to the hundreds of other things that are important in web development, like security and accessibility.
If a web app leaks 5 MB on every interaction, but it still works and nobody notices, then does it matter? (Kinda sounds like a “tree in the forest” koan, but bear with me.)Įven those who have poked around in the browser DevTools to dabble in the arcane art of memory leak detection have probably found the experience… daunting. I’ve researched and learned enough about client-side memory leaks to know that most web developers aren’t worrying about them too much.
0 kommentar(er)
