Step 1: Modules, classes, packaging and other fun
In my case, I have a requirement to support some very old browsers as much as possible (Internet Explorer on Windows 7, for example). For some things, this support simply isn’t possible – the browser has literally no support for the feature I need, it can’t be polyfilled in, and the developers have no plans to add the feature. Despite this, somehow it’s always our fault that it doesn’t work (here’s a nickel, kid, get yourself a better computer). To begin with, however, I’m just working on an up-to-date version of Google Chrome, and then compatibility testing with other up-to-date browsers – I’ll chase the long-tail later.
Memory leaks. So many memory leaks
Unless they don’t. And they weren’t. And given that I’m working with digitial video streams here, this unreclaimed memory can build up quite significantly and quite quickly. And given that people may be watching the streams for several hours without refreshing the page, that’s bad news.
I was wrong.
It seemed that somehow, all of the fetch()s I was doing were somehow immune to garbage collection, and so my browser tab was using an increasingly large amount of memory. I was using the Fetch API because that seemed to be the new and modern way of doing things (I was going to deal with the lack of support in IE later). In the end, I re-wrote them to use the good old XMLHttpRequest, and my memory leaks disappeared (and I got IE support back). I’ve still got a couple of fetch()s to rewrite, but now I’m only leaking a couple of kilobytes per minue, rather than megabytes per second.
I’m also rather curious to see how other sites (both at work, and in general) are for memory leaks – it’s well known that A Certain Webmail Provider has an online client that can be quite grabby when it comes to RAM, and also A Certain Messaging Platform is well known for it’s poor performance and RAM requirements. Am I just being overly sensitive here? Is it really an accepted industry practice to say, “Well, they can just refresh the page to solve the problem”?
The PHP ecosystem has taken a bold approach to this – newer versions of systems like WordPress and Laravel enforce a minimum PHP version, thus obligating hosting companies to upgrade their systems. Not only does this reduce the size of codebases (no need to have compatability code for older PHP versions, and you can use the latest language features without fear) but it also reduces developer stress – a line has been drawn, and if a hosting company is the wrong side of that line, they’re told, “Tough. Upgrade, or maintain your own patchbase to make it work – we’re moving forwards, not looking back.” There seems to have been surprisingly little pushback on this – maybe we can see the same in the browser world.
This site uses Akismet to reduce spam. Learn how your comment data is processed.