Re: 3.2: gjs/seed

While a little biased, I'd rather there was a plan to keep Javascript in Gnome front and center...

I did think the plan of Introspection was to be able to say to Gnome users, "You want to customise application X", pick _your_ favourite language, it's _your_ choice..., rather than getting into a 'this language is better...' story that tends to put people off. More of an Inclusive community concept I guess..

Seed on Gtk3 should be usable, Most of the issues I had with maintaining applications written using it are around the changing Gtk API and introspection changes, which I presume python & gjs all suffer from now. (It would be nice if introspection had a mailing list rather than IRC to follow and/or follow up discussions...)

From a maintenance / development point of view Seed is 'maintained' (eg. bug reports and patches tend to be responded to or applied), however there is little active development (fixing hard problems etc.).. Could have been a good SoC project..

Python is always going to be stronger as it has a longer history in gnome (unfortunately as some people like me really do not enjoy using it), It will also take a long time for JS to gain as much ground, and any sense that the door is closing is not really going to help.

I watched my son last night experimenting with Javascript on a web-page with chrome and komodo for his first programming, it was all javascript, as it's accessible on any platform. While some of us grew up with assembler and BBC basic, as that was all that was available, todays generation are more likely to have toyed with javascript first. These are hopefully the type of people that will eventually drive Gnome in the future and I'd be keen to see the barrier of entry kept as low as possible for them..

Anyway my 2c on that.


On 04/29/11 07:03, Emmanuele Bassi wrote:
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.

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]