On Wed, 2009-11-04 at 02:23 +0100, Christian Neumair wrote: > 2009/11/2 Owen Taylor <otay...@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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
