Memory optimisation ideas?

Hello! I'm back (after continuing to not break my Pixl.js)...

After about a month of development, I've been creating a project with my Pixl.js board which I'm pretty proud about, though there's a small (but currently not-a-big) problem in that the file size in my build folder (bearing in mind that it's all minified using terser) is about 26.7 KB, so it's getting close to the 40 KB limit! I don't expect there to be much more to write any time soon (my project's pretty complete, as far as the Espruino code goes), but it's something to consider.

A bit of background: So yeah, my project is basically an educational OS/environment where people can write their own 'apps' with our IDE, using our API, in JavaScript. The code's minified (again, using Terser) before upload, which is a big bonus considering that one may have a few apps installed and minification definitely reduces the file size. The only problem that remains is if you want to write a more complex app, you run into the high chance of crashing the device the bigger your code gets. A ~1 kb minified app with around 5 numeric vars, 1 bool var, and a couple of ~30 char strings (in some test code/minigame I made) has previously caused the device to crash (not good!).

If you must, the code's here: https://github.com/NanoPlay/os (The photo in the readme will give you a good idea as to how my project operates.)

The problem: My problem is about RAM. How can I optimise using eval to 'open' these apps? The current architecture makes a call to eval once it has read from an app file stored in flash, and then retrieves functions that were instantiated in that eval for processing later. This pseudocode will explain it a bit better:

class AppLoaderScreen extends Screen { // A component of my UI library which enables multi-screen/page navigation
        constructor(appCode) { // When the app is opened
            this.appFunctions = []; // Contains start function, followed by loop function

            this.appFunctions = eval(appCode + `; return [start, loop];`);
        }

        onFirstRender() { // When my internal UI library starts rendering the app screen
            this.appFunctions[0](); // Make call to start function
        }

        onTickRender() { // When my internal UI library renders the app screen from setInterval
            this.appFunctions[1](); // Make call to loop function
        }
}

The actual implementation of my app loader/runtime functionality is here. Specifically, the eval is on line 145.

Enough of my code now! Are there any general optimisations that I can do to improve the memory so that there's plenty of free space for users who wish to write their own relatively large apps? Bearing in mind that my project's use case is kids/beginner programmers, so I don't expect there to be too many colossal projects (otherwise, they should move onto getting a Pixl.js/Arduino/removing my OS altogether if they want the free space!).

Also, one thing that is probably a no, but with regards to the hardware (and specifically the nRF SoC), would there be any way to 'upgrade' the RAM and storage as a simple task of directly replacing/desoldering the nRF52832 and putting in a higher-spec chip (if any)? Then, I would think it's just a case of flashing the Espruino firmware onto the new chip, right? The nRF52833 would easily double the RAM (and the nRF52840 could double the flash and quadruple the RAM!), and I assume it'd just be a case of rerouting some of the PCB traces and then fabricating a PCB that accommodates the pin locations on the aforementioned chips. I'm also wildly guessing the Espruino firmware has some way of detecting the RAM size, and that the chip architecture is very similar across SoCs...

I do admit that I am by no means an expert when it comes to hardware, though! I'm probably quite naïve with respect to the hardware architecture of the Pixl.js board.

Any help with optimisation would be greatly appreciated (I've already tried to implement some of the optimisations on the Performance Notes), but if not, it's not the end of the world! There's a lot to unpick (including my bonkers idea/question at the end there), so sorry in advance if this is quite a long-winded post (probably a book at this point...)!

Thanks,
-James.