I recently dumped Firefox 7 and relegated Firefox to the occasionally used computer corner where I store all my various testing tools. After sending several emails to Mozilla, blogging about how terrible the new release is and tweeting about it…I heard not a peep, zero, zippo. Which is strange. It’s rare these days to not hear anything back from an organization, especially when you make a complaint on social media that’s backed by a blog post. I supposed I’m just one small voice in the sea of millions.
So, I’ve done what consumers do and voted with my feet. I dumped Mozilla in favor of Chrome, which has been elevated to the lofty status of what they call the “Default” browser. I’m still getting used to Chrome and recently had some issues with accidentally closing tabs. And, it’s developer tools are a bit more rustic than Firebug or httpfox’s polished functionality. But, it does seem faster and it’s definately more stable.
So, that’s that. The browser wars continue, especially on the mobile front. By the way, I did briefly try Firefox mobile but dumped that also because the work flows were too ackward. There will be dozens of new browser updates in the next year, who knows what new excitement is in store.
We’ve finally reached the point where the number of browser updates is out of control. There’s an all-out war between the various browser companies to see who can push out the most updates and improvements in the shortest period of time.
All these updates are causing a ripple effect on everything else that is dependent on the browser; for example, plug-in vendors, IT support staff, computer and smart phone vendors, application developers, any company that has a website, and your average consumer. I’m guessing that on average the pace of updates is starting to outpacing business and consumer’s ability to keep up…and it seems to be accelerating.
Yes, I wholeheartedly agree we benefit from the advancements. No argument there. However that is balanced by reality. And, reality is architecting our products to support the latest and greatest. There is also the fact that most of us also have to maintain support for older versions of browsers and there is a cost associated with backward compatibility. And, there is a cost to upgrading. Not everyone is able to update all the time.
As a case in point, let’s take a look at Firefox since it’s fairly easy to find an archive of their older releases. We are only seven months into the year 2011 and Firefox has had two major releases: Firefox 4 and Firefox 5. However, if you include releases candidates, betas and updates to Firefox 3.x the total number climbs to around twenty-two releases so far this year. Yikes!
Sure, most consumers only saw the two major updates: Firefox 4 and Firefox 5. But, they also experience a plethora of plug-in updates. For example, Flash Player has had eight updates so far this year. Silverlight has had three general distribution releases this year and one beta release of Silverlight 5. And, I wasn’t counting but it seems like I’ve had a bunch of Adobe Reader updates in the last few months.
My concern is that the speed of browser innovation is starting to cause businesses and consumers to get fatigued. It begs the question: how long can the ecosystem of browser consumers maintain this pace? Or, at what point do people just start jumping off the bandwagon and simply starting skipping releases? Do most consumers really care if their browser is now 100ms faster in parsing JavaScript? How many new ways can we create tabs?
In summary, I think browser vendors should slow down and become better custodians of their systems. How about also focusing on innovation in security, memory leaks and best practices documentation and vendor-provided validation engines? Indeed, they have sparked tremendous innovation across the entire world wide web since Mosaic released in 1993. But, depending on how many websites you visit, you can still experience slow web pages, in-consistent cross-browser support and browser crashes. I know there are no easy answers because competition breeds creativity. Perhaps we’ll all go back to just looking at basic text, pictures and videos in the future. And, there will just be specific widgets with very focused functionality for other things.
Having a basic understanding of how our web applications affect browser performance is the key to determining whether the apps you build will be great, and which apps will be a miserable experience for your users. You can have the worlds’ best looking app with the nicest user-interface ever, but if it runs horribly on most visitors machines or phones then you’ve done your end users a massive disservice.
I contend that the browser as a web application programming environment should be treated as its own operating system with its own well defined dependencies. If you have a basic understanding of how these dependencies work, you’ll be able to build better, more stable, faster applications.
We are constrained in what we can build because browsers provide a finite environment in which to play in. To make things even more fun and challenging, in just the last five years we have gained access to some very powerful tools to build even more complex applications, such as Microsoft’s Silverlight API, and Adobe’s Flex/ActionScript API. Now we can build applications with very rich graphics in days or weeks that would have taken many months or even years before these tools became available. And, web applications until only recently gained the ability to semi-directly interact with the operating system to perform operations such as save or retrieve files from local hard drives. In the ‘dark ages’ we had to bounce files off a proxy server before being able to download them to the local machine. How we interact with the local machine is ultimately controlled by what the browser will allow.
The browser sandbox
Browsers provide us with a well-defined sandbox in which our apps can run, and from a developer’s perspective it includes the following:
Cache space (includes cookies and local stores like in FlashPlayer)
Access to the internet
Access to local resources
It’s also important note, and if you’ve been building web apps for a while now you’ll know, that browser vendors don’t implement the various proposed standards exactly the same. For example, Internet Explorer may display a certain CSS tag different. Here’s an interesting comparison chart.
What about hardware?
I’m also not saying we don’t need to pay attention to the underlying operating system. In fact, we absolutely do need to pay attention to the following. However, we interact with them only indirectly, and because of that we tend to forget just how important they are:
CPU
Memory
Graphics card
Internet connection
Mobile devices are a great example. Mobile devices are getting more powerful all the time, but when they try and chug through a fully decked out web page, it takes them longer than a typical desktop or laptop. I’ve had developers tell me an app that’s running slow on everyone else’s machine was running just fine on theirs. What the developer forgot was he had the latest, greatest, hottest laptop out there with 8 GB’s of memory and an excellent internet connection! By way of example, I posted a screenshot at the bottom of this post of another website that even my quad-core laptop used between 50 – 80% of its resources to load the page.
Simple Tests
Here are some simple tests to tell if you web app is a good one that will meet the needs of your end users:
How much CPU does it consume? Test it on a moderately configured machine, typical of what your users might have.
How much memory does it use? And, how much memory over time? Browsers can be notoriously leaky, but your program may be contributing to it.
Is everything in the correct locations in the user interface at various common browser sizes? (e.g. 1024×768, 1280×800, etc.)
Does it cause temporary slowdowns or lockups?
Does it crash the browser or browser panel?
Does key functionality and layout work consistently across the major browsers?
Does your app work consistently across all the devices you wish to support, including mobile?
A Few References
Here are a few articles and websites for that are handy to have as references:
