7 ms·

Another developer tool maker here (crudzilla.com). Quite shocking though,they "appeared" to be doing quite ok.

by Edmond 10y ago

sytse 10y ago
The big ones left seem to be Koding and Codenvy. Codenvy focuses on Eclipse Che. Koding is focussing more on Dev infrastructure than the online IDE. Even Heroku started as an online IDE. I wonder why online IDEs have such a hard time. I asked in GitLab and everyone said they didn't want to code in a browser for usability reasons. We're therefore exploring running the environment in the cloud but syncing the file system so you can use you local editor https://gitlab.com/gitlab-org/gitlab-ce/issues/22876 https://gitlab.com/gitlab-org/gitlab-ce/issues/22876 What do people think? Is this the way to crack to problem and break the online IDE spell?
- nitrogen 10y ago
  I think you have to ask why a developer would want to use an online IDE, and focus on that. Do online IDEs have a unique value proposition, or are they just another instance of the counterproductive "X but in the cloud!" formula?
  - sytse 10y ago
    I have the feeling that people want to build online IDE's and that management thinks it is a good idea. I've not encountered many developers that like to use it fulltime. One counter example is https://community.nitrous.io/posts/nitrous-io-stories-yehuda-katz-and-tilde-io https://community.nitrous.io/posts/nitrous-io-stories-yehuda...
- SkyMarshal 10y ago
  >I asked in GitLab and everyone said they didn't want to code in a browser for usability reasons. Can't speak for anyone else but I'm constantly battling to keep my browser from crashing due to too many tabs. Namely Chrome and Firefox on Linux and OSX. I open tabs, then forget to close them. Even as I write this Chrome is popping up alert boxes saying so-and-so page has stopped responding, do I want to Kill or Wait? The thought of adding a fairly heavy-weight SPA IDE to that mix is not attractive. Out of curiosity, can Atom (https://atom.io/ https://atom.io/) load a remote IDE into its separate memory space? Only best-of-both worlds I can think of.
  - sytse 10y ago
    I agree that something like Atom (javascript IDE run locally) might be the best of both worlds. I think GitHub will lead the innovation with that.
  - raingrove 10y ago
    We had an Atom plugin called Nitrogen that did file sync, remote terminal, and app preview. https://community.nitrous.io/docs/using-the-nitrogen-atom-plugin https://community.nitrous.io/docs/using-the-nitrogen-atom-pl... Most of our users preferred the in-browser experience though...
- Edmond 10y ago
  I personally think it is due to a lack of true innovation, most cloud IDEs are just copies of native IDEs minus the performance benefit. The browser is a powerful platform and when you combine that with a server you have something very capable, but you have to think creatively to harness that power.
- ww520 10y ago
  Vendor locked in. Dependence on a fleeting platform. Network connection requirement.
- kajecounterhack 10y ago
  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)
  - sytse 10y ago
    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 https://gitlab.com/gitlab-org/gitlab-ce/issues/19267 3. Yeah, this would work on your local GitLab instance, no third party needed.
    - kajecounterhack 10y ago
      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 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.
- jlarocco 10y ago
  I guess I'd turn the question around and ask what problems are browser based IDEs trying to solve and what advantage do they have over regular IDEs? I'm a full-time C++ developer, which probably isn't the target for most browser IDEs, but I'll throw in my two cents anyway. My perception is that browser based IDEs are inflexible, fragile, slow, and don't scale. It's not even clear to me how a browser based IDE is supposed to work in my environment. Do I clone our source repo locally and open the file from there somehow? Do I clone it to the cloud somewhere? How does a browser IDE handle the third party libraries we link to? Where is compilation done? Where does the executable go? Am I able to debug and step through the binary in the browser? What if there's a GUI component? And don't even get me started on the clunkiness of text editing in a browser compared to an editor like Emacs or Vim. The whole concept of a browser based IDE just seems like a poorly thought out abuse of web technology.
  - sytse 10y ago
    Good points, running the environment in the cloud and the editor locally helps with some of the points, but doing debugging is hard. As a ex ruby developer I'm used to having an editor without the other IDE functions. I guess that IDE in the cloud is a big step from editor in the cloud.
- TylerJewell 10y ago
  Eclipse Che is doing pretty well. Approaching 20,000 usage hours every day from telemetry, up from a couple hundred at the beginning of the year. Eclipse Che is focused on the dev infrastructure. It's about making the workspace completely portable and provisioned on any system without any effort from developers to have to set it up. Lots of use cases: 1. Hosted workspaces with workspace project sync - we provide a che-mount capability for this and it's based upon a fuse file system with unison sync. It can be fine-tuned with excludes and dual unison clients in such a way where the performance is really screaming. 2. Migration of workspaces from location to location for purposes of backup and recovery. 3. Having workspaces match their production topology, so that developers are working on a workspace that is identical to their production deployment. This requires workspace runtimes that are constructed by orchestrators like compose or other syntax. 4. The commonly discussed situations with instructors or team leaders setting up a workspace template which is used by others to facilitate getting started quicker. We are about to launch a team capability that allows a team leader to define a basic template of a workspace that is defined by stacks, composefile structures, and other meta data, but more importantly it explicitly states the aspects that are personal to each developer, so as each developer creates their own workspace replica from the template, they have to populate it with their personal information such as SSH keys, oauth access, database credentials and so forth. 5. Big software vendors value the extensibility of the che platform because there are many products that need workspaces inside of their products, and they would rather customize an off the shelf product vs. build their own. 6. Better agile. Context-sensitive pull requests, git issues, git repositories, issues, and CI jobs - opening a context-aware workspace is a big deal. We do a lot of enterprise customers that focus on those cases. It's hard to set this up on a desktop or with vagrant. We try to stay out of the IDE conflict. We are happy to work with any desktop IDE or provide our own for those that don't want to install something. But we are close to a future where each workspace can host multiple IDEs at the same time, including desktop IDEs that are pre-configured to work with the workspace configuration. The point is that if you sit 5 developers around the table and ask them if they want to code in the browser, you can anticipate the response that you will get. But if you sit 5 development teams around the table and ask them about problems they have with developer onboarding, agile team management, collaboration, developer support, vagrant and using VMs / virtual labs as development environments, then suddenly there are a lot of pains around the table. We think Che is doing really well because we have tapped into this particular need with some efficiency. And we consciously try to avoid being the world's best IDE because of the issues stated previously. Also, with the language server protocol that we announced with Microsoft and Red Hat this summer, it has really taken off. I can see us having support for 20 languages with intellisense + debugging by the end of Q1. It allows the language providers to maintain really good intellisense and we provide the infrastructure around that. And then we can focus on workspace provisioning and giving developers access (without installing software) to intellisense for the languages they love. And 90% of the world is covered by the 75% capabilities of most language servers on the market. So we can be increasingly language and tooling agnostic, while providing great services to teams. Along these lines, we have a new team management offering shipping in a few weeks, not to mention Che 5 - which we'll announce at CheConf. And CheConf is our first users conference that we are holding on 11/15, and after two weeks of promotion, we are pretty stunned that we are approaching 1500 registrations.

Another developer tool maker here (crudzilla.com). Quite shocking though,they "appeared" to be doing quite ok.

by Edmond 10y ago

Another developer tool maker here (crudzilla.com). Quite shocking though,they "appeared" to be doing quite ok.

sytse 10y ago

The big ones left seem to be Koding and Codenvy. Codenvy focuses on Eclipse Che. Koding is focussing more on Dev infrastructure than the online IDE. Even Heroku started as an online IDE. I wonder why online IDEs have such a hard time. I asked in GitLab and everyone said they didn't want to code in a browser for usability reasons. We're therefore exploring running the environment in the cloud but syncing the file system so you can use you local editor https://gitlab.com/gitlab-org/gitlab-ce/issues/22876 https://gitlab.com/gitlab-org/gitlab-ce/issues/22876 What do people think? Is this the way to crack to problem and break the online IDE spell?

nitrogen 10y ago
I think you have to ask why a developer would want to use an online IDE, and focus on that. Do online IDEs have a unique value proposition, or are they just another instance of the counterproductive "X but in the cloud!" formula?
- sytse 10y ago
  I have the feeling that people want to build online IDE's and that management thinks it is a good idea. I've not encountered many developers that like to use it fulltime. One counter example is https://community.nitrous.io/posts/nitrous-io-stories-yehuda-katz-and-tilde-io https://community.nitrous.io/posts/nitrous-io-stories-yehuda...
SkyMarshal 10y ago
>I asked in GitLab and everyone said they didn't want to code in a browser for usability reasons. Can't speak for anyone else but I'm constantly battling to keep my browser from crashing due to too many tabs. Namely Chrome and Firefox on Linux and OSX. I open tabs, then forget to close them. Even as I write this Chrome is popping up alert boxes saying so-and-so page has stopped responding, do I want to Kill or Wait? The thought of adding a fairly heavy-weight SPA IDE to that mix is not attractive. Out of curiosity, can Atom (https://atom.io/ https://atom.io/) load a remote IDE into its separate memory space? Only best-of-both worlds I can think of.
- sytse 10y ago
  I agree that something like Atom (javascript IDE run locally) might be the best of both worlds. I think GitHub will lead the innovation with that.
- raingrove 10y ago
  We had an Atom plugin called Nitrogen that did file sync, remote terminal, and app preview. https://community.nitrous.io/docs/using-the-nitrogen-atom-plugin https://community.nitrous.io/docs/using-the-nitrogen-atom-pl... Most of our users preferred the in-browser experience though...
Edmond 10y ago
I personally think it is due to a lack of true innovation, most cloud IDEs are just copies of native IDEs minus the performance benefit. The browser is a powerful platform and when you combine that with a server you have something very capable, but you have to think creatively to harness that power.
ww520 10y ago
Vendor locked in. Dependence on a fleeting platform. Network connection requirement.
kajecounterhack 10y ago
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)
- sytse 10y ago
  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 https://gitlab.com/gitlab-org/gitlab-ce/issues/19267 3. Yeah, this would work on your local GitLab instance, no third party needed.
  - kajecounterhack 10y ago
    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 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.
jlarocco 10y ago
I guess I'd turn the question around and ask what problems are browser based IDEs trying to solve and what advantage do they have over regular IDEs? I'm a full-time C++ developer, which probably isn't the target for most browser IDEs, but I'll throw in my two cents anyway. My perception is that browser based IDEs are inflexible, fragile, slow, and don't scale. It's not even clear to me how a browser based IDE is supposed to work in my environment. Do I clone our source repo locally and open the file from there somehow? Do I clone it to the cloud somewhere? How does a browser IDE handle the third party libraries we link to? Where is compilation done? Where does the executable go? Am I able to debug and step through the binary in the browser? What if there's a GUI component? And don't even get me started on the clunkiness of text editing in a browser compared to an editor like Emacs or Vim. The whole concept of a browser based IDE just seems like a poorly thought out abuse of web technology.
- sytse 10y ago
  Good points, running the environment in the cloud and the editor locally helps with some of the points, but doing debugging is hard. As a ex ruby developer I'm used to having an editor without the other IDE functions. I guess that IDE in the cloud is a big step from editor in the cloud.
TylerJewell 10y ago
Eclipse Che is doing pretty well. Approaching 20,000 usage hours every day from telemetry, up from a couple hundred at the beginning of the year. Eclipse Che is focused on the dev infrastructure. It's about making the workspace completely portable and provisioned on any system without any effort from developers to have to set it up. Lots of use cases: 1. Hosted workspaces with workspace project sync - we provide a che-mount capability for this and it's based upon a fuse file system with unison sync. It can be fine-tuned with excludes and dual unison clients in such a way where the performance is really screaming. 2. Migration of workspaces from location to location for purposes of backup and recovery. 3. Having workspaces match their production topology, so that developers are working on a workspace that is identical to their production deployment. This requires workspace runtimes that are constructed by orchestrators like compose or other syntax. 4. The commonly discussed situations with instructors or team leaders setting up a workspace template which is used by others to facilitate getting started quicker. We are about to launch a team capability that allows a team leader to define a basic template of a workspace that is defined by stacks, composefile structures, and other meta data, but more importantly it explicitly states the aspects that are personal to each developer, so as each developer creates their own workspace replica from the template, they have to populate it with their personal information such as SSH keys, oauth access, database credentials and so forth. 5. Big software vendors value the extensibility of the che platform because there are many products that need workspaces inside of their products, and they would rather customize an off the shelf product vs. build their own. 6. Better agile. Context-sensitive pull requests, git issues, git repositories, issues, and CI jobs - opening a context-aware workspace is a big deal. We do a lot of enterprise customers that focus on those cases. It's hard to set this up on a desktop or with vagrant. We try to stay out of the IDE conflict. We are happy to work with any desktop IDE or provide our own for those that don't want to install something. But we are close to a future where each workspace can host multiple IDEs at the same time, including desktop IDEs that are pre-configured to work with the workspace configuration. The point is that if you sit 5 developers around the table and ask them if they want to code in the browser, you can anticipate the response that you will get. But if you sit 5 development teams around the table and ask them about problems they have with developer onboarding, agile team management, collaboration, developer support, vagrant and using VMs / virtual labs as development environments, then suddenly there are a lot of pains around the table. We think Che is doing really well because we have tapped into this particular need with some efficiency. And we consciously try to avoid being the world's best IDE because of the issues stated previously. Also, with the language server protocol that we announced with Microsoft and Red Hat this summer, it has really taken off. I can see us having support for 20 languages with intellisense + debugging by the end of Q1. It allows the language providers to maintain really good intellisense and we provide the infrastructure around that. And then we can focus on workspace provisioning and giving developers access (without installing software) to intellisense for the languages they love. And 90% of the world is covered by the 75% capabilities of most language servers on the market. So we can be increasingly language and tooling agnostic, while providing great services to teams. Along these lines, we have a new team management offering shipping in a few weeks, not to mention Che 5 - which we'll announce at CheConf. And CheConf is our first users conference that we are holding on 11/15, and after two weeks of promotion, we are pretty stunned that we are approaching 1500 registrations.