3 ms·
Also in this space, some Atom devs are working on a new editor/engine in Rust and have recently shifted focus to CRDT as a way to get collaborative editing and
by colemickens 8y ago
Also in this space, some Atom devs are working on a new editor/engine in Rust and have recently shifted focus to CRDT as a way to get collaborative editing and advanced SCM-like scenarios.
The editor is called 'xray' and the CRDT tech is Eon. They have some info here and you can find more in the repo/branches.
https://github.com/atom/xray/blob/master/docs/updates/2018_05_28.md https://github.com/atom/xray/blob/master/docs/updates/2018_0...
If you're into the client/server model of Xi, xray is targetting the same, including an in-browser experience connecting to a remote backed. Similarly, there is Theia-IDE which actually seems the most advanced in terms of a functional in-browser editor with a client/server model.
I think these tools are going to enable entire new generations of programmers on super low end hardware where their editor services and toolchains are running in a remote DC.
There are others in this space with similar tech, but most seem focused on very specific niches and use cases. If there are other softwares that hit the collaborative editing, CRDT, and in-browser experience points, I'd love to hear about them.
- iainmerrick 8y agoHmm, what does low-end hardware have to do with it? I can’t think of any challenge in text editing that requires beefy hardware. Coordinating multiple editors is tricky, yes, but it doesn’t need fast hardware, just good software and ideally a reliable network. Editing text on a phone is hard, but that’s a UI problem -- it’s the small screen and lack of a keyboard. Most phones these days have very capable CPUs and plenty of memory. (I agree that this technology is very cool, though! I’m just curious why you pick out that low-end use case.)
- trishume 8y agoI agree with this, but one thing they might have been going for is editing code that you then compile and run on a beefier remote server. Although you don't need a full CRDT for that, it can do that.
- microcolonel 8y ago> I can’t think of any challenge in text editing that requires beefy hardware. The expectations of advanced text editors have expanded to create performance concerns which do not apply to the most basic text editor. It's basically what happens when somebody tries to elevate a vulgar art by doing it big: like making the world's largest macaroni sculpture, anything can be done big enough to meet limitations. In addition to this, Atom also has the problems of being an Electron app.
- colemickens 8y agoThe point is that the frontend is a "thin" JavaScript UI rendered in the browser while the entire real dev environment is remote -- LSP (language sever protocol plugins aka autocomplete, semanic highlighting, nav to reference/definition, etc), other plugins, the project's toolchain, etc, are running in a container/pod on a beefy machine. Theia (and GitPod.io) will give you this today and it is compelling. GitPod gives you a single button on PRs/Issues that drops you in a dev environment, ready to build and test at the click of a button. No cloning, no installing a toolchain, etc. If Rust and Rust Language Server are running in a container with Theia, this means I can use a Chromebook-style device for serious, real development without having to enable dev mode or even Linux apps. Every machine in the world becomes a real potential development environment. Theia even has (or is about to have) debug protocol support too. A real, full IDE running on a remote DC, accessible from your browser. ( If you follow what the Theia and Che devs are doing, they're trying to support the full VS Code API... Which is SUPER exciting!) (Note, with the level I'm speaking about here, the CRDT is a bit of an implementation detail, but it's useful for collaborative editing and in xrays case, syncing state b/w the browser client and the backend and the underlying SCM system.)
- Nullabillity 8y ago> I think these tools are going to enable entire new generations of programmers on super low end hardware where their editor services and toolchains are running in a remote DC. This sounds awfully dystopic to me.
- colemickens 8y agoWhy is that? Did I say everyone had to adopt it? You don't think there's value in someone in a low-income situation being able to experiment with and use a full development experience without having to upfront invest in computing power? Have you tried any of this tooling? It's hard to notice that I'm not in VS Code at times. I'd be curious what you find so dystopic.
- Nullabillity 8y ago> Why is that? Did I say everyone had to adopt it? Given the overall trend towards SaaS I expect tooling vendors to try to enforce this whenever they think they can get away with it. By working on or using these projects you're giving them more ammunition, even if your intentions are to just add another option. > You don't think there's value in someone in a low-income situation being able to experiment with and use a full development experience without having to upfront invest in computing power? And it's better that they get stuck paying rent to some cloud vendor just to access their editor? I'm all for making stuff more accessible, but this is the same nonsense as FB's "Free Basics".
- colemickens 8y agoI don't get it. Theia runs on my home machine, my home cluster, or runs standalone just like any other editor. Everything I've mentioned are fully OSS projects (edit: GitPod has a bit of secret sauce for the workspace functionality, but Che has that, too). If anything, my goal in all of my software choices is user empowerment and I refuse to build or use anything proprietary or tied to a single cloud. My only exceptions are Plex (I'm working on replacing it) and Windows/games on a single machine. There's no reason that a browser based editor has to mean lock-in, and the current landscape doesn't support such gloom, in my opinion.