JS, whilst a good glue language, is nevertheless problematic in this it appears impotent (no native dbus support nor subclassing). I would only recommend it for scripting that does not need dbus. Currently a lot of code needs to be written in C to make up for these shortfalls in Gnome-Shell so I dont think its a particular good choice. I dont however see it as a blocker to gnome-shell acceptance
A much better alternative to any VM out there is Vala which sports two languages (Genie being a python/Delphi as well as Vala's c#/java syntax) and which gives C like performance and is moulded to fit gobject and our platform perfectly with better Dbus integration jamie On Wed, 2009-11-04 at 13:04 -0500, Owen Taylor wrote: > On Wed, 2009-11-04 at 02:23 +0100, Christian Neumair wrote: > > > 2009/11/2 Owen Taylor <[email protected]>: > > > 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 > [email protected] > http://mail.gnome.org/mailman/listinfo/desktop-devel-list _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
