With SPIFFS - perhaps we could look at some kind of abstraction given we now have Linux, FATFS, FATFS over Flash, and maybe SPIFFS - it'd make things a lot tidier. Had you considered using the FlashEEPROM module?
I took a quick glance at FlashEEPROM, and it has many of the same problems as FAT... no wear levelling, no use of the ability to change any '1' bit to a '0' bit etc. Granted, the W25Q128BV has a lot of erase cycles for an SPI flash part, but since the idea is for other people to write whatever they like, I don't really like having them beat on the same sector until it dies.
As for an abstraction layer, I suspect that the limitations of special use things like SPIFFS would either make the abstraction too limited, or make everything in it "optional" or "emulated" thereby making it almost useless. I think that using a common API when possible is likely more useful than an abstraction layer.
With the IDE - you could try running the 'IDE server' - espruinowebide on NPM. That'll run a Node.js app and then serve up the IDE over HTTP. Might be a good way to sidestep any chrome issues?
I'll give the espruinowebide a shot, though Node.js support on FreeBSD tends to be worse than Chromium support... for example, node-serialport has this beauty:
var linux = process.platform !== 'win32' && process.platform !== 'darwin';
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
I took a quick glance at FlashEEPROM, and it has many of the same problems as FAT... no wear levelling, no use of the ability to change any '1' bit to a '0' bit etc. Granted, the W25Q128BV has a lot of erase cycles for an SPI flash part, but since the idea is for other people to write whatever they like, I don't really like having them beat on the same sector until it dies.
As for an abstraction layer, I suspect that the limitations of special use things like SPIFFS would either make the abstraction too limited, or make everything in it "optional" or "emulated" thereby making it almost useless. I think that using a common API when possible is likely more useful than an abstraction layer.
I'll give the espruinowebide a shot, though Node.js support on FreeBSD tends to be worse than Chromium support... for example, node-serialport has this beauty: