IE Market Share Slips

A Net Applications study (via ReadWriteWeb) says IE’s market share has dropped to 67%:

This is an interesting trend. The actual quantity of market share will vary with methodology, but a 7% drop in a year is something to take note of. Moreover, as Readwrite points out, there are two things that will probably make the trend continue:

  • The upcoming launch of mobile Firefox. I would also extend ReadWrite’s point to cover the whole role of mobiles in general. The iphone’s browsing share is now around 0.6%, a massive figure for a single phone. A popular phone to say the least, but one that still has a tiny share of the overall phone market. Just as basic mobiles are standard now across most of the planet, including developing countries, we’ll be seeing a saturation of smartphones over the next few years. You can only say “but I just want to make phone calls” for as long as you don’t see all the benefits others are deriving from all the other features. And we can be fairly certain that Firefox, Opera, and a whole range of niche browsers, many not yet born, will have the lion’s share of browser action. Having struggled reluctantly with MS phones, I know personally the operating system is light years behind and mobile IE doesn’t even have multiple tabs; it’s not even in the race right now for anyone who has a choice.
  • The trend towards cheap notebooks. Implicit here is RW’s assumption that many will run Firefox on a custom Linux distro.

I was recently in a discussion with a developer who was considering an MS stack involving Silverlight on the client. His argument was about efficiency of development. I could debate that, but the greater point here is that we’ve gone beyond a time when it’s reasonable to go to market with an IE-only app. (I realise Silverlight is technically not just IE, but I am coming from a point of pragmatism here, and anecdotally you don’t want customers running Silverlight on other browsers and non-MS operating systems.). Even if it were more efficient to develop with MS tools, the constraint is too great.

In many organisations, people are exercising choice and using various browsers. Say you have 20 people in a company who are all potential users of your web app. What is the chance that all 20 will be using IE? Improbably low, assuming 67% chance that each is using IE. (Okay, somewhat of an exaggeration, because their usage will be correlated as they work in the same place, so it’s not 0.67^20; but still, gut feel is that at least a few people here will be running the Fox.) Even if the corporate standard is IE, I’ve never worked in a company that truly enforces their standard (thankfully for developers in particular), so I’d be willing to bet there will still be a number of folks running Firefox. By releasing a product that only runs on IE, you’re basically guaranteeing that it won’t run on all potential users’ browser of choice. Not a showstopper perhaps as they can still fire up IE – if you’re fortunate enough that they’re running MS – but still a great way to make your product unpopularly received. It might still be mandated if the decision is a central one involving a faceless someone or committee who could care less what browser it runs on; but it’s also possible that the decision-maker will be a Firefox, Safari, Opera, or Chrome user, and will be suitably unimpressed with a late ’90s style IE-only offering.

Ajax Diagnosis And Testing Patterns – Podcast

Welcome to Ye Olde Ajax Patterns Podcaste, the final in this series that began twelve months ago. 3+4+4+1 = 12 podcasts in all, covering 71 patterns (the 70 patterns in the the book as well as Dyanmic Favicons). Find them all on the podcast category – or subscribe to the podcast feed at Thanks for listening!

This podcast covers eight patterns on debugging/diagnosis of Ajax Apps, as well as testing Ajax apps, and I’m joined by Craig Shoemaker from Polymorphic Podcast, also a co-author of “Beginning Ajax with ASP.NET”. After some announcements, the interview begans at 6:00. The podcast overall is 60 minutes.


p> Ajax Diagnosis Patterns:


p> Ajax Testing Patterns:

With the series now complete, the podcast will now resume regular Sotware As She’s Developed topics including but not limited to agile development, Ajax, the web, and usability. Also, more conversations – please drop me a line at [email protected] if you’d like to come drop in for a skype chat.

As always, credits on this podcast to My Morning Jacket for the lead-in track, “One Big Holiday”. All podcasts in this series licensed under CC.

Audio Note: Sorry about the noise at some stages in this recording – I now know a lot more about audio levelling (the problem of keeping both ends at the same level), but at the time this was recording, it turned out I had set Craig’s end at too low a volume. I used Levelator to level each end, leading to too much noise…next time I’ll need to pump up the volume at each end from the start. I’m also looking forward to resuming use of Bias SoundSoap, but there’s no easy way to get this running on an Intel Mac for now!

Portable Comet? It’s the IFrame, Stupid!

Comet Takes to IE Like a Fish Takes to Acid

Comet – or HTTP Streaming, if you will – is a little sensitive when it comes to portability, and I’ll give you four guesses which major browser is causing the grief? Yeah, IE makes it difficult for two reasons: (a) IE’s XMLHttpRequest component doesn’t tell you anything about the response until the connection has closed – even if you try polling it instead of relying on onReadyStateChange, you’ll still get an empty string (Try it); (B) Okay, switch to plan B and inspect IFrame content – we can’t rely on onload, which is only called once at the end, so we must poll. But no, polling won’t help either, as the IFrame content remains empty until (you guessed it) the connection is closed. (Try it).

We’re Going Back, Way Back: Inline Script Tags

Don’t give up on the IFrame so fast … we’re closer than we think. Actually, the solution harkens back to one of the original Push techniques: outputting script tags with inline code (what the HTTP Streaming pattern calls “page streaming”). If you do that in your main document, the code will be executed immediately, and the same is true if you do that inside an IFrame.

I’m talking about a service that outputs stuff like this:

  1. <script type="text/javascript">
  2.     doSomething();
  3. </script>

So Make the Server Spit Out Inline Script Tags

The portable solution is this: Have the server continuously output script tags that call a known function in the parent frame. When you set the child IFrame’s source to point to this service, it will start evaluating the inline scripts as they pop out of the server. This happens to be one technique people have used for remoting for many years (I think Brent Ashley recently told me he was doing it in ?1999). The twist with Comet is that you keep doing it, and don’t actually close the connection for a while. (Again, I’m sure some people were doing that for a long time too!).

Is it elegant? No. It means the remote service is suddenly coupled to the client-side of the web app – it has to know something about what’s in the parent frame, whereas you’d often like it to be generic and just deliver a response in XML, JSON or whatever. Like most things Ajax, we’re using a hack because it nonetheless push all the right buttons for our users.

Try It. Portable Comet for the Masses

Here’s Some Code I Prepared Earlier

In the example above, the remote service outputs script tags in a loop – it’s a simple countdown service:

  1. <?
  2.   for ($i=$_GET&#91;"start"]; $i>=0; $i--) {
  3. ?>
  4.   <script type="text/javascript">
  5.     window.parent.onNewValue(<?= $i ?>);
  6.   </script>
  7. <?
  8.   }
  9. ?>

And in the browser’s initial Javascript, there’s a run-of-the-mill onNewValue() function, it looks something like this.


  1. function onNewValue(i) {
  2.   statusDiv.innerHTML = i; // Paint the new value onto the page
  3. }

See what I mean about coupling? The server-side service had to know that there’s a Javascript function defined in the parent called onNewValue(). At least we’ve minimised the coupling by using an Observer/Event style indirection approach – evidenced by the simple call to “onNewValue()”. It would be worse if it was the script that actually performed application logic directly, repainting the DOM with the new value.

IFrame is the new XMLHttpRequest

Whoever put the X in Ajax ought to put an I in Comit. IE’s XHR component doesn’t provide the response until the connection has closed, and I don’t think version 7 changes that. Assuming (graciously) it happens in IE8, you’ll need to use IFrame for the next five years if you’re doing any Comet work. And of course, you won’t need to do that, because libraries will do it for you.

BTW You could argue that IE is doing the right thing by preventing access to the content until the connection is closed. Maybe they are, maybe they aren’t. From a pragmatic perspective, though, portable Comet requires Ajax. Alternatively, use IFrame with IE and XmlHttpRequest with the others, though I’m not sure if there’s much mileage to be gained from this hybrid strategy.

Who Needs These Browser Warnings?

Setting up a new Windows PC today and not loving the browser warnings.

The messages, as I recall them: “You are about to submit the form. It’s dangerous.”, “You’re going to leave the page. It’s dangerous.”, “This page is encrypted. It’s dangerous.”, “This page is not encrypted. It’s dangerous.”, “This is H20. It’s dangerous.”

So my question is, who’s benefitting? At this stage, the majority of internet users have been submitting forms and using encrypted pages for 5+ years. And if they’re a newbie, is it any more useful to them? (Hint: No.)

The only thing it does is add overhead to setting up a new system. You have to stop and think, “Hmmm is this a negative, double-negative, or triple-negative question? Ah, okay, I think I’ll leave the checkbox unchecked so as to imply I don’t want to not submit the form. And also, I’ll leave the ‘Don’t show me again box’ so it doesn’t not show me again.”


  • Only provide dialog boxes that are useful, otherwise users will ignore them all.
  • Avoid not excluding negative phrasing in your options. Even if the most likely value is negative, you should still phrase it as a positive. (“Remember this” as opposed to “Forget this” or “Don’t remember this.”)

HTTP Streaming: An Alternative to Polling the Server

If Ajax apps are to be rich, there must be a way for the server to pass new information to the browser. For example, new stock quotes or an instant message someone else just sent you. But the browser’s not a server, so the server can’t initiate an HTTP connection to alert the browser. The standard way to deal with this dilemma is Periodic Refresh, i.e. having the browser poll the server every few seconds. But that’s not the only solution.

The recent podcast on Web Remoting includes a discussion of the HTTP Streaming pattern. By continuing to stream information from the server, without closing the connection, you can keep the browser content fresh. I wasn’t aware that it was being used much on the public web, since it can be costly, but I recently discovered JotLive (which is only semi-public since it requires registration) is indeed using it. Do you know any other examples?’s interview with Abe Fettig of JotLive:

How do you handle the “live” part? Polling?

We’re using a (very slightly modified) version of LivePage, which Donovan Preston wrote as part of Nevow, a Python library for building web applications using the Twisted networking framework (which I just wrote a book on: Twisted Network Programming Essentials). LivePage doesn’t use polling. Instead, it uses a clever technique where each browser keeps an open XMLHTTP request to the server at all times, opening a new connection each time the old one closes. That way every client viewing the page is constantly waiting for a response from the server. When the server wants to send a message to a client, it uses the currently open request. So there’s no waiting.

A few (edited) extracts from the HTTP Streaming pattern:

Alternative Pattern: Periodic Refresh is an obvious alternative to HTTP Streaming. It fakes a long-lived connection by frequently polling the server. Generally, Periodic Refresh is more scaleable and easier to implement in a portable, robust, manner. However, HTTP Streaming can deliver more timely data, so consider it for systems, such as intranets, where there are less simultaneous users, you have some control over the infrastructure, and each connection carries a relatively high value.

Refactoring Illustration: The Basic Wiki Demo, which uses Periodic Refresh, has been refactored to use [](HTTP Streaming).

Stream server data in the response of a long-lived HTTP connection. Most web services do some processing, send back a response, and immediately exit. But in this pattern, they keep the connection open by running a long loop. The server script uses event registration or some other technique to detect any state changes. As soon as a state change occurs, it pushes new data to the outgoing stream and flushes it, but doesn’t actually close it. Meanwhile, the browser must ensure the user-interface reflects the new data. This pattern discusses a couple of techniques for Streaming HTTP, which I refer to as “Page Streaming” and “Service Streaming”.
“Page Streaming” involves streaming the original page response. Here, the server immediately outputs an initial page and flushes the stream, but keeps it open. It then proceeds to alter it over time by outputting embedded scripts that manipulate the DOM. The browser’s still officially writing the initial page out, so when it encounters a complete <script> tag, it will execute the script immediately. A simple demo is available at
…(illustration and problems)…
“Service Streaming” is a step towards solving these problems, though it doesn’t work on all browsers. The technique relies on XMLHttpRequest Call (or a similar remoting technology like IFrame_Call). This time, it’s an XMLHttpRequest connection that’s long-lived, instead of the initial page load. There’s more flexibility regarding length and frequency of connections. You could load the page normally, then start streaming for thirty seconds when the user clicks a button. Or you could start streaming once the page is loaded, and keep resetting the connection every thirty seconds. Having a range of options helps immeasurably, given that HTTP Streaming is constrained by the capabilities of the server, the browsers, and the network.

Experiments suggest that the Page Streaming technique does work on both IE and Firefox ([1]), but Service Streaming only works on Firefox, whether XMLHTTPRequest ([2]) or IFrame ([3]) is used. In both cases, IE suppresses the response until its complete. You could claim that’s either a bug or a feature; but either way, it works against HTTP Streaming.

Donovan Preston explains the technique he uses in Nevow, which overcomes this problem:

When the main page loads, an XHR (XMLHttpRequest) makes an “output conduit” request. If the server has collected any events between the main page rendering and the output conduit request rendering, it sends them immediately. If it has not, it waits until an event arrives and sends it over the output conduit. Any event from the server to the client causes the server to close the output conduit request. Any time the server closes the output conduit request, the client immediately reopens a new one. If the server hasn’t received an event for the client in 30 seconds, it sends a noop (the javascript “null”) and closes the request.