Can you please also decide whether WVUI will be the official "shared component library" and if not, what will be? Its a bit confusing that some tasks are about WVUI and others about the "shared component library" and it can be unclear if that refers to a different library and if so, which.

@DannyS712 yes, that decision will be made as part of T286953

What about usage in on-wiki code like gadgets, user and sitewide scripts? I don’t see any tasks listed about them. It’s always been a pain point in gadget development that modern technologies like Less and automatically embedding images aren’t available, only plain JS and CSS, which results in harder-to-maintain, harder-to-understand and less performant code.

In T286946#7264914, @Tacsipacsi wrote:

What about usage in on-wiki code like gadgets, user and sitewide scripts? I don’t see any tasks listed about them. It’s always been a pain point in gadget development that modern technologies like Less and automatically embedding images aren’t available, only plain JS and CSS, which results in harder-to-maintain, harder-to-understand and less performant code.

Could someone answer this question? Even a “we don’t care” would make clear what to expect.

Personally I would like to see gadget and user script authors gain the ability to start using Vue and Codex for their own projects. I think this will eventually be possible but there are a couple of blockers at the moment.

For one, the tooling that validates gadget / user script JS is written in PHP and doesn't support ES6 syntax currently: see T75714. Additionally, there are some technical issues blocking WMF devs from using Vue more widely across MediaWiki and this will likely impact community devs as well. For example, we currently don't have a good way to do a front-end build step (which would allow for tree-shaking, shrinking the size of the code bundles that get shipped to the user). The Design Systems Team currently has a task open about developing guidelines on when and where Vue.js and Codex can be used (see T289208) – a comment about gadget and user script use-cases here would be welcome.

Introducing some Node.js based tooling could potentially solve both problems but may have trade-offs. A technical decision making process (the successor to the RFC process) will likely begin soon to try to figure out the best path forward.

In T286946#7808307, @egardner wrote:

Personally I would like to see gadget and user script authors gain the ability to start using Vue and Codex for their own projects. I think this will eventually be possible but there are a couple of blockers at the moment.

Vue can already be used, see https://meta.wikimedia.org/wiki/User:DannyS712/VueDemo.js and https://meta.wikimedia.org/wiki/Special:BlankPage/VueDemo

For one, the tooling that validates gadget / user script JS is written in PHP and doesn't support ES6 syntax currently: see T75714. Additionally, there are some technical issues blocking WMF devs from using Vue more widely across MediaWiki and this will likely impact community devs as well. For example, we currently don't have a good way to do a front-end build step (which would allow for tree-shaking, shrinking the size of the code bundles that get shipped to the user). The Design Systems Team currently has a task open about developing guidelines on when and where Vue.js and Codex can be used (see T289208) – a comment about gadget and user script use-cases here would be welcome.

Introducing some Node.js based tooling could potentially solve both problems but may have trade-offs. A technical decision making process (the successor to the RFC process) will likely begin soon to try to figure out the best path forward.

Also its impossible for onwiki scripts to use icons from codex

In T286946#7808307, @egardner wrote:

Personally I would like to see gadget and user script authors gain the ability to start using Vue and Codex for their own projects. I think this will eventually be possible but there are a couple of blockers at the moment.

Thanks! No rush – if we’ve survived two decades without a convenient gadget/user script UI framework, a few months/years don’t matter.

a comment about gadget and user script use-cases here would be welcome.

There are several gadgets that build their own UIs – from AddMe and AjaxQuickDelete that contain a single popup form to quite complex ones like GallerySlideshow. The consequence of not having a single client-side UI usable for gadgets is the inconsistency: AddMe uses MediaWiki UI (the predecessor of OOUI), AjaxQuickDelete uses jQuery UI, while GallerySlideshow uses a bit of Apex, but mostly builds its own interface from the ground up. Without an easy-to-use tooling available to gadget authors, there’s little hope to have this mess cleaned up ever. (Actually @MusikAnimal said that he wants to rewrite AddMe by next Community Wishlist Survey; if Vue was available in a timely manner for gadget authors, the gadget rewrite could build upon it.)