Memory leaks in Single Page Applications in Elm

Hello there,

while reading about Single Page Applications around the Web one of the biggest disadvantages often cited about SPAs are the propensity for Memory Leaks due to extended periods of running JS code. A lot of people around the Web even say this is such a big drawback that sometimes it’s best to consider building a Multi Page Application instead.

Since I’m working on an application where I’d like to achieve critical stability and reliability using Elm, I’d like to know what’s Elm take on this problem.

Is the fact that Elm is a higher-level language than JS help with this? Are there any additional insurances compared to JS and the popular SPA frameworks?

I’m greatly interested in this topic so any help and explanations would be welcomed. Thanks!

@Sebastian wrote about SPA memory leaks back in 2014:

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!


Not sure if results in memory leak, but there is

I agree with Richard that by design it shouldn’t be a problem. However software tend to have bugs. So there is no guarantee you won’t have leaks.

It is especially trickier with current state of things in Elm. Bug releases rarely happen by themselves, but usually are batched with bigger releases. Latter ones might take years. So if this is something critical for you, it worth taking this fact into account.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.