The initial render (from PHP) & the JS takeover are getting way out of sync.
There's a significant FOUC (there already was, but it's getting worse now that the UI is drifting apart), changes in functionality that we need to think about (can we skip the filters in no-JS), tabs are about to change, and the actual initial results (that are passed along from backend to frontend) are already based on different calls (filetype=bitmap vs filetype=bitmap|drawing)
We probably need to prioritize this - we should keep the initial render in sync (to some extent) when we make changes in JS, but it is no longer in a state where that is feasible.

I agree that this is a concern and we’ll need to think carefully in how we address it.

Since we’re not using OOUI widgets in the JS UI any longer, I wonder if it would make sense to stop using them server-side as well, in favor of replacing with more basic HTML elements that can share styling with the Vue components. We could move relevant CSS rules into a shared resource module for styling that is needed on both client and server.

I’m happy to spend time on this next week when I’m back (if it’s not too late at that point) – I’ve been interested in learning more about how to generate markup in MediaWiki PHP anyway.

The FOUC might be a bigger problem – in a perfect world we’d render some subset of the actual Vue components on the server and then “hydrate” them as seamlessly as possible, similar to how OOUI “infusion” works. But since we don’t have the infrastructure for this currently (and I don’t know when that will change), we may need to come up with some other solution for MediaSearch.

Another issue here when JS takes a while to load is that the input is completely swapped out, so if the user types in the PHP input their input will be removed when the JS version takes over. I'm sure there are other instances where interacting with the PHP interface will cause UX issues.

Change 623358 had a related patch set uploaded (by Matthias Mullie; owner: Matthias Mullie):
[mediawiki/extensions/WikibaseMediaInfo@master] [WIP] Bring PHP rendered SpecialMediaSearch version back in line with JS

https://gerrit.wikimedia.org/r/623358

In T258611#6413348, @AnneT wrote:

Another issue here when JS takes a while to load is that the input is completely swapped out, so if the user types in the PHP input their input will be removed when the JS version takes over. I'm sure there are other instances where interacting with the PHP interface will cause UX issues.

One potential way to handle this would be to add a small bit of JS that immediately disables elements like the search button and search input before the server-rendered UI is replaced with the Vue.js UI. Users without JS would still be able to use these elements normally.

We can simply grab the contents of the input field (which also contains the existing search term) instead of grabbing it from the url. That also covers the case of users starting new input before JS has had a chance to load.
The main reason that people will be able to start inputting text is the latency of having to transfer the JS bundle, which is now covered.

Another reason could be JS execution time - the delay between when we capture any existing input to render a Vue component with, and the moment that it becomes visible on-screen.
That's not currently possible because the existing render is emptied before Vue even inits, but I've changed things to keep the initial render until Vue has fully mounted.
That should only take a few ms, but I've made sure to disable the input field when we capture the existing text, to make sure that extreme cases of slow execution don't result in the last char(s) being overwritten (though not allowing them to be input is essentially the same :p)

Change 623358 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Bring PHP rendered SpecialMediaSearch version back in line with JS

https://gerrit.wikimedia.org/r/623358