Many of the requirements in this manifesto seem strongly oriented toward a statically-compiled system with a complex backend, but Decker does check a number of boxes:
- We don't need hot-reloads or live "previews"; everything in Decker is continuously interpreted on the fly. Likewise, we don't really have any concept of a "deployment" lifecycle apart from occasionally exporting .html builds of decks.
- Decks are single self-contained files which are, nevertheless, line-oriented, so you can dump them in the moral equivalent of a dropbox and get "atomic" updates or use a traditional VCS like git to manage changes.
- Using lilt to perform "headless" automated testing with the same scripting APIs as ordinary interactive Decker offers pretty handy facilities for testing. It's certainly possible to rig up test fixtures to run continuously as a deck is updated, but it isn't a default.