Thanks for your reply... and yes I'm glad these thoughts aren't going to dev/null.
1.) I agree with and like the idea of continuous feedback... which I'll call "auto-deploy". however I don't feel that this needs to be tied to how and when the files are saved. e.g. if I use https://jsfiddle.net/ I have the option to choose when I want to save.. but if it also auto-deployed the changes to the preview window I think that might be a really nice feature. Thus I like the idea of auto-deploy (to a sandbox), but I don't like the idea of auto-save (other than as a crash backup)
1.b) Related to 1 above, I think there needs to be some clarity between a deployment sandbox and "production". If I am writing some SQL that runs when a user clicks a link/button...
DELETE * FROM someTable WHERE key=1234
If the app saves my content as I type... AND it is auto-deploying it to production... then what happens when I only type this much and it saves?
DELETE * FROM someTable
I'm not going to be impressed... and no level of "scrubbing" back in my timeline will un-erase the data from the DB.
(I realize this may not be applicable quite as coded above, but these are the gotchas that come into play as soon as you start auto-saving)
2.) I'm not currently using the multi-member scenario... but if this exists I think the issues with auto-save actually multiply. The reason why we use version control (without checking out and locking files like in 1995) is because 2 or more developers need to be able to work on the "last stable version" of the code at the same time. If there are no conflicts when they check their code back in, great, but if there are, then the 2nd/Nth developers need to carefully inspect and merge their changes back in. I'm failing to grasp how this will work if multiple coders are hacking the same file at the same time... but moreso I see zero productivity in providing this as a feature (on the same file) without very careful oversight/monitoring to avoid collisions. I tried this with co-workers back when Google Wave came out. It was really neat, but ultimately infuriating to try and be productive.
3.) This is contrary to current developer flow of the past 30 years. When I want to make code changes... I just make them. As long as I don't push/commit my changes, its all local, nothing breaks, no kittens are injured. To change mental behavior so that I have to first think... ah, wait... "go offline" first... then make changes... is going to be very weird.. and only serves to highlight the issue with default auto-saving.
4.) TDD is a controversial subject. While it does provide a certain level of confidence for some developers, I'd argue most seasoned developers want to get their initial ideas out without being mentally railroaded to "think different" and solve non-application problems first. While I get that some developers love drinking the TDD Kool-Aid.. I personally will likely never be one. It kills my productivity and turns coding from fun into a chore.
Admittedly I may not be the ideal candidate for this tool. I may keep it in my back pocket as a quick prototyping tool before moving the code off the tool into my regular development process/tools. Unfortunately unless there are resolutions to the above issues (1, 1b, 2) I don't think I'd be able to use this tool from "Professional Production" development... just for "Script Kiddie" tasks.