The death of dwb

Back in 2013, I was a happy user of dwb, but it became apparent that the project would die at some point. It was clear that dwb would need to make the switch to WebKit2, but the author (portix) didn’t have the bandwidth to do so – as far as I remember, they said it’d basically be a full rewrite, and it’s not going to happen.

While dwb lived on for another 3 years or so, many dwb users – including me – were looking for alternatives. There were things like uzbl or luakit, and addons like Vimperator, but for some reason or another, those just didn’t fit the bill.

Back then, WebKit – especially WebKit 1, still used by most of those projects – was plagued by frequent hangs and crashes (and it being a single-process model, a renderer crash meant that your whole browser did go down with it).

A new browser on the horizon

I toyed with the idea of taking over dwb maintenance – however, it was a C/GTK codebase. While I was writing microcontroller firmware for a living in C for a couple of years, it always seemed an odd choice to me for more OOP-like GUI programming. With projects like Wireshark or LXDE wanting to switch to Qt at the time, it also became clear that GTK wasn’t what I wanted things to be based on. The only real alternative to build a web browser was Qt (Electron was only 5 months old!).

With plans about a new Chromium-based QtWebEngine already on the horizon, this seemed like a great choice. In terms of programming language, the choice was between Python and C++. C++ is the “native” Qt language, and Python bindings have been around since 1998 (!) and were maintained very well. Anything else was out of the question pretty much. Since I had some more Python knowledge than C++ knowledge, and C++ is… quite a beast, I decided to go with Python.

And thus, with thoughts along the lines of “eh, there are good libraries for it, how hard can it be?”, exactly 9 years ago today, I started qutebrowser.

It initially was focused on dwb “refugees”, and much of that is still visible today: The look of the UI, almost all keybindings, the split between book- and quickmarks (probably a bad idea), the idea of having external userscripts (probably a bad name), etc. etc. In other areas, qutebrowser most likely had a pioneering role: As far as I know, it was the first vim-like browser to introduce a more shell-like command interface, with things like :open -t or :open -w rather than separate :open, :winopen and :tabopen commands. Others like Tridactyl later followed suit.

Towards the first release, and then some more

It took a lot of work until, exactly a year later, v0.1 was finally released. Later, Vimperator died with Firefox dropping XUL extensions, and between 2014 and 2019 or so, more and more people switched to qutebrowser (up to around 10% of all Archlinux users participating in package statistics).

More recently, I was able to work on qutebrowser during my study summer break in 2016, again in 2018, and finally for a longer time as a part-time job since 2019. I’m humbled by all the support, it’s what still keeps me going – it’s fair to say that I probably would have burned out and/or stopped by now if I was employed 100% still. Turns out, after all, a web browser isn’t exactly an easy thing to do as your first big open source project. Big kudos to all the other projects which have been going for years if not decades: It’s not easy, and the occasional entitled user who’s pushy or angry at you for their favourite feature™ still not being implemented certainly does not help. Thankfully, those cases are rare: All in all, I’m thankful for the qutebrowser community being so understanding, patient and helpful! <3

Another big transition

It’s probably fair to say that dwb died during the transition from WebKit 1 to 2. Such major upgrades – while often reasonable and needed – tend to use a lot of energy and effort.

In 2016, qutebrowser had its own first big migration, when QtWebEngine finally was ready enough to add support for it. Nowadays, QtWebKit is still supported, though mostly for historical reasons. Chances are big it will be all gone for the v3.0.0 release.

Nowadays, qutebrowser is in a somewhat similar big transition again: It desperately needs to migrate to Qt 6 to keep things up to date, but – while not quite a rewrite – doing so is a bunch of work. With qutebrowser getting older, more popular, and also getting lots and lots more contributions (often in slighly chaotic ways, as things go with open source), this transition is probably the most challenging of them all yet! There are many more things to take into consideration than there have been six years ago. Still, much of it has been going on ever since Qt 6.2 with QtWebEngine was released in September 2021, with a branch with almost 300 commits being nearly finished. If you haven’t yet, you should probably give it a try!

Looking forward towards qutebrowser v3

There are still some challenges to overcome on the development side of things, and some other stuff I’d like to at least look at for the v3.0.0 release. Last year, my job situation changed as well: Instead of being employed 40% over the entire year (often taking a lot more energy and mind-space than those 40%), I’m now busy teaching between September and February. On the flip-side of the coin, that means I don’t have anything other than open source (qutebrowser, pytest, and the occasional paid pytest company training) to worry about between March and August. Last year has shown that this works out much better, especially for big chunks of work like this.

Even though things are still very busy dayjob-wise now (and will be until March), I’m hoping we can still work on some of the remaining Qt 6 blockers, and then I’m hoping to still be able to finish v3.0 early next year. Thanks also to everyone who keeps the ball rolling while I might be busy with other stuff for a while – especially @toofar, who has been doing amazing and steady work over the last couple of years!

Onwards, and already looking forward to qutebrowser being a decade old in late 2023!