Live data from Hacker News

The Future of the Gitlab Web IDE

about.gitlab.com

21–30 of 168 posts

Re: The Future of the Gitlab Web IDE

#21
post #13
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?

> 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…

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

Re: The Future of the Gitlab Web IDE

#22
post #13
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?

> 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 few remote services I rely on broke on me far more times than my local development environment. Far more if you consider degraded internet connections.

I'll stick with my reliable local environment, thank you.

Re: The Future of the Gitlab Web IDE

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

I don't want it but I 100% want to send everyone who's new to coding to something like this. It's so goddamn hard to set up your first environment, when you have no idea what you're doing yet. I recommend people do freecodecamp because everything is right there in your browser and it just works and there's no setup. Setups are so much harder than writing code.

Re: The Future of the Gitlab Web IDE

#24
post #13
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?

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

Re: The Future of the Gitlab Web IDE

#25
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…

Yes, you can.

Web IDEs are usually some sort of containerized linux environment with a text editor and a terminal. All accessible in the browser. What kind of lack of control are you thinking of?

Re: The Future of the Gitlab Web IDE

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

Can the installed dependencies be downloaded locally? It might be a great way to resolve npm dependencies without resolving having to run npm on my system.

Re: The Future of the Gitlab Web IDE

#27
I feel that moving from Monaco to VS Code OSS (which is based on Monaco) is analogous to moving from a custom protocol on top of tcp to the standard http protocol.

It's a big change, but not necessarily groundbreaking or noteworthy.

Re: The Future of the Gitlab Web IDE

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

> I don't want to do all development-related tasks in my web browser

You don't need to use a browser to do remote development. Emacs has been able to remote dev through SSH for ages. Not only opening files, but also launching processes. VSCode also has this feature via an extension that works automatically.

> I want to be able to experiment with the software in various local setups

Precisely. Not everyone has a suitable local machine, maybe because of security, maybe because access to data or maybe because needed hardware.

> Are people really clamoring for this feature?

Absolutely. I think it's truly part of the success of jupyter notebooks, to put an example.

Re: The Future of the Gitlab Web IDE

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

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 middle ground is dockerized development containers in VSCode, IMO. Very excited to set that up when I get a chance. And they translate right into all these fancy web IDEs (like Github codespaces) so you can have a dev env in the cloud if you really want to, and snag it for a plane or train ride etc.

Re: The Future of the Gitlab Web IDE

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

I don’t even know how I would develop with something like this.

My entire workflow is based around tens of little scripts I’ve written. Many scripts tend to be unique to a single project.

For example, I’m currently working in a project that’s based on an open source front end framework that has been discontinued for over 5 years. Creating a new component requires the creation of 3 different files with a ton of boilerplate. And there are many types of components that can go in different locations.

A simple Unix script means I can create all with the boiler plate in an instant. If I want to open a component it automatically opens all 3 files. And if I’m working on multiple bugs/features simultaneously I can create “workspaces”, by entering file names in a text file for each workspace and open each workspace instantly (or automatically on switching on my computer).

This is just one, probably least impressive, but extremely useful, piece of functionality I simply won’t be able to do (or if they provide some sort of API, it will require a bunch of code with a foreign API for me to execute).

Post reply on HN