Browser

Try the uzbl browser if you're tired of feature bloat

Is there a browser for users who dislike the monolithic bloat of the most popular Web browsers, but want more than the console-based minimalism of Lynx and W3m?
uzbl browser screenshot thumbnail

Seven years ago, many computer users found a new Web browser that was a breath of fresh air after dealing with the long-term feature creep, security problems, and unreliability of Microsoft Internet Explorer. Originally called Phoenix, and then Firebird, before finally being renamed Firefox, these days, it has bloated up almost as much as Internet Explorer.

2008 saw the release of the Chromium browser, and users who had begun to get fed up with the growth of Firefox found it to be something of a relief, with a snappier feel to its interface, a cleaner look, and a multiprocess architecture that offers greater stability and security for the entire application. Even so, it is a bit more in size and weight for an applicaation than some would like.

21 April 2009 marked the first commit in the GitHub project for a browser called uzbl -- lolcat spelling for "usable" -- though the uzbl website's first news item dates to almost a month earlier. Uzbl is a browser that diverges significantly from the design philosophy of other browsers like Chromium, Firefox, Internet Explorer, Opera, and Safari. In the words of the README file at uzbl's GitHub repository:

Any program can only be really useful if it complies with the Unix

philosophy. Web browsers (and other tools that work with HTML, such

as feed readers) are frequent violators of this principle:

* They build in way too much things into one (complex) program,

dramatically decreasing the options to do things the way you want.

* They store things in way too fancy formats (XML, RDF, SQLite,

etc.) which are hard to store under version control, reuse in

other scripts, and so on.

The Uzbl project was started as an attempt to resolve this.

It is something of an acquired taste, and its licensing (GPLv3) certainly leaves something to be desired, but the general development philosophy has some teeth to it. It will likely appeal to Chromium and Firefox users most if they are the sort to like the Vimium and Vimperator extensions, respectively -- ways to give each browser a somewhat vi-like keyboard driven interface.

Uzbl is an application, built with the C programming language on the WebKit rendering engine and basic Web browser development tools. The core application does little more than give WebKit a canvas on which to paint a page. Additional capabilities are provided by additional, separate programs, most of which are Python scripts. One script that is included in the standard distribution of it is called uzbl-browser, and it ties some tools together to provide a more complete browser experience. Another, called uzbl-tabbed, uses Python bindings for GTK+ to offer a tabbed version of a uzbl browser.

Each of these really is usable, as the name advertises, surprisingly so, really. The uzbl-browser and uzbl-tabbed versions are pretty much entirely keyboard-driven, with a somewhat vi-like set of default keybindings.

They all lack certain capabilities to which users have become accustomed, but for the most part the major options are there, including support for a Flash plugin. If you are put off by the relative lack of extension options for Chromium as compared with those of Firefox, uzbl will surely disappoint you even more; if you take a lack of functionality extension as an opportunity to create your own, however, uzbl may well be exactly what you need. If you are a mediocre programmer who would like to get better, its highly extensible design based on the Unix philosophy can offer a lot of opportunity to practice and insight into how to develop software to be small, and to work well with other software.

Eventually, you might even get to the point where you can create your own really Unixy, small, highly extensible browser with much the same design philosophy. Maybe you will find some way to redefine some other application that has traditionally become a bloated, unreliable, overly complex monstrosity on your own terms, and make it small and beautiful. I dare to hope that in either case, you would choose a better open source license, too -- something as small, simple, and elegant as the application itself.

Maybe you will just use it, though. Maybe you will never look at the source code. Users are every bit as important as developers, in the final analysis.

Give it a shot. Talk to its community in the #uzbl channel on the freenode IRC network if you need some help getting started. See if you like it. If not, go back to a big, sophisticated browser, if that is what you prefer. To tell you the truth, I am actually using Chromium, Firefox, and uzbl about equally right now, switching between them; I have not entirely given up on those big and sophisticated browsers myself, at least so far. I think you owe it to yourself to see if you like your browser small and simple, though.

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

25 comments
Gis Bun
Gis Bun

It's "light" on blopatware noew but let it grow like every other browser out there. There is no way a browser can keep up with newer technologies without adding to its size. So let's say it had no HTML5 support, adding it would add to the size. Part of ther bloatness is not the size of the browser itself but what people add on that makes it bloaty. Too many add-ons. Too many toolbars. My IE8 comes up immediately. No toolbars. Little in add-ons.

mikifinaz1
mikifinaz1

I am getting tired of the long page downloads and intrusive scripting of the others.

lefty.crupps
lefty.crupps

> and its licensing (GPLv3) certainly leaves something > to be desired The GPLv3 has good uptake with FLOSS apps; people seem to like it. What do you have against that license that you'd prefer a different license?

Sterling chip Camden
Sterling chip Camden

... except for not being able to keep it from blowing up on FreeBSD amd64. I guess that's bleeding edge for you.

Sterling chip Camden
Sterling chip Camden

uzbl is designed to be more modular, so you can add/remove/replace bits of it. Compare firefox -- even without extensions, the basic package is huge and unwieldy because it tries to do everything for everyone. For example, I have no need of an RSS feed reader built into firefox (I use newspipe), but I have to carry that code around whenever I browse the web with firefox.

apotheon
apotheon

No -- not unless you can get it to install with something like Cygwin.

seanferd
seanferd

and find out. (Looking rather Unix-y, though.) Regardless, you'll have to compile it from source.

apotheon
apotheon

* Start here. * Continue here, but ignore the lunacy from people like Ballmer. * Read more here. * Did you know copyleft licensing is an ideal tool for corporate market dominance strategies? * Have a look at the WikiVS page for Copyfree vs. Copyleft. Popularity is not the same as quality or ethicality. The only reason I care about "good uptake for FLOSS apps" is the lamentation that people are so stupid as to use the GPLv3.

apotheon
apotheon

I wonder how much it has been tested on 64b systems. I have been using it on a 32b FreeBSD system, and it works fine for me. It's a shame you have not had as much luck.

seanferd
seanferd

Or Cygwin - Emacs - Ezbl - Uzbl. That sounds like more fun.

pgit
pgit

I'm not about to chase after a load of 32 bit gcc libs just to make uzbl on this 64 bit system... =( I'll try over on my 32 bit desktop, after I claw through the 3 windows boxes begging for help piled up in front of it. Looks promising, though. Love the logo too.

pgit
pgit

Yeah, this guy is crazy. Watching him operate is like when Scotty had to use the "quaint" keyboard. I watched him grabbing an image off a satellite, format it and insert it into a cue to be displayed during the newscast. All cli stuff, with little shells popping up here and there to execute some pipe or daughter process for a split second, then disappearing. Less than a minute, he wheeled his chair over to another Debian box used by the producer, of course with a GUI. He showed me the result of what he'd just done. I really only caught one thing he'd done. These images have the equivalent of a URL. Rather than "see" the presence of the image, read then type the name, he used some sort of query to identify the name, piped it to a buffer, then the download command retrieved the name from the buffer. That took about 8 seconds, to get the download started. He's a rather understated guy, real down to earth actually. He said you can pretty much do anything with a computer through emacs, rather than having to load up on X and a dm. That idea left such an impression on me that over the years I have tried to learn emacs and give the power-ranger method a go. uh-uh, nope, can't do it, no way, fergettabodit, not even, go-waaan, take a hike kid, mm-mm, no can do.....

seanferd
seanferd

I'd love to see something like that. You know, of course, that if you can't do it from emacs yet, give it a week.

pgit
pgit

I know a fellow that runs Debian and all he loads at login is emacs. He accomplishes everything he needs from within it. This includes all the weather and other graphics displayed on the tv news cast at the station he runs. (chief/sole engineer) This guy makes the visuals on "Eureka" look downright windows ME.

seanferd
seanferd

can be integrated into Emacs, allowing Emacs to "have a browser". (Using ezbl to do this.)

apotheon
apotheon

That doesn't sound like fun at all. I was already cringing at the thought of Cygwin. You lost me completely at Emacs.

apotheon
apotheon

I knew it was in Ubuntu's archives, so I figured it might be in Mandriva's. I mean, Ubuntu doesn't even have Cinepaint, so if it has uzbl, the browser must be widely enough used and easy enough to package up that it would be pretty much everywhere.

pgit
pgit

Good lord, it is, and 64 bit at that. I can't believe I didn't check there first. It was right there in contrib. Flash... on Mandriva the plug in is a single file. All the rpm does is stash it in the right place and flash works. On my machines the 64 bit goes in /usr/lib64/mozilla/plugins I found out the hard way if you leave a 32 bit in place in /usr/lib/mozilla/plugins the system will have a tendency to use that one. Maybe a path issue. But in a thread here at TR we were pointed to a flash version test and it reported I was outdated and insecure. I removed the dusty 32 bit file and tested ok. You can also put the plugin in the local user's .mozilla folder. You have to make a plugins folder, in the root of the actual firefox account. eg: /home/cat/.mozilla/firefox/ltvych9j/ Not sure how any other distros handle global plugins but the local path should be the same for any distribution. BTW the local plugin will take precedence over a global one. Found that out the hard way too. Thanks apotheon, I feel like such a moron. I constantly tell people in the Mandriva forums you almost never have to build, and always check the repos first blah blah blah. There's got to be a name for the mental condition that blocks one from heeding their own advice...

apotheon
apotheon

Is uzbl not in Mandriva's package archive?

Neon Samurai
Neon Samurai

I remember a 64bit beta plugin being available briefly. Someone made a Debian package that grabbed it from adobe and installed it. At some point, Adobe discontinued the 64bit plugin and the Debian native package was updated to display "Adobe has discontinued the 64bit plugin. This package will be updated when a new one becomes available." It might be that a new 64bit plugin build is available finally. Sadly, Flash is one of those things where you use adobe or you don't get real support. Gnash just isn't there yet. hm.. me thinks I need to look over my build scripts and confirm if it was Debian5 with the complicated plugin install or if it's here scripted into my Debian6.

pgit
pgit

..I actually might load the 32 bit compiler. I've used Lynx on occasion when grabbing text off the net, but a minimal GUI would be a real time saver. You aren't using the 64 bit flash rc? I also used nspluginwrapper and 32 bit flash, but someone pointed out they do in fact have a 64 bit offering but it's not 'official.' Works better than the 32 bit did. http://labs.adobe.com/downloads/flashplayer10.html

Neon Samurai
Neon Samurai

I've had similar from Debian 64bit. The 32bit apps seem to want the 32bit libraries in the same way that Windows apps may want win32.dll. As the only way to get working Flash, I ended up installing the 32bit player and required 32bit environment inside my 64bit Debian. Everything went ok once the 32bit stuff was in place but I dragged my feet for a good six months hoping someone would do a proper 64bit Flashplugin package. You might also try pointing at the relevant 64bit libraries in your Make line but I'm guessing you get errors about miss-matched architecture or similar.

pgit
pgit

Mandriva Linux 64 bit. The errors I read are pointing to libs I have on board but in the "wrong" path, .../lib64 vs .../lib in some cases. I have installed 32 bit versions of things side by side before, not really sure if that's the hangup here but it appears to be. Being this is the only 64 bit machine I have, and it's my primary use system I don't think I should futz with it. As I mentioned when I can get to my 32 bit desktop I'll try it there. Good news is I'm down to one windows box in the way, a USB transmitter to a remote display device isn't working, should be easy... (as in "yep, she's euchred")

Editor's Picks