Uzbl: a browser following the UNIX philosophy

Over time, a great deal of functionality has been added to web browsers—extensions, download managers, PDF handling, and the like. This has caused some to become dissatisfied, fondly remembering when a browser was just a browser. Over the last few months, a new project, Uzbl (pronounced "usable"), has come along to create a browser that follows the UNIX philosophy: "Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface." The result is a refreshingly different browser, which has a minimal graphical interface, has minimal functionality and is controllable through external shell scripts with customizable key bindings.

Uzbl was born during a discussion about browsers in the Arch Linux user forum. At one point Dieter Plaetinck, a Belgian software developer and Arch Linux release engineer, voiced his opinion in the discussion:

Other participants were excited by the idea and asked if he was really planning to write such a program. After an initial hesitation ("Maybe, if I find the time") and a promising experiment ("well I have been playing a bit with gtk and webkit. you may see some code online soon.. or maybe not"), Plaetinck released the first code on April 21.

In the next couple of days, other Arch Linux users jumped on the bandwagon. They were all dissatisfied with current web browsers, because these are frequent violators of the Unix philosophy. Browsers integrate too many things such as management tools for bookmarks, history and downloads, decreasing the options for the user to handle them the way they want. Current browsers also store data in too-fancy file formats, such as XML, RDF and SQLite, making the data hard to reuse in other scripts. Plaetinck and his Arch fellows decided to change this, and he explains in the FAQ why he invented another browser:

Uzbl follows the UNIX philosophy in the following aspects:

• It has a minimal graphical interface. Users only see what they need: the webpage and little else.
• It has minimal functionality. Tasks that are not central to browsing are not in Uzbl. The user has to handle things like bookmarks, URI changing, history, downloads, etc. through external shell scripts.
• It is controllable through various means: the keyboard, stdin, pipes and socket files, etc.
• It has a highly customizable keyboard-centric input with support for modes, modkeys, variables and the like. As a consequence, the interface can be tweaked to be vim-like, emacs-like or any other scheme the user wishes.
• All data and configuration files are written in plain text.

Uzbl uses WebKit as the browser engine. This means that the user doesn't have to worry about Flash, JavaScript and all modern web standards: WebKit takes care of all this support (including Flash if the user has installed a Flash plugin such as Gnash or Adobe's) and even has a 100/100 score on the Acid3 test page.

Applications that follow the UNIX philosophy may require a fair amount of configuration in order to get them to a usable state; a large amount of that will impact the application's adoption. Your author installed Uzbl to put this to the test. There is no official release yet, but an alpha version can be downloaded for many distributions, and Arch Linux (which is the main development platform for Uzbl) has a PKGBUILD file. The adventurous user can pull the code from git and build Uzbl from source.

A freshly installed Uzbl includes fairly limited settings and is actually rather unusable. There is no status bar, the program has no key bindings, no handlers for the history or downloads, no buttons for navigation, and so on. The user can't even type anything into forms. However, there's a much more usable configuration file in the examples directory. Copy it to $XDG_CONFIG_HOME/uzbl/config (which expands to ~/.config/uzbl on most systems) and start Uzbl again, after which it really becomes usable, with a status bar and vim-like key bindings. Just as in vim, the user starts in command mode. Typing 'b' goes back, 'ZZ' quits the browser, etc. Typing something in a form can be done by first switching to insert mode ('i').

This UNIX-like rethinking of the interface has another strange consequence: Uzbl doesn't have the concept of a location bar. All changes to the currently loaded URI happen outside of the browser. So the user can't edit the current URI, can't load a URI from bookmarks, and so on. Uzbl comes with some example scripts that use dmenu to pick a URI from a history or bookmarks file. Just copy the scripts subdirectory in the examples directory to ~/.config/uzbl and read the example config file for the key bindings to activate the scripts. Users are even able to bind JavaScript code to a key.

While all other mainstream browsers support tabs, Uzbl doesn't like the concept and sticks to the "one page per instance" principle. Each instance of Uzbl is in essence just a small wrapper around WebKit. Although this will be a showstopper for a lot of people, there is some truth in the philosophy that multiple instances should be handled outside of the browser. In their FAQ, the developers point out that tabbing is something that can be handled by many window managers, such as xmonad and wmii. Another solution is to embed Uzbl instances in other Gtk applications, something that uzbl_tabbed.py has done, a Python script that made it into the example scripts of Uzbl. But the fact that Uzbl is focused on one page per instance means that everyone can write their own custom script for multiple instances management.

An active community

Although Uzbl is only a couple of months old, it already has a fairly active community, with a mailing list and an IRC channel (#uzbl on the Freenode network). The website also has a lot of information for users or developers that want to contribute. The wiki has a lot of community-provided information, such as configuration files, scripts for various tasks and screenshots. Browsing through all this, it becomes clear how powerful the UNIX philosophy is for a browser. For example, writing a script to send a link of the current web page to Twitter or to bookmark it to Delicious is dead simple.

According to Plaetinck, the project has 6 main developers and 28 contributors. Most of the contributors work on the core, programming in C. Surprisingly, Plaetinck himself is not that much of a coder:

There were lots of contributions right from the start. In April there were 28 commits per day, and every evening when Plaetinck came home from work he did nothing but merge code. The project also seems to attract a diverse group of people:

As interesting as the project may be, there are still some issues, and these are grave enough that Plaetinck doesn't eat his own dog food yet:

In the longer term, the Uzbl developers have a lot of plans:

Plaetinck says he also wants, in the long term, to split the browser into a rendering component and an interface component to help reusability. The key bindings should be improved too: at the moment users cannot bind the arrow keys, function keys, caps lock or mouse buttons.

For whom is Uzbl usable?

For users who find themselves regularly trying to optimize their "digital workspace", Uzbl is definitely a browser to consider, as Plaetinck explains: "I noticed that the best tools to solve my problems are the ones who are merely building blocks that allow me to implement my own methods." After swapping out bloated programs and replacing them by elegant, more UNIX-like programs, Plaetinck found out that pretty much all software for guys like him was out there: window managers like dwm and wmii of the suckless project, editors such as Vim, program launchers such as Bashrun, media players such as MPlayer and MPD, mail clients such as Mutt or Claws Mail, and so on. But until now, there was no web browser in the same spirit. Even "lightweight" browsers such as Midori or Lynx still do too much themselves and don't integrate well with their environment.

Your author is sympathetic to the idea of a browser following the UNIX philosophy, although that may be swimming against the stream. The core is simple and much less crash-prone than a complex browser with all kinds of management tools. And the developers are right to aim for a clean browser with all management tools outside. This makes it possible to adapt the browser to your own workflow and get a significant efficiency boost.

The end result is a lot more "usable" browsing experience. However, this comes with a significant price: a lot of custom scripting. This suggests that Uzbl will only appeal to people who have a very specific workflow, who are not satisfied with the behavior of current browsers, who like to memorize key bindings and who are not afraid of spending hours configuring their browser. Uzbl users should be confident to work with tools such as grep, awk, dmenu, zenity, wget and gnupg to build their own browser behavior. Users who want a browser that does everything and does it out-of-the-box, or who are addicted to a lot of Firefox extensions, will not like Uzbl. But then, looking at the speed of development of Uzbl (it's not even three months old), your author wouldn't be surprised if in one year the browser has an extensive set of helper scripts that can do many of the tasks that Firefox extensions do.