Re: JavaScript engines
On Tue, Jan 6, 2009 at 8:32 PM, Alberto Ruiz wrote: > 2009/1/6 Robert Carr : > > Hats off for you both guys on working together to achieve compatibility. > > Another issue that might be worth taking into account is that you > should be consistent on how you document the bindings (tutorials, > examples, faqs) as this is how people would end up writing most of the > code. This could be a way to avoid incompatible code out there. > -- > Un saludo, > Alberto Ruiz > ___ This is something I don't want to commit to in full, Seed has a large amount of examples and documentation (compared to almost nothing for gjs), and the documentation/examples make use of features which are not in gjs (some which are pretty core to the way Seed programs are written), and I'm not willing to remove features from the Seed documentation/examples simply because gjs does not support them. A lot of work has been put in to documenting Seed (Tim Horton has driven a lot of this), and I don't want to toss it. However, I'm planning something like Valadoc, which would document the way the bindings map, and this could be used between GJS/Seed (as hopefully the bindings will map the same way), and once we decide on a common C API, I will of course document/provide examples for that. Additionally I would probably want to make some sort of "extending GNOME applications with JavaScript" tutorial that covered the C API/JS bindings, and I would be willing to limit this to the common parts. Thanks, Robb ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JavaScript engines
2009/1/6 Robert Carr : > Another update, I've talked to Havoc in IRC. Seed is going to switch to > the gjs/Vala format for enums (later today), and to the gjs import style. > The remaining difference in the core bindings, is how signals are > handled, and we've been discussing this with no conclusion yet, but in > the not so far off future, some decision will be made on this. > > After that the two will be compatible in how they bind libraries, though > all the aforementioned feature differences will still exist. Hats off for you both guys on working together to achieve compatibility. Another issue that might be worth taking into account is that you should be consistent on how you document the bindings (tutorials, examples, faqs) as this is how people would end up writing most of the code. This could be a way to avoid incompatible code out there. > ==Original message text=== > On Tue, 06 Jan 2009 12:13:32 EST "Matthias Clasen" wrote: > > On Tue, Jan 6, 2009 at 11:59 AM, Jason D. Clinton > wrote: > >>. After all, >> both implementations run the same language with the same syntax and >> they are *both* using the same underlying GObject bindings so the >> API's will be the same. >> > > This is the key question, isn't it. _Are_ the apis the same ? > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ===End of original message text=== > > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- Un saludo, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JavaScript engines
Another update, I've talked to Havoc in IRC. Seed is going to switch to the gjs/Vala format for enums (later today), and to the gjs import style. The remaining difference in the core bindings, is how signals are handled, and we've been discussing this with no conclusion yet, but in the not so far off future, some decision will be made on this. After that the two will be compatible in how they bind libraries, though all the aforementioned feature differences will still exist. ==Original message text=== On Tue, 06 Jan 2009 12:13:32 EST "Matthias Clasen" wrote: On Tue, Jan 6, 2009 at 11:59 AM, Jason D. Clinton wrote: >. After all, > both implementations run the same language with the same syntax and > they are *both* using the same underlying GObject bindings so the > API's will be the same. > This is the key question, isn't it. _Are_ the apis the same ? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ===End of original message text=== ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JavaScript engines
JSCore is open to all these extensions, and they are on the slate to be implemented, just not a priority. It's somewhat likely I could end up implementing some of them, as a few would be nice to have in Seed. Long term though I think there are considerations that have to be considered beyond "Which one supports yield/let today!". Notably, the general push towards WebKit migration (as in, migrating all GNOME modules to WebKit), speed/memory differences, and potential speed/memory differences in the future. Once these JS extensions are implemented in JSCore, it would essentially be a faster spider/tracemonkey, with a cleaner API, so it would be a shame to have decided on Mozilla prematurely. ==Original message text=== On Tue, 06 Jan 2009 12:30:25 EST Johan Dahlin wrote: Jason D. Clinton wrote: > On Tue, Jan 6, 2009 at 11:14 AM, Johan Dahlin wrote: >> The language is pretty different, SpiderMonkey supports quite a few >> /language/ extensions which JSCore doesn't.[1][2][3] > > s/doesn't./doesn't yet./g I don't think JSCore is going to implement all features present in Spidermonkey since they have a different use case. WebKit/JSCore uses javascript mainly to run scripts found on web pages. Spidermonkey is different as it's in addition to that is used to develop native applications (firefox, thunderbird etc). In other words, JSCore (V8 & JScript etc) will reasonably only support what web pages actually uses. So sure, the language extensions present in Spidermonkey might eventually be supported in other engines, but /only/ if web pages actually start to use them. Anyway, what subset of JS that's going to be used in the newest and fanciest web pages seems like a less than ideal criteria to use to select a javascript engine for GNOME. Instead we should compare what's available, which will help developers to write great applications *today*. Johan ===End of original message text=== ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JavaScript engines
While this argument is somewhat counter to my "side" most of the JavaScript extensions are actually quite nice, and will be implemented in WebKit. ==Original message text=== On Tue, 06 Jan 2009 12:52:46 EST "Kalle Vahlman" wrote: 2009/1/6 Johan Dahlin : > Anyway, what subset of JS that's going to be used in the newest and fanciest > web pages seems like a less than ideal criteria to use to select a > javascript engine for GNOME. Instead we should compare what's available, > which will help developers to write great applications *today*. I'd much rather see a *less* extended JS engine in GNOME than adopt the mess of engine-specific JS features that exists in the browser world. But I guess I'm just a day-dreamer ;) -- Kalle Vahlman, z...@iki.fi Powered by http://movial.fiInteresting stuff at http://sandbox.movial.comSee also http://syslog.movial.fi___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ===End of original message text=== ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JavaScript engines
As I mentioned in the other email, dropping Seed to using GJS as the "reference" implementation, would essentially consist of changing small binding semantics, and then dropping around a third of the Seed code base which is oriented towards the more complex features. This isn't really something I'm willing to just do. ==Original message text=== On Tue, 06 Jan 2009 14:07:39 EST "Jason D. Clinton" wrote: On Tue, Jan 6, 2009 at 12:26 PM, Alexander Larsson wrote: > The APIs will certainly not automatically be the same. There are lots > and lots of little decisions you have to make when you bind gtk. If just > one of these differ then they won't be compatible. It's not clear to me why this would not be considered a bug. Hopefully Robert will jump in here and say he's willing to treat GJS as the reference implementation and then everyone can just be happy with two implementations with the same API on which any app can Just Work. Let's wait for Robert to reply before we get too carried away... ===End of original message text=== ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JavaScript engines
I just woke up to about 50 emails to reply to, so this might all come out rather disorganised, but this seemed like a good one to start with. I appreciate Havoc's first point, in that I agree it's not fair to drop the entire responsibility for re basing on the other binding on one group. As both appeared around the same time period, and neither one has had large amounts of adoption yet. Obviously, gjs will not just go away (for Havoc's enumerated reasons). I don't see Seed going away any time soon either, for a few of the following reasons: * I am planning to use Seed in an app I am working on (will release eventually :P), which is already using WebKit. * Epiphany developers have expressed more interest in migrating to Seed for extensions (should be some proof of concept code for that in a few days), and of course epiphany is using WebKit now. * Seed is approaching the point where it goes in to "maintenance" mode, and should by and large have the first (I suppose it could be called the second) batch of features complete within the next few weeks, so I will of course continue to maintain it. I 100% agree developing a common C API makes sense. This API would have to be somewhat limited compared to the full SpiderMonkey/Seed (Seed API does not expose JavaScriptCore) API, but could probably cover common embedding situations. I am not sure an abstraction layer good enough to support the C extension modules is actually feasible, due to the large differences (C API wise) in the class definition mechanisms, and GC semantics. In addition some of the rules on how you can keep C JSContext refs around, are different (I seem to recall some uses of this, which I know would NOT work in WebKit). Then WebKit also has the whole JSContextGroupRef semantic, related to Contexts which can share objects, so I don't know how spidermonkey does this. As for JS level compatibility, the primary issues there are as follows: * Small binding details (i.e. different enum casing). I am willing to change things like this immediately (today?). * gjs/spidermonkey use of let statements. WebKit is open to a patch adding let statements, but it is not one of their priorities...my attempts at this turned out to not be the best approach, and I don't want to commit to trying to get a version of this upstream, but it's likely I'll try again some point soon. * Seed features GJS does not have: Seed supports a lot of things GJS does not, including GObject Subclassing, with new properties/signals (implementing interfaces/abstract methods also "works" but is blocking on a gobject-introspection bug). Some others are, automatic boxing of JS functions in to C function pointers (from libffi), so that functions like gtk_container_foreach work. I believe Seed has somewhat more complete struct/boxed integration (a nice struct literal syntax, etc...), though I will confess to not having looked at Gjs in a while here. Seed also has lots of corner cases fixed that I have not seen done in Gio (the Seed examples cover a fairly large portion of mainstream GObject libraries, and it's let us hit a lot of the issues). All of these are made quite pervasive use of in Seed code, and are also quite useful, and so I do not want to just drop them. There is no obvious technical reason why most of these could not be implemented in gjs (though they are nontrivial...), and I would be willing to help, or change some of the specific semantics of how these things work in Seed, however I can't commit to doing ALL of them in gjs. If these features don't make sense in gjs, Seed could easily be made a superset of gjs, with the rest of the API binding identically. The in-one-repository approach with work on a shared test suite (covering at least the subset of things we can agree on now, e.g. basic binding stuff), and a least-common-denominator C API, both make sense to me. In addition we need to find out the differences in the core binding semantics/builtins, and maybe start to work out some things there. How would you like to go about doing this? Thanks, Robert ==Original message text=== On Tue, 06 Jan 2009 14:38:17 EST "Havoc Pennington" wrote: Hi, On Tue, Jan 6, 2009 at 2:07 PM, Jason D. Clinton wrote: > On Tue, Jan 6, 2009 at 12:26 PM, Alexander Larsson wrote: >> The APIs will certainly not automatically be the same. There are lots >> and lots of little decisions you have to make when you bind gtk. If just >> one of these differ then they won't be compatible. > > It's not clear to me why this would not be considered a bug. > > Hopefully Robert will jump in here and say he's willing to treat GJS > as the reference implementation and then everyone can just be happy > with two implementations with the same API on which any app can Just > Work. > Well, I would be reluctant to put this all on Robert. There's no real a priori reason seed should copy gjs instead of vice versa. The two projects started at roughly the same time with no awareness o
Re: JavaScript engines
On Tue, Jan 6, 2009 at 10:12 AM, Johan Dahlin wrote: > We need to have this discussion sooner or later, seems like sooner > is now required as Robert proposed to have Seed included in Gnome. > > First of all, I think most of us agrees that it would be a mistake to depend > on two different JavaScript bindings in GNOME, we need to chose one and > stick to that one. There are three separate things I think: 1) Binding we would like to use for core GNOME infrastructure like window manager, panel, etc. 2) Binding for writing applications intended to be included in GNOME 3) Binding for writing third party applications I agree it would be a bad idea to have different programs in set 1. However for 2) and 3), historically GNOME has been quite binding friendly. Now, we should try to limit the set of VMs going into 2). 3) is still being battled out in the larger industry. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JavaScript engines
Hi,
On Tue, Jan 6, 2009 at 2:07 PM, Jason D. Clinton wrote:
> On Tue, Jan 6, 2009 at 12:26 PM, Alexander Larsson wrote:
>> The APIs will certainly not automatically be the same. There are lots
>> and lots of little decisions you have to make when you bind gtk. If just
>> one of these differ then they won't be compatible.
>
> It's not clear to me why this would not be considered a bug.
>
> Hopefully Robert will jump in here and say he's willing to treat GJS
> as the reference implementation and then everyone can just be happy
> with two implementations with the same API on which any app can Just
> Work.
>
Well, I would be reluctant to put this all on Robert. There's no real
a priori reason seed should copy gjs instead of vice versa. The two
projects started at roughly the same time with no awareness of each
other.
As a practical matter, the litl app is a huge amount of of gjs code,
so there is no way we can port it to another setup anytime soon (which
does not necessarily govern gjs upstream, but if gjs were incompatibly
changed, we would probably end up keeping a branch that wasn't
changed). So that is a practical consideration for the people working
on gjs at litl, otherwise I might offer to be "seed compatible."
Realistically speaking we need something gjs compatible for quite a
while.
But, I don't know about trying to hash out seed vs. gjs on the mailing
list. They both have pros and cons, both have people excited about
working on them, neither one is a "fork" that post-dates the other; so
it's kind of a mess, but there isn't a clear right answer and it's
not anybody's fault for creating it.
If someone, through hacking, were going to clean it up; I would suggest:
- move them into one module with webkit and spidermonkey subdirs
- have a single test suite covering module system, gobject binding
conventions, etc. and make both pass it
- use a common C embed API like alexl's gscript one (also with test
suite coverage)
But this is pretty complex in some ways:
- if as Tim says, webkit lacks "let", that's a pretty huge issue
("let" is one of the ways gjs-javascript is far less annoying than
browser-javascript).
it'd require a big downgrade to go least-common-denominator on this.
- gjs allows 'native modules' written in C, those use spidermonkey
APIs directly; an abstraction layer good enough to support this would
be a lot of work
- undoubtedly a number of other little things
Anyway, working on reconciling the APIs through some sort of shared
test suite and C gscript API is probably more productive than mailing
list traffic, so perhaps we need a volunteer on that front.
Havoc
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JavaScript engines
On Jan 6, 2009, at 14:07, Jason D. Clinton wrote: On Tue, Jan 6, 2009 at 12:26 PM, Alexander Larsson wrote: The APIs will certainly not automatically be the same. There are lots and lots of little decisions you have to make when you bind gtk. If just one of these differ then they won't be compatible. It's not clear to me why this would not be considered a bug. So it's certainly not straightforward to decide how to bind certain things... (say, for example signal connection) Most bindings are very similar between GJS and Seed, but the structure around it (from what I've seen) isn't. Hopefully Robert will jump in here and say he's willing to treat GJS as the reference implementation and then everyone can just be happy with two implementations with the same API on which any app can Just Work. I'll wait for Robb, since he's the one who makes most of the decisions (and is much more familiar with all of you), but I'd say that it wouldn't be a horrible amount of work to get Seed to more or less compatible with GJS in most ways (however, in the code I've seen, you guys seem to use a lot of 'let', and the like... which JavaScriptCore doesn't have yet... we're still trying to convince them/working out the best way to implement things like that). Let's wait for Robert to reply before we get too carried away... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JavaScript engines
On Tue, Jan 6, 2009 at 12:26 PM, Alexander Larsson wrote: > The APIs will certainly not automatically be the same. There are lots > and lots of little decisions you have to make when you bind gtk. If just > one of these differ then they won't be compatible. It's not clear to me why this would not be considered a bug. Hopefully Robert will jump in here and say he's willing to treat GJS as the reference implementation and then everyone can just be happy with two implementations with the same API on which any app can Just Work. Let's wait for Robert to reply before we get too carried away... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JavaScript engines
On Tue, 2009-01-06 at 10:59 -0600, Jason D. Clinton wrote: > On Tue, Jan 6, 2009 at 9:12 AM, Johan Dahlin wrote: > > We need to have this discussion sooner or later, seems like sooner > > is now required as Robert proposed to have Seed included in Gnome. > > > > First of all, I think most of us agrees that it would be a mistake to depend > > on two different JavaScript bindings in GNOME, we need to chose one and > > stick to that one. > > Actually, I do disagree. The JavaScript interpreter/JIT wars are just > now heating up and its still way to early to call a winner. 2-3 years > from now, there could be a distinct winner in the JS VM battle and it > would be unfortunate if we picked the wrong horse, so to speak. I > think we need to support bindings for both front-runners. After all, > both implementations run the same language with the same syntax and > they are *both* using the same underlying GObject bindings so the > API's will be the same. The APIs will certainly not automatically be the same. There are lots and lots of little decisions you have to make when you bind gtk. If just one of these differ then they won't be compatible. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JavaScript engines
2009/1/6 Johan Dahlin : > Anyway, what subset of JS that's going to be used in the newest and fanciest > web pages seems like a less than ideal criteria to use to select a > javascript engine for GNOME. Instead we should compare what's available, > which will help developers to write great applications *today*. I'd much rather see a *less* extended JS engine in GNOME than adopt the mess of engine-specific JS features that exists in the browser world. But I guess I'm just a day-dreamer ;) -- Kalle Vahlman, z...@iki.fi Powered by http://movial.fi Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JavaScript engines
Jason D. Clinton wrote: On Tue, Jan 6, 2009 at 11:14 AM, Johan Dahlin wrote: The language is pretty different, SpiderMonkey supports quite a few /language/ extensions which JSCore doesn't.[1][2][3] s/doesn't./doesn't yet./g I don't think JSCore is going to implement all features present in Spidermonkey since they have a different use case. WebKit/JSCore uses javascript mainly to run scripts found on web pages. Spidermonkey is different as it's in addition to that is used to develop native applications (firefox, thunderbird etc). In other words, JSCore (V8 & JScript etc) will reasonably only support what web pages actually uses. So sure, the language extensions present in Spidermonkey might eventually be supported in other engines, but /only/ if web pages actually start to use them. Anyway, what subset of JS that's going to be used in the newest and fanciest web pages seems like a less than ideal criteria to use to select a javascript engine for GNOME. Instead we should compare what's available, which will help developers to write great applications *today*. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JavaScript engines
On Tue, Jan 6, 2009 at 11:14 AM, Johan Dahlin wrote: > The language is pretty different, SpiderMonkey supports quite a few > /language/ extensions which JSCore doesn't.[1][2][3] s/doesn't./doesn't yet./g ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JavaScript engines
Jason D. Clinton wrote: > think we need to support bindings for both front-runners. After all, > both implementations run the same language with the same syntax and > they are *both* using the same underlying GObject bindings so the > API's will be the same. Not quite the same as Spidermonkey implements the 1.7 spec, and new features are being used in gnome-shell already (1.7 introduced "let"); there are also some differences specific to gjs/seed, to import modules for example. IIRC those were the main differences I encountered when I "ported" some gjs examples to seed, but it was just when seed got introduced, things may well be different now. Nevertheless it is still very early to pick a winner, and we agree on that, both gjs and seed should still mature before a decision is made, and Johan Dahlin made a good list of evaluation points. Cheers, Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JavaScript engines
Jason D. Clinton wrote: On Tue, Jan 6, 2009 at 9:12 AM, Johan Dahlin wrote: We need to have this discussion sooner or later, seems like sooner is now required as Robert proposed to have Seed included in Gnome. First of all, I think most of us agrees that it would be a mistake to depend on two different JavaScript bindings in GNOME, we need to chose one and stick to that one. Actually, I do disagree. The JavaScript interpreter/JIT wars are just now heating up and its still way to early to call a winner. 2-3 years from now, there could be a distinct winner in the JS VM battle and it would be unfortunate if we picked the wrong horse, so to speak. I think we need to support bindings for both front-runners. After all, both implementations run the same language with the same syntax and they are *both* using the same underlying GObject bindings so the API's will be the same. The language is pretty different, SpiderMonkey supports quite a few /language/ extensions which JSCore doesn't.[1][2][3] I don't see any harm in using both for the short to medium term. What you're saying is essentially the same as saying that we should support more than one toolkit as well. Why don't we go ahead and support Qt next to Gtk in GNOME as well? My point is that you can write an application which supports both but it'll be a lot of extra work to little benefit. Using different JS engines for different applications can also be compared to toolkits. Can certainly be done, but will create similar inconsistencies. Engine 1 supports features A, B, C, but Engine 2 supports features D, E and F. People will just ask; No to mention trying to answer the obvious "Which engine should I use in my application?" question. Johan [1]: https://developer.mozilla.org/en/New_in_JavaScript_1.6 [2]: https://developer.mozilla.org/en/New_in_JavaScript_1.7 [3]: https://developer.mozilla.org/en/New_in_JavaScript_1.8 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JavaScript engines
On Tue, Jan 6, 2009 at 11:59 AM, Jason D. Clinton wrote: >. After all, > both implementations run the same language with the same syntax and > they are *both* using the same underlying GObject bindings so the > API's will be the same. > This is the key question, isn't it. _Are_ the apis the same ? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JavaScript engines
On Tue, Jan 6, 2009 at 9:12 AM, Johan Dahlin wrote: > We need to have this discussion sooner or later, seems like sooner > is now required as Robert proposed to have Seed included in Gnome. > > First of all, I think most of us agrees that it would be a mistake to depend > on two different JavaScript bindings in GNOME, we need to chose one and > stick to that one. Actually, I do disagree. The JavaScript interpreter/JIT wars are just now heating up and its still way to early to call a winner. 2-3 years from now, there could be a distinct winner in the JS VM battle and it would be unfortunate if we picked the wrong horse, so to speak. I think we need to support bindings for both front-runners. After all, both implementations run the same language with the same syntax and they are *both* using the same underlying GObject bindings so the API's will be the same. I don't see any harm in using both for the short to medium term. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
JavaScript engines
We need to have this discussion sooner or later, seems like sooner is now required as Robert proposed to have Seed included in Gnome. First of all, I think most of us agrees that it would be a mistake to depend on two different JavaScript bindings in GNOME, we need to chose one and stick to that one. What we currently have are the following two engines: * Gjs - binding for Spidermonkey, part of Gecko/Mozilla * Seed - binding for JSCore, part of Webkit/Apple Before attempting to list the different reasons for using one over the other we need to decide what are the requirements for an engine using JavaScript. For instance, points such as: - External dependencies - Interpretor implementation language - Memory usage - Speed - APIs (Extending & Embedding) - Documentation - License - Feature completeness - API stability (both in JS engine & bindings) - JavaScript language extensions Would be useful to help out in this discussion. [Note: I have contributed patches to Gjs] Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
