The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
|Content Last Reviewed||
Thanks for visiting this direction page on the Web IDE in GitLab. This page belongs to the Editor group of the Create stage and is maintained by Eric Schurter (E-Mail). More information about the Editor group's priorities and direction can be found on the Editor group direction page.
This direction is constantly evolving and everyone can contribute:
Code Editors are one of the most important tools in a software engineers toolkit because the majority of their work is writing and working with code. They're customized with extensions for programming languages, coding standards and frameworks and more for the type of working being done. They're also optimized for connecting to development runtime environments and services engineers need to do their work. The context in which engineers use this tool dictates the type of configuration required.
Software development is an iterative process that involves requesting feedback from peers (Developers, Designers, Product Mangers etc), and responding to that feedback. In GitLab, this is done using a Merge Request. Reviewing is in fact a specialized editing task (other professions would call this same task editing), for example suggesting specific changes to functions, documentation, and interface text. A local development environment is often not ideal for these editing tasks:
Configuration files are also common to software development and the tools of the DevOps life cycle. Files like gitlab-ci.yml or CODEOWNERS can be difficult to use because they need to be both syntactically (correct commas, quotes, value types etc) and semantically valid (expresses what you intended it to). Local development environments can be configured with syntax checkers, and schemas to help verify syntactic correctness, but lack the context for deeper features.
GitLab CI is fast and highly configurable within GitLab, but it can be hard to remember all the configuration parameters for your goal and a typo can make the complete configuration invalid. Editing this file often involves having documentation open while make changes. Once those changes have been made users leave their editor to validate the file or commit and wait for feedback from a running pipeline.
Once your GitLab CI configuration has been created and validated, it may be responsible for providing review applications for previewing changes, code quality and coverage reports or vulnerability information. As an engineer who is working on a contribution information contained on these reports must be reconciled within their editor.
GitLab's web editors are familiar to developers, and easy to use for designers, product managers and more. It brings editing capabilities into the context of their current task in GitLab, by providing an editing experience designed for the workflow they're trying to accomplish.
Our vision for editing inside of GitLab extends to both the Web IDE and our Web Editor. We believe that both task and context are important aspects to consider when choosing an editing experience and we want to focus on providing complete experiences in all areas.
With the Web IDE, we want to meet the developers where they are and offer a mature, feature-rich editing experience in the browser. By replacing the current Web IDE with a browser-based instance of VS Code, the most popular code editor, we can enable developers to complete more complex tasks and work more efficiently inside GitLab.
On the other hand, with the Web Editor we'll continue to deliver a lightweight experience and explore opportunities for in-context single file editing experiences that present editors inline to the task trying to be accomplished.
The path to wider reach and adoption of Live Preview hinges on the ability to offer server-side compilation of code or remote development environments, something you can read more about in the Remote Development direction page.
GitLab is also supportive of 3rd party integrations to extend these features to developers. One example is the community contribution Gitpod made to add a native integration to GitLab, making it possible to launch a remote Gitpod instance from the repository or merge request with a single click.
One of the benefits of replacing the Web IDE with a VS Code instance is that you will be able to install compatible extensions in the browser-based Web IDE. By bundling the GitLab Workflow extension in the Web IDE, we will enable new functionality and provide consistency across the desktop and web editing experience. Functionality contributed by the community and additional investments in the capabilities of the extension will then be available on both platforms.
The software development process involves many people working across various parts of configuration, contribution and review. All of these users work together to advance software projects in their organization.
Engineering personas who are contributing to development, configuring or interacting with continuous integration and reviewing contributions from other team members. Users performing these tasks need tools that allow them to deeply understand the changes and provide meaningful feedback of both comments and code suggestions. These are specifically addressed by the following GitLab Personas:
Non-Engineer personas who are focused on reviewing and providing feedback for contributions. These users need tools and features that help them preform reviews of code, documentation and interfaces without requiring local environments or complex configurations. Feedback should be easy to leave and actionable by engineers within their editor. These are specifically addressed by the following GitLab Personas:
Configuration Users who configure projects or GitLab need editing tools to help them be efficient at this process. Creating specialized configuration files for working with GitLab CI or other areas of GitLab benefit from feedback provided directly in the editor.
Contribution Engineering personas who work on contributing directly to the code in projects need to action feedback from the review process. Having easy access to the feedback from reviewers and CI jobs inside of the editor should ensure that it's easy to action.
Review The code review process encompasses both engineering personas and non-engineering personas who contribute through design, product and other feedback. In solving for these users it will be important to make sure that people who want to give feedback are able to easily accomplish that.
The Web IDE is loved by many but universally considered a great option for relatively simple edits. In order to achieve a more complete, full-featured editing experience capable of supporting complex development tasks, we need to think bigger. We are currently working to replace the Web IDE with a browser-based instance of VS Code. Afterward we'll be able to address many of the focus areas below and provide a more performant and extensible editing experience.
Editor configuration and customization are important parts of IDE experiences. Teams working together often standardize editor configurations through the use of an
.editorconfig file and developers customize other aspects of the editor to their own preference. Ensuring support for various syntax highlighting preferences and colorization will make working in the Web IDE feel more like a user's local editor.
Providing first class support for editing specialized GitLab files like
.gitlab-ci.yml file, issue templates and CODEOWNERS ensures developers have the tools needed to efficiently accomplish their goals.
Documentation is a less intensive type of engineering effort that requires fewer tools than traditional development environments. Enabling technical users to produce documentation in the Web IDE easier and more quickly will be important as we continue to expand the Web IDE. This includes enhancing markdown tooling and support for more prose based content in the Web IDE.
When working through the code review process users are often trying to understand feedback in the context of their changes. Engineers must examine feedback in one window and then return to their editor to make changes. By expanding code review tools in to the Web IDE we can help provide that review feedback in the Web IDE so that changes can be made more easily.
It's also important to help users quickly jump to definition and find references while reviewing and editing code within the Web IDE. Supporting code intelligence features in the Web IDE will move that vision forward.
Following the integration of the extension into the Web IDE, we will focus on tighter integration with other parts of GitLab.
Quality and Security Scan results in VS Code &6515: GitLab provides feedback to developers through code quality and security scans. This information is provided in GitLab through merge requests and report data, but it isn't immediately available to engineers as they're working in their editor. We'll continue to look for opportunities to expand our efforts here.
Currently, GitLab's maturity in the Web IDE is viable. Here's why:
A complete Web IDE category ensures that the Web IDE is used for tightly integrated editing experiences in GitLab. Moving beyond the focus will be on standardization of editing environments through the use of
.editorconfig and support for user syntax highlighting (including dark mode). Finally, the Web IDE must provide 1st class editing experiences for GitLab features. We aim to achieve this by implementing the web-base VS Code editor and pre-installing the GitLab Workflow extension for VS Code.
Part of a Lovable Web IDE comes by providing support for the Code Review process inside of the Web IDE. This involves support for both leaving and responding to feedback inside of the Web IDE. The Web IDE should also include code navigation features like
Jump to Definition and
Find References to better support this process.
To truly offer a full development experience in the browser, we need a server runtime solution. The Remote Development category has been created to explore this direction and provide a "full" development experience within GitLab.
At the moment, our focus is on replacing the Web IDE with a VS Code instance. This effort will help us address many of the issues already in our backlog as well as provide options for introducing additional functionality throught the extension framework.
Now that the Web IDE Beta is available to everyone and enabled by default on GitLab.com, we will be focused on addressing early feedback and preparing the Web IDE for general availability, at which time we will remove the option to use the previous version of the Web IDE. Key areas we'll be focusing on are:
With the deprecation of the Static Site Editor, we have an opportunity to deliver similar value across all types of projects by making it easier to edit Markdown in the Web Editor and Web IDE. The editors already have a real-time side-by-side Markdown preview, but to fully solve the needs of non-developer personas, we will be working to integrate the Content Editor as an option for editing Markdown files.
We're not currently focused on solving the needs of non-engineering based personas with the Web IDE. Non-engineers require a different type of editing experience and that can largely be focused around different types of content. These editing experiences may include documentation or notes based in Markdown, or more WYSIWYG experiences related to content management systems. The Content Editor will be more focused on these efforts and will eventually be available as an alternative editing experience within the Web IDE.
While our complete maturity plan also aims to ensure some compatibility with the iPad. We won't be focusing on making the iPad or other mobile devices 1st class devices due to our upstream dependencies on Monaco and various mobile OSs. We also do not have sufficient evidence to support mobile devices as code creation devices inside the Web IDE. As our research in this area continues to expand we may revisit mobile support.
The Editor group does not have plans to bring real-time collaborative coding features to the Web IDE at this time. While we previously outlined this as a category to focus on, we don't believe there is enough market demand to warrant investment. We'll continue to evaluate the space and may revisit this use case at a later date.
Currently the Analyst landscape is fragmented on cloud native development experiences. This market will continue to mature as Microsoft pushes ahead with Codespaces and Amazon further integrates Cloud9 in to their offerings.
Top user issues relate to the configurability and customization of the Web IDE. These focus on items like standardizing editor coding style through configuration files and supporting user customization for themes and other preferences.
.editorconfigfor correct encoding #14222
GitLab's current internal usage of the Web IDE is very heavily focused around non-developer personas and so there are not any current issues. We aim to enable more widespread usage of the Web IDE by implementing a bro
The most important item to delivering on the Web IDE Vision are: