Microsoft Visual Studio Code has become one of the most popular development tools. Blending Microsoft’s proprietary features with an extensible open source kernel, it’s a quick install that can be configured to handle most languages and most platforms. It’s especially useful when working across platforms, as its remote development extensions allow you to use it on another machine from your desktop be it macOS, Windows or Linux.
Webview UI is an increasingly important tool, blending web tools with familiar Windows development environments. For example, you could write a management tool for a service that uses a Windows-style user interface, while serving the service’s web user interface output in the same framework. So, it’s not hard to see how a tool using Webview UI can work with VS Code, providing a Chromium-compliant environment for web-based interfaces and dashboards, at the same time that the hosting controls use the same design language as the rest of the editor without being constrained Windows system.
Although Microsoft recommends avoiding webviews in Visual Studio Code extensions unless you “absolutely need them,” they are becoming increasingly important. Visual Studio Code may have started as a tool for .NET systems software development and for general-purpose code editing, but it has grown into a near full IDE, with support for tools like Flutter that need a user interface design surface alongside code. We’ve seen Microsoft’s Browser Tools team extend the F12 developer tools into VS code, and use them to deliver debugging information.
What is in the Webview UI Toolkit?
Perhaps you can think of the Webview UI Toolkit as the Visual Studio code equivalent to the Windows App SDK’s WinUI 3 Component Library. WinUI 3 provides the same controls across different user interface frameworks, from the web to the PC. The Webview UI Toolkit takes a similar approach, offering a set of customizable controls that can give your extensions the same look and feel as the rest of VS Code. This way, if you’re providing information from another app, you won’t add cognitive deficits for users, ensuring that they stay in the same context as their code.
The controls support the same theme model as the rest of the editor. If the user chooses a theme for the editor, the extension will automatically support it. Since they are web components, you are not limited to any one set of development tools and can continue to develop plugins in your choice of web development frameworks.
With Visual Studio Code being used to host extensions from many different developers, and support for as many different languages, services, and servers as possible, it is imperative that they have a common design. Developers need to ensure that the extensions they install work in and with VS Code, not link them loosely and then apply their own standards. We need to know that the same editor shortcuts work across all the extensions we have installed and that these extensions all work consistently.
Offline Toolkit Available as a public preview on GitHub, with some significant issues that make it not quite ready for production. A release of 1.0 is planned for late 2022, so it’s worth starting to look at it even if you haven’t been ready to ship the code for quite some time.
Building a VS Code Extension based on Webview
Microsoft provides a range of Instructions for creating an extension based on Webview, along with a pre-generated sample code. It’s a lot like creating any other Visual Studio Code extension, at least during the initial setup. Here you can use Yeoman-based Extension Generator to prepare scaffolding for your extension. Don’t forget to install both Node.js and Git before using the generator, which then prompts you to answer some basic questions to define your TypeScript code scaffolding.
Once the extension scaffolding has been created by Yeoman, edit the code in the default extension to add a panel class, using the view that will be called by the extension’s activation function. The Panel class is where your Webview code will be written, using VS Code APIs to manage the layout of panels within the VS Code framework. Your class will also need to clean up resources when users reject the Webview panel.
You can now start integrating Webview content into your addon, using the . extension
_getWebViewContent method, adding a call to the Visual Studio Code Webview libraries and extension URI. Remember to add these to any existing constructors or views if you are updating your existing extension code.
Consistent design for productivity and accessibility
It’s important to note that Microsoft designed its components to be ARIA compatible, with built-in keyboard navigation, giving you additional accessibility features without the need for additional code. These include common form elements, such as buttons and input areas, as well as check boxes and radio buttons. The other components are replacements for the familiar layout objects, the addition of a custom grid view for working with data, and new progress loops and dropdowns. The current version offers what you should see as only an initial set of components, with the potential to appear over the next few months. However, they will allow you to “Codify”, if desired, the web user interfaces of the current application ready for use within Visual Studio Code.
Using the Webview UI Toolkit will not change how extensions are written for Visual Studio Code. In fact, it may make it more difficult, as the architecture associated with its components may not be the same as you use elsewhere. But by giving VS Code extensions a consistent, objective set of accessible UI components, it will make your extensions more acceptable to users and help make them more productive. This is a win for all of us.