Slashdot Mirror
Meet Uzbl — a Web Browser With the Unix Philosophy
DigDuality writes "Dieter@be over at Arch Linux forums, a release engineer for Arch Linux, got inspired by this post. The idea? To create a browser based on the Unix philosophy: 'Write programs that do one thing and do it well, programs that work well together, programs to handle text streams because that is a universal interface,' among other points. The result? A fast, low-resource browser named Uzbl, based on WebKit, which passes the Acid3 Test with a perfect score. The browser is controlled (by default) by vim-like keybindings, not too dissimilar to vimperator for Firefox. Things like URL changing, loading/saving of bookmarks, saving history, and downloads are handled through external scripts that you write (though the Uzbl software does come with some nice scripts for you to use). It fits great in a tiling window manager and plays extremely well with dmenu. The learning curve is a bit steep, but once you get used to it, it's smooth sailing. Not bad for alpha software. Though built for Arch, it has been reported to work on Ubuntu."
Worse is better!
The goal isn't to gain popular market share.
it has been my experience that everything regarding steep learning curves in *nix, ends up revealing benefits those who never try will never know of. Try explaining to the average windows user how vim is better than notepad vs watching someone learn vim and having their face light up everytime they figure out they can do something very quickly that's impossible in a standard text editor
How about use it to edit a remote file over ssh, from an Android phone? Or do complex things without using the damn mouse? Or write macros in a usable macro language?
More generally, with commonly used software, some of us just don't care about the learning curve. With the tools I use daily, I don't even remember what the first hour of using them was like, because it was so many thousands of hours ago. I even find it interesting to learn about new ways of doing things, so I don't resent an hour or two of getting up to speed, even if I don't end up using the tool. I could see if I had to learn a new tool an hour before a deadline I'd be annoyed, but the simple solution to that is not to schedule your new-tool experimentation an hour before a deadline. =]
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
OK. So Vim isn't the ideal editor today -- it was designed around limitations of earlier computers and when you remove those limitations you can get rid of stuff like modality that's not really necessary when you have a mouse. So lots of people get attached to modality and hjkl navigation because they spent time learning them, just like people get attached to the emacs OS, even though neither are, today, what anyone designing a new editor would make. They are historically notable -- both were more powerful and easy to use than what came before. I don't think either is very Unixy -- they're each platforms unto themselves at this point. Whatever the first Notepad-like editor was, that introduced the basic elements we consider to be standard text-editing controls today, is definitely historically notable also, and a great achievement -- it flattened the learning curve and (mostly) shattered modality.
Vim and Emacs don't have a lot to do with this browser project, despite the red herring of vi-like keybindings. This project is an experiment about building a browser that's really part of Unix, so as far as an analogous editor goes, perhaps Plan 9's acme, which also relied on external scripts for much functionality. The point isn't to be the greatest or most impressive anything, because... really, who cares? The point is to be a useful tool within the Unix system. If a more self-contained browser is easier to use in many cases that doesn't make it useless.