5 ms·

CI is fine and I am happy GitLab is offering it as it makes sense to integrate strongly with source control. But building a web-IDE? Please don't go down this

CI is fine and I am happy GitLab is offering it as it makes sense to integrate strongly with source control. But building a web-IDE? Please don't go down this rabbit hole, GitLab - there will be dragons (in essence you will have to build an OS for the browser). Developers have their beloved editors that work very well for the most part (at least better than their JS counterparts).

Snappy 9y ago
We're not trying to replace your local editor. We know you love them. But there are still lots of reasons and situations where a web IDE is perfect and beneficial.
- ianwalter 9y ago
  Please do replace my local editor.
zellyn 9y ago
I was at Google when they implemented something like this in their source code viewing system. If you see a typo in a comment, for example, you click the pencil icon on that line, which pops open an editor with your cursor on that line, fix the typo, and can create and submit for review a pull request right there. Less than a minute. It is fantastic. I'm so glad Gitlab is providing competition to Stash and Github. Nice work.
- segmondy 9y ago
  Someone in my twitter feed was just asking for this feature last night. I don't want to open an editor, checkout, fetch, edit, commit, push, open a PR to a PR when I can just do it in an editor. I don't use Gitlab but I agree, it's a brilliant feature.
  - sytse 9y ago
    Thanks! There is a place for web editors (quick edits, new projects) and local editors (working on the same codebase for a longer time). As warned against we don't want to fall in a rabbit hole of spending all our time on this instead of the other parts of our complete DevOps vision https://about.gitlab.com/2017/10/11/from-dev-to-devops/ https://about.gitlab.com/2017/10/11/from-dev-to-devops/ (logs, roadmaps, create project on push, binary repository, incremental rollouts, tracing). Therefore we based the web IDE on the awesome VScode. This means that it is a doable effort to maintain it.
    - Create 9y ago
      Hi! It would be nice to see burndown charts in CE along with EBS[1], just like pipelines and runners. [1] http://help.fogcreek.com/7676/evidence-based-scheduling-ebs http://help.fogcreek.com/7676/evidence-based-scheduling-ebs
      - connorshea 9y ago
        See our Stewardship page[0] for how we determine what goes in EE vs. CE, for now Burndown Charts will stay in EE. As for EBS, feel free to open an issue for it[1] since I couldn't find one :) [0]: https://about.gitlab.com/stewardship/ https://about.gitlab.com/stewardship/ [1]: https://gitlab.com/gitlab-org/gitlab-ee/issues https://gitlab.com/gitlab-org/gitlab-ee/issues
  - vog 9y ago
    This is not so much an argument for a Web IDE. It is an argument against the cumbersome Git workflows, and the even more cumbersome GitHub Pull Request workflow on top of that. Why can't I fix the typo in my editor, hit "upload", enter some commit message and be done with it?
    - mastax 9y ago
      > Why can't I fix the typo in my editor, hit "upload", enter some commit message and be done with it? You can do this, if you have permission from the repository and have a local up-to-date clone already. I suppose it would be nice to be able to create a PR to someone elses repo without needing to fork first. I don't see any other reasonable way to make this easier.
    - zellyn 9y ago
      I'd respectfully disagree. In a monorepo the size of Google's (or even Square's, where I work now), there would be a whole schlep to open the file in your editor. Much better to fix right there where you're browsing. Also, at Google, it's not even Git, or a Git/Github workflow.
      - vog 9y ago
        Please respect the context of a comment, and refrain from strawman arguments. This was not about whether or not this feature is good for the Google repo (of course it is, nobody disputed that!). This was about whether and how to apply this to other projects.
        zellyn 9y ago
        Please respect the fact that some of us actually read comments and reply to them thoughtfully. Throwing around trite accusations of “strawman” arguments doesn't help anything. The comment I replied to was claiming that it was the git workflows (I assume for submitting, but am open to correction) that make this cumbersome. I was pointing out that in an enormous repository (and I did mention my current employer as an example too -- and we use Git, not Google's internal tooling), just getting to the point of having the latest version of some far-flung file that you usually never touch open in your editor is cumbersome enough to make this feature a win, regardless of whether the workflows for submitting the change disappear altogether.
_pmf_ 9y ago
> Please don't go down this rabbit hole, GitLab "No yak goes unshaven."
fatihacet 9y ago
GitLab Frontend Engineer here. I was previously working at Koding.com which is an online IDE and I was the author of Koding's collaborative IDE. Koding's ultimate goal was moving your development workflow to the cloud. To do so Koding's IDE is capable of doing most of the things which Sublime Text can do. Beyond that it has massive collaboration feature built-in. We were thinking that we did the best online IDE and we were ready to replace it with our local IDEs or text editors. We tried really hard to do so but we realised that, it's almost impossible to replace pro users local and powerful stuff with something online. Been there done that before, it didn't work. Hopefully, GitLab's idea is not replacing your local IDE. It is just for making things easier and we are doing our best to give you the most powerful tool out there. Although, it's currently in Beta state, I believe it's very useful when I want to go and fix a typo or change a simple thing in multiple files and do a quick commit. One last thing is, please don't forget that, not only developers use GitLab. It's kinda easy for us to checkout the target branch and do some commits but this is a golden for not so technical folks.

Snappy 9y ago

We're not trying to replace your local editor. We know you love them. But there are still lots of reasons and situations where a web IDE is perfect and beneficial.

ianwalter 9y ago
Please do replace my local editor.

zellyn 9y ago

I was at Google when they implemented something like this in their source code viewing system. If you see a typo in a comment, for example, you click the pencil icon on that line, which pops open an editor with your cursor on that line, fix the typo, and can create and submit for review a pull request right there. Less than a minute. It is fantastic. I'm so glad Gitlab is providing competition to Stash and Github. Nice work.

segmondy 9y ago
Someone in my twitter feed was just asking for this feature last night. I don't want to open an editor, checkout, fetch, edit, commit, push, open a PR to a PR when I can just do it in an editor. I don't use Gitlab but I agree, it's a brilliant feature.
- sytse 9y ago
  Thanks! There is a place for web editors (quick edits, new projects) and local editors (working on the same codebase for a longer time). As warned against we don't want to fall in a rabbit hole of spending all our time on this instead of the other parts of our complete DevOps vision https://about.gitlab.com/2017/10/11/from-dev-to-devops/ https://about.gitlab.com/2017/10/11/from-dev-to-devops/ (logs, roadmaps, create project on push, binary repository, incremental rollouts, tracing). Therefore we based the web IDE on the awesome VScode. This means that it is a doable effort to maintain it.
  - Create 9y ago
    Hi! It would be nice to see burndown charts in CE along with EBS[1], just like pipelines and runners. [1] http://help.fogcreek.com/7676/evidence-based-scheduling-ebs http://help.fogcreek.com/7676/evidence-based-scheduling-ebs
    - connorshea 9y ago
      See our Stewardship page[0] for how we determine what goes in EE vs. CE, for now Burndown Charts will stay in EE. As for EBS, feel free to open an issue for it[1] since I couldn't find one :) [0]: https://about.gitlab.com/stewardship/ https://about.gitlab.com/stewardship/ [1]: https://gitlab.com/gitlab-org/gitlab-ee/issues https://gitlab.com/gitlab-org/gitlab-ee/issues
- vog 9y ago
  This is not so much an argument for a Web IDE. It is an argument against the cumbersome Git workflows, and the even more cumbersome GitHub Pull Request workflow on top of that. Why can't I fix the typo in my editor, hit "upload", enter some commit message and be done with it?
  - mastax 9y ago
    > Why can't I fix the typo in my editor, hit "upload", enter some commit message and be done with it? You can do this, if you have permission from the repository and have a local up-to-date clone already. I suppose it would be nice to be able to create a PR to someone elses repo without needing to fork first. I don't see any other reasonable way to make this easier.
  - zellyn 9y ago
    I'd respectfully disagree. In a monorepo the size of Google's (or even Square's, where I work now), there would be a whole schlep to open the file in your editor. Much better to fix right there where you're browsing. Also, at Google, it's not even Git, or a Git/Github workflow.
    - vog 9y ago
      Please respect the context of a comment, and refrain from strawman arguments. This was not about whether or not this feature is good for the Google repo (of course it is, nobody disputed that!). This was about whether and how to apply this to other projects.
      - zellyn 9y ago
        Please respect the fact that some of us actually read comments and reply to them thoughtfully. Throwing around trite accusations of “strawman” arguments doesn't help anything. The comment I replied to was claiming that it was the git workflows (I assume for submitting, but am open to correction) that make this cumbersome. I was pointing out that in an enormous repository (and I did mention my current employer as an example too -- and we use Git, not Google's internal tooling), just getting to the point of having the latest version of some far-flung file that you usually never touch open in your editor is cumbersome enough to make this feature a win, regardless of whether the workflows for submitting the change disappear altogether.

_pmf_ 9y ago

> Please don't go down this rabbit hole, GitLab "No yak goes unshaven."

fatihacet 9y ago

GitLab Frontend Engineer here. I was previously working at Koding.com which is an online IDE and I was the author of Koding's collaborative IDE. Koding's ultimate goal was moving your development workflow to the cloud. To do so Koding's IDE is capable of doing most of the things which Sublime Text can do. Beyond that it has massive collaboration feature built-in. We were thinking that we did the best online IDE and we were ready to replace it with our local IDEs or text editors. We tried really hard to do so but we realised that, it's almost impossible to replace pro users local and powerful stuff with something online. Been there done that before, it didn't work. Hopefully, GitLab's idea is not replacing your local IDE. It is just for making things easier and we are doing our best to give you the most powerful tool out there. Although, it's currently in Beta state, I believe it's very useful when I want to go and fix a typo or change a simple thing in multiple files and do a quick commit. One last thing is, please don't forget that, not only developers use GitLab. It's kinda easy for us to checkout the target branch and do some commits but this is a golden for not so technical folks.