You are viewing np237

01 April 2011 @ 12:48 am
News@11: Mozilla gives the finger to embedders  

There have been a lot of web browsers embedding the Gecko engine, especially through the gtkmozembed “library” (it was not really a proper library but let’s call it like that). I remember being a happy user of galeon, which went on as epiphany, but there were also all these small applications that just need a good HTML renderer in one of their widgets, like yelp, or several Python applications using python-gtkmozembed.

Anyone having had to deal with these applications, especially the most complex ones, could tell you a few things:

  • the Mozilla developers never gave a friggin’ damn about embedding;
  • they don’t know how to develop an easily embeddable library;
  • the notion of a stable interface is a very arcane concept that they don’t wish to grasp.

So, today, it is official: Mozilla is dropping gtkmozembed from their codebase.

I don’t think this will come as a surprise to anyone. You can’t develop a new version of a behemoth, monolithic application every 3 months while still caring about the interfaces underneath. Embedded applications have been migrating to webkit over the recent years, and those that don’t do it really soon will die.

The interesting part of the announcement is not here. It can be found hidden in a bug report: a stable and versioned libmozjs will just never happen.

What does it mean?

First of all, it means that Debian and Ubuntu will have to go on maintaining their own versioning of libmozjs so that it can be linked to in a decent way by applications using the SpiderMonkey JS engine. It also means that this version will have to be bumped more often.

But it also puts into question the whole future of SpiderMonkey as a separate library. With a shortened release cycle, the Mozilla developers will be tempted to add more specific interfaces to SpiderMonkey, reducing its genericity in favor of its use in Firefox itself. This will produce less and less useful libmozjs versions, until we reach the point when they’ll make the same announcement as above, with s/gtkmozembed/libmozjs/.

This is especially relevant in the context of the GNOME Shell, which is at the core of the GNOME 3 experience. The developers deliberately chose to avoid using JavaScriptCore (the JS library inside webkit) through the Seed engine, and used GJS instead, that relies on libmozjs. In my opinion this was done for frivolous reasons (being able to use more language extensions); and not only this put the GNOME developers in an awkward situation where 2 JS interpreters compete in the same desktop, but now it puts a risk on a technology which is at the core of the desktop.

One of the reasons for the limited adoption of JSCore is that it lies currently in the same library as Webkit, which is a huge dependency. I’ve been very glad to learn that Gustavo is considering the idea of splitting it. We need to provide an escape route for applications using libmozjs, and it looks like more than a decent one. I hope that GNOME Shell follows it sooner than later.

Dr. C. Scott Ananiancananian on March 31st, 2011 09:10 pm (UTC)
The moz JavaScript language extensions are hardly "frivolous", if you've ever had to write/maintain a large javascript application. MozJS is also much easier to embed/extend than v8, AFAIK.

I don't see what the worry is -- if we need to, we can fork mozjs. It's not worth rewriting all the JavaScript code into v8's neutered version, especially since Google has no intention of being on the front lines of JavaScript language development. 'yield' is not an "optional" language feature for asynchronous GUI implementation.
(Frozen)(Thread) (Link)
Dr. C. Scott Ananiancananian on March 31st, 2011 09:14 pm (UTC)
Further, the bug you're complaining about was closed because solves the problem entirely in a different/better way. So fear not, the sky is not falling.
(Frozen)(Parent) (Thread) (Link)
(Anonymous) on March 31st, 2011 10:09 pm (UTC)
"if you've ever had to write/maintain a large javascript application"

Then you are doomed anyway. JavaScript code is totally unmanageable. There is just no sanity in this language, how can you expect to remain sain maintaining a large application in it?

In Dojo you still find code that does array shifting to compute modulo-7... Code quality is pretty close to 0.
(Frozen)(Parent) (Thread) (Link)
(Anonymous) on March 31st, 2011 10:44 pm (UTC)
Re: Javascript
I've actually writing quite large applications in JavaScript. It's actually quite a nice language. Just don't use the hairy corners. There are hairy corners in C/C++/Python as well you are advised to avoid. More details in
(Frozen)(Parent) (Thread) (Link)
(Anonymous) on March 31st, 2011 11:40 pm (UTC)
Re: Javascript
JavaScript code is totally unmanageable. There is just no sanity in this language, how can you expect to remain sain maintaining a large application in it?

Have you tried it? It's a much better language than most people give credit for. It has a bad reputation from the abuses of the past and poor cross-browser compatibility, but for an app running on node.js or something like Seed, or a web-app targeting only modern browsers, it's actually pretty good.

As for calculating modulo-7, don't know why Dojo did it that way, but running "x % 7" works fine for me...
(Frozen)(Parent) (Thread) (Link)
(Anonymous) on March 31st, 2011 10:01 pm (UTC)
Or you can switch to QtScript ()?
(Frozen)(Thread) (Link)
Ian Monroeeeanm on April 1st, 2011 12:54 pm (UTC)
Re: Alternative
Which actually uses the webkit JS implementation for a couple versions now.

So I guess a better sarcastic suggestion is that they use KJS.
(Frozen)(Parent) (Thread) (Link)
(Anonymous) on March 31st, 2011 10:05 pm (UTC)
So what
So just let it die. They never really cared about Linux desktop integration either IMHO.

Also, JavaScript is one of the ugliest languages around anyway. Why encourage anyone to use it if there are sane alternatives? IMHO, gnome-shell should just be rewritten in one of the other languages that are already in use in GNOME. What exactly is the benefit of adding JavaScript?
(Frozen)(Thread) (Link)
Dr. C. Scott Ananiancananian on March 31st, 2011 10:45 pm (UTC)
Re: So what
It's a bazillion times faster than Python, that's what. Don't knock what you don't understand.
(Frozen)(Parent) (Thread) (Link)
np237np237 on April 1st, 2011 03:13 am (UTC)
Re: So what
And how many times slower than C# ?
(Frozen)(Parent) (Thread) (Link)
Dr. C. Scott Ananiancananian on April 1st, 2011 03:38 am (UTC)
Re: So what
It's faster, if you're talking about the time required to write and debug it.
(Frozen)(Parent) (Thread) (Link)
np237np237 on April 1st, 2011 03:39 am (UTC)
Re: So what
It’s interesting how you skew the arguments in the direction that suit you. Python would be faster to write, but you prefer JS since it’s faster to run. And C# would be faster to run, but you prefer JS since it’s faster to write (and I’m not entirely convinced by that last argument).
(Frozen)(Parent) (Thread) (Link)
(Anonymous) on April 1st, 2011 05:12 am (UTC)
Re: So what
So maybe Javascript is the right balance between execution speed and development speed for them ?
(Frozen)(Parent) (Thread) (Link)
(Anonymous) on April 1st, 2011 07:21 am (UTC)
Re: So what
JS's such a good development language that google dropped it in javor of java for its web development toolkit (gwt).

js may be fast to write, but it’s incredibly hard and slow to debug.
(Frozen)(Parent) (Thread) (Link)
(Anonymous) on March 31st, 2011 11:13 pm (UTC)
(Frozen)(Thread) (Link)
(Anonymous) on April 1st, 2011 04:09 am (UTC)
Re: *ehm*
Something without even a description of what it is gets infinity points of fail.
(Frozen)(Parent) (Thread) (Link)
(Anonymous) on March 31st, 2011 11:14 pm (UTC)
I think the issue isn't that there's actual opposition to gtkmozembed, just a lack of interest in maintaining it in the face of architectural changes being made within the codebase it wraps. Afterall, it's a set of bindings not used at all by Mozilla themselves, and used only by a fairly small number of external applications - many of which have already migrated to Webkit, since it's better designed for embedding.

Also note that gtkmozembed isn't the same thing as libmozjs. I agree that basing Gnome3 on Webkit would have been a better idea given it's use elsewhere in the project (Seed, Yelp, Epiphany, etc), but even unversioned, it's at least a public library and used by core Mozilla code (unlike gtkmozembed).
(Frozen)(Thread) (Link)
(Anonymous) on April 1st, 2011 07:56 am (UTC)
Bad choice
I wish they would have used Guile 2 rather than their JS crap. :( It even supports JS.
(Frozen)(Thread) (Link)
np237np237 on April 1st, 2011 09:22 am (UTC)
Re: Bad choice
Yay, back to the sawfish times \o/

Do you have any other useless ideas?
(Frozen)(Parent) (Thread) (Link)
(Anonymous) on April 1st, 2011 02:51 pm (UTC)
Re: Bad choice
Useless ideas like building, say, a desktop system with JavaScript?

Around a library that was never actually supported anyway, no less?

JavaScript in Gnome is a stupid idea. Period. It was supposed to attract web developers to the desktop experience, right? How many of those actually got interested?

How many of those got told on IRC they weren't running the right distribution to participate in development? How many are actually participating?

It was a stupid, ill-thought-out idea that will make the ORBit/Bonobo fiasco look small by comparison.

Ah, and BTW, Sawfish works on my hardware. Gnome-Shell, not so. That's all of Gnome giving me the finger. Talk about useless ideas.
(Frozen)(Parent) (Thread) (Link)
(Anonymous) on April 8th, 2011 03:32 pm (UTC)
Re: Bad choice
Seconded. Gnome-shell just does NOT REASONABLY WORK ON MY HARDWARE. Nor does metacity with compositing turned on, btw.
Some of the older intel graphics chips just suck with OpenGL. I'm sticking to openbox and giving the gnome-shell desktop effects the finger.
(Frozen)(Parent) (Thread) (Link)
(Anonymous) on April 1st, 2011 05:14 pm (UTC)
You're misreading the bombshell you say is "hidden in a bug report"
You link to comment 42 in the SpiderMonkey bug but seem to have misconstrued comment 38 to which it referred. The strategy proposed in comment 38 is to make SpiderMonkey releases when Firefox releases happen: a SpiderMonkey release would basically be the code from the Firefox release. This is now feasible because Firefox is now releasing every three months -- no need to wait an unknown amount of time for a release. This means we need not keep in mind extra technical details to support SpiderMonkey releases in addition to Firefox releases. (If you think it's not that hard to keep in mind the technical details and differences for Firefox releases and for SpiderMonkey releases happening at different times, I submit that you haven't worked on something as complex as a JavaScript engine, and you haven't had to support frequently-changing code over long periods of time as invariants change, sometimes dramatically, from release to release.) The reason for that bug being dropped isn't that the idea is dead -- it's that it's being addressed another way. This is absolutely not the same as dropping support for JS embedding -- exactly the opposite.

You also seem to have missed comment 41, which discusses plans to make a SpiderMonkey release based on the code in Firefox 4, in bug 628723 ( That release occurred last night! Future releases will only get easier as this process is streamlined. If you read that bug, you'll see SuSE, Fedora, and Debian developers are all actively involved in the discussion. I reiterate: this is not abandonment!

With a shortened release cycle, the Mozilla developers will be tempted to add more specific interfaces to SpiderMonkey, reducing its genericity in favor of its use in Firefox itself.

It is true that this temptation exists in theory. But I think you misunderstand just how strong this temptation is in practice. We actively work to remove Firefox-specificity in SpiderMonkey whenever possible. Such specificity has costs (think compilation time costs, from SpiderMonkey-internal headers being overused, such that minor internal changes disproportionately increase overall compile time). When there's a generalized need for a hack, we don't add an internal-ish API for Firefox to use: we add a public, supported API for it. Do you have examples of cases where we added internal API for Firefox, rather than adding public API, when specific embedders would have used that functionality if it had been public?

This will produce less and less useful libmozjs versions, until we reach the point when they’ll make the same announcement as above, with s/gtkmozembed/libmozjs/.

Um, no. From my point of view SpiderMonkey has a much more active embedding community than gtkmozembed ever did. We frequently get questions in js-engine newsgroup about embedding, and we have at least half a dozen embedders regularly active in the #jsapi IRC channel on The calculus for gtkmozembed (that most users were switching to webkit) doesn't apply to SpiderMonkey.

Mozilla doesn't have a great history of designing good APIs, it's true. And I would argue the current SpiderMonkey API is baroque and in need of complete redesign. But I absolutely think we "[grasp] the notion of a stable interface". It's just we don't do a great job of executing it (often creating footguns for ourselves in the process -- riddle me this, does WebKit have a stable API? or did webkit-gtk merely create its own gtkmozembed-alike [albeit one much more cleanly executed]?), and -- yes -- Mozilla's institutional tendency is not to prioritize the creation of well-designed stable interfaces.

But to return to, and sum up, the main point: SpiderMonkey as a standalone source release is not going away. I would appreciate if you updated the original post to reflect this, and perhaps made a new post to highlight this fact for people who might have inherited the misunderstanding from you.

Jeff Walden (regular SpiderMonkey hacker, also long-time Fedora user for what it's worth)
(Frozen)(Thread) (Link)