3.2: gjs/seed

[Colin Walters <walters verbum org>]

Hi,

So speaking as someone who was motivated to make writing GNOME apps
easier, I'm not very happy with how things turned out with the mix of
gjs/seed/python/introspection/gtk3.

In this mail I just want to focus on the gjs/seed situation.  Before
3.0 we chose to use gjs for gnome-shell for a variety of reasons:

1) gjs existed
2) seed didn't
3) Litl contributed a number of engineers to gjs
4) While I know some GNOME contributors here don't like Mozilla, in
the big picture their mission and culture is *MUCH* more aligned with
ours than Apple, at least
5) The Spidermonkey-specific JavaScript extensions like "const" and
"let" were useful and cool
6) Many GNOME consumers actually ship Firefox and not Epiphany, and so
we were technically aligned on that end (yes, this is the "GNOME is a
bucket of parts" mindset, which I would really like to fix, but that's
a separate issue)

But let me cut to the chase and say that I think we'd at least
consider realigning on seed for 3.2 for gnome-shell (and by extension,
mark gjs as deprecated at least in GNOME).

There are, however, nontrivial issues.  First is that actually in good
news on the gjs front, a standalone Spidermonkey release was just made
recently, and I have a patch ready to use it in gjs:
https://bugzilla.gnome.org/show_bug.cgi?id=646369
In contrast though, /usr/bin/seed appears to actually link to WebKit,
which would be a painful dependency to have for gnome-shell, since
it'd be insane to try using it inside the compositor process.  This
may (hopefully) be fixable.

Even tougher would be unwinding the Spidermonkey let/const and
generator usage inside gnome-shell, but we dug the hole, we can dig it
out.

That covers reasons 1,2 and 5.  As far as reason 3), they're not as
active anymore (probably gjs basically works for them), and for 6) I
think we need to change this anyways.  This leaves reason 4) which I
admit is just a feeling.

So - seed/gjs contributors - what do you think?

One thing I'm not totally happy with is the organic growth in API in
both seed and gjs.  seed for example added an "os" module with e.g.
"fork" which I think is totally wrong; it's just broken to fork() a
GNOME app, since it conflicts with threads, etc.  If we're going to do
some unification, we should also prune a lot of cruft.  If there are
bits missing from GNOME (like GIO is really missing both Console and
Process classes), we need to add them.

== 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*.  Python comes
with a vast API, a lot of it really old and crufty, but even more
importantly, large parts of it are *wrong* to use in GNOME.

For example, we don't want people to use Python's mostly-POSIX-like
wrappers for IO, we want people to use GIO, so it doesn't block the
mainloop.  We don't want people to use Python's "webbrowser" module,
its "multiprocessing" module (which totally breaks things like X and
DBus since it uses a bare fork()), etc.

On the other side of the coin though, I think we largely failed to
make JavaScript a compelling way to write apps.  The language is only
a part of the question, and it's really not a large one.  We need to
focus more on a build/deploy story, and less on /usr/bin/gjs.  By
"build" I mean we really shouldn't be leaving it up to app authors to
figure out how to use Automake with gjs/seed and to do
"imports.gi.Gtk".  Deploy is another story.

The other reasons:
  * ecosystem: The industry adoption is reflected in all the work that
goes into JIT compilers, as well as people simply learning the
language
  * Better engine internals - the global interpreter lock in cPython
really hurts it as far as a future in a multicore world

(No, unlike what you've read in some parts of the internets, a reason
to add JavaScript wasn't to attract "web developers" explicitly; but
they are part of the industry)