The Future of the GitLab Web IDE
Way back in April 2018, GitLab 10.7 introduced the Web IDE to the world and brought a delightful multi-file editor to the heart of the GitLab experience. Our goal was to make it easier for anyone and everyone to contribute, regardless of their development experience. Since its introduction, tens of millions of commits have been made from the Web IDE, and we’ve added features like Live Preview and Interactive Web Terminals to enhance the experience. Now, we’re excited to share some big changes we have in store for the Web IDE in coming milestones. What makes an IDE? Over the years, we’ve learned a lot about how you all are using the Web IDE. We’ve compared it to our Web Editor in the repository view. We’ve spoken to developers, designers, product managers, and technical writers alike. Almost universally, we hear that the Web IDE is great for small changes: a quick change to a config file, an update to a Markdown file, or a typo fix in a merge request. These lightweight changes make up the vast majority of the Web IDE usage. And for those use cases, it’s super convenient and intuitive. But to grow, and to really earn the moniker “IDE,” what are we missing? What keeps developers from making more complex changes in the Web IDE? What can we do to elevate the experience? We hear about missing features and functionality like a collapsible file panel that supports contextual actions and drag and drop or tighter integration with merge requests. We’ve learned that there’s no single feature that’s a deal-breaker for most developers; it’s the sum total of a lot of little user experience gaps. The Web IDE is built on top of the fantastic open source project, Monaco. What made Monaco a great choice as the foundation of the Web IDE is also what makes it more difficult to address all these concerns holistically. Monaco is just that: a foundation. We have to implement all these workflows and features ourselves. Meanwhile, another open source project has been laser-focused on delivering a lovable IDE on top of Monaco. Enter VS Code You may have heard of Visual Studio Code, or VS Code. With its dominant market share, chances are pretty good that you are even using it as your primary code editor. As it happens, VS Code core is also open sourced under the MIT license. While the core project isn’t a perfect drop-in replacement for the Web IDE, our Staff Frontend Engineer, Paul Slaughter, wanted to see if we could run it inside GitLab. Turns out, we can: In this video Paul Slaughter, Staff FE Engineer, walks Eric Schurter, Senior Product Manager, through the VS Code Web IDE proof of concept. See parts two, three, and four for closer looks at extensions, performance, and customization. As you can see in the videos above, Paul was able to build a proof of concept that brings the VS Code editing experience into the GitLab UI, running entirely in the browser. No additional infrastructure needed. 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 […]
