Hacker News new | ask | show | jobs
by Snappy 3167 days ago
A web IDE is a great start, and as Sid already pointed out, at GitLab we'll ship an IDE deeply integrated with version control (and CI, CD, monitoring, etc.) in 2018.

But that only covers part of the problem. A lot of the post revolves around newer concepts of realtime as exemplified by Google Docs. Specifically I mean:

* Realtime

* Collaborative

* Versionless

An IDE is obviously realtime, but our focus is on single-user realtime, at least initially. CodeEnvy, Koding, and others have created shared editing environments, so maybe that's a pattern that works. But that still doesn't sound like what the author is really looking for. These are editing environments built on top of git so require the same branch and commit model. e.g. if you forget to commit your changes, anyone looking at the code outside of your (shared, collaborative, online) environment won't see it.

I've been wondering for a while what the next iteration of VCS (or DVCS) is going to be, and I have a hunch it will involve realtime.

What would it look like if the underlying VCS was realtime itself? If it worked like Google Docs?

I imagine it kind of like Google Docs's "suggesting" mode, where edits are shown on the mainline, but as suggestions which can be accepted or rejected. That's kind of like merging a merge request or pull request. But it doesn't seem to scale well. Imagine a doc with hundreds of simultaneous suggestions on the same code, especially stale suggestions that you aren't going to merge, but aren't ready to delete either. Would you switch between groups of suggestions/suggesters (like you would switch branches)? Would you just not work with long branches? I mean, that's an anti-pattern anyway. And don't even think about branches of branches or applying a patch to the last N stable branches. But if you're doing continuous deployment to a web product, those patterns don't apply anyway.

Would being forced to see all the suggestions trigger latent OCD and cause people to clean them up constantly? Or would it turn out not that bad because you're only seeing simultaneous changes on a single page at a time?

That brings up another challenge, changes that spread across many different files, but need to be considered together to make sense. Google Docs rarely have that problem. Maybe that means that it's inherently incompatible. Maybe it just needs a new solution we haven't seen yet. One idea comes to mind: the way recent editors show a mini-map of a file, and when you search, all search hits are highlighted on the mini-map. Extend that in some way so that when I'm looking at one suggestion, related suggestions are highlighted for me. I don't know, might be a dumb idea, but the point is that some thinking out of the box might solve this.

Google Docs (and realtime collaborative editing in general) were such a game changer that people flocked to it even though it was seriously under-featured compared to Word. Sure, tons of enterprises are still on Word, and there's a bit of a gap between companies that have embraced Docs or not. But for those that did, it's changed how we work. Keeping everyone in sync is far more important than having 10,000 options for making words follow a curve in 3D.

I wonder if some realtime version control, applied to code, will open up new ways of working we can't even conceive of today, and we'll slowly forget that we once loved the branch and commit model.