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.

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!

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.

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.

I was editing from 2 locations with the same user.

I was interacting with Safari on an iPhone… which means that it very likely may have reloaded/re-posted when coming out of sleep/hybernation… because, well, iOS Safari is bonkers and you can’t turn off the unnecessary reload

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.

@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.

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.

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!

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!”:

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

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.

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.

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.