GNOME debates Javascript bindings

Which Javascript binding should the GNOME desktop support? This is a question that the GNOME desktop-devel was debating last week. Since GNOME-Shell, the foundation of next year's GNOME 3.0, is built on Javascript, the answer is a major policy decision. However, the difficulties of making the decision are compounded because the contenders, Seed and Gjs, are both in rapid development and their final form is difficult to predict. However, that does not stop the push for a decision from the Seed community.

Both Seed and Gjs are GNOME projects. They are interpreters that allow users to write code in Javascript and have the core GNOME code use it. One of the major differences between them is the flavor of Javascript that they use, with Seed designed to work with WebKit, a Javascript engine favored by Apple and KDE, and Gjs with SpiderMonkey,a Javascript engine designed for Mozilla's applications. Since GNOME-Shell is written in Javascript (currently with Gjs) the choice of engines is a decision with far-reaching consequences. Also at stake is the prospect of tying future GNOME development to a particular dialect of Javascript whose development and adoption is still uncertain.

What makes the decision particularly hard is that, with Seed at release 0.7 and Gjs at 0.2, both are likely to change considerably before their final releases, so judging the suitability of one over the other is next to impossible. All the same, an effort at objective comparison was written by Owen Taylor, the GNOME-Shell maintainer.

Taylor notes that only Gjs currently supports "let" statements, which create variables scoped to the local block, and "const," which is used to declare a constant variable. He also refers to the fact that switching to Seed would currently mean a loss of destructuring assignment, a more flexible, multiple-assignment syntax. But he is largely unconcerned about these losses, viewing them as only temporary. He is more concerned about the choice of the widely used SpiderMonkey as opposed to the more untried JavascriptCore module behind WebKit, although he notes that Epiphany, the default GNOME browser, and Yelp, the GNOME help system, already use WebKit. Without giving particulars, Taylor also characterizes Gjs as having a limited set of well-implemented features, as opposed to Seed, which has more features. In fact, Gjs seems to exist largely to serve the needs of GNOME-Shell as they arise, while Seed is more active and independent project.

At this stage, he is not concerned with the speed of either, reasoning that it will change in coming months, but he does express concern at garbage collection — the reclamation of memory by the removal of unused objects — arguing that both SpiderMonkey's and WebKit's garbage collection is more geared to web pages than desktops. In the end, Taylor seems to be relatively indifferent to which one is used by GNOME so long as it has the tools that GNOME-Shell will require. In other words, the choice is too uncertain for even those most closely affected to have strong opinions on it.

The most that Taylor can provide is a general criterion for making a choice: "Javascript standardization is highly politicized and affected by concerns like what Microsoft can implement in IE and in general by considerations of cross-browser compatibility," Taylor wrote. "We should use whatever dialect of Javascript is supported by our engine that makes our life better."

The push for a choice

Nobody involved with Gjs has been active in this discussion, while those involved with Seed have been raising the possibility of choosing one over the other for six months. Last November, Frederick Peters, in the GNOME Commit-Digest, summarized some differences between Seed and Gjs as described by Robert Carr, Seed's maintainer. According to Peters, Carr suggested that, for the time being, "it's best for both projects to continue development at this point."

By January, as plans for GNOME 2.26's March release were being finalized, Carr was ready to propose that GNOME standardize on Seed. The proposal sparked a discussion about the relative merits of Seed and Gjs as they existed then. But the majority opinion was that it was still too early to make a choice, and the proposal was not accepted.

Four releases of Seed later, with plans being discussed for the release of GNOME 2.28 , the intended beta for GNOME 3.0 that is due for release in November, Carr renewed his proposal in May. He pointed out that Seed would require no new external dependencies, since WebKit/GTK+ and GObject Introspection, with which it interacts, are already scheduled to be included in the upcoming release. Furthermore, Seed already uses standard parts of GNOME, such as gnome-git and Bugzilla. Carr also cited the flexibility of using Seed, arguing that "at this point, most Gjs code could be prettily easily ported to Seed" while porting the other way "might be a bit more difficult" and suggesting that "it would be possible to port GNOME-Shell to Seed with no more than a few days' work." Similarly, he suggested that writing an extension to support Seed would be "around a day's work" for most applications. In passing, he also raised the possibility of a common module for both Gjs and Seed, which would preserve flexibility.

In response to a direct question from Hubert Figuiere about "what makes Seed more suitable than Gjs?" Carr admitted that, "For 2.28, it may make sense to have both Gjs and Seed as modules, and try and keep code somewhat compatible. It's still not entirely clear which Javascript engine is going to end up being better long term, so we might not want to completely commit to one yet."

Still, Carr favored Seed for a number of technical reasons. He argued that Seed's use of WebKit and GObject was more in keeping with existing tendencies in GNOME, and the Seed C API is far more intuitive than the SpiderMonkey API used by Gjs. Moreover, he described Seed as having more example code and documentation, which would make it easier to use.

What would happen to Gjs if Carr's proposal is accepted is uncertain. However, with Seed officially endorsed, Gjs would undoubtedly become a side line within GNOME if it continued at all. So far as most developers are concerned, it would probably survive largely in the code that Seed borrowed from it.

The discussion

The initial response to Carr's proposal was that having two Javascript engines was unnecessary. However, most people on the mailing list gradually seemed to agree with Vincent Untz, who argued that "we need both engines and we need them in our platform sooner rather than later," on the grounds that which one was preferable was still uncertain.

After a few remarks, the discussion turned to a question of whether GNOME-Shell's developers were prepared to use Seed, and what effort that decision would require. Carr replied that he was prepared to write a patch that would allow Gnome-Shell to use Seed. Others, though, such as Xan Lopez suggested that he was underestimating the size of the task. "Do you have any idea of how big a task adding 'let' [statements] support to JSC [Javascript Core] would be?" Lopez asked, referring to a one of Seed's greatest lacks, and implying that the task would be a big one. To this question, Carr replied that he was looking into the issue, and would report back when he had more information.

After discussing the idea of adding let statements to Javascript with the JSC project, Xan Lopez disagreed with Taylor on the grounds that the upstream JSC team was opposed to non-standard extensions. Instead, he urged that GNOME should "just stick to a [Javascript] defined in some standard widely used for all GNOME code, in order to avoid future headaches."

Carr offered to alleviate concerns by maintaining a Seed version of GNOME-Shell separately from the main branch for the next two releases. But, at this point, the unspoken consensus seems to have been that a decision could not be made.

Instead, talk turned to how to implement a common module for both Seed and Gjs. In a long post, Havoc Pennington strongly advocated this position. Pennington's "practical path" was to have both engines use the same modules and test suite, and to add support for let statements. As he saw it, the common module would also need to support disabling features that one or the other didn't support. This path was extra work, Pennington acknowledged, but he thought that the common module "could be the right decision even if GNOME includes only one of the runtimes, just to get more people hacking on the suite of [Javascript] modules."

For now, then, GNOME seems to have chosen to develop both modules together as much as possible, and to delay a final decision yet again. This approach may seem untidy and unsatisfying to many, but, it is hard to see what other decision could be made. Both the engines and Javascript itself are too unsettled for a clear choice to be made. Moreover, the undoubted pressure to advance GNOME 3.0 means that the time to make such decisions is minimal. By compromising, GNOME has allowed itself to progress while keeping as much flexibility as possible.