Sunsetting the Webview UI Toolkit

[hawkticehurst]

Toolkit project announcement

Hi all,

With a heavy heart I'm here to share that we will be deprecating the Webview UI Toolkit for VS Code by the end of the year.

As some of you may have seen, at the beginning of May the FAST project announced a project re-alignment which includes the deprecation of several core packages. Notably, FAST Foundation (one of the defining pieces of technology we used to build the toolkit) was on this list.

Since that announcement we've been working in the background to determine how we should move forward. Skipping some of the details, the only meaningful path forward is a full top-to-bottom rewrite of the toolkit using FAST Element (a lower-level library from FAST for building web components) and unfortunately the resourcing to complete this work was not allocated.

Packages / repositories

As part of sunsetting this project the following packages and repositories will be deprecated and/or archived.

• @vscode/webview-ui-toolkit NPM package
• microsoft/vscode-webview-ui-toolkit GitHub repository
• microsoft/vscode-webview-ui-toolkit-samples GitHub repository

Timeline

There will be two key dates for sunsetting this project.

• The toolkit samples repository will be archived on August 1, 2024 August 2, 2024
• The toolkit NPM package and main repository will be deprecated/archived on January 1, 2025

Ongoing maintenance

During the time between this announcement and formal deprecation, all feature and documentation work, along with most bug fixes, will be closed. Critical security issues will continue to be addressed until January 1.

Thank you

Those are the highest level details, but if there are any questions, comments, or feedback please feel free to leave a message on this thread and I'm more than happy to discuss.

Beyond that, thank you for the last few years of participating in and using this tool. It was a joy to serve and work with all of you. I wish you all the best in your future VS Code extension endeavors!

[Sanderand]

Hey there. I was just starting out using Webview UI toolkit - which works fantastic. So this is bad news for me. Going forward, what are the official alternatives to build web views that are compatible with the VSCode design language?

[alexweininger]

Is there any advice or guidance for consumers of the toolkit going forward?

[hawkticehurst]

Going forward, what are the official alternatives to build web views that are compatible with the VSCode design language?

Unfortunately, in terms of official support/alternatives, webview extension development will return to what is was before the toolkit. It will once again be the full responsibility of extension authors to implement webview UIs that align with the VS Code design language and follow the webview UX guidelines.

The UX guidelines do link to some samples/documentation, but these aren't the most thorough samples so I do have a personal goal to write something (a message, docs, maybe blog post... it's tbd) that summarizes some of the key takeaways/advice I'd give to extension authors who need to build webview UI of their own.

I have actually written a blog post in the past that covers some of this (notably theming) at a very high level that you're welcome to look at, but I would mostly ignore the code snippets provided since they're tied to the way that FAST works.

Is there any advice or guidance for consumers of the toolkit going forward?

I suppose it goes without saying, but the highest level guidance is that I would plan to no longer be a consumer of the toolkit and remove any dependencies on it by the end of the year.

This means the two primary paths forward are to either:

1) Make a plan to recreate the toolkit UI you used in your extension (depending on the components used this will be pretty easy to very hard) 2) Use some combination of third-party projects/component libraries to recreate the UI that the toolkit provided

Like I just mentioned above, I'm hoping to write something that offers a bit more guidance/insights for those who decided to pursue the first option. For those who decide to go with the second option, I unfortunately don't have any particular advice to give.

As for other advice/guidance I think it will depend greatly on what components you are using and the type of extension experiences you have implemented. If you have any specific questions I'd be more than happy to answer them here :)

[figuernd]

I would have assumed that this toolkit is the same set of UI components that VSCode itself uses. Does the FAST deprecation not affect VSCode's native components?

[Sanderand]

I'd also like to know if there is the way to make use of the components, that VSCode uses itself - without the need of having to reinvent the same, existing components?

@hawkticehurst which main problems do you expect for extensions that continue to use the ui toolkit beyond it's deprecation date? I guess some of the design tokens will stop working eventually. What other issues do you see?

Do you have any insights in how the big consumers are dealing with the problem of the deprecation of this package (i.e. nx-console)? Is there any plan that somebody will continue with the maintenance of this package? I find it personally quite sad to see this package go. A lot of unnecessary and duplicate work will be caused by this across hundreds of organizations... :(

[hawkticehurst]

I would have assumed that this toolkit is the same set of UI components that VSCode itself uses. Does the FAST deprecation not affect VSCode's native components?

Perhaps surprisingly, no they are not the same components. The FAST deprecation has no affect on the native UI.

I'd also like to know if there is the way to make use of the components, that VSCode uses itself - without the need of having to reinvent the same, existing components?

Alas no, and it's not without trying. VS Code's native UI is extremely tightly integrated with the VS Code source code itself. Despite several behind the scenes efforts over the years that have explored pulling out the UI code and trying to turn into something consumable for others, it's proven too difficult to dissect from the rest of VS Code. For example, I spent a lot of the second half of 2022 seeing if I could make that happen without any meaningful success.

The basic gist of the problem is that VS Code's native UI is highly imperative vanilla TypeScript (i.e. a bunch of calls to vanilla DOM APIs wrapped inside a bunch of classes) that make heavy usage of custom internal VS Code services and interfaces to function correctly. The end result is a set of components that are very far from being easy to pull out and consume by external developers.

At the end of the day it's easier to just recreate the UI from scratch using a technology like web components, so that's what we did for the toolkit.

Also for anyone who's curious all the native UI source code is open source and is pretty interesting to read through.

Which main problems do you expect for extensions that continue to use the ui toolkit beyond it's deprecation date? I guess some of the design tokens will stop working eventually. What other issues do you see?

The two biggest concerns that come to mind are:

1) Exposure to bugs and security issues without any path to resolve those issues 2) When VS Code updates it's UI/design language there will be no way to adopt those changes

Do you have any insights in how the big consumers are dealing with the problem of the deprecation of this package (i.e. nx-console)?

Unfortunately, I don't have any insights into how the bigger consumers are navigating the deprecation. Everyone was notified of this deprecation at the same time, so I expect bigger consumers are also in the early stages of trying to figure out a plan forward at this point.

As a general call to action: Anyone from the community who reads this and maintains a larger extension please do give some updates about how you've decided to move forward. I know the rest of the community (and myself) would be very grateful for that insight!

Is there any plan that somebody will continue with the maintenance of this package?

Aside from the commitment to fix critical security issues until January 1, 2025, there are sadly no plans to continue the maintenance of this project.

Once FAST Foundation is deprecated trying to maintain the toolkit (as it exists today) would become a nightmare because it would effectively mean adopting ownership/maintenance of an entire second project just to keep the lights on. It would entail even more work than rewriting the project from scratch.

[mattrothenberg]

End of an era! Thanks for all your hard work on this @hawkticehurst

[worksofliam]

Big sad!

[hawkticehurst]

End of an era! Thanks for all your hard work on this @hawkticehurst

The end of era indeed! Likewise thank you –– you certainly played no small part in the evolution and success of this project!

[hawkticehurst]

Big sad!

🥲

[eamodio]

@hawkticehurst sad news, but thank you for all your hard work!

For GitLens we've been using Lit for all our custom components going forward and leveraging Shoelace for some standard components.

In the vein of exposing VS Code's native "components" I've thought there might be a path for vscode to automatically register some webcomponent "wrappers" for the native ones in the webviews. And then webviews could just use them directly, e.g. <vscode-tree>. This of course wouldn't be simple, but would avoid the need to extract the native components from the codebase. A <vscode-editor> component would be killer!

[MaxKless]

Hey! Maintainer of Nx Console here :) We do really use the toolkit heavily as @Sanderand said so this is going to be a tough blow for us. We don't have any immediate plans for handling this - we'll have to reimplement everything, I guess.

I wonder if we could pool our resources and build a kind of community toolkit. We can all agree on webcomponents, I guess and Nx Console uses Lit just like GitLens does. With a little bit of consensus, we could save a lot of work between us!

P.S.: @hawkticehurst thanks for all the work you put into this, it's been an absolute pleasure to use and I'm really grateful this project existed in the first place! I'm sure you're sad to see it go as well 🥲

[estruyf]

@MaxKless and I briefly discussed creating a community toolkit on X. Before we start working on it, anyone who's interested can join the Discord server (https://discord.gg/wtv7wS2A79) to start planning.

@hawkticehurst, feel free to join as well; I believe you could give some valuable insights/feedback on this before we start writing code.

[hawkticehurst]

I wonder if we could pool our resources and build a kind of community toolkit. We can all agree on webcomponents, I guess and Nx Console uses Lit just like GitLens does. With a little bit of consensus, we could save a lot of work between us!

This 👆 –– Building and maintaining a (good/high quality) design system is no joke, I give a big +1 to the idea of investing in a community toolkit

anyone who's interested can join the Discord server. @hawkticehurst, feel free to join as well; I believe you could give some valuable insights/feedback on this before we start writing code.

This is awesome! I just joined and would be more than happy to offer my insights/feedback as time goes on :)

sad news, but thank you for all your hard work!

thanks for all the work you put into this, it's been an absolute pleasure to use and I'm really grateful this project existed in the first place! I'm sure you're sad to see it go as well 🥲

Thanks y'all, very sad to see it go 🥲

[kaviththiranga]

Very sad to hear. We are using this extensively as well. Thank you for creating this.

BTW would love to contribute if we are going to maintain this as a community project.

[bolinfest]

Though even if the official widgets are no longer supported, how can someone create a new toolkit that ensures it honors the theme of the host window? Even if something like agreed upon CSS class names are used, the values have to come from somewhere so that a proper <style> or <link href="...css"> can be loaded in the webview, right?

Currently, ColorTheme is just an enum, so that doesn't help much.

Even if the toolkit is going to be deprecated, can there at least be some commitment to expand to the extension API to provide enough information to create a webview that is visually consistent with the host window?

/cc @evangrayk since this affects Interactive Smartlog: https://sapling-scm.com/docs/addons/vscode

[estruyf]

Though even if the official widgets are no longer supported, how can someone create a new toolkit that ensures it honors the theme of the host window? Even if something like agreed upon CSS class names are used, the values have to come from somewhere so that a proper