@Sebastian wrote about SPA memory leaks back in 2014: https://reinteractive.com/posts/186-lessons-learnt-by-building-single-page-applications
An example he gave was “zombie event listeners” - where you bind an event listener and never unbind it.
By design, this shouldn’t be a problem in Elm because Elm’s Virtual DOM takes care of both binding and unbinding event listeners based on what view and subscriptions are actually using at any given moment. This should be true for 100% of Elm event listeners, although of course you can introduce zombies via JS interop.
So basically I’d think of this quote:
…as pertaining more to JS pitfalls than to cross-language SPA pitfalls. To the extent that JS makes it likely that you’ll have minor memory leaks, SPAs can exacerbate those into major memory leaks.
On the other hand, if Elm’s design doesn’t make it likely that you’ll have minor memory leaks in the first place, SPAs have nothing to exacerbate.
We haven’t observed any memory leak issues with our production Elm SPA code, and I haven’t heard of anyone else having this problem either. That’s the outcome I would expect, based on Elm’s design. That said, I don’t know of anyone having done any deep investigation into this question for Elm SPAs in particular - and especially when it comes to performance questions, things can always be different in practice than they are in theory!