The Future of the Gitlab Web IDE
about.gitlab.com
about.gitlab.com
> 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 already available in VS Code? Or do we embrace VS Code inside GitLab, and invest in extending the experience to more tightly integrate with GitLab and the DevOps workflow?
I feel like if asking myself those questions I'd have come to the same answer, but it's certainly an interesting position. It's not necessarily that I think Microsoft will leverage this open-source project against GitLab. Maybe it just says something about Microsoft's increasingly-dominant position in developer tooling.
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.
Remote development environments are becoming a thing. I've not really had a chance to explore this space a lot but I might.
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...
In 10 years Google regret not buying Github.
They regretted it the day it was announced.
And yet they failed. Remember Atom[1] or Brackets[2]? I'm sure they are still used by a lot of people. But it was interesting to see Microsoft grow VS Code so fast in popularity. My vague notion is that addressing developer pain points early and providing first party plugins for popular ecosystems gave them an edge.
I don't know if it's possible to get the performance you need to make an IDE/text editor feel snappy in most situations with a pure DOM solution.
I would argue that the best thing to come out of VS Code isn't even "VS Code" the overall environment, it's LSP [0], and MS has given that back to the community such that anybody can use it in a competing editor. I don't really think "VS Code" the product has a "moat" here and (up to now, at least) MS hasn't demonstrated much intent on creating one.
On a personal note I've tried using VS Code many times, but although the features look nice, I find the UI too alien. Luckily, vim has plugins to use LSP, so I can have all of the features I want in my existing editor.
As far as I can tell, Microsoft's moats here are things like Teams, Live Share, and Remote. If anyone has or is working on open source implementations that can be installed into the open source version, I'm sure there would be widespread interest.
We have considered Theia in the past. Here are a couple of related epics/issues:
It is an interesting position we find ourselves in and we had some lively discussions about it! I would like to note, though, that Monaco (which powers our current Web IDE) is ALSO a Microsoft project. So this isn't a change in strategy as it relates to using open source projects maintained by those that may be seen as competitors.
We have faith in the future of VS Code as an open source project but I'll also say that this isn't a one-way door. If things change in the future, we're not so heavily leveraged that we couldn't replace the Web IDE's underlying editor again.
And Azure DevOps which is competing in the same corporate segment where gitlab might otherwise make some money.
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 as in "free core" and is in the straight line of the EEE strategy.
So, for me, each time it is less and less reasons to use gitlab and better to use directly GitHub, for better performances anyway...
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?
OP is literally Gitlab admitting they can't build a competitive web editor.
Let Gitlab focus on git repositories, project management and devops. Everything else is just a pure waste of time.
1) It is a product that exists, maintenance is easier than building from scratch in this case.
2) a consolidated effort by many people in maintaining a fork will allow much more effort than gitlab alone can spend.
3) mindshare on how vscode works already exists externally, a new webIDE doesn't have the same level of developer mindshare anyway.
As a paying gitlab customer I'd rather their money be spent on things that actually matter; reimplementing open source tools does not matter.
Or they've just decided it's not a good use of their finite resources?
For me it's https://sourcehut.org/ or https://codeberg.org/ but mostly sourcehut
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.
Also, to your point about vscode not being free; you're right of course, but we _do_ have a FOSS edition of it.
Imho, that’s Web Text Editor. It’d be helpful to not mix junior an “editor” with an “IDE”.
If someone at Gitlab is listening then it’d actually be a differentiator to make an IDE (and charge for it) to also those platforms where having a beefy laptop becomes a requirement (eg Android) and developers on those platforms, or a lot of them like me, would love to have a platform online that’s largely independent of a development machine.
It would be great if you could share your insights and feedback on the public epic for the strategy for remote development: https://gitlab.com/groups/gitlab-org/-/epics/7419
Thanks for linking that epic @john_cogs! You can also see the direction page for remote development: https://about.gitlab.com/direction/create/editor/remote_deve...
We're looking to a future where the Web IDE earns the "IDE" distinction, and you're absolutely right - for smaller edits, we'll continue to have a lightweight Web Editor.
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.
That's not a single roundtrip in any TCP stream I've heard of... Still, a lot smaller than 10MB of course.
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? :)
And I want to also develop fast, not wait for some goddamn web app. And no, I don't need to code on my phone or tablet while travelling to Bahamas.
[0] https://docs.gitlab.com/ee/user/project/repository/vscode.ht...
[1] https://about.gitlab.com/blog/2021/05/20/vscode-workflows-fo...
And I'm just talking about C++ IDEs here.
I feel you are completely out of their target base.
Personally, I’m using Tailscale + VS Code with the Remote-SSH plug-in, accessing my home server.
I like the current WebIDE. It has two features which are important to me:
- Lauch it with the . hotkey, from the file or merge request you currently browse
- multi cursor with CMD+D on a Mac
I don’t think I need VSCode, but we’ll see.
I'm glad you enjoy that `.` hotkey! Don't worry, it won't go away! I'm about 90% sure multi cursor works the same way, but I'll verify and make sure we don't take a step back there :)
I hope you find value in the other features we'll be delivering as part of the VS Code transition!
Yeah, stackblitz is amazing. At least during that one interview, it worked flawlessly.
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.
The extensions and settings sync are going to be interesting, especially since they were pretty positive about extension support in the post.
In short, it's hard to tell if you are doing repeated C++ builds or mining cryptocurrency.
But yeah it's not that different from CI.
If you just need a terminal like thing to local-dev in, toolbx[3] is probably the first choice. These are probably where we run our LSP/Language Server Protocol helpers too. Eventually I expect we won't really notice or care that the "computer" ("local") is virtual, just some container.
[1] https://github.com/okteto/okteto
[2] https://marketplace.visualstudio.com/items?itemName=okteto.r...
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?
For instance if you need to change a value in a configuration file, you can make the change in a new branch, have the CI pass on it, check if every was fine, and merge/deploy as needed. All from the web interface.
I'm sure some people use it do crazy complex changes, but I see it as convenience for scope limited tasks more than anything.
GitHub is using Codespaces itself [0], which is a huge Rails app with tons of infrastructure behind it I’d assume.
[0]: https://github.blog/2021-08-11-githubs-engineering-team-move...
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.
> In this video Paul Slaughter, Staff FE Engineer, walks Eric Schurter, Senior Product Manager
Here's all the justification you need. Work doesn't have any value by itself.
It's a big change, but not necessarily groundbreaking or noteworthy.
The current Web IDE is not an IDE at all - VSCode is.
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 you've got going on with your laptop, you just visit a URL and start work, is an incredible productivity boost for the vast majority of people.
When I think about how much time was wasted on broken personal development environments at my last big employer (several hundred engineers)... I reckon the lost productivity was easily in the low millions of dollars per year.
AND with the fact that management in most companies 100% wants the productivity/onboarding gains of these products.
I hate how broken dev environments always are. This is one answer, and IMO it will work initially and lead to quite bad outcomes for us devs long term.
I see the benefits of having something that "always works" though the browser, but for me, the lack of control does not outweigh this convenience. I mean, can you even step through a debugger session? That's a basic requirement imo.
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?
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.
If until then I'm able to compile stuff on my computer, I'll be happy (source available <> able to compile).
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 not outweigh this convenience
The CTO or CEO will be making this call instead of ICs.
The future is thin clients. It's not just going to be our industry, either. Every creative industry is going to undergo this change.
Workspaces can instantly boot up on any machine. You can share them with your coworkers: "Hey, look at my work and check out XYZ". All the code, assets, and changes are in one place. Press a button and it builds and executes. Frontend, backend, marketing, film editing, you name it.
Zero setup, zero onboarding. When HR terminates you, all access instantly goes away. It's a dream for companies. The first companies to get there will be looking at 10 billion+ TAMs. Plus their other product offerings will interface cleanly for even more sales.
[I'm working on one of these for the creative industry; please reach out if you're interested.]
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.
It is worth noting though that the thin clients are mostly going to be equivalent to a Chromebook, which is considerably beefier than top-of-the-line developer workstations from only a few years ago.
I effectively ran that team for several years. We invested huge resources in tooling for laptop Docker environments.
Eventually (after I had moved on) that team decided that remote development environments would be a more efficient solution. I don't disagree with them!
- Nix, Guix, package managers in general: suitable for advanced users, but smooth sailing is not guaranteed, especially with Nix/Guix on top of an arbitrary system.
- Remote (virtual) desktop: network lags, dependence on Internet connection, issues with resolution mismatches and whatnot, but fairly straightforward and seems to be somewhat popular. Being a remote system in a thin client, seems similar to the web IDE approach.
- Configuration management software (ansible and friends, and/or just git and stow): also rather for advanced users and may require some debugging/adjustments.
- (Possibly lightweight) virtualization: used commonly, with all the containerization. I've also heard of a person downloading a VM from an online storage, working in it, saving the progress, uploading that -- allowing to work locally.
- Web-based projects (as being discussed).
- Working on a remote server over SSH (including pubnix systems), possibly with X forwarding (also similar to the discussed approach, with a thin client, though doesn't require special software).
Edit: also depending on kinds of projects one works on, some of those won't work at all: developing software that interacts with hardware, even something common like a graphics card, may not work at all (or work better, depending on a setup) with remote approaches, and is likely to be more tricky with virtualized ones.
Edit 2: actually looking closer into GitLab Web IDE, seems like it may be closer to the remote/virtual desktop software, but accessible via a web browser.
I literally have not had Python just break on me, and after decades of software development at various places using Python/Java/Javascript I would say it is rare these days to see it happen to other people in the team either.
It usually happens when someone decides to experiment with a different way of handing application versioning that they saw on HN, but they aren't actually experienced enough to test it in a sandboxed environment. Essentially breaking their computer in a new way that no one else on the team can help, and that Google won't give you any help with.
I would say that the person you are replying to is probably inexperienced and doesn't want to learn their tools.
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 the job is waiting for local admin permissions so that you can install brew and make your Mac environment as close to Linux as possible.
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
Why does it have to be remote?
The whole point is that I don't always have internet access, sometimes there are outages and sometimes it's just plain slow for some reason. It's shit enough all the video calls I have to be involved in these days, not as bad as all the face the face meetings in crampt rooms with everyone falling asleep because of the lack of air circulation. Why do you want to make the development environment crappier?
It also isn't clear how it would make code reviews better, or even paired programming? Shared workspaces are already a thing.
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.
I'll stick with my reliable local environment, thank you.
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.
Just let them run the same OS as prod no?
Or have them use VMWare or Docker.
This was sometimes my experience working with and leading teams with devs of varying experience but always full freedom.
Nobody actually likes it.
I have saved droplets for Python JS, and Golang that have just want I need for development in that language. I even have ones based on the environment we used at work.
Then one I want to start a new project I used the saved droplets and boom everytime I have the exact same environment.
Accessing through SSH is just as easy as accessing through URL with VS Code.
I think what the person above means when he says "local breaks ALL THE TIME", the reality is that every now and then during major OS updates MacOS may make major breaking changes in system libraries or library locations, which in the past would famously break Ruby on Rails development environments.
There's also the fact that Windows fits in the same category. So when he talks about fixing dev environments what he really means is consolidating the dev environment in linux.
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 environment your IT department could hand you a fresh laptop with a working environment on it. It's that.
Engineers - junior and experienced - found new ways to break both of those, constantly.
Whatever breaks software environments on the desktop will also break them in a remote compute environment; unless, of course, you put your entire product in a container and use a framework that supports hot code reloading. In which, you can do on a desktop for free.
> The browser-based cloud IDE experience, where it doesn't matter what you've got going on with your laptop, you just visit a URL and start work, is an incredible productivity boost for the vast majority of people.
A users browser is still impacted by things running locally. I'm not sure a web-IDE buys you anything except not running file watchers (which is nice).
I never actually questioned the value of a web based IDE until this moment, and that gives me some pause.
I was in agreement with you initially but then thinking about it - if it breaks remotely it most likely breaks for everyone in the same way, breaking locally may be all sorts of reasons - you could have several people broken at any time for different reasons. For some projects and companies having the remote setup might make sense for this reason.
Also, dependent on what you're doing you might need to run a bunch of services that your laptop isn't powerful enough to handle. This happened with my last project where there were 30+ microservices each in a docker container, 3 frontend environments in docker containers, all running in vagrant (vagrant was gotten rid of when the latest Docker release happened, but I didn't update to get the new experience cause my contract was running out)
Sometimes there were issues when I needed to work on several things together.
With respect to the latter, I'm not sure that a web IDE (without paying monthly cost) would solve this problem. At that point one might as well run an entire developer cluster. That's the way I designed my teams stack.
The joy of remote environments is that they can be disposable.
Break your environment? Click a link, get a brand new one that's guaranteed to work (thanks to automated testing marking known good configurations).
Helping with three different bugs at once? Use three environments, so your work doesn't conflict with itself.
as an industry we keep fighting nature and not working with nature. how much money has been spent trying to optimize python, ruby, js build tools / environments etc. you wouldn't need docker, web ide's and all the other crap if a language could ship a single executable. if we moved away from dynamic linking that's linked to the 80s thinking of limited storage to static linking.
whereas going back to saner defaults would've saved much of this headache.
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.
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).
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).
The delightful development experience that gets praised everywhere. /s
The only huge negative was that IntelliJ doesn’t have such a great remote story, so I had to switch to VS Code.
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/...
You can have that even with web browsers. These are called web apps. Of course if they're implemented to be fully offline is up to whoever makes them. But they can be.
The thing that this allows (and the companies that inspired this stuff, e.g. GitPod) is to codify your development environment - similarly to what has been happening in the infrastructure world. And I'm not talking about editor configs, but the entire toolchain.
Of course, if you're just working on one main project, or a few with a shared toolchain, this won't be adding much value for you. But as soon as the matrix between development environments and projects get bigger, this becomes a huge productivity boost.
Think about a mobile (as in, moves around a lot) developer that uses many different devices - there's no additional work to keep those environments in sync, or set up a new one. It will just work in the browser.
Or a bigger company with many projects and many people (think devops) that need to jump into different projects all the time. I don't want to waste my time setting up the specific toolchain for that project, or even check it out - I can just open up a pre-configured, guaranteed-to-be-working dev environment in the browser in a few seconds and get going. This would by my personal use-case, and I'm super excited to see this happening.
I was already thinking about setting up GitPod for our company GitLab, but if GitLab manages to combine the GitLab CI/CD Runner Session feature with this IDE for background tasks (compilation, terminal, etc), you would get 90% of the awesome-ness of GitPod for free with your regular GitLab setup.
So web IDE definitely have its uses. I think that it's not ready for most projects, because Intellij provides vastly superior experience for almost all languages, but still I believe that VScode is the future and it'll surpass Idea at some day, because it's more open source.
Also, I hope, that all those remote workflows will be replicated with local setups. I don't see any reason not to other than locking user into your website. I mean VScode works locally, docker works locally, git works locally.
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 appropriately (firewall rules, security certificates for services and web) is convenient. Even if dev env was local, your host still must have appropriate access to that infrastructure.
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.
We are currently experimenting with such setup which VSCode enables us.
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...
I've not yet used a lot of remote tooling. But I routinely ssh into remote servers and I can see the appeal of not having my laptop running scorching hot all the time (I use Intellij a lot). Also financially it's not a bad deal. Pay a few tens of dollars per month and use a relatively simple laptop to access the remote setup. I wouldn't mind paying a little extra for some extra fast CPU if I can do it by hour.
Of course what Gitlab does is not that interesting. But e.g. Jetbrains closing a deal with Gitpod (which already runs their IDEs in the cloud) is a potentially a big deal. I could see myself giving that a spin at some point.