You’ll need to freshen up that beverage before you sink your teeth into this article. If you don’t have time now I suggest using Instapaper to save it for later.

/via Justin Blanton.

Firefox 4 was released today and once again I’m made to feel this same nauseating feeling. Every single time a new Browser is released, well Safari, Chrome, or Firefox (we’ll leave Internet Explorer, Opera and others out of this), I’m torn between making the jump from one browser to the other.

I’ve jumped around a lot over the years. And it always comes back to one thing that determines whether or not I use a Browser every day; speed. I don’t use many extensions, themes, or add-ons in any Browser. I had used Safari before it even supported such things. Speed, however, keeps me loyal to a Browser until – inevitably – the next-fastest Browser released pulls me away.

On the outset Firefox 4 feels very snappy. Just about as fast as Chrome (if not faster) and a lot faster than Safari. Chrome and Firefox 4 are now neck-and-neck for winning my default Browser of choice. But that’s today and I’m sure that won’t last long and, once again, I’ll be left with the nauseating choice of jumping ship.

Here are the statistics for the last 30 days here on my personal site. Internet Explorer is still #1 in spite of every single geek on the planet wanting it to simply go away. But it isn’t winning by much. Firefox and Safari are pretty close behind and Chrome is catching up quickly.

The Safari number includes both iPhone and iPad as well as the Macintosh and Windows. The Mac and iPhone split up the biggest portion of this with Windows and iPad nearly tying.

Interestingly, if you combine Chrome and Safari, which both run the Webkit rendering engine, then Webkit clearly stands out as the #1 rendering engine for all HTML/JS on my site.

So it looks like it is Internet Explorer vs. Webkit – at this point – as being the two main contenders in this war. Firefox, which is doing very very well on its own, is beginning to show signs of lagging behind both Safari and Chrome in their growth rates. This could all change in one day with one killer update from Mozilla – but I’m not holding my breath.

So why do I say that there are ton of casualties in this war? Because the people who spend all of their time building websites and applications have more browsers to build against than ever before, not less. More screens, more devices means more problems. Choice for the end user means headaches for the builders.

This problem probably won’t go away even if every browser manufacturer united under the banner of Webkit. If they did the spirit and motivation of competition would be gone – leaving only the end-user to suffer from lack of progress.

It appears that this war is not going to end and the bodies will continue to pile.

Not anymore. I’ve been wanting to switch to the Google Chrome Developer channel (or, the still pretty darned bleed edge releases) for a few weeks but hadn’t had the time to figure out how. After I saw my friend in bleeding edge Chromium releases Justin Blanton take the plunge I began hunting. Turns out, it is pretty easy once you found the right link.

I found this link via the Chromium Blog – but there is an Early Access Release Channels page that explains what each release channel is, its purpose, and how you can get involved. The nice thing about these channels is that these are releases of Google Chrome, not just Chromium, and as such are slightly more stable and refined then the Chromium nightlies I’ve been using. Updating to the next release is also easier in that it happens within the application itself and it continues on the same channel you choose be it beta or developer.

Left: Chromium Right: Google Chrome Dev channel

For example, remember how I complained about Chromium’s Bookmark Manager? Remember those hideous buttons? Well, they are much nicer in Google Chrome then they are in Chromium. Take a look at the graphic that shows the difference between the two. Though the action button doesn’t do much (yet) it does fit much nicer into the Mac ecosystem. Obviously the source list on the left is much nicer as well.

Switching from Chromium to Google Chrome was made all the more easy due to Google’s free Bookmark Syncing service. If you’d like to help test the very latest build of Chrome follow the links on that Early Access Release Channels to download your flavor of Chrome based on which channel you’d like.

A few days ago I updated to the latest nightly build of Chromium, something I do every few days using TechCrunch’s Chrome-Up application, and was elated to discover that Chromium finally has a Bookmark Manager. Up until this release I was unable to edit any of the bookmarks that I had imported from Safari into Chromium. It was frustrating.

I’ve now finally been able to update, sort and delete my bookmarks (which are automatically synced with my Google Account). Something I wasn’t able to do for months and has taken my already fairly bubbly adoration of Chromium and taken it to the next level. A clean browser is a happy browser.

I was surprised, though, at the overall design and implementation of the Bookmark Manager in Chromium. It feels very rushed. Even though I use a nightly build, which is as cutting-edge as you can possibly get, I expected to see a very different approach than what is pictured above.

Chromium’s New Tab, History, Downloads and Extensions pages are very different from what we see in most other browsers. The New Tab page, as an example, is much more like Safari’s Top Sites page (although not nearly as cool). The Downloads page I find particularly useful. It shows up like a Web page and shows you everything that you downloaded recently, by day, with a link back to the page it originated from, a link to the file itself on your own system, etc. Functionally it is very much the same as Safari and Firefox’s Downloads pop-up window but Chrome’s is altogether nicer, in my opinion, because it shows up in a tab.

I expected Chromium to have the same sort of “Web page” feeling to its Bookmark Manager. Maybe this is a case of ‘don’t fix it if it ain’t broken’ but I think there is huge potential for browsers to reinvent the way bookmarks are managed. Why not plug into some social bookmarking sites? (I know there are Firefox plugins that do stuff like this) Why not give us an unlimited amount of metadata to attribute to a bookmark? I remember when Firefox implemented shortcodes for bookmarks, like ‘gr’ for Google Reader as an example, and you could just type ‘gr’ + Enter and off you went to that bookmark. I would love to see that in Chromium (and Safari).

And what about the plus, minus, and eye buttons on the toolbar? I have never, ever, ever seen anything like those on any operating system. Perhaps I’m looking too far into what are basically alpha level builds. Maybe what will end up being released with Chrome for Mac will be vastly different than what is appearing currently in Chromium (I hope so).

And don’t get me wrong, I’m extremely happy to finally be able to edit my bookmarks in Chromium and I always look forward to the next nightly update.

Viewing the source of a page on Google Chrome is, for the most part, a terrific experience. Chrome supports syntax highlighting of the underlying code of a page making it much more readable for us geeks while we look under the hood.

However, something I’ve run into of late is that it doesn’t work very well for dynamically generated pages. The issue seems to be that since Google Chrome opens a new tab to view the source of the current URL that you’re on, it actually “reloads” that page with new session data, as well as ditching all of the POST variables you may have sent to it. This causes some confusion and may lead to head scratching (as it did for me).

I don’t know of a work around currently but knowing this may save you some time.

Side note: I’m loving Google Chrome for Mac.

The next version of Webkit that will be released will come with a new version of the Web Inspector, a tool used by Web developers to “inspect” an already-loaded Web page for debugging, testing, etc., that has some really great new features thanks in part to Joseph Pecoraro.

I love that I can choose either Safari or Chrome and I will still benefit from this update.

As it stands Safari is far and away the best browser available on the Macintosh. Firefox, which is a really solid browser and is much loved by many developers, just isn’t “Mac enough” for us real, devout Mac users. There are so many things missing when an application is not built as a native Macintosh application. Simple things, really. Being able to look up things from the built-in Mac OS X dictionary is one thing. Native spell check. Speed! These are simple things, since Firefox handles some of these things on its own, but once you’ve grown accustomed how real, native Mac applications feel – you want that from all applications on your Mac. Opera and Camino, both very respectable browsers, just are not as lean and mean as Safari is. The are other browsers, to be sure, but none that are backed by corporations with enough resources, or an active enough development community, to really push for the top-spot on the Mac.

Which is why it’d be great for a really, really good browser to emerge on the Macintosh to rival Safari. Both Safari and the Webkit teams are on a tear lately. They have made tremendous strides towards making Safari better and Webkit (along with Squirelfish which is now called Nitro) much, much faster. They’ve improved Webkit’s page rendering (or, how it displays the page based on open standards) to such a degree that it is the envy of all other engines. But, they could do better.

For example, Chrome renders pages faster than Safari. I don’t need a fancy graph or test to show me this – I’ve loaded pages on my Macbook Pro using Chrome and the speed at which the page becomes usable is hands-down much, much faster in Chrome than in Safari (and Safari is fast).

For example, Firefox has add-ons which enhance the features of the core browser. There are add-ons for everything like plugging into your favorite Web sites, aggregating content, security and privacy enhancements, music, calendaring, etc. etc. etc. All optional, based on your needs/wants. Chrome will also support extensions, which are similar to add-ons, that will use open standards (this excites me very, very much).

Competition. That is what it comes down to. Not just competition based on marketing or market share or even mindshare – but an all-out race to be the best. The unequivocal best even if you’re not the biggest. If Google Chrome for Mac is released and is only marginally better than the developer preview releases I’ve been using – the people that are responsible for making Safari will need to trot a little quicker to keep up with where Google is going.

Hooray for us.

Side note: Why I can’t use Google Chrome full time, yet

I’d be tempted to use the developer preview releases of Google Chrome for Mac full time but there are a few key things that are ultimately missing from the application that are vital to my daily browsing needs. Here they are, in case you’re wondering:

• Adobe Flash support is simply not yet available. I’m not sure what makes Google Chrome for Mac any different than any other browser but I’m hoping this is addressed soon.
• Google Gears support. Both Google Reader and WordPress, two applications that I use quite often, support Gears and make the experience of using them much nicer. Kind of ironic that Google Chrome for Mac still doesn’t have Google Gears support.
• Import from Safari. I could probably hack my way into bringing all of my bookmarks and preferences from Safari into Google Chrome – but I hope that an upcoming release has this built-in.

That’s really about it. If I had these things I could probably make the jump to do some real testing of Google Chrome for Mac. For now, I’ll stick with the best browser available for the Mac, Safari.

But we haven’t seen that floor yet.

Downloading Firefox 3 today I have experienced, what I feel, is the quickest page rendering experience I’ve had on the Macintosh since, well, downloading the latest version of Safari.  Before that I thought Camino was the quickest at rendering a page on my Mac.  Just prior to that, it was Safari.  And, according to Ariya Hidayat tests, it seems like when the next version of Safari is released to the public it will again hold the top spot in this rendering speed war that is being waged.

Granted the tests Ariya ran on a recent nightly build of Webkit, the rendering engine beneath the Safari browser, are dedicated to Webkit’s ability to parse through JavaScript only (leaving out the all important HTML and CSS rendering speed capabilities) – but one can assume that Safari will feel much snappier when the next update is release.

So, the beat goes on and on and on.  Rendering speeds in these browsers are going to continue to get better until they reach some sort of limit. I suppose the limit could be considered “virtually instantaneous” but I wonder how long it will be until we see that.

When does it end?

Both Pierre Igot and John Gruber cover this topic in great detail; the fact that the first user interaction with Safari’s tabs while dragging ultimately determine their ability to either reorder the tab and/or open a new window/tab. But that’s generalizing it far too much.

If you’re an anal Safari nut, like me, I suggest you read both of their articles.

Source: Safari 3.0: Dragging tabs up or down to move them sideways.
Secondary, source: Safari’s Tab Dragging Modes.

John does an excellent job reviewing these two applications based on a number of factors including interface, design, feature-sets, and how well each fits into the Operating System.

“I love Firefox’s auto-restoration of tabs and windows. Quit Firefox, relaunch it, and your previously-open tabs and windows are restored. Safari 3 has this feature, but makes you do it manually via the “Reopen All Windows From Last Session” command in the History menu. I’m sure most Safari users have no idea this feature even exists. At least as a preference, Safari should offer the ability to do this automatically.”

He’s right. I never knew that feature was even there. It is little tidbits like this, and John’s superb writing, that have made me never regret my membership fee to Daring Fireball.

Source: Daring Fireball: Firefox 3 vs. Safari 3.

The first thing I’m going to tackle is Safari (though I believe that Safari should be updated as a separate application and not part of the OS). I’ll try to focus my thoughts from fixes, to actual bugs, to feature requests.

Fixes

The following are not “bugs” in the traditional sense. I believe that most of the following was done intentionally, I just do not think they should have been done.

Setting your default browser is currently held within Safari’s preference panel. This “feature” definitely gets on the nerves of many and really I can’t figure out why this resides in here. In order to switch from Safari to Firefox you’d need to first open Safari and tell it you want Firefox to be the default browser.

This isn’t to say that Firefox (and other browsers) do not ask if you’d like to use them as the default browser on your system – but this does not mean that this is the proper location for this preference. What if I uninstalled Safari?

The blue RSS button at the top of the browser is fairly misleading. Apple is attempting to “brand” a doc-spec. In other words, they are saying that all “feeds” are RSS. Obviously this is not true. I do not want that icon to change from RSS to ATOM to “WHATEVER” when it applies, I’d much rather see Apple use the unified feed icons to go along with the unified feed theory (another post I have to bring over to my local site soon).

Multiple feeds detection kinda goes along with the above. I suppose this could be filed under a new feature request – but I feel like they might have kept it simple on purpose. I wouldn’t mind seeing a short list pop up with the available feeds for that site. Obviously this would only be useful if web masters actually listed these feeds in their documents.

Feature requests

Safari is definitely a browser for the average user, but I’d like to see a few of the “not so elementary” features from other browsers find their way into the Leopard release of Safari. Why? Because I’d much rather use Safari than Firefox if it only had the following.

Bookmark keywords (click to zoom)

Bookmark keywords is something I use heavily in Firefox. I am not sure how widely used this feature actually is, since even browsers like Flock do not currently have this feature built in (and Flock is built off of the same engine and core as Firefox). Side note: I’ve been told that Flock 1.0 (due out sooner than later) will have these features as it will be built off of the Firefox 2.0 release.

To explain really quick, for those that are not familiar with this feature – Bookmark keywords allow you to setup shortcuts for your bookmarks. Let’s say that you had a rather long URL that you visited often, and you didn’t want to traverse your long list of bookmarks in order to get to that page without typing in the name manually, you can setup a shorter keyword for that. (see screenshot) You type in that keyword, and poof, you’re there.

Searchable history is not something I use every day, but when you need it – you find it very handy. I suppose I could liken a searchable history to Spotlight. Before Spotlight was introduced we never knew how much of a pain it was to find things on our local system. But, after having Spotlight for awhile now, I find it indispensable. Such is the case with searchable history. Safari’s history menu is crude – and needs a significant update.

Update: As Nathan pointed out the history in Safari is indeed searchable. But I would have never found it if he hadn’t told me where it was. So the UI needs to be adjusted to make this much more accessible.

Final thoughts

Really my requests for Safari are very light and don’t hold a ton of water when it comes to my decision to use Firefox instead of Safari. There are other, underlying, reasons why I use Firefox that are much more “under the hood” type of reasons. For instance, many WYSIWYG editors inside of various web applications do not function properly within Safari. Hopefully, with the very latest version of Web kit no doubt being included in the upcoming release of Safari, we’ll see some of this functionality made available.

I remember the first day I wanted to jump ship from Safari to Firefox. I wanted to use Google Calendar and couldn’t because Safari was not a supported browser. But now that I rarely use any online web applications – I may switch back and deal with my little niggles mentioned above until they become available (hopefully) in the next release.

Note: Be sure to check out other parts of my Leopard wish list listed below:

1. Part one: Safari
2. Part two: Mail
3. Part three: iChat
4. Part three: Finder

[tags]leopard, mac os x, osx, macintosh, apple, safari, wish list, browsers, flock, firefox, bookmarks, history, rss, feeds, atom[/tags]
[slug]leopard-wishes-pt1-safari[/slug]