After several years of inactivity and a quiet relaunch earlier this year, the Dillo web browser has finally released Dillo 2.0.

The open-source project started in 1999 with the goal of creating a small, fast, highly efficient graphical web browser that could run well even on low-end hardware and software. It’s a UNIX application, and runs on Linux, BSD, Solaris, etc. Things stagnated when it became clear that GTK1 was going to vanish, and GTK2 would not fit the project goals, and eventually the browser was ported to the Fast Light Toolkit (FLTK).

If you’ve used Dillo before, some of the improvements in this release are multiple character set support (the old versions were Latin-1–only), tabbed browsing, HTTP compression, anti-aliasing, improved rendering and UI, and smaller(!) memory usage.

It does have its limitations, and a few major items stand out as missing when compared to other modern browsers:

  • No CSS stylesheet support.
  • No scripting.
  • No plug-ins.
  • Limited SSL support.

That said, it’s useful to keep around on an older system, or for situations where speed is more important than rendering, or to test how a website works without styles, scripts, and plugins.

I started building RPMs of Dillo for my own use back in 2002, and became the official RPM packager for the project the following year. I’ve posted Dillo RPM packages for Fedora 9, RHEL 3, RHEL 4, and RHEL 5. Other distros will have to wait until I get my build system out of storage or figure out how to convince mock to let me build two packages together.

Alternative Browser AllianceYou may have seen my website, the Alternative Browser Alliance. I put it together in 2005, when flame wars between Opera users and Firefox users were at their height, to show that we shared a common goal: opening the web. The most popular page on the site is a list of web browsers, which is linked as a resource from a number of sites and also gets a steady stream of traffic from people searching for alternative browsers.

Of course, things have changed a lot since 2005, so I’m planning an overhaul of the whole site. Continue reading

Now that it’s live, I’ve downloaded the Google Chrome beta on my Windows box at work.  Thoughts so far:

Good:

  • Site compatibility seems to be fine so far, with a couple of minor issues (see the “Bad” section).  Mostly I’ve tested it with a couple of forum sites, LiveJournal, Slashdot, and WordPress.
  • I like the simple settings box, with “Basics,” “Minor Tweaks,” and “Under the Hood.”
  • It does feel fast.
  • Showing the URL of links in the lower left-hand corner is a perfect compromise between the spatial advantages of a permanent status bar and the extra room provided by leaving it out.
  • I like the task manager for the browser itself.  It’ll be good for developers, but it’ll also be good for users: as the comic points out, if your browser starts chewing up all available resources, you’ll be able to tell what page/plugin/program is at fault instead of just blaming the browser.

Bad:

  • Gears support doesn’t seem to work quite right.  WordPress.com doesn’t detect that it’s available.  Local WP installs with Bad Behavior can’t sync completely.  (It doesn’t send an Accept header on the request for one of the TinyMCE files, which causes Bad Bahavior to think it’s a spambot and triggers a 403.)
  • Cookie management is too simplistic.  I like to accept all cookies temporarily, but clear everything when I end my browsing session, with exceptions for sites where I want to stay logged in.  This is easy in Firefox, a little trickier in Opera, and doesn’t seem to be an option in Chrome.
  • I have seen it pause a couple of times, with as few as 5 tabs. [edit: these seem to be related to Flash content]
  • No Incomplete spell-check.
  • I keep hitting the forward-slash key to search within a page, since that’s the shortcut I’m used to in Firefox and Opera.
Debatable:
  • The UI does indeed stay out of your way.  I guess this sort of makes Chrome the Anti-Flock.
  • DNS Pre-Fetching is enabled by default.  This is different from full HTTP pre-fetching in that all it does it look up the IP addresses of the links that you might click on.  It’s not clear at what point it does this — I don’t remember seeing it mentioned in the comic, which (ironically) isn’t searchable.  I suppose it could either hit the domains of all the links on a page, or just those that would trigger HTTP pre-fetching, or even just send the query when you hover over a link (to get a split-second head start before you click). Update Sep. 17: Google has a blog post explaining pre-resolving in detail. Apparently it does check the domains for all the links on the current page.

Google Chrome seems to be a multi-threaded open-source browser based on WebKit (with some code from Firefox as well), focusing on making a browser that will work well with web applications.

It’s got built-in support for the Gears API (not surprising). And, like Firefox 3, IE8, and Opera 9.5, it’ll do full-history search & auto-suggest in the location bar. Interestingly, they’ve adopted a couple of UI elements from Opera, including thumbnails of your most-visited pages when opening a new tab (like Opera’s Speed Dial, though in this case the list is automatically generated from your browsing behavior), and putting the tabs above the main toolbar — something that Opera has taken a lot of flack for.

According to the blog post, the first preview release should be out for Windows tomorrow, with Linux and Mac following.

Oddly enough, I found out about it through comics blogs (A Distant Soil, specifically), not tech blogs, because Google hired Scott McCloud (Understanding Comics) to explain what makes the browser different in comic-book form.