See also T289208

Tagging in response to our respective managers connecting the dots.

@Jdlrobson Are you looking for a recommendation from us at this time? I'm happy to give this some time and thought this/next week, but can also wait. I'm just checking on the urgency/timeline for this in relation to other reviews and requests.

@Krinkle I've setup a meeting for Wednesday, 15 September when @Catrope is back. Having some kind of straw man proposal guidelines would be useful going into that conversation. The sticky header feature is being built out this month with a likely October release so we need to work out a plan for this by then. Does that seem a realistic timeframe?

I met with @Catrope @egardner and @Krinkle to discuss all things Vue.js and performance. The challenge we have is there are lots of moving targets. We're not sure how server-side rendering will work yet (and what kind of abstraction layer would be useful for minimizing problems we currently run into such as having to sync mw-ui-button buttons with WVUI ones). We also need to port WVUI to the new library, and solutions such as petite Vue may be used. I made it clear that the web team is tackling migration by using either mw-ui- OR WVUI for its interfaces to put it in a strong position for taking advantage of these solutions when available. In the short term we will have to find some compromises we are okay living with.

In terms of the specific questions posed here:

Can we load WVUI and Vue.js on scroll?

The current recommendation is we should avoid loading WVUI on scroll. Ideally, it should only be loaded on a user interaction, e.g. click/focus/typing text. This doesn't necessarily mean there is not legitimate use cases for doing this.

If not, under what conditions would that be acceptable

We talked about logged-in-only traffic, and we'd prefer not to treat logged-in users differently from logged-out from a performance perspective.

What performance metrics need to be added?

Performance metrics will likely be useful. We didn't establish any at the current time. @Krinkle if there is anything that would be useful to measure beyond https://grafana.wikimedia.org/d/GivPpdsGk/vue-vs-legacy-search?orgId=1 in the context of sticky header please let me know.

Anything else we should be aware of.

We did discuss the possibility of web running case studies e.g. trying petite vue in this context, but I was concerned that given our timelines and work already on our plate this is not likely practical. We also talked about the existing ports of Nearby and RelatedArticles and how in future they would benefit from server side rendering. Server side rendering is going to be more of an option if these are built in Vue.js in the first place. There is a danger that we could run into problems maintaining these if they are not built in Vue.js

The timeline is more flexible there, but I would like to understand how to adapt those (using a click-to-view pattern if necessary).

For next steps:

• I am going to explore using the click to load Vue pattern in the sticky header and report back.
• @Krinkle will provide some compromise options for completing the RelatedArticles port. For example, we could change RelatedArticles to a click to view pattern ; limit the scroll behaviour to certain conditions (e.g. certain time has passed; user has already loaded Vue.js locally in localStorage; user has certain browser performance characteristics). Once I have this I'll talk to @ovasileva about which makes sense