Havoc's Blog

Chris mentions
JavaScript embedding using SpiderMonkey.

When GNOME first started out, there was much talk of using Guile as an
embedded language. The concept was similar to the architecture of
Emacs, Firefox, or all the
games using Lua (such as World of Warcraft).

I would define an “embedded” language as one that doesn’t come
with a platform. It’s small and easy to glue together with an app
written in C or C++. It uses the same platform as the app. If the
platform has an introspection capability like XPCOM or
GObject-Introspection, then the platform can be exported to the
embedded language in an automated way.

At some point, and I was one of the people to blame for this, we
changed the focus of the Linux language discussion to grand unified
schemes involving component technologies and virtual machines. The
result is that too much desktop stuff is still written in C.

A “C/C++ core plus embeddable language” architecture for an
application has many pragmatic advantages.

• Higher layers of code such as UI code are so much easier in a
  dynamic “scripting” language.
• Proven to be practical and scalable for huge apps such as Firefox and
  World of Warcraft, even with dead-simple languages such as JavaScript
  and Lua.
• No platform silos. In a GNOME app, the embeddable language uses
  GIO, GTK+, GStreamer, Clutter, or whatever you are using – it does not
  have its own http stack and everything else.
• You can choose to write each part of the app in the easiest language;
  some stuff is easier in C/C++.
• Sandboxable / well-modularized. The interpreter is generally an object
  that can be destroyed; no heavy language runtime or VM takes over the
  entire app.
• Embeddable languages don’t seem to create a huge jump in memory
  footprint, for whatever reason, so they are still sensible for
  “swarm of many processes” environments like GNOME and KDE that
  multiply any per-process overhead by a significant factor.

(There are advantages to the heavier full-platform languages also, but
I’m guessing everyone knows them already so I won’t make a list.)

JavaScript is a great choice for an embedded language. I did not
realize at first that SpiderMonkey has no dependencies; it is not tied
up with the rest of the Mozilla platform (XPCOM, etc.), it’s completely
standalone. And most programmers understand at least some JavaScript
already.

There are some problems right now, for example there’s no standard
packaging and .pc file for jsapi.h/libmozjs.so, so it’s hard to make
an app build on multiple distributions unless you suck in an internal
copy of the library.

It’s necessary to add a couple things to JavaScript before it’s
truly usable; most notably, some kind of module system. I’m not sure
SpiderMonkey itself should have that though – it starts to
define a platform and make the language “not embedded”. Maybe modules
are introduced by higher layers (in fact xulrunner adds
a
module system if you use the whole xulrunner platform).

I don’t mean this as a SpiderMonkey advocacy post, though we’re using
it successfully at work. Other options are the WebKit JavaScript
engine, Guile, Lua, Tcl, etc.

My main point: the “C/C++ core plus embedded scripting” architecture
is a very smart way to write an app, and doesn’t have some of the real
downsides of heavier platforms.

(This post was originally found at http://log.ometer.com/2008-08.html#25)