Could you say a bit more about your workflow? I'm used to having source code files open in emacs (or zemacs) and a lisp REPL in another buffer. I edit the source files directly and then recompile changes into the running lisp. The code stays in sync because the text code files are the master copy and the running image is updated (when I choose) to reflect changes. Program state (e.g., large data structures) isn't generally kept in the source files. If what's in memory needs to be preserved, then I need to have serialization and deserialization methods, or a database, or I need to save the running image to a snapshot file. I've probably so internalized this process that there are problems with it that are invisible to me.

So SmallJS works the same way. Update text files, press Run and the 'image' is updated in a second or 2. But it contains only code, not data. And I think that's a good thing..

The advantage to me was having persistent data in memory and stored in the image. I used a function ‘ll’ to reload all source code. I stopped using this technique when computers got faster so loading many data sources was not as consuming. Also, for my application I noticed that LispWork’s file IO ran much faster than SBCL so I used LW.

Still, working with images in SBCL is a good technique. Command line utilities built as separate image files load very quickly, and then you get to write utilities in Lisp rather than bash or Python.

You comment is more about LISP, but just to say that in SmallJS, you could write small command line utilities easily, that are started with the Node.js runtime quickly. And yes, the edit - recompile - run loop in SmallJS takes a second or two, so working from an image (with possible side effetcs) is not really necessary.