Auto-saving is cool - as long as you never make mistakes!


#41

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.


#42

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.


#43

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


#44

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.


#45

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


#46

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?


First View from a new Dev
#47

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.


#48

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.


#49

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.


#50

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 :slight_smile:


#51

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.


#52

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?


#53

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.


#54