Live data from Hacker News

The Future of the Gitlab Web IDE

about.gitlab.com

31–40 of 168 posts

Re: The Future of the Gitlab Web IDE

#31
By the way, Monaco is 10MB+.

That's quite impressive nowadays for something so feature filled, but you're staying for 10MB when doing quick edits.

Monaco is a mature, powerful and pluggable, which makes it a good platform to build on top of. More cynically, it's a good bang-for-the-buck project if you are seeking a promotion. The alternative is building your own. Maybe that doesn't make good business sense. And that's exactly why I'm crafting a good enough web-based code editor under 14KB ( a single TCP roundtrip ). I was optimistic for Cloud9. It was built from the ground up, for the web, and was at a suite spot between being light but entirely suitable inline code edits.

Re: The Future of the Gitlab Web IDE

#32
post #29

Earlier quoted context omitted.

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

Agree with you about the MacOS update problem, though this seems to have gotten much better lately. With rbenv, asdf, etc. plus pinned gemfiles, package.json, etc. I really haven't experienced anything like the frustration that surrounded Ruby and JS 10 years ago. YMMV I suppose.

Re: The Future of the Gitlab Web IDE

#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.) But again that is probably fine here.

Re: The Future of the Gitlab Web IDE

#34
post #25
post #15

Earlier quoted context omitted.

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?

30 years of experience of using UNIX as my IDE, with my editor and debugger of choice.

All I see is the industry heading back to the 60s, where the high priests took care of the computer, and users were an after thought that paid for CPU and storage. We had the PC revolution for a reason.

Re: The Future of the Gitlab Web IDE

#35
post #25
post #15

Earlier quoted context omitted.

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?

For example, the ability to spin up ad-hoc services to test the software against, like if I was replacing mysql with postgres, or experimenting with a caching service. If I have access to a terminal connected to a container, that's nice, and maybe I can experiment with some of these services, but if this container is in a Pod in Kubernetes and the K8s scheduler decides to move my Pod to another node, I just lost all of my custom work.

Re: The Future of the Gitlab Web IDE

#36
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'm just starting to notice the oh-no-so-that's-how-getting-old-works fumes myself (31, and not quite on track yet either yay lol). I empathize.

Way I see it, there are at least two ways to use this sort of thing:

- Connecting to corporate dev servers (most likely in EC2, maybe on-prem), maybe even using a tablet or Chromebook

- Doing editing on personal boxen from either across the room, or across town, using an integrated experience that smoothly achieves what the editor+SSH/(S)FTP thing handled reasonably well but not this well

So it's kind of like just moving the server around. Sure it enables the sort of mass anonymity you're describing, but doesn't enforce or especially empower that type of scenario to happen any sooner.

Also just FWIW, VSCode is local-first; it was built for Electron, then monkey-patched (unreasonably easily for obvious reasons) to save and load data using HTTPS APIs... but even though this does now require an online internet connection this particular contraption is built on top of GitLab, and presumably all this will find its way into GitLab CE, so you still retain the ability to own the whole process.

This sort of thing also has a stealth killer app in responding incredibly effectively to the "oh great production broke" type of situation - you can now very literally borrow the first machine in sight, since you only need to open a single incognito tab to do your work. You could even fullscreen the tab to hide whatever else might be on the screen (and you might even prefer to to gain screen real estate).

Re: The Future of the Gitlab Web IDE

#37
post #25
post #15

Earlier quoted context omitted.

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?

Next step would be to put all on a server together with VC, Issues, and CI.

Re: The Future of the Gitlab Web IDE

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

Welcome back to the glory UNIX days when all we had were thin terminals into UNIX development server used by the whole team.

The delightful development experience that gets praised everywhere. /s

Re: The Future of the Gitlab Web IDE

#39
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 boiler…

On the GitHub side, via codespaces, welcome to the modern version of telnet/X Windows.

Re: The Future of the Gitlab Web IDE

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

Yes, many public companies are interested in this to improve supply chain security and to reduce the cost of employee equipment.
Post reply on HN