Live data from Hacker News

The Future of the Gitlab Web IDE

about.gitlab.com

61–70 of 168 posts

Re: The Future of the Gitlab Web IDE

#61
post #55
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 (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…

I agree. I use Neovim and my setup constantly break when upgrading plugins. I could avoid this pretty much by just using Visual Studio Code, but that in my opinion is pretty close to these Web IDEs already.

Re: The Future of the Gitlab Web IDE

#62
post #55
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 (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 setup might make sense for this reason.

Also, dependent on what you're doing you might need to run a bunch of services that your laptop isn't powerful enough to handle. This happened with my last project where there were 30+ microservices each in a docker container, 3 frontend environments in docker containers, all running in vagrant (vagrant was gotten rid of when the latest Docker release happened, but I didn't update to get the new experience cause my contract was running out)

Sometimes there were issues when I needed to work on several things together.

Re: The Future of the Gitlab Web IDE

#63
It would be amazing to figure out how to make a Web IDE with a local shell that's inexpensive to run. Something that uses Spot instances with seamless migration between hosts. No one has really addressed this problem so far - all of the existing cloud IDEs cannot match a modern multi-core dev laptop without breaking a bank.

Re: The Future of the Gitlab Web IDE

#64

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…

At a previous job, we self hosted our version control software, and when it broke, you could practically hear the money being poured down the drain, as the SREs scrambled to figure out why and get us back into a working state. At least when things break locally, they (usually) don't break for everyone. I get that there are pros and cons to each pattern, but I agree that the remote dev crowd is glossing over the fact that these remote envs break too, and the impact is huge.

Re: The Future of the Gitlab Web IDE

#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.

Re: The Future of the Gitlab Web IDE

#66
post #52
post #29

Earlier quoted context omitted.

I don't think it's quite that simple. Everywhere I've worked with Javascript, Python, or Ruby you run into a bunch of random issues that happen with a specific MacOS update or some other crazy context. Or the documentation just isn't the company's priority. However I do agree that web-only seems a bit much. Just last night I was doing some company work on my laptop while my power was out (no internet). The nice middl…

Why don't they have devs use Linux laptops? Problem solved. Just let them run the same OS as prod no? Or have them use VMWare or Docker.

Cause an OS update has never broken docker before right. And prod doesnt run linux with a gui.

Re: The Future of the Gitlab Web IDE

#67
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?

As I see it: people spend lots of time (collectively) when it comes to setting up new environment. Whether you're new developer who just came to the project, whether you're asked to help on another project, whether you need to fix a bug in some old project. I can spend hour setting up project and then 1 minute delivering a fix. Usually I just use notepad to edit source files and then cmd to build and test, but that's not very good environment and many developers are not proficient enough to work with notepad and cmd.

So web IDE definitely have its uses. I think that it's not ready for most projects, because Intellij provides vastly superior experience for almost all languages, but still I believe that VScode is the future and it'll surpass Idea at some day, because it's more open source.

Also, I hope, that all those remote workflows will be replicated with local setups. I don't see any reason not to other than locking user into your website. I mean VScode works locally, docker works locally, git works locally.

Re: The Future of the Gitlab Web IDE

#68
post #55
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 (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 with itself.

Re: The Future of the Gitlab Web IDE

#69

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.

Re: The Future of the Gitlab Web IDE

#70
post #15
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…

The ailments you describe can be resolved by having a small dedicated Developer Experience team. Their mission is to ensure that developers can ramp up quickly with deterministic environments and keep a high velocity with developer tooling. If a big company doesn't have one, they're messing up. I see the benefits of having something that "always works" though the browser, but for me, the lack of control does not outw…

> The ailments you describe can be resolved by having a small dedicated Developer Experience team.

I effectively ran that team for several years. We invested huge resources in tooling for laptop Docker environments.

Eventually (after I had moved on) that team decided that remote development environments would be a more efficient solution. I don't disagree with them!

Post reply on HN