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

131–140 of 168 posts

Re: The Future of the Gitlab Web IDE

#131

Post by dnsmichi »

jillesvangurp wrote: post #90
jve wrote: post #78

Earlier quoted context omitted.

Haven't ever used JetBrains Rider, but I hear they too have remote development capability: https://www.jetbrains.com/remote-development/

Jetbrains just did a deal with gitpod as well: https://www.gitpod.io/blog/gitpod-jetbrains Remote development environments are becoming a thing. I've not really had a chance to explore this space a lot but I might.

GitLab team member here - Sid shared a Twitter thread a while ago which has more insights into remote development environments and server runtime. [0]

At GitLab, there are open roles for "Server Runtime" in the incubation engineering team [1] [2] in case someone is interested in joining and building this together :)

[0] https://twitter.com/sytses/status/1400134840754733059

[1] https://about.gitlab.com/handbook/engineering/incubation/#op...

[2] https://about.gitlab.com/jobs/all-jobs/

Re: The Future of the Gitlab Web IDE

#133

Post by dnsmichi »

jve wrote: post #74
daenz wrote: 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?

You have a choice after all (local vs remote). And it is useful/convenient on having remote development option available. There is another remote development convenience point I don't see mentioned in this thread: Infrastructure. If your frontend/backend is isolated and depends on heavy services (i.e on-premise cloud platform API), having development environment configured for you where everything is configured appro…

> It can benefit security too: no longer can "npm install" consume your private stuff. Worst case - take your source code and, given properly isolated dev env, take only development secrets and data, which must not be useful.

GitLab team member here. Very good point, thanks. A different way for supply chain attacks, the local dev environment.

Similar thought with install routines in extensions (and dependencies) that are scanning your local home directory, where Git/cloud/etc. secrets might be stored in plain-text. Fixable in my environment, can become a problem with teams and onboarding at scale.

The limitations can also bring in new views, for example to switch to using time limited tokens instead of plain text auth (Hashicorp Vault, etc.) and evaluate more possible attack vectors, and ways to mitigate and observe security problems.

A remote development environment runs in a sandbox, similar to a container in CI/CD jobs, can be limited with auth and access, and also be monitored for syscalls and other unexpected behaviour.

Potentially interesting for Ops running the remote development platforms (e.g. Gitpod) - Falco, Cilium, eBPF, etc. for security observability. More updates and ideas in the eBPF day recordings from KubeCon EU last week. [0]

[0] https://www.youtube.com/playlist?list=PLj6h78yzYM2PzqjM3DTYj...

Re: The Future of the Gitlab Web IDE

#134

Post by m_eiman »

alephnan wrote: post #115
m_eiman wrote: post #97

Earlier quoted context omitted.

> under 14KB ( a single TCP roundtrip ) That's not a single roundtrip in any TCP stream I've heard of... Still, a lot smaller than 10MB of course.

https://tylercipriani.com/blog/2016/09/25/the-14kb-in-the-tc...

Ah, so it's "initial window size" than than "ping round trip". Interesting. The RFC they reference doesn't seem to be elevated to official standard, and it appears different OSes have different default values.

On my Mac sysctl net.inet.tcp.maxseg_unacked says 8, which I assume is the relevant TCP option. But in the case of a server responding to a HTTP request I suppose the server could set it to basically any value, so why stop at 10? :)

Re: The Future of the Gitlab Web IDE

#135

Post by alasdair_ »

zarzavat wrote: post #69
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 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.

Jetbrains seems to do well enough.

Re: The Future of the Gitlab Web IDE

#136

Post by dnsmichi »

whazor wrote: post #50
daenz wrote: 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?

That is because we have expensive MacBooks and elaborated development setups. Having a web-based IDE is great for newcomers and will work on cheap Chromebooks or iPads. Especially as Gitlab the entire infrastructure for both development and deployment.

> Having a web-based IDE is great for newcomers and will work on cheap Chromebooks or iPads

Good call, thanks. GitLab team member here.

From my experience as GitLab trainer in my past job, a web frontend to edit files hides the complexity of Git on the CLI, and helps with the "5 min success" to get going and learning. This can help with team member onboarding, as well as OSS projects looking for contributors.

Combined with CI/CD pipeline feedback in the same interface, without context switches, it makes the learning story easier to follow too.

The first workshops to get started with GitLab CI/CD from 2 years ago, are linked in the documentation, and use the Web IDE. [0] Seen great learning curves from the wider community :-) Taking a note to create a new workshop with the new IDE in the future. [1]

[0] https://docs.gitlab.com/ee/ci/quick_start/

[1] https://gitlab.com/gitlab-com/marketing/corporate_marketing/...

Re: The Future of the Gitlab Web IDE

#137

Post by crabmusket »

polote wrote: post #110
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…

Github is not a competitor to Gitlab, they offer some similar services but overall it is not the same value proposition

What would you say are their value propositions then?

Re: The Future of the Gitlab Web IDE

#138

Post by greatgib »

greatgib wrote: post #101

Always have to check the date for April's fool day when seeing a news like that, but sadly it is not... When you think that gitlab started as an open source alternative to the closed world of GitHub, and was free as in "free speech". And then, little by little it becomes the same thing. Less and less things not in premium plan and less affordable plans. Now, they are ok to use as-is a Microsoft editor, that is free a…

Vscode is not free btw: https://news.ycombinator.com/item?id=31488436

The thing is always the same, in OSS you get for free a little bit less good version of VSCode. But you get used to it, competitor development is killed little by little, like in the current case. And, when everyone is "hooked", and every one and companies are used to it, you can slowly reduce/limit the oss version and push everyone to the the proprietary version with telemetry, evil, and more.

Same thing with the OSS version of Android.

Or, worse, what happened with Chrome that replaced every browser engine except FF and Safari to the point of domination. And now, regularly Google impose theirs changes unilaterally to the Web community without discussion possible.

Re: The Future of the Gitlab Web IDE

#139

Post by sarki_247 »

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 Team member here! You can set up different environments with whatever dependency your application needs. GitLab CI can build/deploy your application to the right environment depending on various factors. You can also look at GitLab Review Apps, which "is a collaboration tool that assists with providing an environment to showcase product changes."

See: https://docs.gitlab.com/ee/ci/review_apps/

Re: The Future of the Gitlab Web IDE

#140

Post by dijit »

greatgib wrote: post #138
greatgib wrote: post #101

Always have to check the date for April's fool day when seeing a news like that, but sadly it is not... When you think that gitlab started as an open source alternative to the closed world of GitHub, and was free as in "free speech". And then, little by little it becomes the same thing. Less and less things not in premium plan and less affordable plans. Now, they are ok to use as-is a Microsoft editor, that is free a…

Vscode is not free btw: https://news.ycombinator.com/item?id=31488436 The thing is always the same, in OSS you get for free a little bit less good version of VSCode. But you get used to it, competitor development is killed little by little, like in the current case. And, when everyone is "hooked", and every one and companies are used to it, you can slowly reduce/limit the oss version and push everyone to the the prop…

I'm not sure your link is pointing to the right place; right now it goes to an article titled "The Xinjiang Police Files".

Also, to your point about vscode not being free; you're right of course, but we _do_ have a FOSS edition of it.

Post reply on HN