Re: Module semi-proposal: gnome-shell

[Owen Taylor <otaylor redhat com>]

On Wed, 2009-11-04 at 02:23 +0100, Christian Neumair wrote:

> 2009/11/2 Owen Taylor <otaylor redhat com>:
> >  GJS and SpiderMonkey: Currently gnome-shell is build using the
> >    GJS bindings to Javascript which work with the Mozilla SpiderMonkey
> >    Javascript engine. The comparison to seed/JavascriptCore has been
> >    discussed quite a bit in the past, I don't want to go into in
> >    detail here; basically the advantages for us are:
> 
> I have not been following the GNOME shell discussions, but I wonder
> why we JavaScript is needed at all. Now that some of the core modules
> exhibit Python, suddently JavaScript is discussed. I have always
> considered programming and script languages as interchangeable
> (besides syntactic and refactoring sugar), so we need a good argument
> for adding new ones that just make the dependency stack larger and
> larger. I'd really strongly opt for "C + Mono + one scripting
> language" or "C + Mono" or "C + one scripting language" when we talk
> about the core desktop. I see no advantage whatsoever in a Babylonian
> approach -- unless you convince me with good arguments.

The most fundamental and core reason for the use of Javascript is
that it gives us a clean platform; the experience with Javascript is
that you get a very pure experience with the GNOME libraries - to do IO,
you use GIO, and so forth. There are other languages where this
would be the case (Lua for example), but it's not the case with
Python, Mono, etc which have large standard libraries that overlap
with the GNOME libraries in complicated ways.

There are a number of secondary reasons, among them:

 - Familiarity - Python is certainly widely known, but not as
   widely as Javascript, Javascript provides an opportunity to
   get more people involved with GNOME.

 - Performance; JIT compilation is more advanced and widely
   deployed for Javascript than for Python, there's a lot of
   competition going on currently on performance for open-source
   Javascript engines.

 - Sandboxing - not a huge concern at the moment; we're more
   interested in extensions that have unrestricted access to
   the shell and platform than constrained widgets, but there
   are possibilities opened up by the ability to have an
   interpreter running in a restricted context, something that
   there's a lot more experience with with Javascript than
   any other language.

In terms of "C + Mono" - well, that's certainly a discussion I don't
want to get into, but practically speaking, for whatever, reason, there
is is no use of Mono in the core of the GNOME desktop, though there
are several applications built with Mono as part of the release sets.

> >    In one sense SpiderMonkey is not a problematic dependency;
> >    SpiderMonkey is distributed as part of xulrunner, and will be
> >    present on virtually any computer where GNOME is available.
> 
> Now that both the Epiphany web browser and Yelp [1] moved away  from
> Gecko to WebKit, it seems to be very odd that we suddently introduce a
> XULrunner dependency again. Is this a political decision due to the
> collaboration of the GNOME foundation and the Mozilla foundation that
> was once announced?

The reason that we went with GJS (and thus SpiderMonkey) when we
started was that at point it was more mature than Seed and maintained by
people that we knew better (like Havoc and Johan). Seed quickly made
progress and surpassed GJS in the feature set, and we got to know Rob
and Tim well too, but there's never been a choice where making a switch
from one to the other has seemed like a good use of resources.

There are ways that SpiderMonkey is better technically aligned with what
we are doing with the Shell ... after all, its being used as the core of
a large hybrid native/Javascript application, instead of just inside web
pages. So, there's more control over garbage collection, and more of a
willingness to add language extensions. There's very little interest
from the WebKit to add language extensions because they aren't usable
from web pages, which are by definition cross-browser.

But the main thing is just history and priorities.

I would emphasize that the choice of Javascript engine is largely just
not that important. We don't have any code written directly to the
SpiderMonkey C apis; everything is intermediated through
gbject-introspection. The syntax for imports and for using GObjects is
the same between GJS and Seed. We do use a number of SpiderMonkey
extensions extensively, but removing the use would be straightforward
and mechanical. If switching makes sense, we can switch at any point.

- Owen