Requests for comment/Scripting

Initially MediaWiki templates were a pieces of wikitext which were just substituted into pages instead of copy-pasting. By 2005, any other use was rare and even to some extent controversial. In 2006, ParserFunctions were enabled, allowing users to use constructions like  and , essentially turning wikitext into a purely functional programming language (i.e. language which 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 cause 40 seconds to render) and readability (just take a look at this).

So now 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)

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 for much less 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 subset. Because, if you have certain features in implementation B and do not have it in 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.