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

151–160 of 168 posts

Re: The Future of the Gitlab Web IDE

#151

Post by nisegami »

bibinou wrote: post #106
dijit wrote: post #104

Earlier quoted context omitted.

To be completely fair to Gitlab: reimplementing the same thing but worse isn't exactly fun; gitpods is already doing this basically. VSCode, as much as I don't personally use it: does have a completely free and open source version in vscodium: https://vscodium.com/ Isn't it better to consolidate efforts on a vscode fork in the event of hostile tactics by Microsoft?

a fork developed by who? OP is literally Gitlab admitting they can't build a competitive web editor.

>OP is literally Gitlab admitting they can't build a competitive web editor.

Or they've just decided it's not a good use of their finite resources?

Re: The Future of the Gitlab Web IDE

#152

Post by eschurter »

TekMol wrote: post #59

What is the idea here on how to use it for anything but front end development? When I edit PHP, Python, Ruby, whatever code that is hosted on GitLab via their Web IDE, how am I supposed to see the result when it needs a whole stack with Linux, Apache and MySQL below it to run?

GitLab PM and OP author here!

You're right, the client-side instance of VS Code is only a piece of the full "IDE" puzzle. You can learn more about our direction for providing server-side runtime on our Remote Development direction page: https://about.gitlab.com/direction/create/editor/remote_deve... More on that in the near future.

Re: The Future of the Gitlab Web IDE

#153

Post by rizzaxc »

happymellon wrote: post #79
keybits wrote: post #71

Earlier quoted context omitted.

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…

more like because the language is a non obvious clusterfuck that requires self-inflicted pain to be productive in. sounds like a good use case for a remote container

not to mention, pair programming/ merge review will be easier, making guiding juniors more efficient. of course i'm not saying it'll be all positive but there are legitimate reasons gitlab is doing this

Re: The Future of the Gitlab Web IDE

#154

Post by shp0ngle »

sarki_247 wrote: post #142
shp0ngle wrote: post #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.)…

GitLab team member here! This implementation will be client-side only, with a selection of extensions allowed. Self-hosted instance admins will be able to enable or create an allow-list of extensions on their instance. You can learn more in this epic: https://gitlab.com/groups/gitlab-org/-/epics/7683

Ahh. So users cannot open terminal on your servers, or run a test?

Re: The Future of the Gitlab Web IDE

#155

Post by isitmadeofglass »

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 owns a significant competitor in GitHub.

And Azure DevOps which is competing in the same corporate segment where gitlab might otherwise make some money.

Re: The Future of the Gitlab Web IDE

#156

Post by dimgl »

PoignardAzur wrote: post #114
dimgl wrote: 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.

Oh hey, a recruiter made me code on stackblitz for an interview recently, and I couldn't find the site again afterwards. Thanks for the link. Yeah, stackblitz is amazing. At least during that one interview, it worked flawlessly.

That... might have been me :D haha

Re: The Future of the Gitlab Web IDE

#157

Post by echelon »

teddyh wrote: post #86
echelon wrote: post #45

Earlier quoted context omitted.

> The ailments you describe can be resolved by having a small dedicated Developer Experience team. This is a cost center and will be underfunded in most companies and orgs. Companies want to focus on their core competency. Also, devenv is non-standard across companies. If a company wants a truly interchangeable workforce, they want standard tools that look the same everywhere. > but for me, the lack of control does n…

Because firing people more efficiently in the creative industry is an important problem to be solved?

Think of the trouble companies go to secure their machines and IP in the remote workforce world. To trace which customer accounts you access and when. MDM, remote locks, audit logs, etc. This is one step shorter.

Just because you're trustworthy doesn't mean everyone you hire will be. You see abuses by employees in the news all the time.

In a startup, everyone has admin powers. You don't have time to put up walls. In a process mature company that deals with customer PII, confidential information, trade secrets, etc., you limit the scope to only what is needed when it is needed. This is just an extension of that security posture.

Re: The Future of the Gitlab Web IDE

#158

Post by native_samples »

snitko wrote: post #21
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…

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

Exactly. That problem doesn't exist anymore in the JVM ecosystem. You can literally just install intellij and open some random project. It will download the jdk, the build system, all your dependencies, everything. It works on every OS, every time. It doesn't break across OS upgrades.

This is a language/tooling issue, not a local Vs remote issue even though it may seem that way to people using languages that are only barely working on non-Linux systems.

Re: The Future of the Gitlab Web IDE

#160

Post by simonw »

diffeomorphism wrote: post #111
simonw wrote: post #72

Earlier quoted context omitted.

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

So why remote instead of a container or VM?

We started out giving people a VM (using Vagrant). We later moved to having people run Docker containers on their laptops instead (Docker for Mac).

Engineers - junior and experienced - found new ways to break both of those, constantly.

Post reply on HN