Re: New Module Proposal. libseed

[Robert Carr <carrr rpi edu>]

On Tue, May 12, 2009 at 7:35 PM, Hubert Figuiere <hub figuiere net> wrote:
>
>> In the prior discussion, there was a lot of discussion as to GJS v. Seed.
>>  Since then, compatibility between the two has improved a lot, notably
>> with Seed adopting GJS's imports system.
>> At this point, most GJS code could be pretty easily ported to Seed.
>> Porting Seed code
>> to GJS might be a bit more difficult, due to some things like Seed
>> making pervasive use of GObject.
>> It is more or less possible to write code to a "least common
>> denominator" of the two.
>> In addition I believe it would be possible to port GNOME Shell to
>> Seed, with no more than a few days work.
>
> So in the botton line, what make Seed more suitable than gjs? Does that mean
> there is a committment to only use the selected JS engine for modules in
> GNOME?
>
>
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.

As to why I think Seed has a purpose or suitability, with GJS existing:

- WebKit. There's a general push towards using WebKit in GNOME as
opposed to Gecko, and using WebKit for everything except a JavaScript
interpreter would seem a little wasteful. In addition things like
epiphany-webkit, can't really use SpiderMonkey for extensions.
JavaScriptCore also tends to be faster, while SpiderMonkey tends to
support more language extensions.
- Seed has a lot more example code available, and a lot more documentation also.
-  Seed supports GObject subclassing (and new signals, etc...) in
additional to standard prototypal inheritance, this is more of a
design decision, which could be debated, but it's something I'm fond
of. Once some bugs in introspection are sorted out, it will support
implementing abstract methods immediately, which I think is rather
important.
- I think the Seed C API (which is mostly a glib looking wrapper
around the JSCore API) is a lot more intuitive than the SpiderMonkey
API, and definitely much more in line with GNOME conventions.
- Seed has a few interesting C extension modules (like a
reimplementation of python's OS module, an HTML canvas context backed
by cairo contexts, libxml bindings, a javascript sandbox...). To be
fair GJS also has more complete DBus bindings.
- In the past, Seed has had more sort of "corner cases" with weird
things that pop up in libraries working. I haven't done a detailed
comparison v. gjs recently, so I don't want to put too much weight
behind this statement.