Re: 3.2: gjs/seed

[Emmanuele Bassi <ebassi gmail com>]

hi Colin;

On 28 April 2011 23:38, Colin Walters <walters verbum org> wrote:
> On Wed, Apr 20, 2011 at 7:12 PM, Colin Walters <walters verbum org> wrote:
>>
>> == Dynamic Languages in GNOME ==
>>
>> One thing that's worth addressing though (again) is the question "do
>> we need both Python and JavaScript?".  The uptake of both seed and gjs
>> has been relatively low; lower than Python at least for scripting
>> GNOME apps.  However, I think at least one the core reason for working
>> on JavaScript remains that *we define the platform*.
>
> Actually I've been thinking about this more, and I am changing my
> mind; if we don't have an immediate plan for making JavaScript more
> compelling, and there's still active people maintaining Python, we
> should be advertising the latter, and not the former.
>
> So here's what I propose (and I'm willing to write patches, but mostly
> this is just marketing/messaging):
>
> * Officially mark both gjs and seed as experimental (this is the
> reality as it is for 3.0 anyways)
> * Drop all consumers of seed in GNOME 3.2; rewrite them (this is just
> gnome-games/lightsoff?) using C/Vala/gtkmm/Python
> * Remove /usr/bin/gjs
> * Keep gnome-shell on gjs (but switch to using Spidermonkey 1.8.5, and
> no - porting to Python would be a pointless waste of time at best)
>
> What does this mean about the JavaScript future?  My take here is that
> for 3.2 at least, we could move it more towards being an "embedding"
> language, designed from the very start to be used in a split C/JS
> role.  Also, this allows us flexibility to evolve JavaScript and
> return later with something more interesting.  For example, a combined
> WebKit-with-arbitrary-gnome-JavaScript that I've seen at least two
> different attempts at.
>
> Thoughts?

with all due respect, I think this is a knee-jerk reaction, and an
oversimplification of the issue.

both gjs and seed have been in some way marked as "experimental" de
facto, if not de jure: the fact that only gnome-games and shell have
been written using them is in no way a testament to the widespread
usage and adoption; quite the contrary. so, marking them both as
experimental would achieve nothing, and surely it wouldn't achieve the
goal of having a better support of JavaScript as a primary language
for Gnome applications.

I do agree that the situation is untenable: gjs is barely maintained,
with patches bitrotting in bugzilla (e.g. support for array
arguments); seed is a hodge-podge of web platform, unixy-platform and
gnome-platform, with questionable design choices for the advanced
features like sub-classing support, or missing features. setting them
both to be experimental bindings would not make them developed any
further - actually, it would probably be a surefire way to have them
both killed, with nothing to replace them.

part of the current situation is due to uncertainty: which one to
target when embedding, which one to contribute to, which one to use to
write apps. I think it has come time for the Gnome project to do what
we are generally afraid to do, and that is: pick one side and stick
with it.

in your original email you identified Seed as the potential candidate
because of the platform's general momentum towards WebKit and JSCore;
let's pick Seed - or, at least, let's pick a subset of Seed that makes
sense and remove the cruft, i.e. the unix-wrappers for the low-level
platform and the sub-classing; let's do some profiling on the
introspection-to-jscore layer to verify that there are no
performance/memory usage issues; let's make the syntax as close as
possible as the one in gjs for signal, property and boxed types
handling. then we can add back some form of sub-classing, and
eventually port gnome-shell to it.

in the meantime, for embedding, we should definitely go back to
alexl's idea of a GScript API in GIO, using extension points to avoid
linking to JSCore for every app.

I'm willing to help out in Seed and G-I to make this happen.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/