Last modified: 2014-01-23 12:01:13 UTC
Given that JavaScript is or has, in essence, the eventual potential to be the world language of web development even on the server side, I think it would be quite nice if the proliferation of Scribunto scripts could take place using a syntax already familiar to web developers and likely to be so far into the future... I would think a safe subset could be employed...
JavaScript was considered during the creation of Scribunto, both V8 and Rhino. But Lua turned out to be better suited than either. The main "pro" for either JS engine was that JavaScript is likely more familiar to our users than Lua. Problems with V8 include: * Lack of documentation on embedding. * Unclear whether embedding will continue to be supported upstream. * Lack of a memory allocation hook, making it difficult to prevent poorly-written or malicious scripts from overrunning memory limits. * Huge standalone binary. Problems with Rhino include: * Written in Java. * Impossible to embed in PHP, meaning that WMF wikis would have to use slow IPC. * Very slow startup. This could be mitigated by running as a daemon, but... * Enforcing time and memory limits would require killing the external process, necessitating another slow startup. Either way, JavaScript didn't seem likely without a lot of effort. On the other hand, about the only "con" with Lua is that it would be relatively unfamiliar to most of our users. Pros include: * Designed for embedding, with detailed documentation. * Includes easy hooks to limit memory and CPU time usage. * Standalone binary is small and fast. And a JIT is available if more speed were needed. * Easy to sandbox, with no odd globals. If someone were to come along with a well-done patch to integrate a JavaScript engine we'd likely review it when time permitted, but it's unlikely that we're going to encourage anyone to spend time on it or prioritize it in any way. Lua is already here and is already being learned by the community.
