Comment by kajecounterhack | Hacker News Reader

Comment by kajecounterhack | Hacker News Reader

Parent Full thread

kajecounterhack

1. A web IDE is widely used at Google and has instant syncing with the file system so you can use your local editor and immediately see the changes in the IDE. This is probably helped by the fact that your "local" code is actually a distributed filesystem mounted via FUSE.

2. Features of the web IDE that people love: it works offline via caching and syncs back up the same way you expect an offline Google Doc you were editing to sync. It has plugins (e.g vim bindings) that are most common feature requests from developers. You can build your code very quickly (yay distributed building). No startup time, it loads close to instantly like Google Docs does. Split pane editing, debuggers, linters, etc all built-in. Code search also built in, review tool integration, version control integration.

3. Outside of Google people don't want to pay a 3rd party to allow editing / storage / access of their code; it mostly comes down to "if I get used to a tool I need to be guaranteed it will be around forever," (open source solves this), "I want full control of where my code lives" (on-premise solves this), "performance + features" (not sure if this has been solved anywhere, like being able to modify your code locally and remotely and sync instantly)

Thanks for the feedback, very interesting.

1. So the web idea syncs with the distributed filesystem before any commits are made. We plan to sync the filesystem of the application development container to both your local filesystem and to another container that runs the web idea. That would allow for the same effect, or not?

2. Pretty cool it has operational transformations (OT). We looked at this but it seemed that you either have to pick someone with OT or something that works well with code. We're not doing distributed building but we're considering distributed testing https://gitlab.com/gitlab-org/gitlab-ce/issues/19267

3. Yeah, this would work on your local GitLab instance, no third party needed.

1. Yeah, but it needs to handle unstable web connections gracefully. There's no locking in the UI even when your connection goes down, and when it comes back up it just uses last edited version (whether you made changes on your desktop or in the browser). Definitely tied to #2, which is that you need a sane way to merge conflicting changes.

2. I don't know for a fact they're using OTs but given that you can edit from local / web pretty much simultaneously that's a good guess. Since you don't generally get actual simultaneous edits however (or you don't really have to optimize for this use case since a dev is either editing from the IDE or locally and "simultaneous usage" would generally be a product of network latency), one idea is you could use a tree-like CRDT that tracks divergences and have a UI element that allows nice manual conflict merges. Or you could invent an automated merging strategy, which may or may not be pretty hard.

2b. in re distributed building, https://www.bazel.io Google actually open sourced their build system but I'm not sure (I don't think) the distributed building aspect of it is included. Here's to hoping some headstrong engineer decides to write the open source version of it...that said it's probably not actually that important for most software

3. Cool. I'd love to see something like this from Gitlab! I think once people feel that they have control over the software and their code, it's all about usability, and if you nail that there will be plenty evangelizing the solution.

Great insights and cool to see Bazel. We'll start simple with the terminal https://gitlab.com/gitlab-org/gitlab-ce/issues/22864 and editor https://gitlab.com/gitlab-org/gitlab-ce/issues/22876 and keep iterating from there.

> "if I get used to a tool I need to be guaranteed it will be around forever," (open source solves this)

It solves it partially, but it creates a new problem: if the supporting OSS team that does most of the maintenance of the IDE goes away, you've traded one problem for another. If you want to keep using it forever, you'll need to keep maintaining it forever.

Any idea why that web IDE at Google isn't part of Google Apps For Business? Sounds like it might be a good fit.

Google was working on a web IDE called Brightly back in 2012. But instead of releasing it as a commercial project, the company released the open source Collide project instead. I'm not sure how much of Brightly went into the web IDE now used internally.

Reply on news.ycombinator.com