Technology Lab —

Building desktop Linux applications with JavaScript

Ars takes a close look at Seed, a new framework that allows software …

Seed and Gjs

Gjs is another major implementation of a GObject bridge for JavaScript. It has a lot in common with Seed and aims to serve a similar purpose. Like Seed, it leverages GObject introspection for exposing native APIs and it is designed to be easily embedded in existing C applications. The primary difference between Seed and Gjs is the underlying JavaScript engine. Seed uses WebKit's JavaScriptCore whereas Gjs uses Mozilla's SpiderMonkey engine.

Seed and Gjs each offer a slightly different set of advantages and it isn't immediately clear which one will gain dominance. Seed currently has the upper hand in runtime performance and is also currently more complete, more thoroughly documented, and more accessible to third-party developers. WebKit is rapidly becoming the preferred solution for embedding HTML rendering in conventional desktop applications, so adopting JavaScriptCore for embedded scripting seems like a natural choice.

The most significant advantage of Gjs is that SpiderMonkey is on the cutting edge of the JavaScript standard and supports several very useful and important new JavaScript features that aren't yet included in WebKit's JavaScriptCore. Some examples are support for the "let" keyword, generators and iterators, and array comprehensions. These syntactic features simplify application development and make JavaScript more powerful.

Gjs is already being used extensively by Litl, a secretive startup that employs several prominent GNOME developers. Litl developer Havoc Pennington wrote a mailing list post stating that it would not be possible at this point for Litl to adopt Seed instead of Gjs, but he recommended several potential areas where the developers behind the two projects could collaborate to boost interoperability. These proposals were well-received and appear to have helped build consensus on several issues.

Carr has agreed to change Seed's enum format and import approach to make them consistent with Gjs. Carr says that there are ongoing discussions about how to bring the two into alignment in several other areas, including signal handling. The developers are also evaluating the possibility of moving the two projects into a single repository, collaborating on a shared test suite, and establishing a uniform embedding API for C applications. There is clearly some good progress being made on interoperability between the two solutions.

Conclusion

Seed and Gjs have the potential to bring a lot of value to the GNOME platform. The availability of a desktop-wide embeddable scripting language for application extension and plugin writing will enable users to add lots of rich new functionality to the environment. As this technology matures and it becomes more tightly integrated with other language frameworks such as Vala, it could change the way that GNOME programmers approach application development. JavaScript could be used as high-level glue for user interface manipulation and rapid prototyping while Vala or C are used for performance-sensitive tasks.