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 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.
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.
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.
> 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.
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.
> 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.
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.
> A well-funded team could create a compelling competitor to VS Code.
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.
As a small anecdote as someone who switched from atom, the killer feature for VS Code is being extendable AND performant. I used to use atom for a flexible text editor, and then still have to use sublime text if I wanted to open a large file (atom choked on multi MB json files).
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.
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 :)
It had what was essentially an HTML4 UI and just SVN support for what seems like forever. I can't remember a version of it that didn't look like 2005 Gmail.
Yeah, especially when they could use something like Theia[0], which I believe was built for this kind of purpose? They both still use Monaco under the hood AFAICT. I'd be interested to know if they considered it and decided not to use it for some reason.
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 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...
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.
> These lightweight changes make up the vast majority of the Web IDE usage
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.
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.
VSCode is really an IDE, not a text editor. While it's not built for one particular language in mind, with vast majority of languages it offers all the features you would get from an IDE.
Not sure it'll end up as a cloud offering and instead just a lightweight desktop app, but have you looked into Jetbrains Fleet (w/ Spaces)? Not released yet, but it has potential
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.
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? :)
We've had some success with less technical types using their web-based editor (like fixing fonts, colours and markdown docs). Love it, it's very useful for them to contribute where they can. Cheers to this team.
GitLab team member here - using VS Code on a desktop client works well with the GitLab Workflow extension [0] for Git SCM operations, as well as CI/CD pipeline status from pushed commits & merge requests. Additionally, remote repository views come in handy. [1]
Yeah, practically, it's the same. They don't even own git tbh, and won't even make noise on git core mailing list. I can even go extreme, practically, whether they even can.
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.
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!
I mentioned the CTRL+D multi cursor specifically because I think this feature is only available in VSCode if you choose the Atom key bindings. I regularly try to show this to my colleagues whenever we’re pairing, but they need to fall back to search & replace in VRSCode.
Can the installed dependencies be downloaded locally? It might be a great way to resolve npm dependencies without resolving having to run npm on my system.
I miss c9 which was bought by Amazon. It had a VM running behind it with a terminal so I was able to do .net core development. A couple times I wasn't home and wanted to fix a bug in my project so I was able to login to c9, spin up my project in the browser and it committed back to github.
Yup but no free tier now :D not paying for it for open source dev stuff. Rather just run the IDE on my laptop. Was handy when using someone elses computer.
Why do you have to miss it? Any of the contemporary online IDEs can do more than that now (I ran docker containers in github codespaces) and you can theme it like Ace if that's your thing.
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.
It's all dockerized and security hardened probably. I'm guessing this is not that much of an issue. At least not any more than the likes of AWS, Google cloud, etc. allowing third parties to run whatever on their infrastructure. Not to say that there aren't any challenges but they aren't new challenges. And of course Gitlab has long been running CI infrastructure which would have the exact same issues.
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
There's a long long route to cloudification, but works like Okteto[1] seem like a nice early pass at doing what Docker-Compose was capable of for fast local development, but modern. Pursuing remote-development makes a lot of sense. There's already solid VSCode integration[2].
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.
I'm excited about this, I would love the IDE to move to the browser and have been a fan of the idea since the Cloud9 days. If browsers had a way to delegate their reserved keyboard shortcuts I would use web IDEs full time.
In Qutebrowser, there is a passthrough mode (default keybinding is C-v) that does exactly what it sounds like -- it passes all keystrokes through to the current page for processing. The only keybinding in that mode is the binding to leave it (Shift-Escape by default).
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?
I use the current web editor a lot for small changes on repositories I don't want to full clone.
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 Codespaces and VSCode remote development solve this problem by using docker and optionally docker compose to create reproducible development environments.
GitHub is using Codespaces itself [0], which is a huge Rails app with tons of infrastructure behind it I’d assume.
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.
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."
It would be amazing to figure out how to make a Web IDE with a local shell that's inexpensive to run. Something that uses Spot instances with seamless migration between hosts. No one has really addressed this problem so far - all of the existing cloud IDEs cannot match a modern multi-core dev laptop without breaking a bank.
I feel that moving from Monaco to VS Code OSS (which is based on Monaco) is analogous to moving from a custom protocol on top of tcp to the standard http protocol.
It's a big change, but not necessarily groundbreaking or noteworthy.
Make a free Gitlab account and try out their Web IDE as it is now, and then compare it to Gitpod or just run Coder-server on your machine. It's a humongous change.
The current Web IDE is not an IDE at all - VSCode is.
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. 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.
Combine this with the fact that there is massive $ opportunity with monitoring devs (worst case) and having a monopoly over their working environment (best case)
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.
> Yes. Because local development environments (at least for the languages I work with, Python and JavaScript) break ALL THE TIME.
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.
>Whatever breaks software environments on the desktop will also break them in a remote compute environment;
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.
A container that runs on one dev laptop will (most likely) run on another, unless there's some weird architecture compatibility stuff. Even then, I think the M1s are doing fine and my old boss used to stand our entire fleet up on his Chromebook.
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.
I agree. I use Neovim and my setup constantly break when upgrading plugins. I could avoid this pretty much by just using Visual Studio Code, but that in my opinion is pretty close to these Web IDEs already.
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 outweigh this convenience. I mean, can you even step through a debugger session? That's a basic requirement imo.
> The ailments you describe can be resolved by having a small dedicated Developer Experience team.
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!
> 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 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.]
> The future is thin clients. It's not just going to be our industry, either. Every creative industry is going to undergo this change.
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.
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.
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.
The UNIX high priests here quite active up to 15 years ago, in 2005 I was still telneting into the UNIX development server and starting my own graphical tools via X remote sessions.
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.
The few remote services I rely on broke on me far more times than my local development environment. Far more if you consider degraded internet connections.
I'll stick with my reliable local environment, thank you.
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.
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 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.
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
If we were allowed to use a real OS, you could just run local containers. Or hell, this was solved with Vagrant how many years ago?
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.
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.
I use digitalocean droplets and access them using VS Code.
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.
in as much as Javascript has paid my bills. and in as much your child Django is pleasurable to use.
maybe it's time to move on from these languages that lure as into a false sense of productivity.
yeah initially you can move fast.
but after that it's clusterfuck of fighting your environment every 6 months.
syntax wise JS ain't different from modern C++/Rust/Go etc
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.
> 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 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.
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.
You break it, you spend days on fixing things instead of being somewhat productive, and if you break the codebase, then we wait while you try to fix it, before we need to step in and do it ourselves.
This was sometimes my experience working with and leading teams with devs of varying experience but always full freedom.
Maybe a stupid question, but doesn't the remote environment run basically the same software? Or at least the same software as a local container or VM would?
If so, why would this break less often?
You hit the nail on its head. There is absolutely no reason why the remote environment doesn't have exactly the same issue the local environment has. It will still need its rbenv etc for any sort of ruby/node/python etc versioning.
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.
At a previous job, we self hosted our version control software, and when it broke, you could practically hear the money being poured down the drain, as the SREs scrambled to figure out why and get us back into a working state. At least when things break locally, they (usually) don't break for everyone. I get that there are pros and cons to each pattern, but I agree that the remote dev crowd is glossing over the fact that these remote envs break too, and the impact is huge.
There is a few more approaches to solving this, with different drawbacks:
- 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.
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 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.
> 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]
Well we do have the choice for now, but it's not very hard to imagine a version of gitlab (or competitor) without external git support, and everything would have to be done inside the webIDE. It's for sure very attractive for security/IT people, which is why I would not even be surprised if that actually happens in the future (and that makes me extremely sad)
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.
> I don't want to do all development-related tasks in my web browser
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.
I don't think I'd want to work somewhere where everyone was told what tools to use, 'how to do their job', etc. - even if it was exactly how I happen to like to do it (vim with LSP, but most other IDE-like stuff from the shell directly).
I don't want it but I 100% want to send everyone who's new to coding to something like this. It's so goddamn hard to set up your first environment, when you have no idea what you're doing yet. I recommend people do freecodecamp because everything is right there in your browser and it just works and there's no setup. Setups are so much harder than writing code.
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).
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 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).
As I see it: people spend lots of time (collectively) when it comes to setting up new environment. Whether you're new developer who just came to the project, whether you're asked to help on another project, whether you need to fix a bug in some old project. I can spend hour setting up project and then 1 minute delivering a fix. Usually I just use notepad to edit source files and then cmd to build and test, but that's not very good environment and many developers are not proficient enough to work with notepad and cmd.
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.
Well, you don't have to of course but that does not mean others are like you. Also, it's not necessarily all browser based. The same thing running as an electron app is probably not that big of a deal.
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.
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]
And as usual for these type of things it'll be made by macbook users for macbook users. It'll be sluggish on non top-of-the-line computers. Meanwhile my vim setup works on a potato laptop just fine.
>As a software engineer, I want local control, where an internet connection is optional.
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.
Not so much in this sense, but it was absolutely very handy to be able to do remote dev when my company wouldn’t give me a new (higher spec) laptop, but did allow me to create anything I wanted in AWS.
The only huge negative was that IntelliJ doesn’t have such a great remote story, so I had to switch to VS Code.
> 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.