...is the title of an inspirational write-up I just stumbled upon. Kind of a manifesto, and part of a bigger series. It speaks of spreadsheets, but Decker embodies the same values. Figured it might appeal to some people here.

(Incidentally, my brain just doesn't get along with spreadsheets, while Decker makes perfect sense to me. But that's why variety is vital.)

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.