Jump to content

ResourceLoader/Requirements

From mediawiki.org
Requirement Features Benefits Issues
Debugging
Support direct resource inclusion Allows JS resources to be included individually and without being run through the loader software JS resources can be more easily debugged because file names and line numbers correspond to the actual JS resources Requires L10n fallbacks to be embedded in JS resources
Support stand-alone use of loader Allows the script loader system to be integrated into other frameworks or used as a stand-alone service Development efforts can be shared with non-MediaWiki developers, and those developers' efforts can benefit us Makes MediaWiki integration difficult, makes code more foreign to MediaWiki developers
Useful information on loading failure Provides useful, verbose information about failures to load resources Makes development easier Requires more code to be written
Packaging
Remove debug statements Allows JS resources to contain debug information which is stripped out before being sent to the client Debug information can remain in JS resources for future use More moving parts to break
JS/CSS Minification Strips whitespace and comments from JS and CSS resources Reduces the amount of data sent to the client Makes debugging more difficult
JS Closure Compilation Simplifies and aggressively optimizes JS functions Reduces the amount of data sent to the client, and improves the performance of many JS functions Makes debugging very difficult
CSS Janus transformation Flips CSS rules to make LTR stylesheets appropriate for RTL No need to keep separate files around for this if we can apply this transformation in PHP along with the others Makes it slightly more difficult to figure out what the RTL version of a given CSS file looks like
Resource batching / concatenation Multiple resources can be included in a single request Reduces the number of requests from clients Potentially increases cache size, potentially causes double inclusion of resources
Parameterize batched loading Set a URL param to indicate we need resources for a certain combination of prefs/logged-in-ness rather than detecting this on the server Eliminates the need for uncacheable-for-logged-in-users Vary: Cookie responses Increases the number of URL variants
Web-server-level resource caching Caches processed (localized, minified, etc.) scripts on the server Makes it faster to batch resources in different combination Caching is not free, it takes time and space
Use short client-side expiry times Tells clients to refresh cached resources in short intervals (~1h) Eliminates the need to expire HTML (expensive) to force clients to refresh resources Requires that RL requests be cheap, so they should support 304 and be cached in Squid
Use highest-timestamp versioning scheme Version each RL request with the highest last-modified timestamp of the resources involved, formatted in ISO 8601 and rounded to 10s No more manual style versions. 10s rounding and human-readable format allows faster and easier purging of bad resources from Squid May cause conflicts when new JS is served with old HTML, need to code around that in JS
In-place localization Includes localized messages directly within JS resources Allows i18n of JS software without adding additional requests Mixes i18n work with development work
Localization API Makes messages available on demand individually or in groups Provides yet another option for getting L10n to the client Very inefficient way to get L10n to the client
Separate message resource system Generates JS blobs for l10n separately, stores them in the DB Only relevant JS is regenerated when a message changes Makes stand-alone usage more difficult
Export user preferences to JS
CSS grouping (without JS)
CSS includes registered in JS namespace Allows JS resources to check existence of CSS resources and require CSS resources to be loaded before proceeding Fewer CSS resources need to be included initially and modules can safely avoid re-loading already-loaded CSS resources Requires more code to be written
Resource buckets Allows resources to be grouped into buckets such as "all", "view", "edit", etc. Reduces number of individual requests needed Potentially too many things will get put in these buckets
Runtime loading of JS and CSS Allows resources to be included dynamically Reduces the initial payload sent to clients Potentially presents delay between user action and resource availability
Module based loading Resources are identified by module names Provides a standard way of expressing requirements and checking what resources are already loaded
Module loaders Modules each have associated loader functions which are executed to load the module Provides more flexibility in loading Increases the amount of code sent to the client and level of complexity in development
Configurable URL scheme Allows flexibility in request URL formats Makes using a localhost, web-server or CDN a matter of configuration
Allow version aliasing In the case that a buggy version of a script is released, a version redirect can be put in place Avoids purging PHP generated HTML to resolve JS bugs Potentially introduces level of indirection causing negative performance impact. Not needed if scripts are versioned and cached in Squid
Dependency order preservation Allows dependencies to automatically be included in a specific order if needed Makes dependencies simpler to use May make dependency specification more complex
Structure
Clear division of libraries Makes JS resources communicate with each other using well documented APIs Improves the re-usability of JS resources Takes more time to develop and document
Control a specific JS namespace Specifies a unified naming convention and access point for JS resources Improves maintainability and reduces difficulty to learn the system Requires porting existing code to conform
Control naming between PHP and JS resources Specifies clear naming between PHP extensions and JS modules Improves maintainability and reduces difficulty to learn the system Requires porting existing code to conform
Package-level dependency resolution JS modules can form packages, which can then be required/included as a whole Reduces complexity of specifying requirements making development easier Reduces specificity of requirements potentially causing resources to be loaded that will not be used
Map files, buckets and dependencies in PHP Have an associative array structure in PHP that defines objects, which optionally contain a file and optionally have dependencies Makes for fewer distinct URLs (?), which eases caching and purging Limited support for JS-based conditions, would have to be done through parameterization, cannot scale to user scripts
Division between loading and execution JS modules can be loaded on demand, and executed independently Makes dependencies simpler to use Makes writing modules more complex
Allow explicit re-loading Resources are not loaded more than once by default, but can be re-loaded if desired Makes overwriting/re-loading possible/easier
jQuery should be the primary way of extending functionality
jQuery plug-ins should be centrally organized All jQuery plug-ins should be committed to a central place, with version numbers in their names Makes sharing plug-ins easier / more likely to happen and everyone benefits from bug-fixes equally Causes issues with maintaining extensions or if people cloud the plug-in folder with low-quality plug-ins
JS module version conflict management Makes module version information available to JS resources Makes it possible to migrate to newer versions of plug-ins over time Sends more data to the client, adds complexity to configuration
Utilities
JS localization functions JS facilities for handling 18n functionality such as {{PLURAL}} and $ replacement Messages can be more flexible and reusable Must be maintained in parallel with PHP i18n functions, limitations must be well understood by translators

Sources

[edit]

This document is a synthesis of the following sources