I’m sure there are many people that will love the “Apple way” where everything is just auto-saved for you… but I’m the kind of developer that has been burned more than once by auto-save and has lost work due to an overwrite of content that I didn’t want saved.
TL;DR feel free to keep auto-save as a default option, but I’d really like the option to turn it off.
Hi 
thanks for your interest in the project and for your feedback!
The intention with auto-save is to keep a very tight visual-feedback cycle: you continuously see what you write, deployed in real time.
We are very aware that this approach has its limitations, and one of your future goals is to add lightweight snapshot/versioning to projects. Might this solution work for you? Do you see edge cases in which this might work worse than simply disabling auto-save?
Your feedback is welcome and needed Thanks!
The issue is that we developers are all human. Normally in our editors/IDEs we do a bunch of work, and when happy with it, we save.
Every now and then something goes wrong… our mouse/OS/app decides that the cursor is down and is selecting content… we freak out cause it wasn’t supposed to be, we click somewhere to “dismiss” the selection and find out we have actually “moved” the selected chunk of code into a new location (something we had no intention of doing).
CTRL+Z and the problem is solved (or we simply don’t save, ditch any changes, re-open with our last saved changes e.g. Parachute FTW!)
Alternatively we copy/paste the wrong thing to the wrong location… highlight a chunk of text to copy it out but accidentally cut it… or the cat walks on our keyboard and types over the highlight.
CTRL+Z and the problem is solved (or we simply don’t save, ditch any changes, re-open with our last saved changes e.g. Parachute FTW!)
However with auto-save turned on all the time, you run a very high risk that you will blow away your ability to recover if something went wrong (this is all outside of source control).
TL;DR If there is no way to turn this off, I would do ALL of my editing in my own editor… then copy/paste to HyperWeb in order to “deploy” changes. I will never (personally) use a code editor that auto-saves. (excluding to backups, or crash recovery files)
I agree that some sort of versioning is essential.
Here are some ideas/edge cases:
Thanks to both of you for your valuable feedback
Version control is definitely on our list of things to implement, and it is very high on that list.
I don’t think we would ever have a toggle to disable autosave, but that would probably be redundant with proper save/snapshot/versioning and branching in place. If you think differently please let us know because we strongly belief that always keeping the “feedback loop” between what you write and what gets deployed is one of the core values of HyperDev as a product
As long as the end result is “if autosave cant be disabled, but I can go back in time to a previous snapshot to recover from an accident” then I’m ok with it.
However like I originally stated, I would personally prefer the ability to disable it. There’s a good reason why I don’t have autosave turned on in ANY other piece of software I use… Because when (not if) the ‘fit hits the shan’ I don’t want to lose anything. Nothing will cause customers to leave faster than lost data.
(note autosave as a “backup” is 100% fine, and desired!, just not as the control of the actual file)
I have a couple of concern with auto-save 
You could be executing incomplete code… sometimes this could be dangerous!
I know it’s not normal that we’ll be writing shell scripts here, but while I was (to get Dart working), it was constantly executing while I was typing commands. In some cases, half-typed commands are valid and do things you don’t want. Eg:
mkdir mything
This could end up creating directories called m, my, myt etc. if it was being executed as I typed.
Obviously it’s not a great example, but if you’re writing code that manipulates data in a server-side datastore maybe there could be similar issues.
Sometimes it can also just be annoying… I was tweaking some CSS and I got interrupted… when I looked back at my screen, the live app and reloaded and the styling was really broken so I’d totally forgotten what it the styling tweak I was trying to make was (because I couldn’t see the original bad version). Sometimes it’s handy to see your app as it was while you’re deciding how to fix something.
Finally… sometimes you’re causing so many reloads (and they may be slow, eg. if it’s installing npm packages) that it’s hard to know if what you’re now seeing in the app is caused by the reload from your last keystroke, or when you were halfway through typing something. Sometimes I find myself waiting around and scanning the logs window trying to figure out whether it’s rebuilding again or my change was bad.
I really think there’s value in allowing people to disable it. I’d rather have to press Ctrl+S after every change to have the app reload and at least know it’s loading what I wanted and not some intermediate state.
How about something like Etherpad’s timeslider feature? It literally saves every single keystroke ever and gives you a slider to go back arbitrarily in time. (Actually Etherpad’s implementation is kind of broken, but that’s the idea.)
Probably a bad idea.
But I like the idea of a simple Checkpoint aka Snapshot button. And maybe that’s what should trigger a deploy too. [EDIT: I’m really loving the idea of having the tightest possible feedback loop but @DanTup has a pretty compelling counterargument.]
I don’t like the idea of just letting some people turn off autosave.
This seems to be going nowhere really, really fast.
I’ll be blunt. If I don’t have finite control over when I can save each individual file, I will ABSOLUTELY NOT be using this software, plain and simple. Even if everything else it does is the best thing ever created in CS history.
I’m not saying turn off autosave for everyone, I’m just saying there is a HUGE community of developers that have been burned more than once when software “tries to guess what we want”. By providing the option to turn this off and present a discrete Save button is incredibly simple, I’m failing to see why there is such stubbornness to give users what they want?
If I am working on a project… and I have 3 files I’m “working on” shuffling bits of code back and forth between them as I re-factor… trying to deal with 3 individual timelines to scrub back on to get back to the state I want is going to be a real pain in the butt. If however I can work on them… then every 5 min or so when I’m confident I like the state I’m at… I can save them (or a set of them) then I’m good.
For anyone that still isn’t grasping the issue here, pretend while you edit your code right now in your favorite editor/IDE that every ~30seconds your code is auto-commited and pushed to your repo! Is it backed up? yes. Can you roll it back if you need to? yes. Would it be a royal PITA? you bet!. It is much better if the person that knows how good/stable the code is - is the one in charge of saving/versioning.
Hi scunliffe,
don’t be worried, we hear you Your comments raised interesting conversations and thoughts inside our team, and we are carefully considering every feedback that our users are sending us.
Even if the situation can change in the future, our major concerns right now are:
We are trying to provide you with an opinionated workflow. And our opinion is that the workflow should be centered on continuous feedback. It’s tough for us to give up on this if you don’t provide a compelling argument for the contrary. You already have unlimited Ctrl-Z history, and we will provide you with snapshots and rollbacks, that are exactly the same, if not better, than “save when you feel comfortable”. On top of that we will also provide branching, so that all of your experimental code will stay safe and happy in a separate branch. Can you please elaborate on what additional advantage “disable auto-save” would provide?
Disabling auto-save would make it a bit more complicated to handle the multi-member usecase. If you invite someone on your project, (s)he can collaborate with you, live, on the same code. Handling the auto-save-off case in this scenario might lead to unexpected situations.
If you are worried by the unexpected results of half-typed code, there is already a very simple workaround (it’s not polished, but it is very effective): just remove or change the line in package.json that defines the start command. If you put a bogus command there, it will just not run your code until you feel comfortable.
TDD might help you feel more comfortable on the state of your refactor, there is an example app in the gallery that shows how to use mocha as a precondition for running your app: https://hyperdev.com/#!/project/blossom-scorpion
Stay tuned, we really hope to accomodate every complain and hopefully you’ll end up enjoying HyperDev as well
Thanks for your feedback!
Hi etamponi,
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.
Cheers,
Steve
Again, thanks for your reply
I think that we are actually on the same page as for 1 and 1b, I did not get that you wanted auto-deploy while disabling auto-save! Now it makes a lot more sense, and it is exactly what we want to address with our “branching” feature, that would also provide sandboxing. I am not only an HyperDev developer, I am also a quite active user, and I had “production” code running and serving a lot of people. I had the same problems as you: I needed a sandbox (what I’d like to call a branch) for testing the new features, and then “merge” on the “production” branch. So don’t give up on HyperDev too soon Check back in from time to time, I am sure we will deliver what you’re asking for really soon! A lightweight branching implementation is already planned for the next few weeks.
Thanks for your thoughts on 2, we will definitely take note of that
As for 3, you’re right! I would just like to provide a simple workaround for now… I am not suggesting you to take that as an habit or a definitive solution!
We don’t get into agreement about TDD, but… well, this would turn into a never-ending thread and also quite off-topic, so eventually in the future we will have time for a fight (a costructive one hopefully! 
) on best development metodologies
Heh heh he
Thanks for the quick reply. 
As for the TDD discussion I’d be happy to have a fun friendly debate over it… over some wings n beer (or a non-meat/non-alcohol equivalent) should I ever be in the NYC? area. As Jeff Atwood would say, “I have Strong opinions, weakly held”… thus I’m always up for constructive debate/ideas.
I feel that there’s another topic related to auto-save, something like auto-release and auto-deploy, worth discussing here.
As I currently understand, the auto-save is also triggering a (implicit) release and deploy of the code. But next to the merits of auto-save, normally I want to have control on what/where/when gets released (“yeah, this is the version that I want to give others access to”) and deployed (“yes, push this to the production service.”)
The current always-on save-and-automagically-release-and-deploy (as I understand it) might work for things like document editing like Google Docs, but for anyone past the novice level in developing software and using it in a production-like setting, I’m not sure.
And then there’s another important discussion: how to rollback to a previous version (and specifically which version)?
This is our bet
We do think that immediate-release-and-deploy is not only viable, but also beneficial for app development. HyperDev has been build to “prove” (or… disprove, eventually) this assertion.
As for critical apps, or apps for which you don’t want to risk to cause service disruption while developing, we are planning to add a “branching” feature, so that you code and deploy your branch (separately from the production deployment) until you are done and feel safe to “merge” it back to the production branch. This is more or less the same workflow you can expect on your own dev environment, with the added benefit of immediate and automatic app deployment.
On our favor, we can already say that some part of HyperDev are built using HyperDev itself So even without the “branching”, we feel it is already strong enough to support the development of important apps. Of course branching will provide tons of benefits and we are working towards implementing it.
Again: it’s a bet… we really believe in it, and we are all but novice programmers Let’s HyperDev talk for itself, with your help of course
Hi,
Ha, that never was my suggestion. Sorry if it came across that way.
Thinking bits through, there might be another area where ‘auto-save-becomes-auto-deploy’ is tricky, being the persistency level. How to handle schema migrations, record upgrades (and rollbacks in case of problems in production)? Normally, these are explicit actions in a release-and-deploy process.
Since HyperDev itself will also have some persistency level, and auto-save seems to be working for you, you might want to provide some documentation and helpful guides how to cater for such needs. (That is, if you are using persistency in the parts where HyperDev is used in building HyperDev.) If I may make another (and last) pointer to Heroku, I really appreciate their developer documentation, both on how to use their platform and basic features, as on how to make necessary changes when their service is changing (like platform upgrades, deprecated APIs or new features).
(Oh, and it might be us guys ‘from the old world’ trying to grasp how things work in your world 
Please keep challenging and changing our way of thinking.)
This sounds like the best of all worlds. Btw, I love the opinionatedness!
I’d just like to re-emphasize the importance of some kind of sensible snapshotting feature. I accidentally deleted a few paragraphs of code, closed the browser, and lost my undo history. It was very frustrating to be unable to recover that code in any way. This is giving me a bit of a fear of using this tool, and hesitate to recommend it, though I otherwise love it.
Autosave in combination with forced reloading has destroyed my work.
I mistyped ^A ^C and pressed ^A ^V instead. In just that moment, hyperdev first autosaved and then reloaded my project, leaving me with an almost empty file and no way to undo anything.
If I was using HyperDev for a real project and not for playing around, I’d be mightily annoyed.
Jeremy, zocky
You guys make a great point. History management (being able to rollback to automatically saved states) is definitely on our roadmap. It’s a major problem for us when people approach coding with trepidation of any kind