5 ms·

Not criticizing the project, genuinely curious: It's great that browsers can achieve more functionality previously exclusive to native applications, but anytim

by cm3 10y ago

Not criticizing the project, genuinely curious: It's great that browsers can achieve more functionality previously exclusive to native applications, but anytime a code editor written in JavaScript to be run in a browser is announced, I wonder one thing: why don't we try to come up with a client/server protocol that would allow you to use your local editor, which is already fully customized to your needs? Is the idea that the files being edited are remote and therefore the only thing that would make sense is improving extensions like "It' All Text!" or wasavi? It ought to be enough if one can trigger opening a buffer in a local editor, which accesses a local webserver provided by your browser, backed by the textarea, and having a means of updating the textarea on save via a POST issued from, say, Emacs to Firefox's textarea-httpd.

vbezhenar 10y ago
I guess that most people want to launch a browser and start to work. Installing, launching another application is a burden and if you want to use it, why do you need a browser at all? Just do your work locally.
- tkinom 10y ago
  It is much harder to monitor / monetize you when you just do work locally. You need to be part of the Matrix.
TheAceOfHearts 10y ago
I can't see myself using this regularly, but I can see the value for many people. I can definitely see some value in being able to try stuff out from the browser. Honestly, having to setup and configure your environment and tools is tedious. When you're unfamiliar with the ecosystem, it can take you pretty long to get everything up and running. I think this is more approachable for the average person.
- falcolas 10y ago
  It's probably just me, but: "having to setup and configure your environment and tools is tedious" has never really been a problem for me. Between dotfiles, bookmark backups, and a few choice CLI commands, I can get a *nix/OSX development environment up in under an hour (including downloading and compiling non-standard tools).
  - sitkack 10y ago
    The is a lot of mutation. And that is with practice. Wouldn't if it be nice if we could clone fork undo merge dev environments?
nl 10y ago
Oh, I know this one! I use 3 different computers regularly, two tablets and occasionally a phone. I used to try to keep environments synced across them all. That was fun during the 1990s, but I'm over it now. Now I do as much work as possible in Jupyter notebooks. They suck on tablets, but I never, ever have to worry about having the tools installed anymore.
LoSboccacc 10y ago
Well, the idea is sound, but the timing is wrong. we're past company caring about interoperability, i.e. compare FTP vs WebDAV. There won't be new open protocols to exchange data for a long while as the whole tech scene is built around growing as a monopoly of a sector.
- amelius 10y ago
  Sad but true. Any ideas what may turn the tide?
  - stuartaxelowen 10y ago
    A new sector arising, I suspect.
  - sytse 10y ago
    At GitLab we're exploring an idea that may turn the tide. I agree that online editors don't seem the way forward. The problems are: - People have wildly different preferences (TextMate, Sublime, Atom, VScode, vim, emacs, etc.) - It is really hard to get an online IDE right. The most advanced version is probably Eclipse Che and they have an API to do autosuggest by looking in all the files. Also see https://gitlab.com/gitlab-org/gitlab-ce/issues/22863 https://gitlab.com/gitlab-org/gitlab-ce/issues/22863 "It ought to be enough if one can trigger opening a buffer in a local editor, which accesses a local webserver provided by your browser, backed by the textarea, and having a means of updating the textarea on save via a POST issued from, say, Emacs to Firefox's textarea-httpd." I think the better approach is to sync the entire directory so you can do global search and replace and autosuggest. My idea of how to make the IDE sync work: 1. You click on an icon in GitLab, it is next to where we now show the url for the terminal. 2. The icon opens a url, with a schema specific for our solution (although we should open source the protocol so others can reuse it). In the url is the following information: server and project location, pod and container to connect to, a token to identify the user. 3. Beforehand the user has installed a local client that is registered to handle this type of schema. 4. The filesystem of the container is synched to the users machine by the local client (I propose to a default directory system specific to the local client). 5. The local client also opens up the favorite editor of the user (make this configurable with smart default by seeing what editors are installed via which). 6. The local editor talks to an endpoint of GitLab, similar to how our terminal works. 7. GitLab uses kubernetes/docker exec to run unison and fswatch on the container (this is a different approach that the volume approach suggested in https://github.com/leighmcculloch/docker-unison#docker https://github.com/leighmcculloch/docker-unison#docker ). 8. GitLab makes a reference implementation of this for MacOS, using unison and fswatch. The community will hopefully make Linux and Windows clients. What do people think? Also see https://gitlab.com/gitlab-org/gitlab-ce/issues/22876 https://gitlab.com/gitlab-org/gitlab-ce/issues/22876
tyfon 10y ago
You can achieve this with version control systems, I do it myself with RStudio web/Jupyter and the git integration. When i want to do something locally i just pull the repository and go at it.
z3t4 10y ago
Or you just paste the code to the editor of choice, then past it back to the browser :P Or you can invent the edit:// protocol, just like skype:// etc.
- deleted 10y ago
  [deleted]
radriaanse 10y ago
I agree. Eclipse Che seems to be going the right direction with this one. What I've tried so far looks really good even considering it's not around for that long. I Also like there just using Docker for it, so that makes it somewhat more 'standard'
- moondev 10y ago
  Wow just checked it out and seems awesome so far. Are you running the server in the cloud or locally?
Sargos 10y ago
Google Drive (the web app) does something similar to this (at a high level anyway). You can open a file from the Drive website in Photoshop, Word, etc and make changes with your desktop software and when you hit save it is actually saving the cloud copy. So the file stays in the cloud but you can use any local software you like or need to be productive. I believe this uses a Chrome extension at the moment but extensions are also web based for the most part so the idea is solid.
abysmallyideal 10y ago
I can see how working for Google, there is no issue using their cloud infrastructure... For other companies I don't see the benefit esp since Google is an enormous data broker to the US government and security infrastructure. Microsoft used a similar, yet relatively benign tactic, of copying works created in their dev environment and then pushing out the competition simply through free or cheaper prices. It just can't be ignored that promising or lucrative businesses, workflows, models using SV infrastructure provided by Google et al, will just be passed off to those passing through the revolving door as "rewards", etc.
TYPE_FASTER 10y ago
Emacs can do this: https://www.emacswiki.org/emacs/TrampMode https://www.emacswiki.org/emacs/TrampMode It's really handy.

by cm3 10y ago

vbezhenar 10y ago

I guess that most people want to launch a browser and start to work. Installing, launching another application is a burden and if you want to use it, why do you need a browser at all? Just do your work locally.

tkinom 10y ago
It is much harder to monitor / monetize you when you just do work locally. You need to be part of the Matrix.

TheAceOfHearts 10y ago

I can't see myself using this regularly, but I can see the value for many people. I can definitely see some value in being able to try stuff out from the browser. Honestly, having to setup and configure your environment and tools is tedious. When you're unfamiliar with the ecosystem, it can take you pretty long to get everything up and running. I think this is more approachable for the average person.

falcolas 10y ago
It's probably just me, but: "having to setup and configure your environment and tools is tedious" has never really been a problem for me. Between dotfiles, bookmark backups, and a few choice CLI commands, I can get a *nix/OSX development environment up in under an hour (including downloading and compiling non-standard tools).
- sitkack 10y ago
  The is a lot of mutation. And that is with practice. Wouldn't if it be nice if we could clone fork undo merge dev environments?

nl 10y ago

Oh, I know this one! I use 3 different computers regularly, two tablets and occasionally a phone. I used to try to keep environments synced across them all. That was fun during the 1990s, but I'm over it now. Now I do as much work as possible in Jupyter notebooks. They suck on tablets, but I never, ever have to worry about having the tools installed anymore.

LoSboccacc 10y ago

Well, the idea is sound, but the timing is wrong. we're past company caring about interoperability, i.e. compare FTP vs WebDAV. There won't be new open protocols to exchange data for a long while as the whole tech scene is built around growing as a monopoly of a sector.

amelius 10y ago
Sad but true. Any ideas what may turn the tide?
- stuartaxelowen 10y ago
  A new sector arising, I suspect.
- sytse 10y ago
  At GitLab we're exploring an idea that may turn the tide. I agree that online editors don't seem the way forward. The problems are: - People have wildly different preferences (TextMate, Sublime, Atom, VScode, vim, emacs, etc.) - It is really hard to get an online IDE right. The most advanced version is probably Eclipse Che and they have an API to do autosuggest by looking in all the files. Also see https://gitlab.com/gitlab-org/gitlab-ce/issues/22863 https://gitlab.com/gitlab-org/gitlab-ce/issues/22863 "It ought to be enough if one can trigger opening a buffer in a local editor, which accesses a local webserver provided by your browser, backed by the textarea, and having a means of updating the textarea on save via a POST issued from, say, Emacs to Firefox's textarea-httpd." I think the better approach is to sync the entire directory so you can do global search and replace and autosuggest. My idea of how to make the IDE sync work: 1. You click on an icon in GitLab, it is next to where we now show the url for the terminal. 2. The icon opens a url, with a schema specific for our solution (although we should open source the protocol so others can reuse it). In the url is the following information: server and project location, pod and container to connect to, a token to identify the user. 3. Beforehand the user has installed a local client that is registered to handle this type of schema. 4. The filesystem of the container is synched to the users machine by the local client (I propose to a default directory system specific to the local client). 5. The local client also opens up the favorite editor of the user (make this configurable with smart default by seeing what editors are installed via which). 6. The local editor talks to an endpoint of GitLab, similar to how our terminal works. 7. GitLab uses kubernetes/docker exec to run unison and fswatch on the container (this is a different approach that the volume approach suggested in https://github.com/leighmcculloch/docker-unison#docker https://github.com/leighmcculloch/docker-unison#docker ). 8. GitLab makes a reference implementation of this for MacOS, using unison and fswatch. The community will hopefully make Linux and Windows clients. What do people think? Also see https://gitlab.com/gitlab-org/gitlab-ce/issues/22876 https://gitlab.com/gitlab-org/gitlab-ce/issues/22876

tyfon 10y ago

You can achieve this with version control systems, I do it myself with RStudio web/Jupyter and the git integration. When i want to do something locally i just pull the repository and go at it.

z3t4 10y ago

Or you just paste the code to the editor of choice, then past it back to the browser :P Or you can invent the edit:// protocol, just like skype:// etc.

deleted 10y ago
[deleted]

radriaanse 10y ago

I agree. Eclipse Che seems to be going the right direction with this one. What I've tried so far looks really good even considering it's not around for that long. I Also like there just using Docker for it, so that makes it somewhat more 'standard'

moondev 10y ago
Wow just checked it out and seems awesome so far. Are you running the server in the cloud or locally?

Sargos 10y ago

Google Drive (the web app) does something similar to this (at a high level anyway). You can open a file from the Drive website in Photoshop, Word, etc and make changes with your desktop software and when you hit save it is actually saving the cloud copy. So the file stays in the cloud but you can use any local software you like or need to be productive. I believe this uses a Chrome extension at the moment but extensions are also web based for the most part so the idea is solid.

abysmallyideal 10y ago

I can see how working for Google, there is no issue using their cloud infrastructure... For other companies I don't see the benefit esp since Google is an enormous data broker to the US government and security infrastructure. Microsoft used a similar, yet relatively benign tactic, of copying works created in their dev environment and then pushing out the competition simply through free or cheaper prices. It just can't be ignored that promising or lucrative businesses, workflows, models using SV infrastructure provided by Google et al, will just be passed off to those passing through the revolving door as "rewards", etc.

TYPE_FASTER 10y ago

Emacs can do this: https://www.emacswiki.org/emacs/TrampMode https://www.emacswiki.org/emacs/TrampMode It's really handy.