With the introduction of the iPhone many of the leading RIA frameworks have been investigating ways to apply the same technologies which we use for building RIAs to mobile application development. Fully-fledged browsers on smartphones (iPhone, Android, Palm/webOS, and others) make it possible to run large JavaScript applications on phones, but there are some challenges every project faces:

• Performance optimization necessary for mobile devices.
• More modular JavaScript libraries to reduce initial parse time.
• Adjusting component design to smaller screens and the fact the many mobile apps are using finger based touch instead of mouse pointers and keyboard.
• Touch-enabling existing components to support full user interaction on multi-touch devices.
• Installation of RIAs as native applications on the phone, typically solved by the application of a framework like PhoneGap or Appcelerator providing a headless browser inside the app, into which the RIA is loaded.
• Tools for automatic packaging for deployment as W3C or Opera widget as well as Adobe AIR 2.0 application.
• Access to native phone APIs out of JavaScript or ActionScript.

OpenLaszlo faces the same challenges, when you try to deploy run apps on mobile devices, either hosted or as an installable application.

Mobile OpenLaszlo – the past

There have been some initiatives by Laszlo in the past year to create a mobile runtime for OpenLaszlo, and there has been a proof-of-concept for a J2ME based mobile app, Project Orbit. In 2006 Sun started a cooperation with Laszlo code-named Orbit. The idea was to create a Java bytecode generator for OpenLaszlo, compiling LZX source code into Java bytecode. The project scope was reduced, and in 2007 a proof-of-concept was shown running an OpenLaszlo DHTML application inside a J2ME Java stack, loaded into the Rhino scripting engine. Many OpenLaszlo community members and companies using the technology expected a mobile runtime in the not-to-distant future, but unfortunately that never happened.

The technical approach the engineers on the project chose resembles the approach of the excellent PhoneGap framework, where you can build a native application for a range of devices and just load HTML/JavaScript content into the application using a WebView/UIWebView component – which is a headless browser. If you don’t know PhoneGap, check the About PhoneGap page first. The advantage of that approach is clear: You don’t need to generate a native application out of your source code, but can re-use JavaScript code for a number of devices with a WebView like component, running on top of an abstraction layer provided by the framework.

Deploying mobile OpenLaszlo apps

We all – the OpenLaszlo community members – have been waiting since 2007 for any sign that Laszlo will start working on a mobile runtime, or that there is at least some initiative for mobile OpenLaszlo apps using a light-weight approach. Unfortunately nothing happened. That’s a bit surprising, since there are enough open standards and open source frameworks available at no cost, which can be combined with OpenLaszlo to provide powerful mobile app development capabilities.

Knowing how little it would take to build proof-of-concepts for OpenLaszlo apps running on smartphones through PhoneGap, as a W3C widget or mobile Flash/AIR app I’ve decided to initiate the Mobile OpenLaszlo project as a community R&D or labs project to show what can be done with OpenLaszlo on mobile devices NOW, without huge investments into new runtimes – based on the ongoing improvement of the OpenLaszlo platform funded by Laszlo and other sponsors.

Click the image for a larger version.

The idea is to create a set of tools and proof-of-concepts for mobile OpenLaszlo applications, using a range of existing standard, technologies and frameworks. The goal is to have OpenLaszlo applications running on smartphones, the Apple iPad and similar devices, devices supporting standards like W3C widget, Opera Widget, and JIL as well as to the runtimes supported by Adobe’s Open Screen Project (Flash 10.1 and Adobe AIR 2.0).

Why a separate initiative and not under the umbrella of OpenLaszlo?

Timing and development speed: With Laszlo things are just painfully slow. Everyone is expecting mobile support now, and not in maybe 2 years or later. After seeing other Laszlo initiatives – like the OpenLaszlo IDE announced in 2008- fade away, I’m careful to not see another good idea die. Laszlo’s communication around the OpenLaszlo project hasn’t been exactly clear in the past years. Wonder what the mobile strategy is for Laszlo Webtop or OpenLaszlo? Try to search for the term “mobile” on the corporate website, and all you get is an outdated product page. Same is true for the OpenLaszlo project roadmap, no sign of mobile support.

My experience with the OpenLaszlo team is very different in that respect: Responsive, excited about technical innovations, quickly adopting HTML5 features into the OpenLaszlo platform – true advantages of an open source based development approach. Laszlo should seriously consider to launch a non-profit OpenLaszlo foundation like the Dojo Foundation, to motivate companies and developers using OpenLaszlo to contribute, and to open up the decision making process for new features, the OpenLaszlo roadmap and a long term strategy. Complaining that there is not enough contribution from OpenLaszlo adopters – and not opening up – doesn’t work well, based on my experience. As a result of the current situation, I’m convinced that – without a non-profit OpenLaszlo foundation in place – the Mobile OpenLaszlo initiative should be run as a separate project, independent of Laszlo’s direct influence.

Mobile OpenLaszlo – Ubiquitous W3C Widgets and Mobile Apps with OpenLaszlo

Mobile OpenLaszlo will speed up development of tools and best practices for building mobile OpenLaszlo apps. Sharing ideas and concepts, putting those ideas into practice as proof-of-concepts and demonstrators, publishing tutorials on mobile OpenLaszlo development – all in a community driven open source project. Companies and OpenLaszlo community members interested are invited to join the project.

The Mobile OpenLaszlo source code is currently hosted at GitHub. The community discussion is lead the mobile OpenLaszlo mailing list, which is hosted at OpenLaszlo.org. Read this introduction on MobileOpenlaszlo in the Wiki, where you will find a other interesting pages on the project as well (OpenLaszlo & PhoneGap, OpenLaszlo & W3C Widgets, etc.). All source code will be published under the OSI certified MIT License.

As soon as an OpenLaszlo Foundation exists, all code and products built as part of the Mobile OpenLaszlo project would be immediately donated to such a non-profit foundation, which would have my full support. I believe that OpenLaszlo as a relevant RIA and mobile platform in today’s competitive market will only stand a chance if the contribution and sponsorship model is completely revised, and that would be to the benefit of Laszlo as a company as well.

After all the talk about the project, back to what we really want to see: First proof-of-concepts for Mobile OpenLaszlo in action. Well, here you go:

OpenLaszlo native Android App

This application is a small OpenLaszlo demo I wrote last year to show how some of the HTML5/CSS3 features can be used in OpenLaszlo today. The application is deployed as a native Android 2.1 application on the Google Nexus One smartphone, utilizing the excellent PhoneGap framework.

PhoneGap’s JavaScript API connecting directly to the phone’s hardware (in this case the accelerometer) can be called directly of of the LZX code, here’s an excerpt of the program code:

  <handler name="oninit">
    <![CDATA[
    var opt = {};
    opt.frequency = 100;
    if (typeof navigator != 'undefined' &&
      typeof navigator.accelerometer != 'undefined') {
      navigator.accelerometer.watchAcceleration(this.accelCallback, this.accelFailure, opt);
    }
    ]]>
  </handler>
  <method name="accelCallback" args="acc">
    // Landscape mode, acc.y translates to x position
    var newY = canvas.height/2 - acc.x * (canvas.height/20);
    var newX = canvas.width/2 - acc.y * (canvas.width/20);
    theText.updateShadow(newX, newY);
  </method>

Through the navigator object you can access the full PhoneGap JavaScript API. I will post a tutorial showing how you can build your own Android apps using OpenLaszlo & PhoneGap later this week, and post the link to the tutorial here.

W3C widget generation support

One of the first proof-of-concepts I built is an Apache Ant based tool for compiling an LZX file into a W3C/Opera widget available. Here is a screen casts showing how that can be used to directly convert an LZX file into a *.wgt file, packaged for installation:

When I told the OpenLaszlo team about the possibility to generate W3C widgets out of OpenLaszlo apps, the team showed a lot of interest and gave me the information I needed to integrate with the OpenLaszlo deployment tools (thanks, Tucker & Henry!). The next step was to get the Ant script running and some templates prepared to generate the *.wgt file, as a proof-of-concept. Once that worked, the decision was made to include such a functionality into the OpenLaszlo platform at some time in the near future, since the modifications can easily be made to the current deployment tool to generate a *.wgt instead of an *.zip file for deployment. The corresponding JIRA issue (LPP-9148) has been entered, you should find updated information on the implementation status there.

Join the Community!

If you are interest in the Mobile OpenLaszlo project, please feel free contact me directly (rajubitter[at]gmail.com), join the mailing list and become involved. If you are interested in professional consulting for building OpenLaszlo widgets or mobile OpenLaszlo apps, the project will soon host a list of contributors (developers and companies) offering professional service for building mobile OpenLaszlo applications.

I finally got a new phone – the HTC Desire: Fantastic device, it’s Android based, delivers awesome performance, has a great display – and has the 10.1 Flash Player! Adobe has been saying that the first devices with Flash Player 10.1 will be shipped by device manufacturers in the 2nd half of 2010, but here’s the proof that there’s a Flash Player 10.123 installed on my device – which I bought in Germany.

I noticed that existence of Flash Player 10.1 on the HTC Desire when I tested the OpenLaszlo demos on the OpenLaszlo.org website. Just out of curiosity I loaded the SWF8 based version of the OpenLaszlo component sampler – and to my surprise the app loaded. Ok, I thought, let’s check SWF10 – and again, the app loaded in the browser. Using the Laszlo debug console I dumped the version of the Flash Player, and it’s Flash Player 10.123. Have a look for yourself:

OpenLaszlo SWF10 Flash application running on HTC Desire

I tested a number of websites with Flash, including Spiegel’s video portal (Germany’s leading news portal):

Spiegel's Flash based video gallery running on the HTC Desire

And then the final test, loading the massive Laszlo Webtop application into my phone. It’s a Flash8 SWF file with a total size of more than 1mb. I was able to load the app, log into the system – but then the app ran into problems connecting to the server. Still, I never would have expected such a large Flash app to load into the Flash Player on a mobile device.

I wonder if the HTC Desire is supposed to be sold with the Flash 10 Player pre-installed. I signed for the beta testing phase of Flash Player 10.1 for Android a few weeks ago, but hey, I got the player already!

Last year – in a discussion about what could be the next feature for a multi-runtime RIA platform like OpenLaszlo – the former OpenLaszlo director Jim Grandy came up with the idea of generating either JavaScript or OpenLaszlo’s XML based LZX source code out of exisiting SWF files. Today heise.de reported the launch of project Gordon by Munich based Tobias Schneider. Gordon is “An open source Flash™ runtime written in pure JavaScript”. You’ll find some demos of the current version of Gordon here, and the source code is available on githup. Technically Gordon translates the SWF tags into SVG through a JavaScript SVG renderer. The project wiki contains information on the supported browsers as well as the supported SWF tags (SWF 1.0).

Check this picture of one of the oldest Future Splash demos (Future Splash is the old name of Flash before the technology was bought by Macromedia) running on an iPhone through Gordon.

Gordon - rendering an old Future Splash demo on the iPhone

That reminds me of the Henry Minky’s demo rendering OpenLaszlo’s XML into SVG (instead of Flash or JavaScript code). The question is, how much of the advanced interactivity the SWF format offers can be reproduced using SVG? An interesting post in the Open Web Advocacy Group titled “A Rant about SVG” discusses the various technical difficulties around using SVG and JavaScript in modern browsers.

Without being an expert on the SVG subject I have the feeling that there are still a few shortcomings if you plan to build full applications using SVG – if you plan to have the apps running in the various versions of IE in the market. But Gordon is definitely an interesting project, very much welcomed by anyone interested in an more open standards way of building Flash-like apps for the web.

After many months (even years) of waiting we finally have some information from Adobe on when the infamous FP-40 bug should be fixed. As an Adobe employee posted a few days ago: “I did a little investigation and confirmed this is fixed and will be available in the Flash Player 10.1 Beta to be released later this year.”

I’m tempted to say: “Good for the Flash community and the Linux world!”, but Adobe’s decision to not communicate any details around the issue for such a long time makes it very hard for me to say anything positive. Would it be too sarcastic to say that the Microsoft support seems to be pro-active compared to Adobe behavior in this case, but then – I’ve made my experiences with customer support and “open communication” when it comes to U.S. based technology companies.

Remember the Macromedia slogan Experience Matters?

Great experiences are hard to quantify, but we all know when we are having them. They are the memorable events that give shape to our lives. We believe that technology has reached a point in enabling the digital world to move beyond function towards great experiences – experiences that can complement and even compete with those of the physical world. Join us on this journey to explore what great experiences are, how they deliver better business results, and how to create them.

Wonder what the Adobe/Macromedia experience is like in 2009? Here’s quote from one of the frustrated customers commenting on the FP-40 issue:

I have posted an GetSatisfaction customer request for Adobe asking why is this bug not fixed. It has been ignored for 9 months now.
http://getsatisfaction.com/adobe/topics/why_doesnt_flash_support_international_characters_on_linu

With this kind of experience, I have just one more motivation to say: “The quicker Flash fades away, the better for all of us.” HTML5 and CSS3 will give us many of the features Flash offers right now. I’m not totally opposed to proprietary plug-ins, but I’m not up to more Adobe Flash FP-40 experience.

Have you ever been dealing with detecting support for the new HTML5 and CSS3 features in browsers? Check out Modernizr, an open source JavaScript library which will probably make things a lot easier for you:

Modernizr is a small and simple JavaScript library that helps you take advantage of emerging web technologies (CSS3, HTML 5) while still maintaining a fine level of control over older browsers that may not yet support these new technologies.

Modernizr uses feature detection to test the current browser against upcoming features like rgba(), border-radius, CSS Transitions and many more. These are currently being implemented across browsers and with Modernizr you can start using them right now, with an easy way to control the fallbacks for browsers that don’t yet support them.

Using Modernizr within your CSS style sheets is very easy:

.multiplebgs div p {
/* properties for browsers that
support multiple backgrounds */
}
.no-multiplebgs div p {
/* optional fallback properties
for browsers that don't */
}

The approach Modernizr takes is not to assume what features the current browser supports based on the result of a user agent string analysis. Instead it uses feature detection for 20 innovative HTML5 and CSS3 features.

Just after finishing my last post on downloadable font support, I saw another update to OpenLaszlo trunk, containing the code to support rounded corners in the JavaScript/DHTML runtime. Here’s a a screenshot of the application in SWF10:

OpenLaszlo rounded corners in SWF10

While that has been possible in Flash for years, here’s the more interesting part: the same application running in DHTML, showing the rounded corners for Webkit, Safari and Firefox. It should work in Chrome as well, but there’s a still a small bug which will be fixed:

For a re-design of the OpenLaszlo components these features will give the OpenLaszlo team a lot more flexibility. At the same time application performance should increase (less views need to be generated) and download size should be drastically reduced (due to the lack of multiple request made to the art assets used for skinning).

Max Carlson has added support for CSS @font-face inclusion of True Type (TTF), Open Type Fonts (OTF) and embedded fonts in Internet Explorer (EOT) to OpenLaszlo trunk. As a result, now it’s possible to display custom fonts in Firefox (3.5+), Safari/Webkit, Opera 10 and IE 6,7 and 8. Technically Chrome supports downloadable fonts as well, but for security reasons is has been disabled as default (you can test by adding the parameter –enable-remote-fonts to Chrome at start-up).

This example applications shows a custom font embedded into a DHTML/JavaScript OpenLaszlo application in various browsers. In Flash fonts could be embedded for a long time already, but such a widespread support of that feature based on open standards is definitely exciting.

The following collection of screenshots shows how the application is being rendered in different browsers – notice the significant differences in font size in IE8.

Downloadble/embedded fonts supported in OpenLaszlo for these browsers

With support for text-shadow, box-shadow, downloadable fonts, ongoing work on support for rounded-corners and other HTML5/CSS2+3 features, OpenLaszlo currently is one of the most advanced RIA platforms supporting the Open Web movement.

Using downloadable/embedded fonts is as easy as this, just make sure you have an EOT version of the font available for IE.

  <!-- A font by Jos Buivenga (exljbris) -> http://www.exljbris.nl -->
  <font name="yanone" style="bold" src="YanoneTagesschrift.ttf" />

  <text x="50" y="35" font="yanone" fontstyle="bold" fontsize="28" text="OpenLaszlo for the Open Web!" />
  <text x="50" y="65" font="yanone" fontstyle="bold" fontsize="28" text="Downloadable Font Demo." />

With some adjustments to the font size and rendering – quality of the font in IE depends very much on the quality of the tool used for transforming from TTF to EOT format – the results will be very acceptable, although not pixel perfect as in Flash. Another big step would be to support HTML 5 video in OpenLaszlo.

If you have been using OpenLaszlo, what things would like to see improved, which features should be added? Any ideas for new APIs or standards that should be supported? Following some comments and good feedback on OpenLaszlo in the forums, I created this wiki page as a “community wishlist” for a future OpenLaszlo 5 version.

Personally I’m excited about the HTML5 and CSS2/3 features which are added to the platform. But there are other fields where improvement is needed, like

• components
• integration with backends and web services
• charting
• support of the advanced text layout features in Flash 10
• …

If you have ideas and visions for OpenLaszlo, feel free to create a wiki account and make changes to the page. Any help and support by the community to further improve OpenLaszlo is more than welcome!

Wired Oktoberfest 101 Wiki

Reading Wired on a calm Saturday morning I was surprised to discover they feature an “Oktoberfest 101 Wiki” on their front page. If you live in Munich you can’t miss the thousands of Germans and tourists from all over the world, running around in Lederhosen and Dirndl. While the dress at least resembles what’s part of Bavarian folk tradition – most designs have been a bit modernized – the fashion of drinking too much beer gathered in huge tents with thousands of people hasn’t changed.

At Oktoberfest the breweries put up huge tents hosting more than 10,000 guests for the duration of the festival. Some are more traditional in style and music selection, some a bit more modern. Here’s a webcam image from Löwenbräu tent, that should give you a good idea of the atmosphere. It’s very hard to get a seat in the evening, and don’t even try on the weekends unless you have reserved a table – that’s what many companies do.

Oktoberfest Webcam - Löwenbräu Festzelt

The Oktoberfest 101 Wiki is well written, and will give you valuable input for your Oktoberfest visit. Just make sure that you can still walk leaving Oktoberfest, and better don’t sleep on the lawn next to the festival area, in case you are totally drunk! If you enjoy drinking a lot of beer, meeting people from all over the world, dancing on the tables – then this is the place to be right now. Prost!

The announcement of Google Chrome Frame – an Internet Explorer extension that embeds a Google Chrome browser into Internet Explorer – could sarcastically be called the “making of an IE which fully supports open standards for the first time”! If you haven’t heard of Google Chrome Frame, here is the description from the project website:

Google Chrome Frame is an early-stage open source plug-in that seamlessly brings Google Chrome’s open web technologies and speedy JavaScript engine to Internet Explorer. With Google Chrome Frame, you can:

• Start using open web technologies – like the HTML5 canvas tag – right away, even technologies that aren’t yet supported in Internet Explorer 6, 7, or 8.
• Take advantage of JavaScript performance improvements to make your apps faster and more responsive.

How can Chrome Frame be enabled for existing web pages?

To start using Google Chrome Frame, all developers need to do is to add a single tag:
<meta http-equiv=”X-UA-Compatible” content=”chrome=1″>

When Google Chrome Frame detects this tag it switches automatically to using Google Chrome’s speedy WebKit-based rendering engine. It’s that easy. For users, installing Google Chrome Frame will allow them to seamlessly enjoy modern web apps at blazing speeds, through the familiar interface of the version of IE that they are currently using.

Adding the meta tag to my blog, I could instantly run the OpenLaszlo JavaScript/HTML5/CSS demos I’ve built in the past months in IE! This video shows an IE8/Chrome Frame running an HTML5 demo:
[See post to watch Flash video]Microsoft – despite the Silverlight hype and the immense investment of the company into that technology – has constantly failed to deliver an IE version which can compete with either Firefox, Webkit/Safari/Google Chrome (all based on the Webkit platform) or Opera. The last time IE was on a par with Mozilla was about 7-8 years ago.

As a result, many company employees with access to IE only  - and latest stats show that still 25% of Internet users browser the web with IE6 – suffer from the extremely bad performance of that browser. In the corporate environment companies still report up to 40% IE6 users.

An interesting development could be witnessed last year. In September 2008 Google announced, that they worked closely with Microsoft to get better performance in IE6 for the Gmail application:

Last October, we launched a rewritten code base for the Gmail user interface to Internet Explorer 7 and Firefox 2 users. Since then, we’ve added support for Safari 3 and Firefox 3 and improved performance in other browsers. ….

The newest version of Gmail pushes modern browser technology to the limit, so initially we weren’t able to make it available to those of you who use IE6. Because it was released way back in 2001, IE6 wasn’t able to handle the complexity of the new code in a way that met our performance and stability goals. Over the last few months, we’ve been working with the IE engineers at Microsoft to address these issues: they released a critical update to their JavaScript implementation that fixed a performance problem with how the script engine allocates and frees memory.

By the end of September Google sent out a completely different message, as was reported by TG Daily:

Taking a page out of Apple’s book, Google is now urging Gmail users to drop Internet Explorer 6 (IE6) in favor of Firefox or Chrome that, according to the company, run the popular web-based email service “twice as fast.” Google also labels IE6 as an unsupported browser, meaning it fails to run some Gmail features.

As far as I can say there was no official announcement by Google, but who would doubt that the decision might be connected to the fact that Google Chrome 1.0 was released in December. What a strange timing – announcing cooperation with Microsoft to improve IE6 performance in September, and 3 months later tell your user to upgrade to a more modern browser instead. Would be interesting to hear what happened between Google and Microsoft within this short period of time.

Meanwhile companies start utilizing the massively improved performance of JavaScript engines of Chrome, Firefox and Webkit, as TG Daily reports:

Fast JavaScript engines and greater compatibility with web standards have become Chrome’s and Firefox’s biggest selling points over IE this year. In the corporate world, these benefits could turn into decisive reasons for companies to ditch IE. Some business software vendors have begun tweaking their web applications for Chrome’s speedy V8 engine, resulting in a dramatic speed gains. For example, a Chrome-optimized version of the Recruiting CRM software delivers a 300% performance increase in complex queries.

In July 2009 Google discontinued the support for IE6 in Youtube. IE6 users see a message saying: “We’ll be phasing out support for your browser soon…”, as Ajaxian and others reported. Companies can probably live with the fact, that your user experience won’t be as good if you visit Youtube with an IE6 at work. But for Google Apps functionality – switching from Microsoft to Google Docs – that’s a whole different story.

Google Chrome Frame and Korea – dealing with a 60% IE6 market share

There has been a country where we could see an approach similar to Chrome Frame: South Korea, with the difference that over there Firefox has an embedded IE which is used depending on which website/domain you visit. The reason for using IE is, that most of the secure Internet communication in South Korea is enabled by use of ActiveX plug-ins (the Korean government required companies to offer 128bit encryption, when the export of that technology was forbidden by the Clinton administration; as a solution Koreans developed their own encryption powered by ActiveX). And what happens in a country, where Firefox had a market share of less than 1% in 2007, totally dominated by IE (around 98%)? Gen Kanai of Mozilla in Asia reported:

In IE 7 and in Vista, Microsoft has re-architected Active X controls in such a way to make them “more safe” by requiring a user action for the control to run. This is obviously impacting every web site and company that uses active X controls on their websites, which include just about every website in Korea that handles any kind of secure transaction. Every online bank, every governmental agency, every ecommerce site. Without enough time to re-architect Korean websites, 3 S. Korean governmental ministries, the Ministry of Information and Communication, the Ministry of Government Administration and Home Affairs, and the Financial Supervisory Service, warned S. Korean users that upgrading to Vista would disable the user from making any secure transaction online.

Gen Kanai’s report is from 2007, but IE6 is still a hot topic in Korea, as you can tell by this article published this week by the Korea Times, titled “Korea paying price for Microsoft monoculture”:

“There are much better technologies out there, but Active-X has left us stuck at Windows XP and IE6,” said Channy Yun, an official from Daum (www.daum.net), the country’s second-largest Web portal, and also the local leader of the Mozilla foundation, a non-profit organization promoting the Firefox Web browser. …
Active-X usage became a hot topic again in July when a massive Internet attack left more than 80,000 Korean computers crippled. It was pointed out that Active-X provided an easy route for cyber criminals spreading the malware for the distributed denial of service (DDoS) attacks. …
Another problem with Active-X is that it is prolonging the life of IE6, the sixth revision of Microsoft’s Web browser that was introduced in 2001. The antiquated browser doesn’t support key Web standards, which makes it difficult for developers to design more sophisticated Web pages that are compatible with other browsers. …
However, the IE6 share in Korea is close to 60 percent, according to local Web analytics firm, Internet Trend, as companies are reluctant to go through the trouble to test and reprogram their Active-X entangled Web pages for newer browsers. So it’s easy to imagine Korean users waking up one day and experiencing difficulties in watching YouTube videos.

If Microsoft should ever disappear or get swallowed by Google, I’m sure going to miss stories like this about IE6, ActiveX and Vista craziness! And to the Korean web industry: maybe Chrome Frame can solve some of your problems, at least enabling companies to build open standards based web applications that can rendered inside IE through Chrome – even it is an IE6!

Update: According to tests run by Computerworld, Internet Explorer 8 (IE8) with the plug-in was 9.6 times faster than IE8 on its own. Computerworld ran the SunSpider JavaScript benchmark suite three times each for IE8 with Chrome Frame, and IE8 without the plug-in, then averaged the scores.