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.

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.

You Want XUL, You Got XUL

I've written a lot of articles for IBM over the last couple of years. I've covered a lot of topics. It was interesting for me to see which articles have been viewed the most. Last year I did a tutorial on XUL for beginners. To be honest, I really thought XUL was a very niche topic. If you are going to write a Firefox extension, you have to learn XUL. There are lots of resources out there about that. I did not want to write about that kind of XUL development. So instead I wrote about creating a XUL desktop application that used a lot of web development skills. Hey if Adobe can market AIR as a way for web developers to create desktop apps, then why shouldn't Mozilla do the same thing with XUL? It was a fun article to write, but I didn't expect it to be especially popular. Boy was I wrong!

That tutorial has been one of the most popular things I have written for IBM. So it made sense to update it this year. The tutorial used Firefox 3 as a XUL runtime. When I wrote it, Firefox 3 was in alpha stage. Obviously it has been released since then and is in wide use. So the opportunity for web developers to use XUL to create desktop applications is greater than ever. This week IBM published the updated tutorial, so go check it out.

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.

Firefox 3.1: Bring on the JIT

Web developers everywhere are excited about Firefox 3.1. Part of that is because of CSS improvements, but the big reason is because of TraceMonkey. This a JavaScript engine with a JIT that uses trace trees, a pretty clever technique to turn interpreted JavaScript (read slow) into compiled native (read fast.) JIT is a big part of why VMs like the Java VM and the CLR are very fast, in general much faster than VMs that do not JIT like in Python, Ruby, or (until now) JavaScript. It is why JRuby is faster than Ruby. Thus the prospect of making JavaScript much faster is very exciting.

Recently I had done some micro-benchmarking of JavaScript performance vs. ActionScript/Flash performance. This concentrated on XML parsing only. Now the ActionScript VM is a JIT VM. In fact, Adobe donated it to Mozilla and it is known as Tamarin. It has been Mozilla's intention of using this for JavaScript in Firefox for awhile, as JavaScript is essentially a subset of ActionScript. TraceMonkey is based on Tamarin, but it adds the trace tree algorithm for picking what to JIT. The trace tree approach allows for smaller chunks of code to be JIT'd. For example if you had a large function, like say a single script that runs when the page loads, then with a traditional JIT you either JIT the whole function or not at all. Now what if that function has a loop that runs dozens of times, maybe populating a data table for example. With a trace JIT you can JIT just that one critical loop, but not the whole giant function. So it should be an improvement over Tamarin and thus ActionScript. Of course there is only one way to tell...

So I repeated the same XML parsing tests that I did for Firefox 3.0 and Safari 4 (beta). First, I had to enable JIT in Firefox. One of the links above describes how to do this (open about:config in FF 3.1, look for the jit.content option and set it to true.) I restarted FF 3.1 just to make sure this took effect. I then ran the tests. The results? Not much difference between FF 3.0 and 3.1b+JIT. FF 3.1b+JIT was about 4% faster, which is probably statistically negligible. It was still 6x slower than ActionScript and almost 3x slower than Safari 4.

So what went wrong? Not sure. Here is the code that gets executed in my test:

function load(){
 var parser = new DOMParser();
 var xml = {};
 var start = 0;
 var end = 0;
 var msg = "";
 var results = document.getElementById("result");
 var li = document.createElement("li");
 initReq();
 req.open("GET", "LargeDataSet?size=50", true);
 req.setRequestHeader("Connection", "close");
 // use a closure for the response handler
 req.onreadystatechange = function(){
  if (req.readyState == 4 && req.status == 200){
   msg = "XML Size=" + req.responseText.length;
   start = (new Date()).getTime();
   xml = parser.parseFromString(req.responseText, "text/xml");
   end = (new Date()).getTime();
   msg += " Parsing took: " + (end-start) + " ms";
   li.appendChild(document.createTextNode(msg));
   results.appendChild(li);
  }
 };
 req.send(null);
}

Pretty simple code. I manually execute it 20 times. It would sure seem like it could be JIT'd. What gets timed is just the parser.parseFromString(...) call, where parser is a DOMParser. Maybe that object cannot be JIT'd? Maybe there is a bug with the JIT that will be resolved in the future? It does seem to suggest that TraceMonkey may not always be the slam dunk everyone expects.

I was surprised by the results. I thought that FF3.1 would be faster than FF3. I didn't think it would be faster than ActionScript in this case, but I thought that it might be close. In many other cases, I expect ActionScript to still be much faster than TraceMonkey. Why? Well there is one other ingredient in VMs like the JVM and CLR that make them fast: static typing. This allows the VM to make a lot of other optimizations that work in combination with JIT'ing. For example, knowing that a particular variable is a number or a string allows the VM to inline references to that variable. This can eliminate branches in logic (if-else statements, where maybe the else is not possible.) The JIT can then take place on the simplified, inlined code, and be about as fast as possible.

If you read about some of the techniques used in TraceMonkey, it tries to do a lot of the above via type inference. So in some cases TraceMonkey and the AVM2 (ActionScript VM) may be able to do the same level of optimizations. In fact, given its tracing approach, TraceMonkey may be able to do better. But I am guessing that there will be a lot of situations where AVM2 will be able to do more optimizations just because of the extra information it has at its disposal in the form of static typing.

Beta Browsers 2008

This is a big year. Both IE and Firefox will release new versions this year. That hasn't happened ... ever? IE8 had its first beta, whereas Firefox 3 is at beta four. Indeed FF3 is much more polished at this point than IE8. However, I must say that Microsoft has been smarter than the Firefox team in a number of ways.

First, IE8 includes an improved IE Developer Toolbar by default. The IE DevBar is roughly equivalent to Firebug, but Firebug does not work with FF3. Of course you can’t really blame this on FF, but IE8 is much more web developer friendly. Web developers are the primary (only?) audience for beta browsers. IE8 also includes the IE7 emulation mode. Again this is very nice for web developers who have to program for IE7 currently, but need to get a head start on IE8 (wait, isn’t that all web developers?)

Flock 1.0

In case you missed the news, Flock finally went 1.0 late last month. I've been playing around with Flock for over a year. They're integration with social services has gotten better and better. I did a clean install of it and setup my Flickr, YouTube, and Blogger accounts very easily. I've given up on using it for RSS, as having a server-based solution (Google Reader) is too valuable to me. They've also added Facebook and Twitter integration, two favorite services of mine. Both are well done. And of course it's based off Firefox 2.0 now, which is great. Most Firefox plugins work great with it. I'm using its blog writer right now, as I'm planning on using it as my primary for a week or so and then figure out if I should go back to Firefox or not.

Blogged with Flock

New IBM Tutorial on XUL

I wrote a tutorial on XUL for IBM. It's a very introductory look at XUL. You can do some seriously crazy programming in XUL. The focus of the tutorial is on how web skills can be leveraged in XUL. Adobe AIR is getting a lot of press right now (and deservedly so) for letting web developers bust out some desktop apps. XUL lets you do the same thing. It's definitely a little more complicated than AIR, but also much more powerful. XUL gives you access to a lot more desktop resources than AIR does. Plus, if there's something that it doesn't already give you, then you can just write some native code and expose it via XPCOM. I think a lot of AIR developers are already begging for this kind of extensibility.

XForms Article on IBM developerWorks

IBM recently published an article I wrote on XForms. There have been so many times in the last five years that I've looked at XForms on behalf of whoever I was working for. It was always such a promising technology. It just needs browser support. It's funny that Mozilla has a great plugin that they don't include by default. Of course it's really just a matter of Microsoft. If IE included XForms support, it would get rolled into Firefox the next day. But of course they don't do this and instead re-invent the wheel...

FlashTracer

If you're doing Flash/Flex development, FlashTracer is a great Firefox plugin. It simply monitors your Flash log file and pumps its content to the Firefox sidebar. Very simple, but useful. The only problem I've had with it has been on my MacBook. But I got it to work. Here's how.

From the command line...
cd ~/Library/Preferences/Macromedia/"Flash Player"
mkdir Logs
cd Logs
touch flashlog.txt

Open up FlashTracer and click on Options. In the Select Output File enter Macintosh HD:Users::Library:Preferences:Macromedia:Flash Player:Logs:flashlog.txt
Obviously replace with your username (short name). Restart Firefox, and it should work!

Oh yeah, obviously you need to have the debug version of the Flash Player installed...

JavaScript Benchmarks

Whenever I play with a new computer, one of the things I like to do is run some JavaScript benchmarks (BenchJS.) It's a useful benchmark, since if I'm going to use the computer a lot, chances are that I'll spend a lot of time browsing the web on it. So JavaScript performance will be noticeable to me.

I have two computers at work. The first is a Dell Optiplex. It has a 3.0 GHz Pentium 4 with a 1.5 GB of RAM. I've never had a computer clocked at 3 GHz before. That was near the pinnacle of the NetBurst architecture.

The second computer is an IBM ThinkPad T43p. It has a 2.1 GHz Pentium-M with 2 GB of RAM. Again this was near the pinnacle of the single core Pentium-M's. It has some other nice features, maybe I'll blog about it so more later.

Finally, I recently upgraded my home computer. It's still an AMD 64X2 3800+. I upgraded the RAM to 2 GB. I also upgraded the video card, but I don't think that would matter much for JavaScript performance. I've bought a new hard drive for it, but haven't installed it yet. Again I doubt that would matter. I'm also already bought Vista for it, and will upgrade it soon. Maybe this week, or maybe next weekend, whenever I have time.

Right now, all three computers in question are running Windows XP. I ran Firefox 2.0.03, IE 7, and Opera 9.10. Here are the results:

Setup Browser Test 1 Test 2 Test 3 Test 4 Test 5 Test 6 Test 7 Total Pentium4-3.0 GHz/1.5 GB RAM Firefox 2 1.594 1.344 0.594 0.547 0.266 2.468 1.594 8.407 Pentium4-3.0 GHz/1.5 GB RAM IE 7 1.578 6.203 0.547 0.703 0.422 1.796 0.688 11.937 Pentium4-3.0 GHz/1.5 GB RAM Opera 9 1.563 1.156 0.438 0.312 0.078 2.156 0.641 6.344 Pentium-M/2.1 GHz/2.0 GB RAM Firefox 2 1.672 0.844 0.39 0.406 0.156 1.61 0.719 5.797 Pentium-M/2.1 GHz/2.0 GB RAM IE 7 1.562 2.969 0.344 0.75 0.453 1.328 0.672 8.078 Pentium-M/2.1 GHz/2.0 GB RAM Opera 9 1.562 0.437 0.282 0.265 0.063 1.328 0.422 4.359 AMD 64X2 3800+/ 2.0 GB RAM Firefox 2 1.609 0.906 0.344 0.609 0.171 1.594 1.875 7.108 AMD 64X2 3800+/ 2.0 GB RAM IE 7 1.563 3.328 0.375 0.657 0.687 1.391 0.718 8.719 AMD 64X2 3800+/ 2.0 GB RAM Opera 9 1.563 0.516 0.297 0.281 0.078 1.422 0.469 4.626

Interesting results! From the browsers, Opera was always faster than Firefox and Firefox was always faster than IE. No surprises here. I was most surprised to see how well the Pentium-M performed. I thought the AMD would beat it out, but it did not. The biggest difference between the two was on the last test. This test calculates the day of the week for Christmas day for the next 1000 years. This test accounted for almost all of the Pentium-M's advantage on each system. I'd be interested to see the JS code for this, but one would think that it would come down to a lot of integer math. So it would make sense that the Pentium-M would have an advantage here. Actually, you gotta wonder why the P4 didn't do better on this test.

Google Web Toolkit and Firebug

Today I was working on a small web application that uses the Google Web Toolkit. I think a lot of the appeal of GWT is that Java developers have distaste for JavaScript. So what do they do? They build a framework to generate all the ugly JS for them.

I like JavaScript, and I'm not worried that saying so will cause me to take a pay-cut. I have some tools I like to use to deal with it. One is a bookmarklet I found for viewing XMLHttpRequests and responses. It works really well in Internet Explorer 7.

I was playing with my little app on IE, and decided to open up my bookmarklet to see exactly what the GWT-generated JavaScript sent to the server. What did I see? Nothing at all...

Ok, time to get serious. I switched over to Firefox, where I have every web developer's best friend, Firebug, installed. I flipped the switch on Firebug and repeated the same process. What did I see here? Again nothing. Nada.

What the heck was going on? I see the request hitting the server and the response causing the data on the page to be changed. Yet somehow these common debugging tools were oblivious to what was going on. Was there an inviso-IFrame being used? That would be so Web 1.0-ish.

I probed around with Firebug, and indeed there was a massive hidden IFrame on my page. I opened it up and saw that there was a GWT-generated HTML page that was being dumped in here. That page contained tons of JavaScript. And not just any JavaScript, but amazingly obfuscated JavaScript. Here's a sample of it:

function gX(hX,iX){hX.aX = iX;}
function jX(kX){return kX.cX;}
function lX(mX,nX){mX.cX = nX;}
function oX(pX){return pX.bX;}
function qX(rX,sX){rX.bX = sX;}
function tX(uX,vX){uX.fo(eX(vX));uX.cq(jX(vX));uX.fo(oX(vX));}
function wX(xX,yX){gX(yX,xX.jo());lX(yX,xX.Ep());qX(yX,xX.jo());}

I don't know what to say about this stuff, but it's not the point. This wacky IFrame was where all the magic happened. It's the use of this IFrame and its Skynet-like JS that allows the GWT guys to claim:

Your GWT applications automatically support IE, Firefox, Mozilla, Safari, and Opera with no browser detection or special-casing within your code in most cases.

They're not using the sexiest flavor of AJAX, they're using the lowest-common-denominator version of it.

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.

Data Islands

My company's resident JavaScript guru likes to use a technique called Data Islands. While I can roll some JS and have even been known to make asynchronous calls before there buzzwords to describe such a thing, I had never heard of this term until a few months ago.

The idea is simple. You have some server side technology that is serving up data as (drum roll please) XML. This XML is consumed by the client side. If you're doing a lot of AJAX after the initial page load, then you might already have client side assets for reading XML and rendering it in the browser. This technique leverages the same thing, only the XML comes over with the initial load of the page.

So how to embed XML? Well somebody at Microsoft apparently decided it would be great just to have an XML tag in the page and dump it all inside that tag. Hence the term data island.

Surely you see where this is going. The data island is a Microsoft thing and its corresponding implementation via the XML tag is only understood on IE. Still it seems like a technique with some merit, and there are ways to get it to work on Mozilla based browsers, too.

Mozilla will ignore the XML tag as just some unknown HTML tag. However, it will try to show the contents of the tag (and the child tags) so first thing for cross browser support is to give your island an invisible style (style="visibility:hidden".) Next you can slurp up the contents of the tag since it still part of the page DOM. You can pass the contents into a DOM parser, a voila!

A couple problems, though. Mozilla still thinks everything is HTML and "reads" it that way first. So if you have a tag that shares its name with an HTML (or JavaScript) tag/reserved word, you'll have issues. No label or title tags. In fact, even an image tag won't work because of it's use in JavaScript. Similarly, no self closing tags like . If you do it like it won't cause problems, but it will be ignored completely, like it wasn't even there.

That's a lot of baggage to deal with. I investigated some alternatives.

1. Load the island asynchronously. Chances that the reason you would use the data island technique is that you are also using AJAX for updates to your page, thus you wanted to re-use script written for that XML. In that case, you could just load the data island with a separate AJAX call after the page loads. Obviously the big drawback here is that you have to make a second call to your server to load the page.
2. Emebed your XML as a JavaScript string instead of an HTML tag. In this case Mozilla won't try to read it as HTML, so it won't give you all the weird things mentioned above. The big drawback is that this is not as efficient on IE, since you aren't making use of the special mechanism, and you have to make sure to make your XML string JavaScript string friendly.
3. If you're going to go the route in #2, then you might just consider going one step further. Don't use XML at all, and just make your data into a JSON string that is evaluated when your page loads. I didn't do any testing, but this would seem like it has to be pretty close to being as fast on IE as the data island, while still being cross browser. Maybe I'll put that hypothesis to the test. Obviously the big drawback is that you'll want all your client-server communication to use the same mechanism, so you don't have redundant code. Thus you'll probably want to use JSON for your AJAX calls.

I'm kind of partial to #3, which is probably the biggest mutation of the data island technique. I can hear a lot of people saying "well you shouldn't try to make use of an MS extension to HTML anyways..." Don't forget that XMLHttpRequest was once an IE-only extension from MS, but became a "standard" that is now the cornerstone of so many web applications. The data island technique is very complimentary to AJAX, so maybe it will see the same kind of adoption.

More on Firefox 2.0

I upgraded my home computer with Firefox 2.0 when it became GA this week. The other critical factory in the upgrade was that the del.icio.us extension was upgraded to work with FF2. My wife and I both use this extension, so this was necessary if I was going to upgrade our home computer. That's when the trouble started.

The del.icio.us extension does indeed work with FF2. However, I immediately began having issues with it in combination with the Google Toolbar. My wife also uses the Google Toolbar, and she had the same problem. Disabling either one of the extensions seemed to solve the problem. We both chose to disable del.icio.us, as we both found the Google Toolbar more useful. She likes it's autofill for forms (I like this too) and I use its site search a lot. That's an invaluable tool for searching for things on open source forums. Those forums often provide their own search, but just using Google to search their site is almost always more effective.

Anyways, things didn't stop there. I was buying some stuff from Amazon, and FF2 froze up. This really annoyed me, especially since I had already entered in a credit card number in the order process. Of course Amazon is good at dealing with this kind of problem. I killed FF2, launched Flock (it's still FF 1.5 thankfully) and went back to Amazon. All was well, as my order was in my cart, and all I could pick up the checkout process right where I had left off.

So at this point I went ahead and disabled all my other extensions: Google Toolbar, Google Browser Sync, FireBug, and FireFTP. Maybe I'll try re-enabling them one at a time, to try and determine what was causing the instability. Hopefully the answer won't be "don't blame the extensions, blame FF2."