Big question: how do faster browser releases affect your work?

Browser updates are being released more frequently, but is changing quickly all that it’s cracked up to be? We consult our experts

Speaking as a browser vendor employee, our move to accelerated released cycles has mainly been great for our work: bug fixes and new features are rolled out more quickly, which alleviates developer and user frustration.

The main problem area, I believe, is likely to be the enterprise, where a system admin might have to test a new browser version and roll it out to potentially thousands of machines. Having to do this more often could be a real pain point.

I’m quite happy with the accelerated release cycles, although Mozilla have gone from fairly slow to extremely fast, even in the last couple of months. I’d like to see a happy medium between the two but as long as the release notes are being read and understood it doesn’t alter the way in which any of us should work in my opinion. Accelerated release plans aren’t a bad thing: we’d complain if they were going too slow.

It’s great that browser makers are pressuring each other into making better and better browsers: we all win from that. The way Chrome (and to a lesser extent, Firefox) handles upgrades makes it more feasible to use new features, such as prerendering, which is great. I think IE, despite all its progress, will continue to be a problem – there are going to be a lot of versions of that floating around, for a long time.

I’ve had a bee in my bonnet for a little while now about this subject. In essence: Chrome has it right, and everyone else is doing worse to some extent, but especially Mozilla.

While I applaud Mozilla’s dedication to improving Firefox quickly, without the seamless upgrade process Chrome provides (behind the scenes, without a version number in the browser’s name) it risks becoming a support nightmare.

Browser extensions are just one area where that effect is already visible. Firefox automatically disables any extensions that are not explicitly marked as compatible with a new version. On some level this makes sense, to prevent extensions from making the browser appear broken, but when their release cycles are so short, it means extension developers must update their extensions (and resubmit to Mozilla’s Add-ons gallery) even if there’s no change other than the version number support.

This isn’t practical, and shouldn’t even be required unless Mozilla changes something that extension developers have access to (and even then, Firefox ought to be smart enough to know if an extension uses anything that has changed or might break because of changes to the updated browser).

In general, I love the fast updates – each one brings us closer to a web where we have to waste far less time testing for compatibility, instead putting that time and energy to good use (for example, building things and making them better).

A lot of it boils down to how the existing code is affected by the release. Vendors that are releasing frequent bug fixes or new features – while leaving the existing functionality in place – is a developer’s dream. The issue comes when each release slightly tweaks the way the existing code works, forcing the developer to have to change their code if they want to use the latest release.

A good example of this is jQuery. With each new release, they still provide backwards compatibility for older functions and methods, while fixing and adding to the feature set. For the most part, you can feel comfortable upgrading your jQuery version, while leaving your existing JavaScript code in place.

Chip is a consultant, developer and designer specialising in PHP development

Chrome’s system of pushing new versions every six weeks and silently upgrading users is the best system out of all the browsers. It’s like web-based software. You don’t have to be bothered to download and install stuff when Gmail has new features, they’re just there. It makes sense that the thing web software runs inside of behaves the same way.

Unfortunately, until all the major browsers do this it doesn’t affect my workflow all that much. I can’t wait until it does though. I love the idea of being able to drop a vendor-prefixed property the day a browser implements a spec version, because all users are immediately running the new version that supports it.

I think the fact that we’re seeing rapid evolution in the browser market is a good thing overall. The constant updates mean no one version is sitting on the shelf, gathering dust the way IE6 did, but it’s not all wine and roses either.

For me, as a developer, it means I have to do at least basic testing against three to four (and sometimes more) versions of each browser on each platform. That increases our per-project QA time dramatically. As our agency is focused on progressive enhancement, it doesn’t pose much of a problem for us, but (on occasion) the rapid release cycles introduce catastrophic bugs that can’t be neatly side-stepped. Bugs and regressions aside, we’re also seeing the “chrome” end of the browser evolving faster than the add-ons many of us rely on can keep up (especially given that most of them are not for-profit extensions and are being created and maintained on the developer’s free time).

As a web professional and standards advocate, I’m excited by the rapid evolution of the browsers and the technologies they’re supporting, but as someone who also has to test on them and as a consumer who keeps getting notified that a new version of Firefox is out … it’s becoming a bit of a pain in the ass.

Our work isn’t typically designed for an unknown audience, our clients are particularly interested in targeting a specific demographic and geographic. This information is key to informing our solution to a brief and determines what browsers this audience is likely to be using.

Campaigns aimed at a teenage audience in North America are likely to be using a modern smartphone or desktop browser. As we found from our work on campaigns for the world cup in 2010, a similar audience in South Africa is typically using feature phones, as broadband penetration is low. Targeting users in China often requires supporting early versions of IE, where this is the dominant browser. We use statistical data on the audience to determine what features we can expect to use in our solution.

As browser vendors continue to increase the performance of JavaScript and provide native display performance in graphical effects with CSS3, we are developing ever more exciting native browser experiences instead of having to rely on Flash. The popularity of iOS based devices and the lack of Flash support has tipped the scales, ensuring that Flash is rarely considered an option.

The acceleration in the release cycles ensures that we can strive for ever more immersive experiences without having to wait for years to push the creative envelope. This is incredibly exciting for our creative and development teams, but it creates some new challenges too.

At AKQA, one of our core values is Quality, which we guarantee through rigorous testing. The migration from testing a discreet number of browsers on key OSes to an extensive matrix of browser vendors, versions and OSes has its implications in time and cost.

Depending upon the browser, this acceleration in releases has created either a universe of competing and conflicting versions or a core audience of users running the latest version.

Chrome, Firefox and Opera are auto-updating, ensuring that users can simply upgrade their browser by clicking through a number of confirmation messages. The resulting user base on older versions is therefore relatively small, which may be considered irrelevant to our solution design or testing.

Updating IE, however, is far more challenging, users have to be familiar with Windows Update picking the key updates required or update everything. Large scale updates are enough to put off most users. The result is a large number of users running a variety of IE versions, including major releases and point updates. This creates significant issues for our teams as the capability, performance and quality of IE ranges dramatically between versions. Depending upon the campaign and target audience this results in increased time and costs.

Microsoft isn't helping things either. While the latest releases of Chrome, Firefox, Safari and Opera continue to support Windows XP, accounting for 50 per cent (according to NetMarketShare) of the PC desktop market, Microsoft stopped with IE8.