This is cool but I'm struggling to think of a case where I'd want to run backend JavaScript in a memory constrained environment, doubly so where performance isn't a concern.
I have an example for you. I self-host a Telegram bot, which is written in Python. However, I believe that if it were written in JavaScript, the situation would be similar.
The bot is rarely used, so on average, it only uses 0.06% of my machine's CPU power. However, it consumes 3% of the RAM at the same time. --smol switch according to Jarred's tests reduces memory usage ~7 times by increasing CPU usage just 2x times. In my case such redistribution of resource consumption would be a clear win!
To save RAM, I actually switched to a 32-bit Python base image. This switch resulted in a 30% reduction in RAM usage.
Full process/container isolation for many instances of untrusted code, perhaps? A serverless PaaS could use this to cut down significantly on the frequency of cold starts, all else being equal.
> This is cool but I'm struggling to think of a case where I'd want to run backend JavaScript in a memory constrained environment, doubly so where performance isn't a concern.
Maybe launching lots of separate services/containers locally, just to have the ability to debug everything and step through how a request travels through all of the services in one go, with multiple IDE instances also open locally, in addition to other stuff?
Distributed tracing is nice for remote environments, but having 5-20 IDE instances open with all of the related services can also provide a nice debugger experience. Not every machine has ample RAM for this, though, so I guess it's nice to have the option, without the processes/containers running into OOM so much?
The macbook air only has up to 16GB of memory right now. There's plenty of cases where one might want to run a javascript script on their laptop which uses quite a bit of memory, and they'd rather it complete at all, even if it's a bit slower.
My browser is already eating half of the 16 GiB of RAM I have on my laptop. I definitely don't need random small command-line tools which eat >300 MiB of overhead each. So far I am a happy non-user of Electron apps.
Uninformed spitballing here but I can totally imagine brewing up an eInk display that grabs X from the internet then draws something via the Canvas API. JavaScript would probably be a fine solution for that.
Yeah, and how is this different from the behavior V8/JavaScriptCore would already have on a system with very little memory? Unless this actually makes it possible to run on lower-memory systems than before, I don’t really see how it’s helpful. Unused memory is wasted memory and all that. I hope it’s using every last byte, not letting memory sit unused.
The bot is rarely used, so on average, it only uses 0.06% of my machine's CPU power. However, it consumes 3% of the RAM at the same time. --smol switch according to Jarred's tests reduces memory usage ~7 times by increasing CPU usage just 2x times. In my case such redistribution of resource consumption would be a clear win!
To save RAM, I actually switched to a 32-bit Python base image. This switch resulted in a 30% reduction in RAM usage.