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
Instead of auto saving immediately on every keystroke, what if each keystroke started or reset a timer for an auto save that happens after a short time? Only after you stopped typing for a period of time would the auto-save complete.
One way to represent this in the UI would be…
UI state with auto-save enabled:
Circular countdown graph moves around buttons that represent “save / pause auto-save” during a save countdown that change to “saved / undo” when everything is saved.
UI state with auto-save paused:
Circular countdown graph motion disabled, the buttons would represent “save / start auto-save” when unsaved changes exist or “saved / undo” when everything is saved.
Just spit ballin’ here - thanks for a great tool!
I danieljonce,
yes, this is already in our todo list It didn’t make it for the release date, but will be online anytime soon.
Thanks for the suggestion on the visual feedback! I think that initially we will just use very short delays so the feedback shouldn’t be needed. In the future we will consider using your approach! I really like it!
I’ve encountered a new issue due to auto-save.
Warning, DO NOT EDIT YOUR APP ON MULTIPLE DEVICES!
In testing the rendering on my iPhone, I figured I might try to see how the editing works there… spoiler… it works, but it is a bit painful (not so much the editor, but just the phone/keyboard sucks for coding).
Anyway I pushed that aside and went back to my laptop, code, code, code… I made a bunch of worthy progress and went back to my phone to look at it… but because I still had the editor open… in an older state of the code… the auto save kicked in and I lost all my work… not thinking I went back to my laptop, thinking that the phone issue was a caching issue and I hard reloaded my laptop to “pull the true source”… which was now the server version… from my phone, from ages earlier.
I hate to be a squeaky wheel about this, but I’m finding this auto-save to be the most annoying “feature” of Gomix right now. Every time I partially type some code it is trying to re-deploy and throwing errors right left and center… constantly hitting external APIs for content I don’t need to fetch until my next actual save/test.
On a more minor note, with a touchpad as a pointer it is very easy to accidentally select text when scrolling. I ended up deleting a bunch of code accidentally when I scrolled… selected by mistake… then when I went to hit Esc I hit Backtick instead, replacing my code with “`”
I hereby strongly re-request the ability to turn it off. I do not want it turned on, ever.
I’m sorry that happened to you, scunliffe. Just FYI, your mental model of how autosave works isn’t quite right. When two editors are connected, they aren’t saving and overwriting each other’s changes. They are editing the same document, like Google Docs. In your case, it sounds like something went wrong with that, but in general having two editors at the same time shouldn’t be dangerous.
When you were editing the code on the laptop, were you viewing the changes to the site itself, or just editing the code? If so, then we should have a backup of the good code. What project was it, and what time did you lose the changes, roughly?
If you weren’t trying the site while editing, it’s possible that the changes made on the laptop were never saved to the server. This is a little more likely, I think, since they didn’t show up on the phone. If that’s the case, I’m sorry to say, there won’t be any way for us to get them back for you.
We’re putting the infrastructure in place this week to allow you to go back in time in the project, so if this kind of thing happens in the future, it will be much easier to roll back to a working version.
additional note: It sounds like scunliffe hit a (extremely serious) UI bug that may be related to the editor allowing text entry when offline. I’ll make fixing this issue a priority.
(the ideal way to fix this is with local caching of diffs when offline and merging them properly when connected, but we’re a bit far from doing that in the short term sadly)
In this case, I don’t need the backup now as I’ve re-coded everything I lost. I don’t know the specifics of how your collaborative editing works but I’d like to point out that my scenario has some specific differences from a collaborative scenario.
That all said, regardless of how the auto-save works (or doesn’t)… conceptually I can’t stress enough how much I don’t want any part of it. I want an actual save option, that works 100% of the time because it is an IMPLICIT action, not a passive, NON-IMPLICIT action. I will only want to save when I click save, or when I press CTRL+S.
A version history will be great too, but it needs to be per file, and this just seems like a band-aid for the real issue.
There’s just SO MANY scenarios where auto-save can go wrong (only a few have been noted in this thread, none with solutions) that it just isn’t worth the risk of trying to duct tape it to try and make it work.
I have recommended this before, but seem they don’t want to do that feature.
@nampdn Not sure where you got that impression from, our response to daniel’s suggestion was “yes, this is already in our todo list It didn’t make it for the release date, but will be online anytime soon.”
The same thing just happened to me, only I don’t know what key combination triggered the loss.
I was in the middle of typing and all of the sudden the last two characters typed were in a different file (readme.md, where I had been working in server.py). There was a “we seem to be having trouble communicating with the server. Perhaps try refreshing” message from top right.
I switched back to the file I was working in, and the entire thing was blank! Ctrl-Z had zero effect. I reloaded the page from browser (Ctrl-R) and the file is still empty.
Auto-save is cool, but auto-reload without undo is horrible.
There’s another issue with auto-save and auto-deploy when you accidentally create an endless loop.
I had a bunch of code that I wrapped in a for loop… ‘][’ is the cursor:
“for(][){”
I only got this much of my for loop typed in my for loop structure… ‘][’ is the cursor:
“for(var i=0;i<list.length;][){”
because this created an endless loop (it is missing the “i++” iterator), both the editor and the auto-synced view choked. In the end it did come back, but any attempt to type failed because it was trying to execute unfinished code.
I really can’t stress enough how much I am despising the auto-save. Please add the ability to turn it off soon. This will only get worse when dealing with versioning and dev code vs. deployed code.
Sorry about that, maphew.
Your code is regularly backed up while you’re working on it, so we can get that file back for you, and try to figure out what went wrong, if you let us know the project details.
This is similar to the issue I mentioned way up top. I still think auto-deploying incomplete code is really dangerous. Imagine you were typing:
executeSQL("DELETE FROM [user] WHERE user_key = @blah")
If you completed the quotes/brackets before typing the command, this would potentially wipe out the whole table (I know this is a contrived example, but it illustrates that incomplete code can be dangerous pretty well).
I don’t know if anything has changed with this (it’s been a while since I used Gomix; I was just coming to see how things had changed) so if there’s already an option for this, great! If not, I really think it needs one!
Alright,
there is a simple hack you can use to disable auto-rebuilding it won’t disable auto-saving, but it will make sure that changes to the code don’t trigger a restart.
Create a file named .trigger-rebuild and a watch.json file and put this code in it:
{
"install": {
"include": [
"^package\\.json$",
"^\\.env$"
]
},
"restart": {
"include": [
"^.trigger-rebuild$"
]
},
"throttle": 100
}
The only change that will trigger a rebuild is a change to a file named .trigger-rebuild. Changes to .env and package.json will still trigger a reinstall + rebuild. If you don’t like that, you can remove those from the file. Beware: changes to watch.json will always trigger a rebuild.
Caveat: this only works during the editing session. If you close the editor and stay out of the project for long enough (around 10 minutes) the project will be stopped and then rebuilt and restarted the next time it is visited.
I acknowledge it is an hack, but I think it delivers what you want – at least until we implement proper branching and rollbacks
UPDATE: since it is a bit cumbersome to always go to that .trigger-rebuild file and edit it to trigger a rebuild, you can also put this bookmarklet in your bookmark bar, and name it “Rebuild!”:
javascript:(function() { var currFile = application.selectedFile(); var triggerFile = application.files().filter(function (file) { return file.path() === ".trigger-rebuild"; })[0]; if (!triggerFile) { alert("Please create a file named '.trigger-rebuild'."); return; } application.writeToFile(triggerFile, `restart-${Date.now()}`); })()
Make sure you have a file named .trigger-rebuild in your project, otherwise this script won’t work.
To throw in my two cents. I really like both auto-save and auto-deploy for the most part, but do see how both can cause issues in some scenarios. In my usage, the main issue is that I can break the app until I finish typing. For example, my bot stops responding until I finish figuring out some regex. The branching you mention would solve this.
That said, I am wondering if Git isn’t the better place for that. Let Glitch be good at coding and running, and Git be good at versioning and branching. In fact, it’s possible to do branching and versioning today using git import/export. Develop myapp-dev.glitch.com against a dev branch, and then when ready merge to the main branch and import into myapp-prod.glitch.com. Tighter integration (like CI so that merges to git get automatically deployed) could improve that. The argument against this is that it would be harder for users not as familiar with git, but maybe glitch can make it as drop-dead simple as they have the other things
Thanks for your feedback danroot,
this is exactly our direction. We’ll make use of git underneat, but we are trying to make it usable even for people that are not familiar with it. It’s a big task, and we are evaluating it very carefully. We want to deliver the full power of git for the pros, and a clean, fun and functional interface for the beginners.
However, we felt like a temporary solution was needed, as this is one of the most active threads in the forum. So I provided a simple hack to disable the auto-rebuild step.
Thanks again! Happy coding.
I think there is still a huge disconnect here between what developers want and what this tool is providing.
In my local, normal dev environment(s) I have a watcher that watches a directory. When enabled (normal) it detects any new files, file deletions, and file saves… automatically triggering a (build*)/deploy to my SANDBOX environment (*depending on the code base type). This works insanely well because it only deploys files that are saved, and it only deploys to my SANDBOX, so nothing bad with the PRODUCTION version can happen as they are not connected. Pushing to Production is a separate step, done with much forethought due to how dependencies, DB scripts and versions work.
By removing the ability to do explicit saves, you’ve lost the ability to do explicit deploys. I don’t want any files to be deployed/compiled/? until I save a file… explicitly.
Hi scunliffe,
we know, and this is exactly the problem that we will try to address with branching
However, in the meantime (until the branching feature is shipped), the split between “production” and “sandbox” can easily be obtained by remixing. Say you have your app-production project, and you don’t want to live-modify it since it is… as you say, production. You can simply Remix it into a new project with a completely separate env, with different variables, you can hook a different database, and so on. You do your work there, and then you either export/import your work through github, or you rename the sandbox application to app-production.
UPDATE: as I already said, we know this workflow isn’t optimal as it doesn’t support branching. I am just saying that we are getting there. Consider the advantages of always having the same environment in both your production app and in the sandbox. Deploying becomes as easy as renaming a project.
UPDATE take 2: and consider we did exactly this for the revamped community site. Deploying it took 2 seconds (a rename), and worked like a charm. So it is a pattern that can already be used for “production grade” apps.
Done this with gomix quite a few times myself
I would go further than this… Once an app is “live” (eg. not just a dev hacking around to test stuff out) I wouldn’t want anything deployed unless it is committed to source control.
That said, it’s possible this branching feature will provide exactly that; it’ll be interesting to see how it works once it’s available.
OK, I have a partial solution.
You can instantiate a git repository in a glitch project. So you can commit your work, make changes, and if you need to recover files, you can do that by
git checkout <file>
And you can do any other git command that you would like as well. So all the power of git and the power of glitch combined.
For example you can do:
git reset --hard HEAD and throw out all your changes since the last commit
The project is here.on glitch
It’s also on github, here. So you can clone the remix the project on glitch and fork the project on github and export your changes and send me a PR.
You can also join the project here.
The README.md gives all the details
Thanks for the offer Tim, but I didn’t see it in time. I took a 5 month holiday from Gomix/Glitch instead.
I had a similar lost content event today, but nowhere near as serious, only losing 2 lines this time. It’s related to network connectivity. The safe thing to to do is to completely stop any kind of typing when there is “Reconnecting…” message at top right, except to copy everything from the current window to somewhere else for safe keeping.
I get the reconnecting message several times an hour, sometimes several times in a few minutes. Other browser windows do not show a connection problem, but their behaviour is quite different. Almost all passive consumption (reading, searching, etc.). My suspicion is that my upload link is too slow or has high latency.
I accidentally made something popular, and I’d like to develop it further, but I’m afraid that it’ll break for users as I’m hacking on new stuff. So I guess I’d like to be able to brach the project, hack around with it, then merge it back into the original when I’m happy.
yup the flow we’re using to develop the community site without breaking it is to remix your project, make the changes you need to make, then export your remix to a github repo, then import that repo into your existing project.
We’ll eventually have something better, but it’ll take us some time to get there
I know that I’m “late” in the discussion, but I want to bring out a separate point that might be very important.
I don’t make express apps. I actually make discord bots. I am constantly on the prowl for interesting free VPS that the people that I teach bot making to (more often then not, young teenagers with little or no money) could use to host their small bot projects.
Most VPS’s are either too complex to use (see: heroku) or can’t save data locally (see: heroku).
Now beyond the fact that Glitch can save data which is great (JSON, SQLite, etc), there’s one tiny bit of an issue that’s covered here but is actually a really hard barrier to using Glitch: Discord Bots are limited to 1000 “logins” every day. If a bot logs in more than 1000 times, it’s considered to be “broken” (or glitchy, lol) and its token is reset so that it stops spamming the API.
Now here’s the problem: If your editor constantly auto-saves basically every single character I write it means every single character causes a reload which then causes a login, which obviously is going to be causing these serious API-spamming issues.
And this affects any sort of code that, on load, does any sort of query on a rate-limited system.
And - sorry if I ramble on a bit here - some solutions here include “push with git”. Well, I’m sorry but your front page clearly shows you targetting people even younger than my base clientele of 13 year olds (I think it would probably attract my 6 year old daughter, visually) but you want people to use a git push system… There’s quite the schism here.
Using a watch.json file in your project to override the default behaviour for specific files or file types would seem to workaround this issue: https://glitch.com/faq#restart
Understandable that watch.json is a workaround for it saving every word I type and restarting the app. It does not however sound like a proper solution, since then you are ensured that whatever “delay” you put in the watch.json is however long you’re going to have to wait for your app to restart when you are ready to push the changes.
This issue’s been going on since April 2016 and no one’s cared enough to make a “Disable auto-save” checkmark that stops the front-end from saving automatically?
It’s not a lack of care, it’s a product decision to help avoid unnecessary complexity for the majority of use-cases. For the most part it’s fine, but there are edge cases that make it difficult and we’re always considering the best approach as new constructive feedback is provided.
There’s been constructive criticism and people asking for this feature for 17 months. Are you sure you’re considering it, because from the point of view of someone coming into this conversation from April 2016, in September 2017, it really doesn’t seem like you care to implement this.
Simplicity does not, and should not, trump functionality. For the user it 's a checkmark in a drop-down that’s on by default and that people like me can disable if we want to. No harm done, but you’re making all the people in this thread happy.
I know this sounds really simple, but it’s not as easy as it seems. Adding the checkbox is, although we do want to be careful about adding too much noise to the UI. The hard part has to do with the way the editor works. Because we support multiple people editing a file, it’s not as simple as the client sending the current file to the server and saying “save this”. Instead, each client has to send its changes to the server, where they’re applied to the server’s copy of the file, and then passed on to the other editors. This raises some interesting questions:
If we disable saving, how does that work with multiple people? If your user preference says “save immediately”, and mine doesn’t, and we’re both editing a project, what happens? Maybe we could get past this by making auto-save a project setting rather than a user setting?
If saving is disabled, how do changes propagate? You enter some text, and it’s sent to my editor as well, but not saved on the server, right? When you hit ctrl-s, is that only saving the changes you made? That would be pretty complicated - we have to keep each user’s pending changes, and we would have to resolve what is essentially a merge conflict automatically. Does it save the most “up-to-date” version of the file with both of our changes? Maybe I’m in the middle of typing something and you just saved a broken version of the code.
Another question is, what happens if your changes don’t get saved? If you close your browser tab and forget to hit save, your changes are just gone? We can make the browser give you one of those annoying “Do you really want to leave?” dialogs, I guess. What if you just lose your connection? I suppose the server has the latest code in memory, and not saved to disk, but that’s going away in 10 minutes of inactivity. Maybe we could store your unsaved changes in local storage in the browser, and sync things up when you reconnect?
I agree with you that it would be nice to have the option to disable auto-save, but it will take a noticeable amount of work, and we don’t want to get it wrong. I would be interested in everyone’s feedback on the questions above.
We’re a small team, and we’re also working on a lot of other things - see all of the changes to Glitch in the last year. It’s certainly not true that we don’t care about the problem.
I would also add that I think you are missing the full power of watch.json. The throttle is not the only option you can change. I actually wrote about a solution that is exactly what you are looking for earlier in this thread here.
We’ll add a more detailed tutorial
Alright, you bring interesting, valid points, so let’s address them. I could say “yeah well it’s your job to figure these out, like, 17 months ago” but that would just be copping out, so I will make the effort to try and show how they can be resolved from my point of view. So let’s do that.
I’ve seen many people bring up the point that collaborative editing is not the end-all be-all solution to everything, and I’m going to bring it here: If I’m the only one working on a project, and no one else is there, why would I possibly be concerned by this as a limitation? The answer is, of course, that I’m not, personally. And others aren’t either.
That being said, there’s a solution. Collaborative editing can happen without saving to the server. All you need is a websocket messaging server that transfers this information between clients without changing the file and HEY look at that, we have a solution. Presumably, one that involves actual communication between people where they decide if they’re ready to save the file or not.
Using the above example of a simple websocket messaging service to propagate changes, the point is essentially moot because anyone saving the file saves the same file for everyone - the “live editing state” is a different one than the “saved, running” state and that is fine. There are plenty of possible visual cues to indicate that a file isn’t saved, and people can decide, together, whether it’s time to see if the code runs.
Let me bathe in my brilliance here for a moment and state that this also prevents any conflicts since you’re keeping the fully collaborative live editing (you’re doing it anyway you just need to make it not persistent to disk).
You seem to have approached this issue in the same way Google does it with Docs - auto-save is law there, and that’s great. You’re not dealing with a word document. You’re dealing with code that may have massive, damaging side-effects if saved at precisely the wrong time. Plenty of examples have been provided here from partial SQL queries to external API queries.
I have to specifically and very loudly laugh my ass off at this one. Seriously this is exactly why your damnable auto-saving is so bad, are you seriously bringing it up as a point of why it’s particularly good? I just can’t… I can’t even.
You just painted yourself into a corner that has a big bright yellow neon arrow sign that says “SOLUTION HERE”. Yes, absolutely, quite logically, one could save data using our modern browers’ ability to save data in the event of a loss of connection, crash, shutdown, or nuclear explosion (ok maybe not that last one). Does it bring additional complexity to the process? Yes, for those who collaborate, there is a certain amount of thought that has to go into it.
One alternative way to deal with this is, the editor would react in the same way as, say, C9.io does when I lose connection. A big, bright, yellow warning banner at the top that says HEY YOU LOST CONNECTION. This clearly indicates you can’t make changes anymore, and prevents conflicts completely.
So this can go either way - either you disable editing in the event of a connection loss (as C9 does) or you store data locally and the deal with conflicts later on.
Conflicts is of course another sort of solved problem, as it has been an “issue” in versioning system for decades. Look to those systems as inspiration on how to deal with them. Can we merge? is there actually a conflict? Were we editing a completely different part of a file or simply a different file? Is there a non-confusing way of displaying conflicts like github does?
How about a nice possible middle ground? A MVP if you will. Give me an option to disable auto-save if I’m not collaborating. That gives you time to work out the kinks of what can ultimately be a solution (such as my websocket messaging above) and does actually pacify those of us in need of an actual solution.
Then, the second step is to disable editing on communication loss, with the websocket idea. No conflicts, no problem. And finally, the implementation of the fully functional death star safe collaboration space: conflict resolution (I sound like I’m in a gender studies debate lol).
I’m not saying you don’t care about Glitch itself, or that you’re ignoring everything and everyone generally. I’m specifically and only saying, this exact issue seems to have been poorly handled in the past year and a half. During that time you seemed to have changed your name twice. Sounds like wasted brainstorm sessions that could have been used to answer these questions much sooner.
With that last bit of sarcasm set aside, I’ll continue monitoring this thread and I’m open to further questions and suggestions.
Perhaps you should write a Glitch.com alternative, for free, while trying to earn your actual living, and then you can show them how to respond immediately to every request someone deems their personal pet issue? Also, then you too could demonstrate to the Glitch-team how to respond without ‘that last bit of sarcasm’!
I mean, just take a minute to look at your own response! You offer up a bunch of counter-points and explanations for potential solutions and your response goes on for what feel like 3 pages… all of it is merely conceptual, none of it is actual code having to be maintained or deal with any real-world details and edge-cases… 3 pages of simple high-level concept solutions! There’s an awful lot of code, testing, and complexity buried under those 3 pages!
It’s true, I’m being critical. But as a professional developer myself, threads like this are unfair. The product is free. Offer to help and you might have a point. But didn’t your parents ever teach you to not look a gift-horse in the mouth?
Quick note on this thread — we welcome feedback, and debate over the prioritization our team makes on shipping features for Glitch is always an interesting topic to discuss. But please do read what it says the first time you visit Glitch: “Glitch is the friendly community where you’ll build the app of your dreams”.
This thread isn’t friendly, and doesn’t model the behavior that will make people who are new to coding, or new to Glitch, feel welcome. So this thread is done. We’re working on our explicit policies for this support forum, but in the interim let me make clear that this is not how conversations will be carried out in any part of the Glitch community.
Thanks to everyone who is passionate enough about Glitch to express their opinions on what we’re doing. We’ll take the substantive points into consideration going forward, and also the broader lesson about making clear our community expectations.