Re: 3.2: gjs/seed

[Juanjo Marin <juanjomarin96 yahoo es>]

On Thu, 2011-04-28 at 18:38 -0400, Colin Walters 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.
> 

I think that GNOME has the aspiration of being a multilanguage platform
since its conception. We should keep in mind that allowing access to C
objects from other languages was one of the major design goals.

The latest addition of Vala and Javascript to our language toolset is
very convenient because it makes easier to develop specifically for our
platform. However, we should keep working on making all our API is fully
accessible (GObject Introspection is big step in this direction) and
help programmers to use it right using other popular languages.

That said, I think Javascript and CSS-styling styling is very good move
because it gives the impression of adopting web standards in the
desktop.

Cheers,

  -- Juanjo Marin