Sunsetting the Webview UI Toolkit #561
Comments
|
Hey there. I was just starting out using Webview UI toolkit - which works fantastic. So this is bad news for me. |
|
Is there any advice or guidance for consumers of the toolkit going forward? |
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.
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:
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 :) |
|
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? |
|
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... :( |
Perhaps surprisingly, no they are not the same components. The FAST deprecation has no affect on the native UI.
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.
The two biggest concerns that come to mind are:
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!
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. |
|
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. |
|
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 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 |
VS Code provides CSS variables which values change depending on the activated theme, so you can take advantage of those CSS variables in your components/webviews. https://code.visualstudio.com/api/extension-guides/webview#theming-webview-content |
|
@estruyf Looking at the DOM inspector for an existing extension: is it VS Code that is injecting a |
|
@bolinfest that is the work of VS Code. The UI toolkit uses these variables to style its components. |
Our Sapling codebase actually recently migrated away from this toolkit to our own (visually identical) implementation of all the components. It's MIT licensed in case anyone wants to use it as a starting point to migrate away from the toolkit themselves (if you use react): https://github.com/facebook/sapling/tree/main/addons/components |
can we still join? the invite is invalid. |
|
@idoprz of course you can join, here is a new invite link: https://discord.gg/wtv7wS2A79 |
heyo, would love to contribute too ! |
|
@akurtaliqi-sg happy to hear. Feel free to join the discord server. Yesterday I created the repository to get the community project started: https://github.com/estruyf/vscode-community-ui-toolkit |
|
Alternative library based on Lit |
Thanks for sharing, I didn't know this library exists. It even provides more components then the webview-ui-toolkit. Am I missing something or what are the reason not to use this library but develop a new one? |
|
Wow this looks really good... On a first glance I'm not spotting anything that looks non-native either |
- Add User Agent - Add transform evaluation support for `decomposeDiacriticalMarks` (cf. [#90](#90)) by [@Semperverus](https://github.com/Semperverus) - Add new command to enable logging - Fixed dependency (axios, micromatch) - Refactored code due to [#36](sailpoint-oss/typescript-sdk#36) - Removed Workflow Tester view due to webview-ui-toolkit deprecation (cf. microsoft/vscode-webview-ui-toolkit#561) - Add support for Applications - Error with session management (cf. [#93](#93))
O pacote @vscode/webview-ui-toolkit foi descontinuado, por isso foi migrado para @vscode-elements/elements. microsoft/vscode-webview-ui-toolkit#561
[`@vscode/webview-ui-toolkit` is being deprecated in January](microsoft/vscode-webview-ui-toolkit#561). This PR replaces the UI components from `@vscode/webview-ui-toolkit` with components from `@vscode-elements/elements`.
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-toolkitNPM packagemicrosoft/vscode-webview-ui-toolkitGitHub repositorymicrosoft/vscode-webview-ui-toolkit-samplesGitHub repositoryTimeline
There will be two key dates for sunsetting this project.
August 1, 2024August 2, 2024Ongoing 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!
The text was updated successfully, but these errors were encountered: