Currently there are both technical and performance considerations that prevent us from loading Vue/Codex on article pages or other high-traffic or performance-critical areas. One potential solution would involve greater reliance on Node.js build tooling (for front-end build step and/or server-side rendering). Alternatively, a solution based on progressive enhancement techniques may be worth pursuing.
The purpose of this task is to develop a working prototype demonstrating this latter approach. Such a model will make it easier to evaluate advantages and disadvantages when deciding how we should move forward. This work may inform a future Technical Decision Making Process around this topic.
- Build a prototype MediaWiki skin using petite-vue (alternative Vue.js distribution optimized for progressive enhancement) and Mustache templates (which are already widely supported in our stack and don't require any additional infrastructure)
- Review the pros and cons of this approach and document them here
Related tasks:
What is progressive enhancement?
The Mozilla Docs have a pretty good summary:
Progressive enhancement is a design philosophy that provides a baseline of essential content and functionality to as many users as possible, while delivering the best possible experience only to users of the most modern browsers that can run all the required code.
The word progressive in progressive enhancement means creating a design that achieves a simpler-but-still-usable experience for users of older browsers and devices with limited capabilities, while at the same time being a design that progresses the user experience up to a more-compelling, fully-featured experience for users of newer browsers and devices with richer capabilities.
Outline of this approach
- Views are authored in Mustache templates (which MediaWiki already supports) and rendered normally on the server when a user requests a page. The rendered markup would also contain embedded Vue.js syntax (directives, variable bindings, etc).
- Clients using legacy browsers (non-ES6 capable) or users with JS disabled for any reason would stop here. They would have access to all server-rendered content, and any interactivity would be supported through basic HTML (buttons, links, web forms, etc). Submitting a search would take them to a separate search result page, etc.
- Users of modern, JS enabled browsers would download the above markup immediately (making for a good user experience), but very soon after they would also receive the page JS from ResourceLoader.
- The enhanced user experience would be powered by the petite-vue library, which weighs ~7KB minified and gzipped. Existing markup would be re-used (no virtual DOM, re-rendering of UI, etc), but now all off the previously-dormant Vue code embedded in the markup becomes active. Now the user interface is reactive like any other Vue app, meaning that changes in application state will automatically update the page.
- This is meant to be a complimentary approach to the SPA-style usage of Vue.js in places like Special Pages, suitable for use in Article pages where there is a lot of server-rendered content which needs to co-exist with client-side interactive features.
Example Code
Advantages
- Performance friendly (~7kb JS runtime)
- Write UI code once (JS files and mustache templates); no-JS users still get a functional UI
- Relies on existing tech that we already support (no Node runtime needed for MW, much smaller security footprint, etc); less tech debt and complexity
- Team writing front-end code can still get (most) benefits of Vue: declarative templates, reactive UI elements, etc.
- Vue syntax (mostly)
Disadvantages
- Instead of a single set of coding standards, we will have 2
- Features on content/high vis/perf critical pages (or wherever server-rendered UI is needed): Limited to petite-vue and mustache
- Features on stand-alone Special pages or non-perf intensive areas (dashboards, etc): Allowed to use full Vue and Codex
- Use of Codex components will be limited to where “full vue” is allowed, although some markup/styles could be shared
- Mustache has much more primitive support for “componentization”, so it will be hard to make a re-usable template partial for a low-level component like Button (unless we do it in PHP, similar to OOUI PHP…)
- This places a greater burden on developers to write (or at least copy/paste) what they need themselves
- Without a build step, some developer experience improvements will not be possible (Typescript, etc)
