Requests for comment/Scripting

This page documents the history and current status of wikitext scripting.

Background
Initially MediaWiki templates were pieces of wikitext that were substituted into pages instead of copy-pasting. By 2005, any other use was rare and, to some extent, controversial. In 2006, ParserFunctions were enabled, allowing users to use constructions such as  and , essentially turning wikitext into a purely functional programming language (i.e., a language that has no concept of state at any level and one part of the code may not affect any other part, it can only change its own output). This eventually caused several problems, including performance (some pages are overloaded with templates and require 40 seconds or more to parse/render) and readability (just take a look at this).

Proposed solutions
In order to resolve these issues, we are looking for a scripting solution that will replace our current template system. Options:
 * 1) Lua (implemented)
 * 2) WikiScripts (implemented)
 * 3) Probably some JavaScript backend (Node.JS)

Objectives
What do we want from the scripting system:
 * 1) Performance. The current headliner of the profiling is PPFrame_DOM::expand. The scripting solution must allow us to render pages like en:Barack Obama in much less time than 40 seconds.
 * 2) Portability. Parser functions are currently the most popular MediaWiki extension and our templates are reused all around the world. If we choose the solution that would require users to have something unportable (for example, do not support Windows or require PHP extension most hostings do not have), that may have serious negative impact on our vision.
 * 3) * This imposes restriction on dual-implementation of the scripts. If we have solution A (in PHP) and solution B (faster version in C used on WMF), they must implement equal features, not a subset. If you have certain features in implementation B and do not have those features in implementation A, the users of B will soon start using those non-compliant features and their code will become non-reusable for the users of A.
 * 4) Sandboxing. Users must not be allowed to abuse the server resources using the scripting language. The solution must be protected from DoS attacks and security exploits.
 * 5) Determinism. The same script with the same engine configuration must always produce the same result. Two backends must always produce the same result (see portability note above).
 * 6) * When combined with portability requirement, this also shows why things like CPU limit are bad for sandboxing. CPU time on different machines would be different.
 * 7) Extensibility. We would need to insert our own functions into that language to allow users interact more easily with MediaWiki.
 * 8) Isolation. No template should be able to affect the execution of any other template except by transcluding another template and passing arguments into it. Due to fact that each template is stored on a separate page, such non-local effects would be difficult to debug.
 * 9) Usability. Ease of use, learning time, as well as presence of syntax highlighting and code editor.