Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Future of the Gitlab Web IDE

about.gitlab.com

Post reply on HN
Print view View original

141–150 of 168 posts

Re: The Future of the Gitlab Web IDE

#141

Post by lobocinza »

greatgib wrote: post #138
greatgib wrote: post #101

Always have to check the date for April's fool day when seeing a news like that, but sadly it is not... When you think that gitlab started as an open source alternative to the closed world of GitHub, and was free as in "free speech". And then, little by little it becomes the same thing. Less and less things not in premium plan and less affordable plans. Now, they are ok to use as-is a Microsoft editor, that is free a…

Vscode is not free btw: https://news.ycombinator.com/item?id=31488436 The thing is always the same, in OSS you get for free a little bit less good version of VSCode. But you get used to it, competitor development is killed little by little, like in the current case. And, when everyone is "hooked", and every one and companies are used to it, you can slowly reduce/limit the oss version and push everyone to the the prop…

I think you posted the wrong link.

Re: The Future of the Gitlab Web IDE

#142

Post by sarki_247 »

shp0ngle wrote: post #33

Running VSCode remotely introduces many interesting challenges, mostly due to security. (You are letting your users run any arbitrary code on your infrastructure.) However, I guess GitLab already has this sorted out, because of their existing IDE, and they are experts in this area. Also the open source versions of VSCode don't have access to the official VSCode marketplace. (Both VSCodium and coder.com Code Server.)…

GitLab team member here! This implementation will be client-side only, with a selection of extensions allowed. Self-hosted instance admins will be able to enable or create an allow-list of extensions on their instance. You can learn more in this epic: https://gitlab.com/groups/gitlab-org/-/epics/7683

Re: The Future of the Gitlab Web IDE

#144

Post by kodah »

simonw wrote: post #68
kodah wrote: post #55

Earlier quoted context omitted.

> Yes. Because local development environments (at least for the languages I work with, Python and JavaScript) break ALL THE TIME. Whatever breaks software environments on the desktop will also break them in a remote compute environment; unless, of course, you put your entire product in a container and use a framework that supports hot code reloading. In which, you can do on a desktop for free. > The browser-based clo…

> Whatever breaks software environments on the desktop will also break them in a remote compute environment The joy of remote environments is that they can be disposable. Break your environment? Click a link, get a brand new one that's guaranteed to work (thanks to automated testing marking known good configurations). Helping with three different bugs at once? Use three environments, so your work doesn't conflict wit…

Sort of? A container is disposed of the same way, remote or local - state along with it.

Re: The Future of the Gitlab Web IDE

#145

Post by kodah »

bryanrasmussen wrote: post #62
kodah wrote: post #55

Earlier quoted context omitted.

> Yes. Because local development environments (at least for the languages I work with, Python and JavaScript) break ALL THE TIME. Whatever breaks software environments on the desktop will also break them in a remote compute environment; unless, of course, you put your entire product in a container and use a framework that supports hot code reloading. In which, you can do on a desktop for free. > The browser-based clo…

>Whatever breaks software environments on the desktop will also break them in a remote compute environment; I was in agreement with you initially but then thinking about it - if it breaks remotely it most likely breaks for everyone in the same way, breaking locally may be all sorts of reasons - you could have several people broken at any time for different reasons. For some projects and companies having the remote se…

A container that runs on one dev laptop will (most likely) run on another, unless there's some weird architecture compatibility stuff. Even then, I think the M1s are doing fine and my old boss used to stand our entire fleet up on his Chromebook.

With respect to the latter, I'm not sure that a web IDE (without paying monthly cost) would solve this problem. At that point one might as well run an entire developer cluster. That's the way I designed my teams stack.

Re: The Future of the Gitlab Web IDE

#146

Post by JeremyNT »

zarzavat wrote: post #69
crabmusket wrote: post #47

It's interesting to me that GitLab is adopting a Microsoft product (VS Code) and Microsoft owns a significant competitor in GitHub. Nothing intelligent to say about that other than to wish I'd been a fly on the wall for the discussions about that. > Next, we asked ourselves the question: Do we want to continue to invest in implementing custom features for the Web IDE that ultimately deliver the same value as those al…

Microsoft may have a dominant position in developer tooling, but they don’t have a monopoly. A well-funded team could create a compelling competitor to VS Code. The issue is that there’s no money to be made duplicating the effort that has gone into VS Code when VS Code is open source. Even Google doesn’t seem to care about entering that space.

> Microsoft may have a dominant position in developer tooling, but they don’t have a monopoly. A well-funded team could create a compelling competitor to VS Code.

I would argue that the best thing to come out of VS Code isn't even "VS Code" the overall environment, it's LSP [0], and MS has given that back to the community such that anybody can use it in a competing editor. I don't really think "VS Code" the product has a "moat" here and (up to now, at least) MS hasn't demonstrated much intent on creating one.

On a personal note I've tried using VS Code many times, but although the features look nice, I find the UI too alien. Luckily, vim has plugins to use LSP, so I can have all of the features I want in my existing editor.

[0] https://microsoft.github.io/language-server-protocol/

Re: The Future of the Gitlab Web IDE

#147

Post by d_watt »

codemusings wrote: post #126
zarzavat wrote: post #69

Earlier quoted context omitted.

Microsoft may have a dominant position in developer tooling, but they don’t have a monopoly. A well-funded team could create a compelling competitor to VS Code. The issue is that there’s no money to be made duplicating the effort that has gone into VS Code when VS Code is open source. Even Google doesn’t seem to care about entering that space.

> A well-funded team could create a compelling competitor to VS Code. And yet they failed. Remember Atom[1] or Brackets[2]? I'm sure they are still used by a lot of people. But it was interesting to see Microsoft grow VS Code so fast in popularity. My vague notion is that addressing developer pain points early and providing first party plugins for popular ecosystems gave them an edge. [1] https://github.com/atom [2]…

As a small anecdote as someone who switched from atom, the killer feature for VS Code is being extendable AND performant. I used to use atom for a flexible text editor, and then still have to use sublime text if I wanted to open a large file (atom choked on multi MB json files).

I don't know if it's possible to get the performance you need to make an IDE/text editor feel snappy in most situations with a pure DOM solution.

Re: The Future of the Gitlab Web IDE

#148

Post by eschurter »

crabmusket wrote: post #47

It's interesting to me that GitLab is adopting a Microsoft product (VS Code) and Microsoft owns a significant competitor in GitHub. Nothing intelligent to say about that other than to wish I'd been a fly on the wall for the discussions about that. > Next, we asked ourselves the question: Do we want to continue to invest in implementing custom features for the Web IDE that ultimately deliver the same value as those al…

GitLab PM and author of the OP here.

It is an interesting position we find ourselves in and we had some lively discussions about it! I would like to note, though, that Monaco (which powers our current Web IDE) is ALSO a Microsoft project. So this isn't a change in strategy as it relates to using open source projects maintained by those that may be seen as competitors.

We have faith in the future of VS Code as an open source project but I'll also say that this isn't a one-way door. If things change in the future, we're not so heavily leveraged that we couldn't replace the Web IDE's underlying editor again.

Re: The Future of the Gitlab Web IDE

#149

Post by eschurter »

john_cogs wrote: post #128
crossroadsguy wrote: post #58

> These lightweight changes make up the vast majority of the Web IDE usage Imho, that’s Web Text Editor. It’d be helpful to not mix junior an “editor” with an “IDE”. If someone at Gitlab is listening then it’d actually be a differentiator to make an IDE (and charge for it) to also those platforms where having a beefy laptop becomes a requirement (eg Android) and developers on those platforms, or a lot of them like me…

GitLab team member here. Thanks for the feedback. It would be great if you could share your insights and feedback on the public epic for the strategy for remote development: https://gitlab.com/groups/gitlab-org/-/epics/7419

GitLab PM and OP author here.

Thanks for linking that epic @john_cogs! You can also see the direction page for remote development: https://about.gitlab.com/direction/create/editor/remote_deve...

We're looking to a future where the Web IDE earns the "IDE" distinction, and you're absolutely right - for smaller edits, we'll continue to have a lightweight Web Editor.

Re: The Future of the Gitlab Web IDE

#150

Post by eschurter »

rmetzler wrote: post #44
dimgl wrote: post #5

While this is cool, for Node.js there's something far better: https://stackblitz.com/ . This is one of the more impressive IDE in browser experiences I've had. Comes complete with a terminal and a shim around `npm` that allows you to install JavaScript dependencies directly to the browser. Some truly cool stuff.

There is also https://www.gitpod.io/ I like the current WebIDE. It has two features which are important to me: - Lauch it with the . hotkey, from the file or merge request you currently browse - multi cursor with CMD+D on a Mac I don’t think I need VSCode, but we’ll see.

GitLab team member and OP author here.

I'm glad you enjoy that `.` hotkey! Don't worry, it won't go away! I'm about 90% sure multi cursor works the same way, but I'll verify and make sure we don't take a step back there :)

I hope you find value in the other features we'll be delivering as part of the VS Code transition!

Post reply on HN