Opera had previously announced that it had submitted its browser to the App Store for approval back on March 23rd, in an effort to drum up support for its inclusion in the App Store. Back then, many suspected it would likely be rejected on the basis of it duplicating built-in functionality on the iPhone, namely the included Safari web browser. (Though some questioned this analysis)

Whatever the reason, this comes as a surprise to many, especially given Apple’s most recent behaviour towards potential competitors and development on the iPhone in general. Nonetheless, let’s give Opera Mini for iPhone a quick test drive!

The Opera Mini advantage

To begin, it’s worthwhile to understand that Opera Mini is not a regular web browser, in that it does not make direct connections to websites to retrieve their content, unlike Safari on the iPhone or any other desktop web browser. Instead, all requests are handed through a proxy server that Opera controls. This proxy server retrieves the remote web page, reformats the content for better display on a mobile screen and finally compressed for delivery to the end device. The format used is Opera’s own, called OBML, and furthermore the pages need not be delivered to your device over HTTP. (More information on this Opera Mini infrastructure is available here.)

Ostensibly, all of this work is done to improve the mobile browsing experience in at least two ways. Firstly, the size of each webpage is reduced, thus speeding load times. Secondly, the content is reformatted by Opera’s servers to allow for mobiles to better display content that was only designed with computer monitors in mind.

These features certainly made sense for a phone like the Samsung M510, my first mobile. But what about the iPhone 3GS and its larger, high-quality screen and faster HSDPA access speeds? In this case, are these optimizations even needed or helpful?

The iPhone Experience

The Opera Mini browser has the same general UI layout as Mobile Safari, which is unsurprisingly given the smaller real-estate of mobile screens – there are only so many UI configurations for a web browser on such a space and even fewer potential effective ones. There’s the address bar up top, with a web search field in the upper right corner. The list of search engines is also configurable. Standard browser buttons such as back/forward, reload and tabs are at the bottom of the screen.

When opening Opera Mini the previous state of the app is restored, so the current page you’re on as well as any open tabs you had when you closed the browser remain. This was pretty much expected – anything less would be a huge mark against the app. Opera Mini has a unique tab switcher, one that’s arguably better than Safari’s. When activated, it allows you see to quite a few more tabs than Safari, which just shows you the previous and next. Switching between them is pretty easy, as is opening a new tab.

When opening a new tab, the default page is Opera’s “Speed Dial” feature, something a heck of a lot more useful than the blank tab Safari gives you. It’s easy to configure what pages show up here.

Reading webpages with Opera Mini

The standard tasks of scrolling and zooming were okay, though there are some differences from Safari. In particular, it didn’t appear possible to click a link based on “small” text without zooming into the appropriate section; zooming is also accomplished with a single-tap, not a double-tap. I suspect the two changes go hand-in-hand. This is actually a decrease in functionality from Safari – Safari had some pretty good detection for helping you click smaller links with fat fingers without having to resort to zooming in on the area. Opera now forces the issue.

Opera also implements double-tap to zoom out. But it’s a bit more sensitive as to exactly what constitutes a “double-tap”. In Safari, you don’t have to double-tap exactly in the same spot in order to trigger the zoom out action. Opera Mini seems to be a bit more sensitive to exactly where you double-tap before it zooms out. This impairs usability somewhat.

Selecting text was straightforward; simply tap and hold a section and you can select text using a resizable box. The text can then be copied or used to search.

Other features

Because Opera Mini was going through a proxy server and dynamically reformatting the content before passing it to your device, I had some worries that websites would not properly detect the user-agent of the iPhone and thus would not redirect to iPhone-specific sites. But during my testing, thankfully this was not the case. Most redirected properly to their mobile versions, if available.

Opera Mini also two other features of note: Full screen and Mobile view. Full screen (see below for The Globe and Mail’s website) simply removes the bottom bar and gives you only the minimum amount of browser UI you’d need, saving you a little more space for the actual website.

Mobile view, which is far less useful, causes Opera Mini to reformat the entire website to “fit” the layout of the screen, rather than just text. I use quotes with the term “fit”, because the reformatting of Mobile view is in general, quite awful and results in a mangled look. Perhaps it made sense to do this kind of reformatting on the extremely small screens of older mobiles, but it simply makes no sense on the iPhone. You can see the results of this by comparing the CBC News website in normal versus mobile rending mode below.

Comparison with Safari

The real question, however, is how does Opera Mini compare with Mobile Safari? After all, this is its main and perhaps only competition it faces on the iPhone, and furthermore Safari is entrenched with most users simply because of its strong tie-in with the iPhone platform. If Opera Mini hopes to win any market share, it can’t just be as good as Safari – it has to be a lot better so people will switch.

Unfortunately, this isn’t the case. In my opinion, Opera Mini is actually behind Mobile Safari in many areas. Furthermore, the main benefits of Opera Mini actually don’t matter that much on the iPhone.

Opera Mini uses its proxy server setup in order to speed access by compressing pages before they’re sent to your device. During testing, this benefit was minimal over 3G or Wi-Fi networks and in fact Opera Mini may have been slower in some cases due to the delay induced by having to wait for page compression on Opera’s servers. To be fair, Opera focuses on the comparative speed advantage on 2G/EDGE data networks, so if you’re in that situation it may have some real benefit.

But even considering this, the entire model that Opera Mini uses completely breaks end-to-end security, so accessing HTTPS sites no longer guarantees confidentiality unless you completely trust Opera and trust that Opera’s servers won’t be compromised.

But these might be implementation details – what do they matter? Unfortunately, the end user experience also suffers in the way text is rendered and formatted by Opera Mini. See the comparison of Engadget’s site below in Opera Mini and Mobile Safari:

At the fully-zoomed out level, all text is basically unreadable in Opera Mini, while in Safari this is not the case. Some images also looked aliased, owing to Opera’s compression of the page.

Even zooming in, we can see some differences. Firstly, Opera Mini seemingly switches the rendering of the website-specified font to a sans-serif one, while Safari maintains the actual font for the text. Safari also keep the original layout, allowing the text to flow around the image and still be readable. Opera Mini seems to just reformat the text to fit the width of the screen without regard for maintaining the overall layout of the site. In this respect, Safari better preserves the original look and feel.

But perhaps the biggest hit against Opera Mini is its lack of fully supporting JavaScript. This is again due to the proxy model it is using. Because of this, the functionality of web applications is severely impaired or even blocked. Meanwhile, Safari is a fully-featured browser supporting Ajax techniques and even subsets of HTML5. These differences are most apparent when looking at how Gmail renders in each browser:

Opera Mini cause Gmail to step down to a primitive version, something you’d expect to see on older mobiles. Safari, however, has access to an iPhone-optimized version of the web application, which Google has been available for some time, is being constantly improved and arguably better than the built-in Mail app.

The fact that Safari works so well for the web should be no surprise, since Apple’s original plan was for their WebKit browser to be the only “SDK” for the iPhone. That is, web applications would be the way developers would make apps for the iPhone – no App Store involved. With this in mind, Apple engineers put a lot of work in to Safari to make sure it would not only be a good web browser, but one that would be able to run the future of web applications, and look good doing so.

Because of this, Opera Mini had a formidable opponent to go up against. The fact that it couldn’t beat it is not a reflection of Opera’s ability, but more a reflection of the time Apple spent on Mobile Safari.

Conclusion

I may have seemed a bit harsh and some of the criticism of Opera Mini may have been unwarranted. After all, it’s a free download, so can you really complain? I just don’t think I’ll be using it to replace Safari any time soon and that its current popularity is simply a result of the drama played out in the App Store and exaggerated by blogs.

There’s an interesting article out that points to the fact that every day there are 10,000 canceled installations for Firefox; this meaning that each day 10,000 people download the Firefox installer, “fire up” the *.exe and then click “Cancel”. (A further 40,000 apparently downloaded the setup file, but didn’t even make it far enough to start and then subsequently cancel the installation)

Even more interesting were the reasons why the 10,000 canceled their install. A large part of the respondents were “confused” with some part of the install process (nearly half) while most of the other half identified that they did not have the proper permissions to complete the install.

Not simple enough?

The results seem to indicate that the installation process is not as easy as it could be. However, it’s dismiss the results by saying that Firefox is already easy enough to install, because after all, how hard can it be to just click “Next” a few times? But this ignores the central problem, that is, assuming everyone is technically proficient enough to find such things routine.

For example, to a mechanic an oil change would likely be an easy five-minute operation. For someone like me, who’s rarely popped open the hood of a car, much less done anything underneath it, such a task would likely entail reading a manual (or just Googling for the answer), then carefully following the steps one-by-one; I’d be lucky to get the whole thing done within 30 minutes.

The same can be said for software installation. Something that seems routine for most developers or power users may only seem routine because we’ve dealt with it countless times, or because we’ve dealt with more daunting situations that required manual workarounds and hacks in order to get things working. One person’s routine can be another person’s out-of-this-world experience.

The value of feedback

This is why Mozilla is actively taking steps to improve the process by collecting feedback from users who canceled the installation.

Users who canceled could optionally provide the reason why they canceled, how the installation made them “feel” as well as any suggestions or comments they had. This formed the basis for the feedback results Mozilla compiled:

The fact that a significant percentage of the respondents were “confused” shows that they are some issues that the installer could make easier. The vast majority of this confusion stemmed from the fact that installer could not close an existing/running Firefox process, a step required for the installation/upgrade to proceed. This is a legitimate technical issue that can hopefully be solved.

Installation rights

The other significant factor, based on user feedback, was the lack of permissions required to install Firefox. Normally, Firefox requires administrative privileges on the machine in order to install it. This wasn’t a problem during the days of Windows XP, when users by default had these rights, but with the advent of Windows Vista this is no longer the case. Instead, users will typically be hit with a UAC prompt when trying to install software, which may deter them from completing the installation if they are unsure or unaware of what it means, something that is exacerbated by a user’s inexperience.

This article by TG Daily shows how some other browsers have simplified the installation process. Apple has started to bundle Safari as an “update” in an aggressive attempt to gain market share, while Google’s Chrome uses a lightweight online installer to speed up the installation process.

Easy or flexible?

Chrome’s installation approach is particularly remarkable in how it works. It requires less user intervention and furthermore, installs itself in the current user’s Application Data folder, which does not trigger a UAC prompt. (This also means that it must be installed for each user on a system, rather than being installed on a system-wide basis) Google also installs its updater, which runs in the background to keep any Google software up to date on the target system. Such a system is highly convenient for non-technical users, who don’t want to be bothered with manually keeping things up to date, but has drawn complaints from those more technically-oriented.

This highlights the differences a developer faces when creating an installation procedure. Typically, developers will lean towards providing the end user with as many options as possible because it’s the easiest way to solve a design decision. Can’t decide between X and Y? Let the user choose! This also goes along with the philosophy of power users, (a group that developers are pretty much a subset of), who like to know exactly what’s being installed on their system and what’s being done to it.

This contrasts with the needs of the typical user, who just wants the software to install as seamlessly as possible. I’ll have to admit, the Chrome installation procedure irked me a little, as I was more comfortable with the “normal” Firefox installation procedure, which gave you the option of where you wanted to install the software, etc. But ultimately, the Chrome installation process likely worked for 95+% of the users, so in the end that way wins out.

Lowering the barrier

Much can be learned from these results if you’re trying to get users to sign up for a service. In many ways, the process for signing up a user is like the process of getting the user to install software. Both require the user to entrust their resources to your service, and both require them to go through a series of steps. If the user really wants your service, they’re likely to put up with more of a hassle, but in general your aim is just to get them to try out what you’re offering, so you have to make things as simple as possible.

This is what I’ve tried (not sure if I’ve accomplished) with the RunTrackr registration process. Obviously, there are changes/improvements to be made. If the service were to get more popular, I’d have to implement more anti-spam/anti-bot measures, some of which might impede usability. But in general, I like the one-step registration process.

One of the things I decided from the get-go was to allow users to create routes without registering; this lowers the barrier required for them to create content and allows them to try out the service before committing to registration. However this has resulted in a lot of “unowned” routes created as an initial use. Following this, even if the user registers, they are unable to “claim ownership” of the route. One improvement I’d like to make is to tie in a “quick registration” option after the unregistered user has created their first route, allowing them to register and claim ownership of that route. I haven’t figured out the best way to do this, though.

However, I’ve been looking at Kijiji as an example of how this might be done. Kijiji is a localized online classified ads site, owned by eBay, and it allows users to post wanted/for-sale ads without registration. (The user must enter an email address to provide confirmation, as an anti-spam measure) However, after posting an ad, Kijiji makes it easy for that user to quickly register in one step and claim ownership of the ad they’ve just created. I suppose this is easy, since they already have the user’s e-mail address, but I would still like to implement something similar to improve the user experience.

IE6 is universally reviled among web developers for its poor support of web standards, namely with CSS and even PNG transparency. Many hours of hair-pulling frustration have been wasted when developing web applications, trying to “get things working right” in IE6 after having already spent so much time making a site look good in most of the other browsers. IE7, while better, is still not that great.

So, you may be surprised to know that I think the “War against IE6″ is misguided and perhaps a bit out of touch with reality. It’s not that I don’t believe in their message, but rather that I believe it’s somewhat impractical. The unfortunate reality is that support for IE6 will have to continue for some time.

Preaching to the converted

The article suggests using a conditional comment tag to show a nice “warning” to IE6 users, recommending that they upgrade to a newer browser, preferably one that isn’t IE at all. The “warning” is shown in a comforting green colour, suggesting peace and tranquility rather than the typical yellow/amber of other warnings. Note that this is much better than using a modal dialog box forcing people to read why you think they should stop using IE6.

For the most part, this message appeals most to those who stopped using IE a long time ago. These people are keenly aware of the drawbacks of IE6, and indeed even the drawbacks of IE7 and IE8. You don’t need to convince these people to switch, as they already have. But what about those that haven’t, such as the average user? Well, unfortunately they don’t care and are likely to be annoyed at yet another warning asking them to upgrade their software; to them, it’ll be indistinguishable from the plethora of ads, popups and such asking them to download and install software they don’t know about.

Technical details for the non-technical

The unfortunate fact is that most people simply don’t care about what browser they’re using. Furthermore, they don’t want to switch because what they’ve been using has worked for so long and from their point of view, it isn’t “broken”. Indeed, although Firefox has been nicely eating away at IE’s market share in the past few years, the real decline in IE6 happened when Microsoft started pushing out IE7. People generally won’t upgrade unless something is horribly broken or they are forced to.

This creates a sort of catch-22. You could code your website to not work at all with IE6, but then people would simply leave and go to another one. Only if absolutely every site out there did the same, would there be a chance of this having a real effect. This is apparently the goal of this campaign, but I fail to see how it will pick up “critical mass” since the early adopters will suffer the most if they alienate their users this way.

Restrictions to the market

Furthermore, as the article acknowledges, corporations are notoriously slow when it comes to adopting patches, upgrades and new versions of software because of the extra support and training required of their staff and IT teams. This is why you won’t find the latest versions of MS Office being rapidly deployed right on release day, nor will you find many businesses scrambling to install the latest Windows Service Pack on their workstations. Heck, many are still using XP and will continue to do so for some time. I imagine Windows 2000 still has a small but noticeable install base.

For this reason, IE6 still has a large install base in businesses. Heck, in my work place IE6 is still the standard, and indeed some of the corporate intranet sites only work in IE6. It is a damn shame and a travesty, but one that’s a reality of the corporate world.

Even technical people such as non-web developers still use IE6 at my workplace because of corporate policy. They are completely free to use Firefox or Opera (as I do) but “choose” or stick with IE6 simply because it’s there and that’s what they’ve been using for 5+ years. If these people can’t be bothered to switch, what’s to make even less technically-inclined folks switch? This reinforces the idea that people won’t switch unless it’s done for them, by default.

E-commerce: The big question

This sort of thing would never fly in the world of e-commerce, where your goal is to attract the widest share of users, not alienate them through an admirable, but misguided attempt to improve the state of the web. The goal of an e-commerce site is to make the flow of things and user interaction as smooth as possible. They last thing you want is a large warning, even if it’s in green, to disrupt the user.

This article clarifies that they are not trying to “dictate” to users what browser they should use, and then laughably suggests that “You can use any browser you want, so as long as it’s not IE.” (Paraphrasing)

Such a position would be suicide in the business world. IE still has significant market share, and like it or not, it will have to be supported for some time. This would be like refusing to write software for Windows when > 90% of your potential user base uses that OS, just because you don’t agree with its security model.

Summing it up

Let me reiterate that I agree with the principals of the “War against IE6″, having suffered much and sacrificed many hours at the IE6 altar, trying to get layouts and designs working right in that awful browser. I don’t mean to be negative, but am just trying to put a realistic spin on things. Ironically, we can look forward to increased adoption of Vista and the upcoming Windows 7 as ways to put the final nail in IE6′s coffin, even if it is in favour of IE7 and IE8.

Like many, I’ve been using Chrome occasionally ever since it came out back in September.
I never really had any problems with any sites, and was impressed with how fast it left the “Beta” stage, considering Google’s affinity for the term.

Initially, I had no problem using Hotmail with Chrome. (Yes, I still have a Hotmail account from years ago, even after switching to Gmail for almost all of my needs) But recently, it stopped working for me – basically, I could go to the Inbox, but clicking on any of the messages or trying to compose a new email would not working. Basically, none of the links worked. I can’t pinpoint the exact date that this occurred, but it was likely after an update to the Hotmail site.

The fix is really quite simple, which I found on the Chrome Help Forums. You just need to alter your shortcut to Chrome to add an option/parameter when it’s run. If you right-click the icon/shortcut that’s used to launch Chrome, you should see something like this in the “Target” field:

"C:\Documents and Settings\<user name>\Local Settings\Application Data\Google\Chrome\Application\chrome.exe"

Change it to this, adding the --user-agent option to the end.

"C:\Documents and Settings\<user name>\Local Settings\Application Data\Google\Chrome\Application\chrome.exe" --user-agent="Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Version/3.1 Safari/525.1"

Note that in the above two examples, user name is meant to be the folder of the currently-logged in user. Change as appropriate. Note that even though the help forum is talking about the 2.0 Developer Beta version, I found that this fix worked with the latest 1.0.154.43 release.

From what I gather, this “fix” just makes Chrome identify itself as another type of browser, which apparently makes Hotmail serve up the proper pages to Chrome. If this is true, this would mean Microsoft deliberately disabled Hotmail for Chrome users. This would not be surprising, as Google has been trying to sway users away from Internet Explorer (especially 6.0) by recommending other browsers (such as Chrome) when using Gmail.

It appears that the Browser Wars are again moving into webmail as a sort of proxy battle.

What’s good

On the positive side, there are some reports that Chrome’s market share has already surpassed that of Opera, coming in at close to 2.5% when I last checked. These results should be taken with a grain of salt, as Clicky’s web analytics might only be used by websites that tend to be visited by those more technically-inclined and thus more likely to try out something like Chrome. (Though Chrome’s visibility on Google’s main page no doubt has some small part in its fast growth)

For what it’s worth, Google Analytics on my lowly-trafficked site amounted to over 4% of hits in the past five days. (Google Analytics has since started identifying Chrome as a specific browser type, no surprise)

Chrome browser share on my site

What’s iffy

While the V8 JavaScript engine of Chrome was reported to be fast (myself included) Mozilla has fired back with their own results when compared to the upcoming Firefox 3.1, which also features a newer, faster JavaScript engine dubbed TraceMonkey.

Even if this only manages to bring Firefox 3.1 to within striking distance of Chrome for JavaScript performance, it’ll still easily hand the win over to Firefox 3.1 considering its much larger established base and support for extensions/addons.

Microsoft, meanwhile, still seems to have their heads in the sand when it comes to IE. True, IE7 still have a substantial margin on any other browser but that lead has been steadily sinking. Though IE8 will likely be a vast improvement over IE7 and seeks to erase all memories of the abomination that was IE6, it looks like Microsoft will have its work cut out with the stiff competition from Firefox and Chrome.

Problems

The release was not without controversy, as since this product was from Google, many privacy concerns were voiced. There were concerns about the “GoogleUpdate.exe” process that is installed with Chrome, which apparently allows for higher privileges to install software, which understandably freaked out some users. Generally, unwanted processes running in the background are just the thing the tinfoil-hat wearers are looking for.

Additionally, some keen-eyed users who perused the EULA discovered that Google had apparently tried to claim ownership of all content posted through Chrome. (Who actually reads a EULA?) Evidently, it was all a mishap, as Google quickly moved to correct the errors in the TOS. Apparently, in the rush to release Chrome, a “standard” TOS was used as the basis for the EULA, most likely similar to the ones covering services like Blogger, etc.

My own experiences

Personally, I’m very pleased with the browser. The “application shortcut” feature is very nice as it makes web apps like Gmail integrate very nicely with the desktop. I can’t wait to setup my Mom’s computer with shortcuts to things like Gmail that will undoubtedly make her life easier.

The JavaScript performance is very fast compared to other browsers, but some things like Flash are still buggy at times. This has caused problems with sites like Google Finance (which uses Flash for the charts) and YouTube, which are ironically Google’s own services.

I guess the “Beta” tag and the lack of a full version number excuse these problems, though it looks as if the list of bugs is already quite extensive. Google’s bug tracker for Chrome lists over a thousand bugs/feature requests currently, though likely many of them are duplicates. (Google is, however, following the trend of using the “Beta” moniker in an increasingly loose manner)

After much speculation yesterday, marked by a leaked web comic and finally an acknowledgment by Google, Google Chrome, the much anticipated web browser, is here.

I encourage you to download it and give it a try, as I did as soon as it came out. Here are some of my initial impressions.

Overview

Google released a fairly long web comic that delves into quite a bit of detail about Chrome – it’s not your typical comic! Touted as being built “from scratch”, Chrome uses the WebKit rendering engine, the same one that powers Safari and Konqueror.

The first thing you notice is how minimal the “Chrome” or UI of Chrome is. If you’re used to a half-dozen toolbars, buttons and widgets all over the place, Chrome will seem like a greenfield to you. By default, there is only a tab bar and then an address bar containing back, forward, a combined reload-stop button and the address bar. There are also buttons for bookmarking a site and for page and browser settings. The bookmarks bar is not displayed unless you specifically change that setting.

Keyboard shortcuts are also present so that you don’t have to click through context menus. If you’re used to the keyboard shortcuts of Firefox and IE7 you’ll be pleased to know that most of them transfer over without change: Ctrl-T opens a new Tab, Ctrl-W/Ctrl-F4 closes a tab, Alt-D focuses the address bar and Ctrl-J opens Downloaded Files.

The address bar also functions as a search bar, and this combination just makes sense. It’s something I’ve always been doing using Firefox Quick Searches

By default the home/start page is set to set to show an Opera-style “Speed Dial” page containing most recently-accessed pages/bookmarks. You can also configure Chrome to restore the previous tabs/websites on startup, which is my personal preference ever since I started using Firefox.

Features

Chrome integrates Google Gears to speed up supporting web applications and is an obvious effort by Google to self-promote. This is substantial since the download link for Chrome is on the main Google search page – no small feat considering only the most popular/important services get that sort of attention and furthermore the link is positioned dead center beneath the search field.

The address/search bar

Chrome allows for quasi-Site-Specific Browsers by use of “Application Shortcuts”, which can be set for any website but are meant to be used mainly with web applications. These allow you to open the target URL in a browser window that does not have the menu or address bars and essentially serves as a blank canvas upon which the web application’s own UI can be displayed.

This is similar to other SSBs such as Mozilla Prism or Fluid for the Mac, as they aim to bridge the gap between desktop and web applications to make their integration more seamless.

However, like Google Blogoscoped points out, using such non-browser interfaces may condition the user to be more lax when entering their credentials and makes phishing attempts more viable since no URL is displayed. This is curious since security, “sandboxing” and general safe browsing were so high on Chrome’s feature list – this feature seems to help undo some good user practices of always confirming the URL before entering credentials.

There are also some nice little enhancements as well – the combined address bar/search bar is very much like Firefox 3′s “awesome bar”. Chrome also allows you to dynamically resize any textarea element, without the site designer having to code this specifically in JavaScript or some other client-side technology.

Performance

Each tab/window is a separate process and thus will show up separately in Task Manager; Chrome also offers its own Task Manager but the memory usage reported here differs from that in the Windows Task Manager. To get the full picture, you have to click on the “Stats for nerds” link, which takes you to about:memory

This page displays the full memory usage details, and also, surprisingly, displays memory usage for any other web browsers also currently running! (I have confirmed that it will display Firefox 2/3, IE7 and Opera 9)

Much talk has been made of this feature; indeed while it does use more resources, it also prevents a single site from bringing down the entire browser as only that tab/window will be affected. To test this out, just terminate one of the instances of chrome.exe and you will see that tab’s screen into a “sad tab of death” with an amusing message.

JavaScript

Though JavaScript falls under the category of `Performance` I felt it deserves its own section because of the importance of JavaScript in web applications. Chrome uses the Google-developed V8 JavaScript engine, which has also been released as open source.

The main points of V8 are outlined at the Google Code page for the project, and are quite interesting. One of the main improvements in performance is the use of a Virtual Machine (VM) for processing JavaScript.

The V8 Virtual Machine is different from say, the JVM (Java Virtual Machine) in that it compiles JavaScript source directly to machine code; there is no intermediate byte-code representation used and hence no interpreter is needed for this. This seems to indicate that JavaScript performance might be faster on Chrome since there’s no intermediary. Google provides some benchmarks to confirm this.

From some informal/unscientific preliminary testing, the V8 JavaScript engine in Chrome does appear to be quite fast; loading the same Digg topic in Firefox took longer than it did in Chrome. (Roughly 14 secs vs. 8 seconds over a few trials – and Chrome did not have the benefit of AdBlock Plus) I’d be very interested to see how Chrome stacks up against Firefox 3.1, considering the rumoured performance boosts coming with it.

If Chrome has anything going for it, it’s definitely the lightning fast JavaScript performance. Coupled with the crash-proofing this makes it ideal for use in web applications.

Development

Chrome comes with a nice DOM inspector reminiscent of Firebug. Using it is dead simple; you just right click and select “Inspect Element” and the inspection window will pop up with the element highlighted. Here you can see the full DOM tree as well as the computed CSS styles for the element.

There’s an included JavaScript console for executing code/commands/expressions on-the-fly and while there is a JavaScript debugger included, it seems at this time to be a command-line only tool, far less user-friendly than Firebug.

Not ready for prime time yet?

Of course, Chrome is marked as Beta by Google, something we’ve come to expect since Gmail has been in beta for longer than the company has been publicly traded. Nonetheless, there are still some features that are sorely missed.

The one thing I absolutely love about Firefox is the vibrant developer community and subsequent widespread availability of quality, useful extensions. This has produced such gems as the aforementioned Firebug and Adblock Plus.

For now, extensions/addons are not part of Chrome but may be added in a later version. In the meantime I don’t think I’ll be even close to ready to switch, as I’m very stubborn. I don’t use that many extensions but the few that I do are “must-haves” and I just can’t browse without them.

Lastly, there are always privacy concerns, especially from a company as big an involved as Google. Though you can turn off the sending of usage statistics, there will always be some with their tinfoil hats on.

Conclusions

All things considered, Chrome is a very good entry into the browser market. While I don’t think it’s ready to take on Firefox or IE yet, it does provide competition. So as long as Chrome continues to support standards (which I think it will, since it uses the WebKit renderer and Google has also been forthcoming with their support for web developers), I won’t have a problem with it. I won’t be switching over to it anytime soon, but at the very least it’ll be a useful development tool to verify/test my websites on to make sure they look proper in Safari/Konqueror/Chrome.

The issue was with an Ajax request I was sending. The return value was an array in JSON form. More specifically, the server was returning something like:

{tag:[{id1:'A',id2:'B'}, {id1:'A',id2:'B'}, {id1:'A',id2:'B'}]}

This was perfectly valid and worked fine in both Firefox and Internet Explorer. However, in Opera 9.26, I got a JavaScript error indicating that the JSON was not valid. It was then that I realized I was using an older version of jQuery, v1.2.2. Upgrading to the latest, 1.2.6 fixed the problem. Strangely, I could not find anything on their bug tracker indicating that such a problem (JSON and Opera) had been fixed.

What was even more interesting was that upgrading to Opera 9.50 also solved the problem independently; that is, things worked fine even with the older version of jQuery. This goes to show the importance of keeping your software up to date and highlights the complicated interactions between different browsers and client-side code in a web application.

If you’re into web development you’re likely aware of the big news from Microsoft that Internet Explorer 8 Beta 1 is now available. This comes less than 1.5 years since IE7 was released, and represents a much faster development cycle than was observed with IE7. (Over five years passed between the initial release of IE6 and IE7)

With Firefox Beta 3 released not long ago and the final version due in the first half of 2008, Microsoft has been feeling the heat and probably has decided to devote real effort towards improving Internet Explorer in order to regain market share lost mainly to Firefox.

However, what’s most interesting and impressive about IE8 is not its fast follow-up to IE7, but its broad support for web standards and other improvements that many did not expect, especially after the poor track record of IE6 that wasn’t improved much by IE7.

Be Ready

Microsoft details the many important changes IE8 will bring in their IE8 Readiness Toolkit. Besides passing the Acid2 test (MS has created a list of CSS 2.1 Test Pages/Cases), the browser also natively supports the hAtom Microformat in order to implement what MS calls “WebSlices”, which are basically portions of a webpage that can be subscribed to, much like an RSS feed. The example shows how to mark up an auction item and its price so that the content can be easily be scraped, organized and read by an aggregator.

Other improvements in the area of JavaScript are also appealing. In the area of Ajax, MS is pushing a Cross-Domain Request model (XDR), which would overcome the same-origin restrictions of the current XHR object. It is claimed that this is secure, but we’ll have to wait-and-see if this also adopted by other browsers. Hopefully it is, if its proven to be an open and robust standard – after all, XMLHttpRequest did start off at Microsoft. Whatever the outcome, clearly a solution to the same-origin XHR policy must be found, since current workarounds (such as injecting a script element into the document) are cumbersome at best.

IE8 has also addressed the JavaScript circular memory leak problem seen in previous versions. This problem can occur because of careless coding that creates references and situations that the previous garbage collector could not deal with properly; basically, if two objects referenced each other (with their properties), they would never be considered “dereferenced”, even if no other references existed for them. This has the tendency to eat up memory, and unfortunately, it’s quite easy to do this accidentally in JavaScript. Fixing this problem is especially important now that web applications are increasingly relying on complex JavaScript for features.

From a user point-of-view, IE8 adds a lot of social-web and other features that cut across multiple websites. For example, it’s easy to share a website on Facebook/Digg, or select an address on a webpage and look it up using Microsoft’s Live Maps service with the built-in functionality. What remains to be seen is if IE8 will develop a vibrant third-party plugin community like Firefox has – this has been one feature of Firefox that I simply couldn’t do without, and it allows you to easily add functionality that’s not present in the core.

Hope for the future

All of this may come as a shock to web developer, who for years have had to deal with IE’s hopeless inadequacy when it came to following web standards. Far too often, the development cycle would look something like this: 1) Get it working in a standards-compliant browser (like Firefox or Opera); 2) “Hack it” to get it to work properly with IE. Though I have not had a chance to properly look at IE8′s beta, it appears that this version will finally get things right, making things much easier for us all. Microsoft has claimed this to be part of their interoperability push, but I believe it’s a push to be more like Firefox to slow the flow of users who are switching from IE to Firefox.

The biggest change, and perhaps the most recent, to IE8 was Microsoft’s reversal of how they’d handle standards mode. Previously, they had decided that true standards-mode would only be invoked on the browser’s rendering engine if the web page specified it. That is, by default, IE8 would use a quirks-mode compatible with how IE7 had worked. This was utterly stupid and contrary to the nature of web-standards. A standard should be used by default!

Furthermore, the only reason behind this decision was that MS did not want to “break” how IE8 worked with websites that were previously designed to work with IE7′s not-so-standards mode – a problem that they had created by not following standards in the first place. This sort of reasoning effectively slows adoption of standards, since it creates a chicken-and-the-egg problem – if the dominant web browser doesn’t properly follow web standards, neither will a significant number of websites. Thankfully, Microsoft decided that the chicken’s (or the egg, if you will) time has come, and that IE8 will support standards mode by default – the way it was meant to be.

Some things do concern me, for example, the way “Activities” are implemented. Currently, a website can add in an activity with the following code example from the IE8 site:

<button onclick="javascript:window.external.addService('GetMap.xml')">Add Map Activity</button>

The “GetMap.xml” file points to XML that describes the activity’s functionality. So as long as other browsers/plugins aren’t prevented from implementing support for this, things should be okay. Otherwise, we risk a disturbing slide back towards the day when sites were “best viewed in “.

(As a side note, I understand that the example code was for brevity, but the best way to invoke JavaScript on a page is not using an inline call like that, but in a separate JavaScript file using proper event handlers. Also, one should test for the existence of a method that may not exist, before calling it. Checking for user-agents/browser versions is a big no-no. As far as I know, window.external.addService is IE8-only right now.)

Looking forward

Overall, I’m very pleased with what IE8 promises. It’ll be interesting to see how fast it is adopted by the masses and how this measurement compares with how fast IE7 was adopted. We’ll also get to see if Microsoft’s adoption of web standards has an effect on its share of the browser market.

While everyone (myself included) has applauded Microsoft for making moves towards supporting standards, a mere slight improvement over IE6 is not enough this time. I mean, come on – they’re Microsoft, one of the largest software companies out there. Why can’t they seem to get things right?

The bane of web developers and designers

It’s a well-known secret among those involved in making websites that IE6 is horrible when it comes to supporting CSS (Cascading Style Sheets), a format for defining how webpages should be presented. Provided you’re not doing everything in Flash, and care about web standards, you’ll quickly find that you have to learn CSS in addition to (X)HTML if you want to properly design a website, possibly in addition to server-side technologies.

Designing your first website using CSS for the presentation, you’ll quickly find that IE6 is the odd one out, and hardest one to “make things look right” in. Out of all the selectors in CSS 2.1, IE6 only supports a few of them. Additionally, many of the pseudo-selectors, such as :hover, only work on certain elements. Boo-urns!

As most web developers/designers have switched over to a different browser, either by choice (Firefox/Opera) or because of necessity (Safari), they’ll quickly find themselves always having to refer back to IE6 to “fix” the site once things are already looking great in the other browsers. Thus, IE6 has been the target of many a web designer’s curses throughout the course of history. (Perhaps similar to how Netscape 4 caused many headaches years ago – but maybe not as bad as that!)

Corporate lethargy

Some would suggest this is merely the result of Microsoft growing too large and becoming a dinosaur of sorts, not able to respond to changes in the marketplace. A good example of this is their Live-series of web-based services and applications, most of which seem to be inferior to competing products offered by other companies. In this respect, it seems that Microsoft caught on a little too late to this trend.

However, I don’t think this is the case with IE7. Microsoft, by all accounts, has talented people working for them – there’s just no way they could have become so successful without talent. Microsoft research in particular has some really smart people working for it – an MS researcher recently visited our lab last month, and I was impressed not only by his depth of knowledge in his field, but also his breadth of knowledge. He seemed to know, in quite some detail, about each of the areas the people in my lab were engaged in.

Shunning standards?

Therefore, it seems that solving a problem like making IE7 standards-compliant can’t be that big of a problem. I mean, they have had five years – and other companies like Mozilla and Opera have made browsers that fairly standards compliant, with Opera being a bit better than Firefox at standards support. One argument could be that they don’t want to release a browser that’s so different from IE6 that sites will “break” on the new IE7. This isn’t accurate though, as they’ve already made enough changes to virtually guarantee that sites “made for IE6″ will break on IE7.

As much as I hate to say it, some believe that IE7′s lack of support for standards is something that’s been deliberately “implemented”. HÃ¥kon Wium Lie, of Opera software, best sums it up in an interview on Slashdot:

It’s quite clear that Microsoft has the resources and talent to support CSS2 fully in IE and that plenty of people have reminded them why this is important. So, why don’t they do it? The fundamental reason, I believe, is that standards don’t benefit monopolists. Accepted, well-functioning, standards lower the barrier of entry to a market, and is therefore a threat to a monopolist.

From that perspective, it makes sense to leave CSS2 half-implemented. You can claim support (and many journalists will believe you), and you also ensure that no-one can use the unimplemented (or worse: buggily implemented) features of the standard. The only way to change the equation is to remind Microsoft how embarrassing it is to offer a sub-standard browser. And to use better browsers.

What he’s saying is certainly plausible – Microsoft has been known to engage in anti-competitive practices, and after all, anti-competitives practices are really sound (but perhaps not ethical) business strategies that only become available when you’re the clear market leader. And, when you have shareholders always squeezing you to make more money, sometimes business strategy can take a more sinister direction.

I want to stop short of actually declaring MS to be engaging in anti-competitive strategies here (though a compelling argument could be made for this), but I will say that the effects of their actions, for whatever motivations, are horrible for web development. Internet Explorer 6 was a big enough problem, as since it’s the majority market holder, professionals in website development had to account for it – there’s just no saying “Screw non-standard browsers”, when your expected client base is 80% (or higher) IE6. And, with the release of IE7 (to be pushed to users automatically), more problems will be created: sites made to work with IE6 will probably not work too well in IE7, and vice-versa. Clever tricks, whether through CSS or JavaScript will eventually provide work-arounds, but all of this adds substantially to the development time for a site.

So much for the chant, “Developers, developers, developers!” Microsoft, please fix IE7 before it’s widely released, and you’ll be sure to receive heartfelt thanks from many formerly-frustrated developers out there.