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 Future of the Gitlab Web IDE
21–30 of 168 posts
Re: The Future of the Gitlab Web IDE
#22Maybe 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…
I'll stick with my reliable local environment, thank you.
Re: The Future of the Gitlab Web IDE
#23Maybe 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?
Re: The Future of the Gitlab Web IDE
#24Maybe 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…
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
#25Earlier 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…
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
#26While 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.
Re: The Future of the Gitlab Web IDE
#27It's a big change, but not necessarily groundbreaking or noteworthy.
Re: The Future of the Gitlab Web IDE
#28Maybe 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 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
#29Earlier 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.
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
#30Maybe 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?
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).