After looking deeper into the different JS I think the complete migration of all our existing JS to Vue.js code is complex because many of the current code abstractions and entities do not fit well in a component approach framework like Vue. IMO this task should be marked as an EPIC and sliced into several.

Some challenges we may face are:

• Have a clear server-side strategy. Until now we use PHP to serve HTML then enhance it with JS. We can continue to do so but we need to come up with a solution for replacing the OOUI infuse mechanism
• OOUI components and ours built on top would ideally use the new WM Design System Codex which is still in development
• New Codex and old OOUI components won't have the same HTML structure so our LESS code will need to change accordingly

However there are several actions that we could make to modernize our front-end codebase which would facilitate a later adoption of Vue. These are some:

• Prioritize and follow up actions in T283221: GrowthExperiments adds 2.1K cost to Wikipedia pageviews [alert: Startup threshold exceeded], maybe starting with T289060: Create single homepage module and single account creation related module to reduce the number of entry points and re-structure our code
• Have a clear spec of which browsers, devices and skins we want to target. Something similar to the MW browser support matrix but for the growth experiments
• Create unit tests for existing JS business logic
• Start using and refactoring modules to ES6 (based on IE11 support decision we could use a build step in case we want to transpile to ES5)
• De-couple JS code as much as possible from jQuery and OOUI
• Remove OOUI-coupled LESS code as much as possible

For anyone interested here's an attempt of refactoring the help panel button to a Vue component.

In T296646#7622828, @Sgs wrote:

After looking deeper into the different JS I think the complete migration of all our existing JS to Vue.js code is complex because many of the current code abstractions and entities do not fit well in a component approach framework like Vue. IMO this task should be marked as an EPIC and sliced into several.

Some challenges we may face are:

• Have a clear server-side strategy. Until now we use PHP to serve HTML then enhance it with JS. We can continue to do so but we need to come up with a solution for replacing the OOUI infuse mechanism

I found prototypes for a Node service (T286963) and V8JS (T286966), but I'm not sure what the timeline is for first-class server-side rendering support.

For some of our features, we don't need to think about server-side rendering. For example:

• help panel button (simple enough that we should be able to live with code duplication)
• help panel (all client-side)
• mentor dashboard overview module (no server-side rendering currently)
• suggested edits task type and topic filters
• post-edit dialog

• OOUI components and ours built on top would ideally use the new WM Design System Codex which is still in development
• New Codex and old OOUI components won't have the same HTML structure so our LESS code will need to change accordingly

However there are several actions that we could make to modernize our front-end codebase which would facilitate a later adoption of Vue. These are some:

• Prioritize and follow up actions in T283221: GrowthExperiments adds 2.1K cost to Wikipedia pageviews [alert: Startup threshold exceeded], maybe starting with T289060: Create single homepage module and single account creation related module to reduce the number of entry points and re-structure our code
• Have a clear spec of which browsers, devices and skins we want to target. Something similar to the MW browser support matrix but for the growth experiments

Yes, I think the main thing we need to know is how adopting Vue for e.g. suggested edits would impact the userbase of growth features in countries / locations where IE11 usage is relatively high.

• Create unit tests for existing JS business logic

+1, a good first step would be to catalog what is important for us to test and perhaps group by priorities so we can start making progress on this.

• Start using and refactoring modules to ES6 (based on IE11 support decision we could use a build step in case we want to transpile to ES5)

This is complicated (see T279108 and T199004). We could work around that by committing the artifacts to the repo. I've not been excited about that approach so far, but if there's good arguments for doing so, I'm open to doing that.

• De-couple JS code as much as possible from jQuery and OOUI

+1

• Remove OOUI-coupled LESS code as much as possible

+1

For anyone interested here's an attempt of refactoring the help panel button to a Vue component.

Thanks! As we discussed in chat, could you please post to gerrit so we can review and discuss there?

In T296646#7626020, @kostajh wrote:

I found prototypes for a Node service (T286963) and V8JS (T286966), but I'm not sure what the timeline is for first-class server-side rendering support.

These are promising. We can continue to use OOUI for some interim period for the server-side rendered interfaces and eventually start migrating them to a VueSSR mechanism or keep just HTML + CSS but drop OOUI styles and replace them by new Codex design tokens.

For some of our features, we don't need to think about server-side rendering. For example:

• help panel button (simple enough that we should be able to live with code duplication)
• help panel (all client-side)
• mentor dashboard overview module (no server-side rendering currently)
• suggested edits task type and topic filters
• post-edit dialog

Nice, these are great starting points.

Yes, I think the main thing we need to know is how adopting Vue for e.g. suggested edits would impact the userbase of growth features in countries / locations where IE11 usage is relatively high.

I've seen some numbers in https://www.mediawiki.org/wiki/Compatibility/IE11 but it would be nice to see which are the shares for newcomers edits. An optimistic hypothesis is that newcomers use newer browsers.

• Create unit tests for existing JS business logic

+1, a good first step would be to catalog what is important for us to test and perhaps group by priorities so we can start making progress on this.

This is tricky because many logic is hidden inside OOUI widgets so the creation of the unit tests would imply diving into heavy mocking. For me a good starting thumb-rule would be to test anything that doesn't inherit from OOUI.

• Start using and refactoring modules to ES6 (based on IE11 support decision we could use a build step in case we want to transpile to ES5)

This is complicated (see T279108 and T199004). We could work around that by committing the artifacts to the repo. I've not been excited about that approach so far, but if there's good arguments for doing so, I'm open to doing that.

Since ResourceLoader supports ES6 we would not need the build step if we downgrade IE11 to Grade C support (in our extension) and provide server-side fallbacks.

• De-couple JS code as much as possible from jQuery and OOUI

+1

Based on the IE11 decision we could make a list of warning deprecations or lint rules to help us clean up. ie: Prefer Object.assign over $.extend to remove jquery dependency

• Remove OOUI-coupled LESS code as much as possible

+1

It is not only LESS code actually but also JS and PHP. I created a specific task for this T300557: Remove oo-ui-* references in Growth Experiments extension

Thanks! As we discussed in chat, could you please post to gerrit so we can review and discuss there?

I pushed the experiments code to gerrit and linked in T297764: Add Vue tooling and scaffolding for GrowthExperiments and T300532: Migration of mentee overview to Vue tasks.

I'm happy to see this discussion here. @Sgs, you are correct to point out the bigger-picture problems the Design Systems Team is still investigating (SSR or other progressive enhancement strategy for Vue, front-end build tooling, etc). I agree that identifying some smaller/simpler modules for migration is a good starting point.

The Design Systems Team is currently working towards an "alpha" release of Codex. I've added the Mentor Dashboard project to the list of projects (see T300280) that may be interested in serving as early adopters to alpha-test the library once we make it available inside NPM and ResourceLoader. That should happen in 1-2 weeks, once T294993 is resolved.

Finally, since it looks like some implementation work has already begun, you may find this example project useful: https://gitlab.wikimedia.org/egardner/mediawiki-extensions-vuetest

That repo includes examples of how to set up linters, Jest, and other related scaffolding in a manner that is suitable for Vue 3 & MediaWiki usage. Single-file .vue components are supported in RL, and you can now write them in ES6 syntax (using vue as a dependency now automatically sets es6: true in ResourceLoader settings). Finally, once the Codex icons package is available in RL, you will probably want to use the callback feature in your extension.json file so that only the necessary icons get loaded: here's an example.