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.
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.
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
Actually, I'm runing this on fedora 11 right now, and flash works just fine for me (not extensively tested, just youtube & addictinggames). Sure it's a mite choppy in fullscreen, but about the same as it is on XP/IE [7,8] Actually, uzbl as a whole works just fine for me. It has seriously joined the war between Iron and FF on my system. The lack of uri editing might be a problem, but I'm sure I'll be fine.
Only marketroids use Flash for their fucking annoying banner ads that either moves all the time, plays music and sounds or even worst starts playing a fucking video while I'm trying to read the godamn fucking webpage.
Annoying Flash crap = I can't focus on the actual page content = I close the fucking website and never go there again.
It *is* preferable to have a separate ad-blocker, that should be a no-brainer within the unix philosophy. What you're thinking of is a client/server model where right clicking the ad in the UI (which UI? Maybe there could be several to choose from) should initiate a conversation with the ad-blocker daemon.
Notepad is, and was designed to be, an extremely basic text editor. It doesn't have lots of features not because those would necessarily make it hard to use, but because they'd take resources to develop. It is just a simple program to display a text file, little more.
Now compare Vim to something like UltraEdit. Here you have a tons of features. Maybe even more than Vim has. However it is still simple to use the basics. You can fire it up and open up a file and edit it with no more effort than notepad. It is easy to do the simple stuff.
The real mark of well designed complex software is where the learning curve is variable, meaning it is only as steep as it needs to be for a given thing. Simple lings are easy to learn, more complex things are harder. You don't have to bash your head against a wall learning all sorts of complicated things to accomplish the basics. The complex capability is there, but it doesn't interfere with simple stuff.
That's why something like Vi fails to impress me. When I got my current job, I had to learn about it, since it is the only text editor that comes with Solaris by default. I was annoyed with it as it is the first and only text editor I've ever encountered that I couldn't edit text in without a manual. I tried to use it, and couldn't make it work. Our Solaris guy had to show me how it worked. He, like you, seemed to assume I'd love it once I learned about it because of its power. I challenged him to show me something it could do that UltraEdit couldn't. He wasn't able to come up with anything.
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.
Your proxy doesn't generally need to parse the page -- while operating on a page tree ala Greaseonkey may be the One True Way, you can get quite decent results by simply returning null objects (e.g. 1x1 pixel gifs, pngs, etc.) locally for certain outgoing requests, or the entire result (with no parsing needed or modification performed) to any other requests. And the browser can simply append new patterns to the proxy's config file from right-clicking on an ad.
If you want to modify the page layout to eliminate the space the ads were meant to take up, or to eliminate text ads, this isn't really ad-specific, and should usually be implementable with local CSS overrides -- again, no need to reparse the page, and this is also more general than just ad-blocking.
But on the topic of "my browser already parsed it, but I need to do $TASK on the parsed tree, why should I have to re-parse it?", here's a somewhat plan9ish fix: provide a virtual filesystem representing the HTML/XML tree, and giving other programs full read-write access. (If you've messed with wmii, this should make sense...)