|Content Last Reviewed||
This direction is constantly evolving and everyone can contribute:
Building new features involves more than the just primary code development process. It may include things like Code Review, documentation or simple bug fixes. We envision the Web IDE becoming the primary tool for these secondary engineering efforts.
These tasks are essential parts of the engineering process, but can often be disruptive to local environments and have challenges when working inside of GitLab. Currently GitLab supports editing multiple files within a single interface, but editing files alone isn't enough to support these efforts. This makes it harder to resolve feedback in merge requests, fix small bugs when reading source code, or contribute to projects.
Development environments are also a very personal tool of engineers and customization is an important part of that. Engineers working on teams need to standardize on coding standards and styles in all of the editing environments they use. Configuration and customization are important features to make the Web IDE a valueable tool for developers.
We want to make it easier for engineers to work on secondary development items in the Web IDE. By removing barriers to the code review process, working on standardizing configuration and other support tooling engineers will be able to provide more meaningful feedback in a GitLab native environment.
The Web IDE is primarily targeted at engineering personas working on secondary development tasks (e.g. code review, docs, and small fixes) who are familiar with working in local development environments. GitLab personas that the Web IDE is seeking to solve for are:
By prioritizing the needs of engineering users for non-primary tasks GitLab can focus on providing an experience that supports the ability to contribute in a cloud environment.
While we're prioritizing the needs of engineering users first, the Editor Group is also supportive of other editing personas and existing editing use cases within GitLab. Additional improvements will be addressed via issues and in other areas like the Static Site Editor.
Engineers generally hold very specific editing preferences and engrained workflows. Supporting user preference and configuration in the Web IDE will be important in garnering adoption for the Web IDE. It will also be important to introduce value added workflows that don't try to replace primary engineering activities.
Code review within GitLab can be a burdensome process for some users. It requires reviewers to checkout branches locally for review and then return to the GitLab UI to find the line and file and provide comments. When the feedback is reviewed, 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 speed up and make that review process easier.
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.
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 providing realtime collaborative tools for editing.
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.
Other areas of interest include supporting remote development environments and integrations with local IDEs for more seamless GitLab experiences. Providing first class support for editing specialized GitLab files like
.gitlab-ci.yml file, issue templates and CODEOWNDERS are important.
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 all file/code editing in GitLab. Moving beyond using the Web IDE for all editing 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 some support for things like linting and code completion.
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.
In progress: Self-hosted client side evaluation &484
Client-side evaluation live preview in the Web IDE is powered by Codesandbox and currently relies on Codesandbox services to retrieve and package dependencies. Ideally, self hosted GitLab installations should be able to use Codesandbox capabilities in an entirely self hosted manner.
Next: Use Web IDE for all file/code editing &498
Standardizing on a single editor experience supported by our use of Monaco will allow us to bring a consistent experience to users in both the Web IDE and single file editing modes like Snippets or GitLab CI.
Future: Increase configurability of Web IDE &175
User preference and organization standardization are important aspects of the editing experience. We'll look to support user syntax highlighting preferences (inlcuding dark mode), editorconfig standards and other important preferences for user customization.
Future: Lint, Format and Code Completion &70
As users continue to move more work to the Web IDE tools commonly found in local environments become more important. By bringing linting, formatters and code completion to the Web IDE users can be more confident in their work and spend less time in code reviews working through simple errors and poor formating.
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 Static Site Editor group will be more focused on these efforts.
The editor group is not currently building or maintaining plugins for local development environments (e.g. VSCode extensions). There are many local editors, and the needs of users in this area will require further research. As we continue to investigate this area additional information can be found in our 1st-Party GitLab Extensions epic focused on this.
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 VS Code Online 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.
GitLab's current internal usage of the Web IDE is very heavily focused around non-technical personas and so there are not any current issues. As we look towards delivering on an IDE for technical users we'll update this section as appropriate.
The most important items related to moving the Web IDE strategy forward is Self-hosted client side evaluation &484. By enabling all GitLab instances to run client side evaluation in the browser, more developers can contribute to these types of projects without the constraints of local dependencies.