To better determine how to proceed in regards to T321354: [SPIKE] Draft scope for CSS-only subset of Codex, let's explore what CSS-only Codex components would look like for a moderately complex use-case: replacing the MediaSearch server-rendered UI with Codex-compatible HTML/CSS components. This interface uses the following components:

• Search Input
• Icon
• Button
• Tabs

Research Spike outcome

I posted a series of patches that explored the feasibility of migrating MediaSearch's custom Vue components to their Codex equivalents. MediaSearch uses the component styles to render a no-JS fallback interface which then gets progressively enhanced by the interactive, JS components. The first patch in the series is here:

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MediaSearch/+/862409

Based on my exploration, I think that this approach is a good one for Codex to follow when it comes to delivering CSS versions of components alongside JS ones.

However, there are a couple of issues in how we are currently doing things that need to be addressed:

• There is currently no good way to get just the styles from the Codex ResourceLoader module in MW. Since MediaWiki lacks a front-end build step, we can only work with existing modules as they come. It's actually possible to get just the styles from a module using the following work-around, but I consider this kind of an ugly hack:

$this->getOutput()->addLink( [
	'rel' => 'stylesheet',
	'href' => wfAppendQuery( wfScript( 'load' ), [
		'modules' => '@wikimedia/codex',
		'only' => 'styles'
	] )
] );

• To address this, we should provide both CSS and JS modules for Codex in MediaWiki. The JS modules can depend on the CSS ones, but the CSS modules should be able to wrk stand-alone. Then, a PHP ui could call addModuleStyles( [ 'codex-styles' ] ) so that all necessary CSS is part of the page immediately. The equivalent codex JS module can be added at runtime when JS initializes for progressive enhancement purposes. If the UI in question didn't need JS at all, then only the CSS module(s) would need to be loaded.

• Having to load all of Codex (CSS and/or JS) just to get a small number of components is not great from a performance perspective. Without a true front-end build system we'll never be able to perfectly optimize this, but we can provide some smaller sub-packages of Codex that contain styles and JS code for only a specific sub-set of components. This approach is already done in OOUI and fits well with ResourceLoader; Codex-based features would just declare the modules they need as dependencies in ResourceLoader. This would require a little bit of re-structuring upstream but it's similar to how we are already handling the codex-search package. Example patch here: https://gerrit.wikimedia.org/r/c/design/codex/+/865840

In conclusion: features like MediaSearch would benefit from the following things:

• Provide Codex CSS as available as stand-alone modules that can be loaded independently of JS
• Split up Codex into multiple modules for use inside of MW (where we don't have the ability to tree-shake out a feature-specific build)

The approach suggested in T323180: [SPIKE] Determine how to mitigate performance concerns for CSS-only components has been informed by this investigation.