Re: JavaScript engines

["Havoc Pennington" <havoc pennington gmail com>]

Hi,

On Tue, Jan 6, 2009 at 2:07 PM, Jason D. Clinton <me jasonclinton com> wrote:
> On Tue, Jan 6, 2009 at 12:26 PM, Alexander Larsson <alexl redhat com> 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