February 11, 2009

PyXPCOM vs. jsbridge

Yesterday Tempura left a good question as a comment on my blog post concerning Ubiquity’s experimental support for Python:

What about http://pyxpcomext.mozdev.org ? They bring Python in an xpi for all major plattforms, without the need of an local installed interpreter.

Using PyXPCOM was actually a potential option we had considered, but we ended up going with jsbridge for a number of reasons:

  • PyXPCOM uses XPCOM as its means of communication between Python and the Mozilla platform. Unfortunately, XPCOM is super heavyweight and it's a particularly difficult hurdle to get through when all you really want is for two very dynamic languages to communicate with each other. For instance, Ubiquity itself implements very few XPCOM interfaces, and most of its functionality is exposed through JS Modules; jsbridge allows us to access these JS Modules directly, while accessing them from PyXPCOM would require us to create verbose XPCOM wrappers around them—a particularly egregious amount of work when you think about how similar JavaScript and Python are.
  • One advantage of using the local system's Python installation is that we inherit whatever packages come with it, which means that on OS X 10.5, for instance, we automatically get access to Python's bindings to Objective C and Cocoa, whereas with PyXPCOM we really have to manage the user's distribution manually. It could similarly be said that PyXPCOM takes an embedding approach, while jsbridge takes an extending approach; a very good analysis between these two approaches has been written by Glyph Lefkowitz here.
  • In regards to Windows, putting a distribution of Python on the end-users system that any other application can leverage is a good thing—much better than requiring the user to download a big package and then only allowing Firefox to use it. This gets into the idea of Python as Platform that I've written about before.
  • In regards to OS X and Linux, using the pre-existing installation of Python is obviously nice because it doesn't require the end-user to download anything (aside from mozrunner and jsbridge, which are pretty small).
  • jsbridge has no binary components, which makes it a lot easier to maintain and experiment with than PyXPCOM, which is difficult to compile and extend.

PyXPCOM is definitely useful for a lot of things, though—for instance, manipulating the DOM of a page—so I think there’s still some things we can leverage there. And jsbridge certainly presents its own hurdles and limitations, too, but hopefully this post sheds some light on the thought processes that went into deciding which mechanism to use.

© Atul Varma 2017