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

71–80 of 168 posts

Re: The Future of the Gitlab Web IDE

#71

Post by keybits »

happymellon wrote: post #42
snitko wrote: post #21

Earlier quoted context omitted.

Perhaps the problem isn't your particular environment, but these languages infrastructure.

It sounds like PEBKAC. I literally have not had Python just break on me, and after decades of software development at various places using Python/Java/Javascript I would say it is rare these days to see it happen to other people in the team either. It usually happens when someone decides to experiment with a different way of handing application versioning that they saw on HN, but they aren't actually experienced enou…

The person they're replying to is, amongst other notable achievemeents, the co-creator of Django: https://en.wikipedia.org/wiki/Simon_Willison

Re: The Future of the Gitlab Web IDE

#72

Post by simonw »

diffeomorphism wrote: post #53
simonw wrote: post #13

Earlier quoted context omitted.

> Are people really clamoring for this feature? Yes. Because local development environments (at least for the languages I work with, Python and JavaScript) break ALL THE TIME. With 20+ years of experience I can just about keep my own laptop ticking over - but it takes work, and every time I mentor a new learner this is the number one sticking point. The browser-based cloud IDE experience, where it doesn't matter what…

Maybe a stupid question, but doesn't the remote environment run basically the same software? Or at least the same software as a local container or VM would? If so, why would this break less often?

200 engineers means 200 subtly different laptop environments, each of which could break in slightly different ways.

With a good remote environment solution, each engineer can click a link and get a pre-tested, standardized development environment.

They can then break it in any way they like... but then they can click that link again to get a fresh, working environment again.

Imagine if any time you broke yoir environment your IT department could hand you a fresh laptop with a working environment on it. It's that.

Re: The Future of the Gitlab Web IDE

#73

Post by simonw »

rjzzleep wrote: post #57
diffeomorphism wrote: post #53

Earlier quoted context omitted.

Maybe a stupid question, but doesn't the remote environment run basically the same software? Or at least the same software as a local container or VM would? If so, why would this break less often?

You hit the nail on its head. There is absolutely no reason why the remote environment doesn't have exactly the same issue the local environment has. It will still need its rbenv etc for any sort of ruby/node/python etc versioning. I think what the person above means when he says "local breaks ALL THE TIME", the reality is that every now and then during major OS updates MacOS may make major breaking changes in system…

I have seen environments break in so many different ways - especially for less experienced developers.

Re: The Future of the Gitlab Web IDE

#74

Post by jve »

daenz wrote: post #12

Maybe I'm getting old, but I don't want to do all development-related tasks in my web browser. As a software engineer, I want local control, where an internet connection is optional. I want to be able to experiment with the software in various local setups. I just don't get why Gitlab thinks this is a good idea worth a huge amount of engineering effort. Are people really clamoring for this feature?

You have a choice after all (local vs remote). And it is useful/convenient on having remote development option available.

There is another remote development convenience point I don't see mentioned in this thread: Infrastructure. If your frontend/backend is isolated and depends on heavy services (i.e on-premise cloud platform API), having development environment configured for you where everything is configured appropriately (firewall rules, security certificates for services and web) is convenient. Even if dev env was local, your host still must have appropriate access to that infrastructure.

It can benefit security too: no longer can "npm install" consume your private stuff. Worst case - take your source code and, given properly isolated dev env, take only development secrets and data, which must not be useful.

We are currently experimenting with such setup which VSCode enables us.

Re: The Future of the Gitlab Web IDE

#75

Post by simonw »

ARandomerDude wrote: post #24
simonw wrote: post #13

Earlier quoted context omitted.

> Are people really clamoring for this feature? Yes. Because local development environments (at least for the languages I work with, Python and JavaScript) break ALL THE TIME. With 20+ years of experience I can just about keep my own laptop ticking over - but it takes work, and every time I mentor a new learner this is the number one sticking point. The browser-based cloud IDE experience, where it doesn't matter what…

> Yes. Because local development environments...break ALL THE TIME. This seems like more of a process problem than a technology problem. Our company has a simple rule for this: you break it, you fix it -- immediately. As a result, our development process is very stable.

How many hours a week on average do your engineers spend fixing something in their own environment that they broke?

Re: The Future of the Gitlab Web IDE

#76

Post by defanor »

ar_lan wrote: post #17
simonw wrote: post #13

Earlier quoted context omitted.

> Are people really clamoring for this feature? Yes. Because local development environments (at least for the languages I work with, Python and JavaScript) break ALL THE TIME. With 20+ years of experience I can just about keep my own laptop ticking over - but it takes work, and every time I mentor a new learner this is the number one sticking point. The browser-based cloud IDE experience, where it doesn't matter what…

Nix solves this exact problem you've described.

There is a few more approaches to solving this, with different drawbacks:

- Nix, Guix, package managers in general: suitable for advanced users, but smooth sailing is not guaranteed, especially with Nix/Guix on top of an arbitrary system.

- Remote (virtual) desktop: network lags, dependence on Internet connection, issues with resolution mismatches and whatnot, but fairly straightforward and seems to be somewhat popular. Being a remote system in a thin client, seems similar to the web IDE approach.

- Configuration management software (ansible and friends, and/or just git and stow): also rather for advanced users and may require some debugging/adjustments.

- (Possibly lightweight) virtualization: used commonly, with all the containerization. I've also heard of a person downloading a VM from an online storage, working in it, saving the progress, uploading that -- allowing to work locally.

- Web-based projects (as being discussed).

- Working on a remote server over SSH (including pubnix systems), possibly with X forwarding (also similar to the discussed approach, with a thin client, though doesn't require special software).

Edit: also depending on kinds of projects one works on, some of those won't work at all: developing software that interacts with hardware, even something common like a graphics card, may not work at all (or work better, depending on a setup) with remote approaches, and is likely to be more tricky with virtualized ones.

Edit 2: actually looking closer into GitLab Web IDE, seems like it may be closer to the remote/virtual desktop software, but accessible via a web browser.

Re: The Future of the Gitlab Web IDE

#77

Post by alephnan »

DeathArrow wrote: post #65

I want to own the code, own the software, own the tools (IDE, compiler etc) and also be the only one who controls them. And I want to also develop fast, not wait for some goddamn web app. And no, I don't need to code on my phone or tablet while travelling to Bahamas.

What IDE do you 'own'?

Re: The Future of the Gitlab Web IDE

#78

Post by jve »

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.

Haven't ever used JetBrains Rider, but I hear they too have remote development capability: https://www.jetbrains.com/remote-development/

Re: The Future of the Gitlab Web IDE

#79

Post by happymellon »

keybits wrote: post #71
happymellon wrote: post #42

Earlier quoted context omitted.

It sounds like PEBKAC. I literally have not had Python just break on me, and after decades of software development at various places using Python/Java/Javascript I would say it is rare these days to see it happen to other people in the team either. It usually happens when someone decides to experiment with a different way of handing application versioning that they saw on HN, but they aren't actually experienced enou…

The person they're replying to is, amongst other notable achievemeents, the co-creator of Django: https://en.wikipedia.org/wiki/Simon_Willison

His comment was more that the juniors that he mentors break their environments.

The junior breaking their environment is usually self inflicted. Besides to fix this, you still don't need to run everything remotely.

[Edit] In my experience, the biggest slowdown to being productive is corporate lockdown of laptops, but then no support from corporate for getting a development environment set up. So the first 2 weeks on the job is waiting for local admin permissions so that you can install brew and make your Mac environment as close to Linux as possible.

Re: The Future of the Gitlab Web IDE

#80

Post by makeitdouble »

DeathArrow wrote: post #65

I want to own the code, own the software, own the tools (IDE, compiler etc) and also be the only one who controls them. And I want to also develop fast, not wait for some goddamn web app. And no, I don't need to code on my phone or tablet while travelling to Bahamas.

Are you even using Gitlab then ?

I feel you are completely out of their target base.

Post reply on HN