The Future of Epiphany

Announcements 13 Comments

Attention! Ceci n’est pas un poisson d’avril!

Over the last few months, the Epiphany development team has been discussing the future of the Gnome web browser. We feel that we haven’t been living up to the full potential of a well-integrated Gnome application, due to both internal and external constraints.

The Epiphany user interface is built on top of an abstraction layer above the web rendering engine, enabling us to support multiple back-ends. Currently Epiphany supports the Mozilla browser engine (Gecko), and the WebKit engine.

The Epiphany dependency on Gecko creates a number of problems for us. The Gecko release cycle is very long (e.g. Gecko 1.8 was released with Firefox 1.5 in 2005; 1.8.1 with Firefox 2.0 in 2006 and 1.9 will be released sometime this year with Firefox 3.0), prone to delays and not synchronised with the unvarying 6-month Gnome release cycle. Furthermore, it and the feature work on Gecko are mostly driven by the Firefox browser, our main competitor on the Gnome desktop. Also the embedding API of Gecko (GtkMozEmbed) has been unmaintained and stagnant for a long time. Finally, the current plans for “Mozilla 2.0” bring much uncertainty to us, as well as much work to account for their proposed big API changes.

We are a small team, with only one maintainer and a hand-full of regular contributors. Maintaining the abstraction layer, and the Gecko back-end require lot of effort and time. Much time alone is spent on keeping up with Gecko API changes, and we have not had much contributions to the Gecko back-end in a long time.

Therefore we have decided to radically change the future of Epiphany in the upcoming 2.24 development cycle. We will drop the abstraction layer, making the code more maintainable, allowing faster development and enabling us to take advantage of the features of the back-end directly.

Furthermore, we will choose only one web engine back-end to support and concentrate our efforts on it instead of spreading our efforts to multiple back-ends and restricting us to the common features all back-ends support.

This single back-end will be WebKit.

We see several advantages in WebKit. These include:

  • The WebKit APIs. The API has been designed from the ground up, and feels like any other GObject based API. A two-way GObject bindings to the web page’s DOM, and to JavaScript is in development; this will allow us and our Extensions to access the DOM directly, which hasn’t been possible before in Epiphany in either C or Python.
  • WebKit uses Gnome technologies directly. Similarly to Gecko, it uses Cairo for graphics, and Pango for the rendering. On top of that, it uses libsoup for the network layer, and GStreamer for the <video> and <audio> tag support in HTML5.
  • Starting in time for Gnome 2.24, WebKit/GTK+ will implement a 6-month release cycle synchronised with the Gnome release schedule.
  • We feel that WebKit has the momentum, and can bring more developers to both Epiphany directly and the Gnome platform by extension. WebKit/GTK+ already has more people working on it than are working on either GtkMozEmbed or the Epiphany gecko back-end.
  • WebKit is a better match for other uses in Gnome, e.g. as a HTML widget in Yelp, in Devhelp, and as an editor in Evolution replacing GtkHTML.

We will propose WebKit as an approved external dependency for Gnome.

In case that we are unable to complete this development in time for 2.24.0, we will delay the new Epiphany to 2.26. For this end, we will maintain the gnome-2-22 branch in a state that allows us to potentially make the 2.24.0 release off of that branch.