The Truth About Europe

Earlier this week I read yet another fascinating post by Peter-Paul Koch. In this post, @ppk takes on developers who think that developing for mobile just means developing for the iPhone. He points out that the iPhone has a small market share, in terms of number of devices being bought or in use. He tackles the obvious counter-argument that the iPhone dominates in terms of mobile Internet usage in the US. In particular he points out that the US does not matter, since Asia and Europe account for a much higher percentage of mobile users worldwide. He is completely right, but if you are a mobile web developer, these facts are completely irrelevant.

It does not matter how many mobile web users there are in North America, Asia, or Europe. This has no bearing on how you design your site or what kind of technologies you choose to adopt. All that matters are the users of your site and what kind of devices they use. There can be 100x more smartphones in Japan than in Spain, but if all of your users are in Spain, then you should not care about Symbian's market share in Japan.

For a lot of sites, it is very easy to figure out where their users are because they are not localized. If your site is focussed on Brazil, then it's a good bet that most of your users are in Brazil. For sites that are international, things get trickier. This is a problem that I have had to deal with at eBay. Fortunately my job was easier because we already had a mobile site that was setup almost ten years ago. It is designed to support all devices, from old school WAP devices all the way up to iPhones and Droids. It has a presence in all of the countries where eBay has a presence. So there I had a lot of data to use where I could say "this % of our users are using iPhones, this % are using Blackberries" etc.

Most people do not have this luxury. If you do not have a specialized site for mobile, you can still look at your server logs and figure out what mobile devices are being used to access your site. However, you should be cautious with this data. If you do not have a specialized site, chances are your main site does not work properly on a lot of devices (especially true if you use a lot of JavaScript.) So chances are your users that use those devices will not use your site from their devices. However, chances are that your site does work properly on an iPhone, even if it is far from optimized for it. So iPhone users may be over-represented in your data.  You might want to fall back to using X% of users are from A, Y% from B, and the devices breakdowns in A and B are... Now if your site relies on Flash...

Let's get back to the @ppk's post and the iPhone for a moment. He makes a nice analogy to IE6 back in the day. When doing analysis on mobile eBay traffic and our strategy for the future, I actually made a similar analogy. There is one huge difference. The iPhone's browser, Mobile Safari, has been a front-runner in adopting HTML 5 standards. If you are optimizing for the iPhone, there is a good chance that you are in fact using HTML 5 standards. In other words, optimizing for the iPhone does not mean adopting a plethora of technologies that are proprietary to Mobile Safari. It's just the opposite in fact. This is the fundamental difference between Mobile Safari today and IE6 circa 2002. That is not to say that there aren't some technologies that are unique to Mobile Safari. There are. However, those are the exception, not the norm. Most of the code that you could write for Mobile Safari that would not work on other mobile browsers is actually standardized APIs that other browsers simply have not yet implemented. So yes, you could be excluding users -- this is where you need to figure out what devices your users are using -- but you are not putting up an iPhone-only wall. You are putting up a wall, but it is a "modern device that supports web standards" wall.

Don't Dream It's Over

Sometimes you need some 80's music. While you listen to that song, I want you to think about something: the Opera browser. As an OG geek, I used to use Opera -- I even paid for it. It was so much better than IE and that was back in the day when there was just the Mozilla Suite Monster, no Firefox. Sure, there were sites that didn't work well in it, or that actively discriminated against it (including my current employer...) That was ok. It was so much faster than anything else out there, that it didn't matter.

As the world has turned over the years, history has proved Opera right. How fast your browser is does matter. How secure your browser is does matter. There is plenty of room for innovation in the browser space: tabs, download managers, speed dial, magic wand, etc. So many of Opera's ideas have been taken by the Firefoxes, Safaris, and most lately, the Chromes of the world, and touted as innovations -- that were then copied by IE. Meanwhile, what's happened to Opera? It doesn't always pay to be right.

I got news for you, Opera is still kicking butt. There has been a renewed focus on browser technology, and in particular what is collectively known as HTML 5. Apple, Google, Mozilla, and even Microsoft all like to talk about how awesomely they implement the HTML 5 specifications. Turns out they are still way behind Opera. Don't believe me? Take a look at @ppk's HTML 5 browser comparison. Or perhaps you are more visual...

Code (courtesy of a colleague):

<form> 
    <datalist id="mylist"> 
        <option label="Mr" value="Mr"> 
        <option label="Ms" value="Ms"> 
        <option label="Professor"value="Prof"> 
    </datalist> 
    <div class="entry"> 
        <label for="form-1">Name (required) </label> 
        <input id="form-1" name="name" type="text" autofocus required> 
        ← autofocus here </div> 
    <div class="entry"> 
        <label for="form-2">Title</label> 
        <input id="form-2" name="title" list="mylist" type="text"> 
    </div> 
    <div class="entry"> 
        <label for="form-4">Age</label> 
        <input id="form-4" name="age" type="number" min="18" max="25"> 
    </div> 
    <div class="entry"> 
        <label for="form-5">Email (required)</label> 
        <input id="form-5" name="email" type="email" required> 
    </div> 
    <div class="entry"> 
        <label for="form-6">Blogs</label> 
        <input id="form-6" name="url" type="url"> 
    </div> 
    <div class="entry"> 
        <label for="form-7">Date of Birth</label> 
        <input id="form-7" name="dob" type="date"> 
    </div> 
    <div class="entry"> 
        <label for="form-8">Attractiveness </label> 
        <input id="form-8" name="a" type="range" step="0.5" min="1" max="10" value="5"> 
        <output name="result" onforminput="value=a.value">5</output> 
    </div> 
    <div class="button"> 
        <button type=submit>Submit</button> 
    </div> 
</form>

Opera:

Latest Chromium Nightly:

As you can see, Opera does a great job of implementing many of the new markups in HTML 5, while Chrome .... not so much. Big deal, right? You can do all of these things with JavaScript you say. Yeah, but not only will that be a lot of heavy JS, but it will lose semantics. Don't think that matters? Well, not only do those semantics matter to folks who use screen readers, but it also matters to the most important user of the Internet: googlebot.

Anyways, the point is that once again Opera is leading the way, not the folks who talk the loudest about pushing browser technology.

Note: This blog post created with Opera.

HTML 5: Don't Believe The Hype

In case you haven't heard, HTML 5 is The New Hotness. I have been watching this tide rising for awhile. There have been many skirmishes between The Unite Emirates of JavaScript and The Kingdom of Flash over how plugin technologies were going to be made obsolete by HTML 5. To hear some folks talk about the future of HTML 5, it is a veritable morality play. HTML 5 is all about the nobleness of open source and open standards. It is democracy and freedom. Everything else is closed and tyrannical.

Things really took off a few weeks ago at Google's IO conference. GOOG officially put its chips in the HTML 5 pot. This should not have been a surprise, as Google has invested in improving browser technology first through Gears and then through its own browser, Chrome. Of course Chrome actually uses the now ubiquitous WebKit for its rendering engine. This is at the heart of not only Apple's Safari browser, but also the mobile browsers on the iPhone, Android, and Palm Pre. Google used the "standardization" of WebKit on mobile devices to deliver mobile versions of GMail and Calendar thus punting on native applications.

So HTML5 is the future, right? Not so fast. I know it seems this way to a lot of people, especially the emphatic fans of open standards. However, those guys live in a different world than I. In the world I live in, browser fragmentation is at an all-time high. In a world of fragmentation, standards are an amusing concept. If history has taught us anything, it is that standards are set by whoever has the most users.

This has long been a source of pain for Google and others. In all fairness, IE8 implements some of the HTML 5 features, but not all of them. Also, the IE family of browsers has been losing share for several years. However, it is going to be awhile before web developers can forget about IE6, not to mention IE7. Given the update cycle of IE in the past, we can expect the older versions to stick around a long time before IE8 finally becomes the king. Again it does not even implement all of the highly touted HTML 5 features. Maybe more will be supported in IE9? How long before that becomes the dominant browser?

My point is that if you want to hitch yourself to HTML 5, you are not hitching yourself to Firefox, Safari, and Chrome. Well ok, you can hitch yourself to those browsers (or IE+Gears), but you are saying go away to 60-70% of the world. So assuming you don't want to do that, then hitching your app to HTML5 means hitching your app to future IE adoption. That just seems like a scary proposition to me.

But what about mobile devices? Here things are clearly better. Again the standards are set by the dominant player. WebKit is the dominant technology in high-end mobile browsers. Still there is fragmentation. The exact same APIs do not work on Mobile Safari as on the Android browser (don't know about the Pre.) Thus you may have to do some abstractions to smooth over the differences. Oh wait, that is starting to sound a lot like the situation with desktop browsers... Anyways, many HTML 5 features are present on the iPhone and Android browsers, so you have much more latitude to use them. However, there is another, more important question to answer when considering going down the path of GMail/Calendar on the iPhone/Android. Can a browser based be as good as a native app? Probably not, but maybe it's "good enough." However, I have to wonder, how many GMail users use the GMail web app on their iPhone instead of using the native Mail application? The GMail web app gives you all of the features you are used to, like conversations, labels, stars, and awesome search. The native Mail app provides none (or at best much weaker implementations) of this, but yet I would guess that most people still prefer it over the web app.

Safari Flash Fail

This happens to me a lot:

Take a look at the stack trace that gets sent to Apple:

So I think this is being caused because I set the storage allowed by the Flash player to 0 KB. The default is 100 KB. Why do I have it set at 0 KB? It's not because I am some privacy fanatic, just the opposite in fact. It was because I was debugging some PayPal code a few months back that required that Flash local storage be unavailable. Most sites then ask to set it back to the default 100 KB. However, if the SWF in question is too small to show the settings dialog, then it can't show the dialog to ask the user to set the amount of local storage for the site. You can right-click any SWF to bring this setting up, well any SWF that is biggest enough to display the settings manager. This is on a per site basis, but you can set things globally as well. Dealing with the error that is thrown when setting data fails is what I helped PayPal with. Obviously there are a lot of sites that do not deal with this error, and that seems to bubble up in Safari and cause it to crash.

JavaFX Performance

Recently I did a comparison of JavaFX performance vs. Scala. I did this mostly for kicks, and because some people thought that Mr. JavaFX was picking on other, non-Java languages that run on the VM. James Iry duly pointed out that JavaFX should be benchmarked against the likes of Ruby, Groovy, or Scala. It is meant to be a client-side technology, so it should go up against client-side technologies. So I re-did the little performance comparison to match JavaFX against JavaScript, ActionScript (Flash), and C# (Silverlight).

A comparison like this really becomes a comparison of Virtual Machines. For JavaScript there are a lot of choices. I decided to go with some that are supposed to be fast: Google Chrome, Firefox 3.1 (beta 2), and Safari 4 (developer preview.) Because I wanted Chrome involved, I had to go Windows. So I ran everything under Windows XP, running under Parallels on my MacBook. Here is the pretty graph:

I was just a little surprised by these results. JavaFX is indeed the fastest, but just barely. I was somewhat shocked to see Chrome's V8 JS engine right behind. In fact the difference is negligible for small iterations (shown above.) At larger iterations, JavaFX maintained 20-40% margin. As you can see from the graph, Flash and Silverlight were kneck-and-kneck as well, but was always about 7-10x slower than Chrome/JavaFX. Safari and Firefox were very underwhelming.

Of course this was just a micro-benchmark. The code just does a series of recursive calls. So what were are really measuring is the ability of the VMs to unwind these recursive calls. It is not suprising that HotSpot handles this easily. Actually, the same code in straight Java is much faster than the JavaFX version. It is surprising to see how well V8 handles this.

Now does the ability to unwind recursion translate into performance that a web application user would notice? Maybe. It certainly points to JavaFX's or V8's ability to make optimizations to application code. It is probably a more meaningful test than some raw number crunching.

JavaScript Benchmarks, now with Chrome

As promised yesterday, I did the JS benchmarks again on a Windows machine so I could include Google Chrome. I tried to be pretty inclusive, adding in IE7, IE8 beta 2, Firefox 3.0.1 (current release), Firefox 3.1 with and without JIT, Safari 3.1 (current release), Safari 4 beta, Opera 9.5 and Chrome. This was all run on my workstation, a 4-core, 3.2 GHz box with 8 GB of RAM. Any add-ons, extensions were disabled. Here is the pretty picture.


Once again Safari is the kind. Safari 3.1 beats everything except for Safari 4 beta, which crushes even Safari 3.1. Opera was a little slower than Safari. Chrome was generally comparable to the various Firefox browsers, but overall slightly slower. Like Firefox 3.1+JIT, it was very on error handling! Of course IE was the slowest by far, but at least IE8 is faster than IE7. Maybe IE8 is shipping with debug symbols included (as Microsoft has often done in the past) and the release candidates will be much faster than the betas. Or not.

Anyways, Chrome, and its V8 engine, does well, but does not seem to be ahead of Firefox and is certainly behind Safari and Opera. Maybe they can do better on the Mac!

More JavaScript Benchmarking

My old boss sent me this link about Google Chrome performance. It's a good read. It includes a link to an interesting JavaScript micro-benchmark. It included some interesting findings on Chrome vs. Firefox 3, Safari 3.1, and the new IE 8 beta 2. I was curious about some other browsers, namely Firefox 3.1 beta with and without JIT, Safari 4 beta, and Opera 9.5. Of course I made a nice picture of my results.

Interesting results. First off, FF 3.1 with JIT did not crash. It crashed so many times on me yesterday, that I was sure it would crash on this. Even though it did not crash, it was barely faster than FF 3.1 no JIT or FF 3.0.1. In fact, it was really only faster at error handling and the same on everything else. Apparently errors are easy to JIT for TraceMonkey!

Next, Safari 4 beta is fast. If you look at the link above, Safari 3.1 was already the fastest thing out there, so I guess this should not be a surprise. It crushed everything and it did it on the kind of tasks that real developers do a lot: array and string manipulation, regular expressions, and DOM manipulation (technically not part of your JS engine, but practically the most important test.) I am not used to seeing Opera lose when it comes to any kind of benchmark. If you throw out the array manipulation, it and Safari are pretty close.

I will have to boot up Parallels and try out Chrome vs. Safari 4 beta vs. FF 3.1 beta on Windows.

(More?) ESPN Fantasy Baseball Problems

My ESPN fantasy baseball teams have been doing very well this year. I always check them in the mornings. This morning I noticed something odd with the statistics and standings. Here's a picture of the standings sorted by WHIP:



Quick note if you're not familiar with the WHIP statistic in baseball. It stands for Walks + Hits per Inning Pitched. It's basically how many base runners a pitcher allows each inning on average. Thus a lower value is better.

So you'd expect the team with the lowest WHIP (VENEZUELA ANATOMY with a 1.143) to be at the top of the list when teams are sorted by WHIP. Having the best WHIP, they should also get 10 points contributed to the point totals used for overall standings. Instead, VENEZUELA is in third place and the team with the fourth best WHIP is in first.

Do we have another case of ESPN having problems? Well, sort of. You might have noticed that I was using the Windows Safari browser. There have been a lot of bugs with WinSafari. So it was only prudent for me to load the same page in Firefox:


Now everything looks exactly as it should! Notice that not only have the display orders changed, but the point totals as well. You might notice the my team (Campbell HGH in bold) even has two more points in Firefox than in Safari (89 vs. 87.) I tried the same page in IE7 and Opera, and it displayed correctly (just like Firefox) in both of those as well. I'll give it a try on MacSafari later, too.

So how could using Safari cause such a bizarre "bug" with Safari? Well doing a view source on the ESPN page revealed a lot. Here's a snippet:

This Sortable JavaScript class is the key. It looks like ESPN just passes in the raw data (each team plus it's cumulative statis in each category) to this JavaScript class and then uses JavaScript to do not only the sorting, but also the point calculations (since it is based on the sorting) and overall rankings.

It seems like a reasonable way to render such a page. All sorting and calculations are done client-side. JavaScript is certainly more than capable of handling such tasks. Well, at least it should be. These screen shots suggest that there is a bug with Safari's JavaScript. It would seem like a fairly severe bug, too, since it seems to be related to how it is comparing floating point values. That's just a guess. It could be a lot more subtle than that.

Let Them Eat Safari

I can't complain about Apple's WWDC being too disappointing, not with it coming fresh on the heels of true disappointment the night before. Still, there wasn't much there. In fact there was only thing of note:

Apple doesn't want to open the iPhone up as an application development platform. Instead they want everyone to build AJAXed web apps (oh by they way, screw Flash, Silverlight, and JavaFX.) To help developers with this, they are pushing out Safari for Windows, so you can easily test your web app against the "same" rendering engine that will be used on the iPhone. In essence, they are trying to push Safari as the standard for HTML/CSS/JavaScript rendering ... Which isn't so bad, since Safari passes the Acid2 test, but I digress.

I know we all keep hearing about how Apple doesn't third party apps causing the iPhone to crash or whatever, but that is just lame and obviously far from honest. I think it is more likely that they have some technical limitations that are preventing them from supporting JavaME or some other standardized runtime, and they are not ready to roll out their own.

So I guess if I want to do map search on the iPhone, I better like using Google Maps. If I want push email to it, I better be using Yahoo Mail. I don't guess I'll be pulling down videos from YouTube or ESPN to watch on the phone.

Of course having a "full" browser on the phone is huge. Apple has to be totally committed to this at this point. Theoretically I can go to GMail directly on the iPhone and get the full AJAX interface we all know and love. Maybe there is some way to have it run in the background so I can get the email pushed to me. Of course I still can't go to Yahoo Maps, since it uses Flash ... Ditto with YouTube... Also, Outlook Web Access works ok on Safari, though it's not going to provide push email like the IE version would (or like you would get with a Blackberry.)

So does any of this matter? The most significant thing is that one can expect that support for Safari just became more important web developers everywhere. Not a lot more important, but at least a little. I don't think Microsoft or Mozilla have to worry too much about IE/Firefox users switching to Safari. It's big draw is speed, and Opera was already way faster than IE or Firefox. Plus it's got a lot of issues...

Safari Slowdown

It's a few days old, but I noticed this article on /. about the Safari browser causing other Mac apps to run slower. I had just noticed the same thing yesterday. I was editing a slideshow in iMovie, tweaking around with durations and effects on slides along with the accompanying music. At the same time, I was also writing some code in XCode. I opened up Safari to check some C++ documentation, and it was like iMovie had been crippled. I didn't think it was Safari to blame in particular. I had opened a third application on a machine with two CPU cores, and both of my first two tended to be CPU intensive (encoding is never cheap, nor is compiling code.) Sounds like maybe I should have checked the documentation in Firefox instead. The reason I used Safari was because it is much faster at rendering most pages. I don't use it for everything mostly because it doesn't work as well with several Google apps I use a lot.

Safari

I found myself using Safari for the first time in ... a long time. I have to say that it has some definite speed advantages over Firefox on OSX. Firefox on OSX compares pretty well I think to Firefox on Windows and Linux. Blogger gives me a dumbed down interface on Safari though. I guess some of its rich editor features don't work on Safari. I'm guessing that's probably a common problem I'll encounter with Safari. Like Opera, it really embraces standards.