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!
So it's not a web browser, but rather a HTML rendering widget you can use to write a web browser, or use in other programs? I think .NET has one of those based on the I.E engine...
Come as you are, do what you must, be who you will.
The goal isn't to gain popular market share.
I don't think they're looking for standard users, and kind of the whole point was to create a learning curve. This implies that it's targeted at powerusers and developers. With the script-integration, this could be useful for quickly churning out a limited-use kiosk with a few helper apps or something (e.g. a novelty photo booth with web integration).
Anyway, the price is right.
"They were pure niggers." – Noam Chomsky
Novel ideas usually don't live on by themselves unless they become useful. The worst thing the developers did (besides the name) was create a "steep learning curve" for the common web browser. The best thing the developers could do is work with an existing product that already has market share and works great like Chrome (also based on Webkit) and make their additions to it in support of better key bindings.
That depends on whether the goal is to obtain the largest possible marketshare. If that is the goal, or if that is your sole definition of "useful," then what you say does apply. If they don't give a damn about competing head-on with the likes of IE or Firefox then what you say is completely irrelevant. What I don't understand is the (usually) unstated assumption that marketshare numbers are the only reason why anyone creates any piece of software. While it's important in terms of attracting developers and, in the case of browsers, for putting pressure on Microsoft to make IE more standards-compliant, there are many reasons why someone might write a browser and this includes reasons that wouldn't personally motivate you.
I see the same sentiment shown when some people discuss Linux as though its only purpose is to compete with Windows. They then act like Linux is a complete and utter failure if it doesn't bust up the Windows desktop monopoly. I disagree with this; Linux just "is." If it happens to displace Windows, that's great. If it doesn't, that's fine with me too. Though I have happily introduced folks to Linux who showed an interest in it, I'm not out to win converts; I just want something that works for me. There are those of us for whom Linux is a good solution, who have no dependency on any Microsoft products, and who are able to do our computing completely aloof from Microsoft, unaffected by any decision Microsoft makes. It's abundantly possible that this is intended to be a niche browser, designed for the relatively small number of users who are technically inclined and willing to tinker with something like a Web browser and its supporting scripts.
It is a miracle that curiosity survives formal education. - Einstein
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.
The real challenge to good software is to make things as easy as possible, and make it so the complicated doesn't interfere with the simple.
When they're designed for ease of use. When they're designed for *efficiency*, however, as ViM is, the challenge is to keep the complex possible while making the simple as fast as you can. How easy it is to learn never enters into the equation.
The editor designed for *power* is Emacs, whose LISP interpreter can't be beat in that department.
No problem is insoluble in all conceivable circumstances.