Re: New Module Proposal. libseed

[Owen Taylor <otaylor redhat com>]

I wanted to provide some gnome-shell perspective here.

In quick summary, we'd see including libseed in the GNOME-2.28 desktop
set as a positive step toward heavier use of Javascript in GNOME in the
future.

Porting gnome-shell to Seed would certainly not be a big deal; I would
sigh in regret over losing const and let and destructuring assignment
(most over the last), but in the end, they don't determine the overall
feel of programming with Javascript; or whether Javascript is a good or
bad idea.

(And conversely, if libseed didn't work out for some unforseeable
reason, we could easily port GNOME modules using it to gjs post 2.28,
with at most a week or two of feature work on gjs.)

Quick comparison from my perspective between the two sets of systems:

Spidermonkey: Mature, good API for extensibility. Nice language
   extensions. (JS 1.7.) Mostly packaged as part of xulrunner, which is 
   a problem. Maintained by an organization that has a thorough
   commitment to open source. (That doesn't mean that we have more
   influence over the direction, necessarily, but is worth noting.)

JavascriptCore: Newer, not used much outside of WebKit so far.

GJS: Fairly limited set of features, but those that are there are
   done well.

Seed: More features, common features are quite compatible with GJS. 
   I'm not delighted with how GObject subclassing was done, but if we
   have better proposals, we can certainly lobby and submit patches
   to change things :-)

(The big caveat from the above is that I haven't worked with Seed or
JavascriptCore at all.)

Speed comparisons just don't matter for anything we are doing, and it's
not going to be long-term accurate either; what's faster now may not be
faster in 6 months. I'm more concerned about garbage collection, but
honestly both of the engines have garbage collectors that are tuned for
web page usage and not for the desktop. From discussions with Rob
earlier, Spidermonkey may have a slight lead in flexibility in this
area.

The more important differences really are:

 - Alignment with HTML components in GNOME. The apparent trend towards
   WebKit in Epiphany, Yelp, etc certainly gives a strong impetus to
   going towards JavascriptCore and avoiding a Gecko dependency.

 - Activity of maintainership. Rob and Tim are appear committed to 
   libseed as a GNOME component and interested in it as a project
   in its own right. The people at litl have done a good job with
   gjs, but the work that they do on it is features that their code
   needs. The work that we've done it from the gnome-shell side 
   are features that gnome-shell needs.

Are we going to switch gnome-shell to libseed if it gets accepted as a
desktop module for 2.28. Not sure - it certainly would make it simpler
to compile gnome-shell as an add-on to a 2.28 distribution of GNOME. On
the other hand we're more comfortable with the gjs/SpiderMonkey codebase
at this point, and moving over might not be a good use of time.

- Owen

P.S. - Is compatibility with Javascript standards a concern? No. 
  Not at all. Javascript standardization is highly politicized and
  affected by concerns like what Microsoft can implement in IE and
  in general by considerations of cross-browser compatibility. We
  should use whatever dialect of Javascript is supported by our engine
  that makes our life better.