Web app as a mainstream? Its precursor?

Behind iOS, there were two people, Steve Jobs and John Rubinstein.
Steve Jobs wanted native environment, while John Rubinstein, as far as I know, supported Web as the platform. Choosing Web as its main environment would make existing web developers app developers for iPhone very easily and it means it can catch more market than MS hopefully. However, thanks to Steve Jobs’ tactic, native environment became very popular for developing apps on iOS devices, and it kind of pressed the booming of web development, for the time being at least.

However, after Steve Jobs passed away, what I see nowadays is not the Apple’s dooms day financially, but the rising of Web apps again.

John Rubinstein left Apple and joined Palm and announced WebOS.
It was elegant. It has the refined finish like Apple’s. However, somehow it failed in stealing market share. Well, personally, I couldn’t figure out gestures on the WebOS easily.
However, failure in the market doesn’t make it “BAD” OS.
What is interesting with WebOS was that they sought some performance by making an architecture which allows C++ code hooked from JavaScript frontend.

Now, at Ars Technica site, there were two news articles about the movement of Mozilla. One is to embed Unreal 3 Engine in a Web browser and the other is demonstration of JavaScript-only H.264 decoder achieving 30fps.
Although it may not cover big screen yet, it sounds quite immpressive technological preview and shows lots of potential.

So, let’s keep watching that.

Testing Chrome OS on VirtualBox

Recently we lived in the strange world in terms of development of OS. Unix, Multics, Mac OS X, Windows, etc are so called OSes. However, nowadays there are some OSes which are not really OS itself. They are Chrome OS, FireFox OS, Android and many other OSes built on top of Linux.

In Korea, a company called TMax announced that they would introduce Windows compatible OS in S.Korea. We were kind of shocked because there was no real research on OSes and we didn’t think we had such a capability. it turned out that they overlay a GUI and some compatible layer with Windows on top of Linux. So, it booted as Linux and there layers are stacked. We don’t really if they developed their own Windows compatibility layer or just used WINE. Some even shouted, “it’s deception!”.

However, I’m not as strongly sure of Chrome OS and FireFox OS as the Windows-compatible OS of TMax. Technically speaking, they are just like TMax OS. However, they are just Linux. In other words, “Their own service or GUI on top of Linux”. So, technically they should not call them Chrome OS, for example. It’s Chrome-Linux. Android? Soley-Java-Linux.
Then they may claim, “How about Mac OS X? Isn’t it mach kernel-BSD unix? Why does Apple call it Mac OS X and why did NeXT call it NeXTStep?”
Well.. yeah.. there are some blurry point which can be only felt by people who understand OSes. I think it’s OK to call Apple’s and NeXT’s as Mac OS X and NeXTStep. Probably it’s because they recreated many things from the bottom, although they borrowed many things from BSD Unix. However Chrome OS and Android are not.

Anyway I decided to try Chrome at least once to find out where it is at and if I can study how to port an OS to other platform like Raspberry Pi.
So, as a first step, I tried to build it for x86 architecture.

So, here it is.

Chrome OS, the 1st screen

So, basic setting can be chosen on the 1st screen. The presentation looks clean.

Some introductory screen..

Introduction, a kind of Quick Start Guide

When every setting at the first boot-up screen is done, Tada~ Chrome OS is presented.

Chrome browser as its main GUI

The Chrome browser is the main and the only one interface of the OS. It’s the desktop. It’s what you see.

Minimized Chrome browser

The main UI, i.e. Chrome browser can be minimized and maximized to fill the screen.

File browser in a separate window

Interestingly, you can see a file browser in a separate window. I don’t know if it’s another web page or not, though. Also, it couldn’t launch Linux app although it’s Linux. Probably it’s because the app accesses some functions which are stripped off from the Linux of the Chrome OS. ( It was the VirtualBox’s Guess Add-On installer which doesn’t have GUI. ) If you try, it crashes instantly.

An Linux app crashed

The Chrome browser can be moved on a screen.

It’s interesting that the main UI, Chrome browser window can be moved on a screen. Then how about the gray background? It’s an unused screen real space. I would like to put some alias or files on somewhere, hmm.. the “desktop” and make it accessible any time. But, this GUI is very limiting. It doesn’t look to allow that. Well.. actually I didn’t try it, because the UI doesn’t give me an impression that it can be done.
GUI is not just a beautiful face of a computer. It should suggest implicitly what users can do. But Chrome OS lacks such thing seriously. This is one of the biggest problem of Chrome OS to me.

It’s just the same Chrome browser

So, at this moment, it became very apparent it’s nothing other than slimed down Linux to reduce booting time and contain nothing unnecessary OS component. it’s not clear if Chrome OS uses X-Window or some slimed-down build of X-Window to present the GUI.
I guess that Google forked X-window and merge it with a light-weight window manager.

Anyway, everything is a web page. I’m not sure of the file browser, but even the task manager is a web page.

A Task Manager as a web page

And it does crash. ( According to Chrome OS introduction video, which you can find on YouTube, said that Chrome OS is crash-free or crash-less-happen OS. However, i noticed that web apps crashed a lot. However, the crash is localized only to a “tab”. So, recovery is quick. But you know.. what’s the point if web apps are not enough powerful to use or you feel like that you are captivated in a room? Yes.. Whenever I use web apps, I feel like that. )

It does crashes.

For setting up the Chrome OS more like input method, GUI interface language, etc, you lick on the bottom right profile image. Then it pops up a menu for configuration.

Configuration page

It already supports various languages. Input method may be written using JavaScript, but I’m not sure.

If you are logged out or locked by not using it a few minutes, it presents this.

locked screen

OK. Now, I tried if it support WebM/H.264/HTML5 on web page or it uses a Flash plugin.

My YouTube account is set for HTML5 video.
As you can see, it doesn’t load a YouTube page in HTML5 video mode. Probably WebM version of the video was not there on a YouTube server. But interestingly it tried to load a Flash plugin. If it happens it means that it passed HTML5 video ( whether it’s WebM or H.264 ) and reached flash  approach. Also it looks like that it doesn’t have Flash plugin installed by default.
However, when I visited Adobe’s Flash page, it says that it’s already installed.

Can’t load HTML5 video

Confirmation of HTML5 setting

Adobe Flash page says it’s already installed.

If you use a computer for just web browsing and casual write-up, probably Chrome OS does for you. Also while HTML5 offline behavior is getting implemented more, Chrome OS can become more useful.

However, it felt too restrictive to me. By design, it doesn’t look to allow drag & drop files from one to the other. Also, everything is, as Chrome OS description page of Google said, web apps. I know that current generation like web apps. But I don’t like web apps generally except for certain very special cases. It’s like that you are kept in a room called web browser. You don’t feel any freedom.
Another thought is that it’s not designed for desktop or tablet. It doesn’t feel to fit in anything. So, i think there are long way to go for Google to make this stuff attractive.
Because it’s all about Web, things are slowed down based on network access speed. Also, why we should waste CPU times for executing JavaScript code? Well, CPUs are getting cheaper and faster. So, for Web programmers, it means that their experience can be applied to wider audience, but isn’t it waste of our resource?

Well… I would use Mint Linux or Ubuntu Linux for cheap notebook computers if you care about price.

That’s my final thought on Chrome OS.

 

성전(聖戰) : Flash video vs. HTML5 video

오늘 Flash video와 HTML 5 video에 대한 상당히 좋은 기사가 Gizmodo에 나왔다. Giz Explains : 왜 HTML5가 인터넷을 구할 수없는가?

모두들 읽어보시라. 재미나면서도 이해하기 쉽게 나와있다.

이제 내 생각을 피력해 보기로 하겠다.
우선 나의 입장을 말해보자면, 나는 HTML5의 video tag를 선호한다. Flash는 제발 좀 없어져주면 좋겠다? 하지만 다른 한편으론 HTML5냐 Flash냐는 조삼모사(朝三暮四)의 문제라고 본다.

여기에 대해서 왜 그런지 생각을 해보자.
우선 왜 내가 HTML5의 video tag를 Flash보다 선호하는지 보자.
그 이유는 HTML5의 장점과 Flash 단점때문이다.
우선 쉽게 Flash 단점을 말해보자. 내가 알기로 Flash는 원래 Macromedia의 Authorware가 새 단장을 한 것으로 알고 있다. 그래서 Flash의 event 모델은 Authorware의 그것과 같고, 그때의 코드를 여전히 유지하고 있다고 알고 있다. 이것은 Flash가 처음 나왔을때 알게된 것이므로 현재는 좀 다를 수도 있다. 하지만 그때나 지금이나 Flash가 로딩되었을때 컴퓨터가 반응하는 것이 여전히 같은 것으로 봐서, 거의 그때의 코드를 여전히 유지하고 있다고 생각된다. 단 Windows 버젼의 Flash는 다르다. Authorware는 원래 Mac용 프로그램이어서, 이것이 Windows용으로 포팅될 때, 두 플랫폼의 이벤트 모델이 다르기 때문에 아예 다시 작성한 것으로 추측된다. 어쨌거나, 현재 Flash가 Mac의 웹 브라우저에서 로딩 될 때, CPU를 많이 쓰고 메모리를 무척이나 많이 사용한다. 실제 비디오를 재생하고 있건 말건 말이다. 이건 Flash자체가 가만히 있을 때도, 무척 바쁘게 뭔가를 한다는 소리다. 즉 busy idling을 하는 것이다. 아마 event dispatcher가 계속 event를 polling하고 있는게 아닌가 한다.
즉 바로 이런 것 때문에, 노트북과 같이 배터리를 사용하는 장비에선 배터리 충전량을 급속도로 떨어뜨리는 역할을 한다. 여러 곳에서 Flash를 휴대폰, 스마트 폰과 같은 모바일 장비에서 테스트한 것으로 알고 있는데, 역시 같은 소리를 왕왕 듣곤 한다. 배터리가 굉장히 빨리 방전된다는 것이다. 사실 Windows용도 Mac 버젼에 비해서 좀 낫다 싶은거지, 별로 괜찮은 상황은 아니다.

그리고 HTML5의 장점은 이렇다. 사용자가 특별히 비디오 재생을 위한 플러그인을 설치할 필요가 없다. 또한 산업계 표준인 H.264를 이용한다. 즉 표준을 지원하는 웹 브라우저는 그것이 자동차에 설치된 장비이건, 아니면 어떤 특화된 제품이건간에 똑같은 내용을 보여줄 수있다는 것이다. 물론 H.264는 라이센스 비용이 들어가는데, 이건 사용자들에게 부과되는 것이 아니다. 브라우저를 제작한 회사나 서비스를 제공하는 회사가 부담하면 되는 것이다. 이 비용을 들이기가 싫어서 Mozilla같은 곳은 Ogg Theor같은 것을 이용하길 원한다. 많은 사람들은 무료라는 점에서 Ogg Theor를 선호하는 것같다. 하지만 이건 내가 보기에 넌센스다. 그 이유는 Gizmodo의 기사에서 잘 나와 있다. 사람들이 대개 묵시적으로 H.264의 라이센스 권자가 흡사 MS나 Apple과 같은 사기업으로 여기는 것같다. 근데 그렇지 않다. MPEG LA와 같은 것은 비록 국가 조직은 아니지만, 비디오에 있어서 산업계 표준을 만들기 위해 조직된 것이다. H.264는 유럽 ITU-T에서 정한 이름이고 미국을 중심으로하는 ISO에서는 MPEG-4/AVC라고 한다. MPEG-1/2/3때는 ITU-T와 다른 스펙을 가지고 있었지만 MPEG-4대에 와서는 두 조직 즉 ISO와 ITU-T에서 협의를 해서 동일한 스펙을 제정했다. 그러므로 유럽과 미국을 중심으로 한 포맷의 통일이 이루어진 것이다. 특허권자를 보호하고, 특허를 사용하고자 하는 주체들의 원할한 정보 교류등을 위해 운영비가 필요하고, 또한 표준을 제정하는 노력들을 지원하기 위해도 비용이 필요하다. 그러므로 MPEG-4/H.264를 사용하기 위해 지불하는 비용은 충분히 그 목적이 있는 것이다.
그리고 산업계 표준은 시너지 효과를 제공해 줄 수있고, 처음엔 비용이라고 생각되어도 시간이 지날 수록 표준을 지원하는 것에 대한 잇점을 누리게 된다. 쉽게 생각해 보면 KS 마크와 같은 것이다. KS 표준에서는 볼트와 너트의 크기, 모양등을 표준화했다. 그럼으로써 볼트와 너트를 만드는 업체들은 정해진 것들을 대량생산하기 용이해지고, 렌치를 만드는 회사들은 어떤 규격의 볼트와 너트를 대상으로 공구를 만들지 확실히 할 수있다. 즉 어떤 회사의 볼트와 너트, 어떤 회사의 공구를 사던 간에 아무런 문제가 없이 사용할 수있게끔 보장하는 효과가 있다.
자 이쯤되면 HTML5가 H.264/MPEG-4라는 산업계 표준을 주로 언급하고 있다는게 어떤 의미를 가지는지 쉽게 이해가 갈 것이라본다.
아마 이 블로그를 읽는 분들에게는 이미 이런 내용은 당연한 것이라고 생각은 되지만…

자 그럼 이제는 내가 왜 HTML5냐 Flash냐가 조삼모사라고 생각하는지 알아보자.
HTML5를 사용한다는 장점에는 Gizmodo의 기사에서도 나와 있듯이, 비디오 재생을 위해 별도의 플러그인을 설치할 필요가 없다는 점이 있다. 그리고 이런 언급이 되어 있다.

In theory, eliminating the video plugins means no extra CPU overhead, fewer crashes, and wider compatibility—if HTML 5 video was standard now, we wouldn’t be stuck waiting for Adobe to port their plugin to our mobile phones, and Mac users wouldn’t bring their systems to a crawl every time they tried to watch a YouTube video in HD. As a general rule, playing a video file through an extra plugin like Flash is going to be slower, buggier, and more resource-intensive than playing it through a browser’s native decoder. That’s why people are excited about HTML5 video.

이 말이 사실일까? 플러그인 없앤다고 별도의 CPU 오버헤드가 안들어갈까? 죽는 빈도가 줄어들까? 호환성은 늘어나겠지. 리소스를 더 적게 쓸까? 내가 볼때 위의 커멘트는 완전히 넌센스다.

CPU 오버헤드가 더 들어가고 아니고는 어떻게 구현했는가에 따라 달라지는 문제이지, 그 구현이 플러그인이어서이고 아니고가 문제가 아니다. 물론 플러그인을 따로 로딩하고 그것을 관리하는 부하가 없지는 않지만, 비디오를 decoding해서 플레이하는 부하에 비하면 그건 없는 것이나 마찬가지이다. 즉 플러그인이어서 별도의 CPU 부하가 들어간다고 말하는 것은 조그만 것을 과장하는 것에 지나지 않는다. 둘째, 죽는 빈도가 줄어들까? 이것 역시 어떻게 코딩을 했느냐에 따라 달라진다. 플러그인이기 때문에 오히려 호스팅 프로그램에 상관없이 혼자만 죽게 될 수도 있다. 역시 호스트 프로그램 자체에 비디오 재생기능이 들어가도, 비디오를 로딩하고 재생하는 부분을 process로 만들면 그 프로세스가 죽어도 호스트 프로세스 자체는 안전하다. 쓰레드로 구현하면 다 죽겠지만. 즉 구현에 따라 그 안전도가 변하게 된다. 리소스를 더 적게 쓸까? 마찬가지의 문제이다.

물론 보다 많은 사람들이 같은 브라우저를 사용하게 되므로, 버그 리포팅이 보다 더 집중적으로 받을 수도 있을 것이고, 그것은 문제점이 빨리 노출되고 그만큼 관심을 받게 되므로 문제 해결도 더 적극적으로 될 것이다.

즉 이 점은 바꿔 말하면, 플러그인을 만드는 회사가 충분히 사려깊게 구현을 하고, 충분히 버그를 추적하고 반영하면 굳이 브라우저 자체에서 구현하는 것과 별 다름이 없다는 소리다. 물론 비디오를 배포하는 업자들이 사용자가 무엇을 설치했던 다 동일하게 보여지게 하려면, 배포하는 비디오 포맷에 대한 표준이나 그 선택을 몇가지로 제한하는 편이 좋겠고, 그것은 사용자나 플러그인을 제조하는 업체 입장에서도 마찬가지이다.
즉 HTML5를 지원하는 브라우저 자체에 비디오 디코딩/재생 기능을 넣느냐, 아니면 그와 같은 비디오 코덱을 지원하는 플러그인을 잘 만드느냐는 실질적으로 별 차이가 없다는 것이다.

즉 현재의 문제는 WMV처럼 특정 업체 자체의 비디오를 지원하는 웹 서비스 업자들의 개념없는 선택이 문제이지, 인기있는 비디오 코덱과 wrapper 파일 포맷을 지원하기만 하면 아무런 문제가 아닌 것이다.

물론 HMTL5에서 표준적인 비디오 포맷을 사용하기를 알게 모르게 묵시적으로 강제하면, 서비스 제공자들이 어쩔 수없이 산업 표준을 따라가는 측면은 있을 것이다. 그러면 개념없는 서비스 제공자들이 아무 생각을 안해도 어쩔 수없이 어느 사용자라도 접근 가능한 컨텐츠를 제공할 수밖에 없을 것이다. HTML5를 지원하는 아마 궁극적인 의미는 여기에 있어보인다.

HTML5의 비디오를 선호하고 지지하건, Flash 비디오를 선호하건 지지하건 개발을 이해하는 사람이면 이런 측면을 이해해야 할 것이다. Adobe가 Flash를 왜 개선하거나 아예 뜯어 고치지 못하는지는 이해가 되지 않는다. 아마 Flash 프로젝트에 투입된 인원이 적거나, 아니면 효율적으로 프로젝트가 진행되지 못한다던가하는 문제가 있을 것으로 보인다.

어떤 이들은 Flash가 후진 것을 알겠는데, 왜 Apple이 적어도 선택의 자유를 주지 않는가라고 말한다.
그거야 뻔하지 않는가? Steve Jobs 성격을 보면 뻔한거 아닌가? Altair같은 머신이 나올때 Apple II를 설계하고 디자인한 것을 보면 대번에 나오지 않는가? PC H/W가 쏟아져 나올때, 깔끔하게 daughter board와 motherboard를 설계하고 아주 깔끔하게 컴퓨터의 내부를 정리했던 NeXT Cube보면 그 이유가 나오지 않는가? Mac Pro의 내부를 봐도 그 이유가 대번에 드러난다.

Safari 4 beta for Windows

Finally, Apple announced a new Safari web browser for MS Windows.
I downloaded one and tried using it on my Windows Vista x64 edition installed on my MacBook with Intel GMA chipset, which is a graphic chipset may people don’t like because they prefer nvidia’s.

It turned out that the Safari 4 beta was quite fast. On a MacBook, Internet Explorer 7 is very fast, but the Safari 4 feels faster.

However, I would like to pick what I like the most.

1. Integrated look for the Windows
2. No more blurry font rendering
3. Very clean, minimal style GUI but quite functional and covering most of needs.
4. Integrated behavior like F4 for showing/hiding menu bar
5. Probably matured Objective-C/Cocoa environment for the Windows
6. Good use of the CoverFlow

For 1, it doesn’t look like mimicking Mac OS X on a Windows any more. It feels and looks like “born for MS Windows”.

For 2, the font rendering is very clean. They mentioned that it now uses Windows font, and users can change if they want to use Mac anti-aliased fonts. Many Koreans complaint about the font rendering of the Safari for Windows before. Now, they don’t need to complain about it.

For 3, Oh!

For 4, Pressing Function 4 key shows and hides menu bar of the Safari like other Windows apps on a Windows Vista. How did they do this? I don’t think they used Windows API.

For 5. I have lots things to say. I hope you remember what I wrote at my egloos blog before. I said that it looked like that Apple was preparing Cocoa/Objective-C development environment for the Windows. Yeah.. It is the OpenStep for the Windows, so to speak. Again, with the Safari 4 beta, it seems to be clearer.  Take a look at these screenshots.

It is clear that the Safari Beta 4 is written in Objective-C. Was there a objc.dll file for the Windows version of the Safari before?

Also, they maintain Mac’s app style resource.

For 6, I doubt how useful the coverflow is. Apple Inc. found a good way to use it! Bookmark!!!! The CoverFlow fits very well with the concept of bookmark!!!

At first, I thought the introduction of Safari for Windows was not for another browser-war. In my opinion, it was for providing developers a testbed for their iPhone web apps. By attracting web developers, it could be a very popular web-enabled mobile device, and also for hot interest shown by many developers, Apple Inc. could announce iPhone SDK. If the iPhone SDK was announced earlier than Web app development environment, the iPhone native development environment would not get such hot attention.
Another reason I thought was to prepare Cocoa/Objective-C development environment for the Windows.
They had OpenStep for the Windows. They had white-NeXT. So, they secretly had worked on the Mac OS X for the Intel platform.

From the Safari 4 for Windows, at least it became clear that Apple used some environment which had Obj-C tool chain. Because the DLLs are mainly for Core… and other common Unix libraries, it may not be Cocoa/Objective-C yet. But, I don’t see any reason that they don’t have such an environment.
Also, from the Leopard SDK, I see more and more words, i.e. “Windows”, in the Cocoa header files.

In that sense, the Safari 4 for Windows is promising. The Core… thing seems to be well integrated to the Windows environment. So…. it feels like that it is not so far from now to announce Cocoa/Objective-C development environment to write Windows-native programs. Probably… Xcode for Windows?

Ah… there is one thing which is not implemented for the Windows version.

What is very stupid about the Internet Explore is that you can’t easily select each URL component.
For example, I would type “https://jongampark.wordpress.com”. But I found out that I was not logged in.
So, I would like to type “www.wordpress.com”. On a Mac OS X, whether you use the Firefox or the Safari, double-clicking on the “jongampark” will select it, and you can just type “www”. But with the IE, it is not possible. it selects the whole URL. With the Safari 4 for Windows, it also selects whole thing except for the “http://”.

CSS Animation : very easy and good explanation

CSS Animation is sometimes said to be Flash-replacement for certain areas. I doubt how flexible its animation can be : presentation flexibility, performance, resource usage, and so on.

The WebKit blog article introduces the CSS animation in very easy-reading style. Probably most of advertisement flash can be replaced with this CSS animation, and it would get rid of lots of burden from web browsers. Especially Korean web sites use flash-advertisement very heavily. They are even obstructive. I want them not to use that many advertisement in such obstructive way. But if they once do it, I want it not to degrade web browser responsiveness.

Web developers! Study the CSS animation!!!!!

SquirrelFish Extereme!

As I summarized before, there are 3 strong players in the JavaScript engine field. Due to the Google’s chrome, how fast it is became quite a big issue. The WebKit people raised the bar even more yesterday by introducing SquirrelFish Extreme.

According tot their web site, the new engine is almost 2 times faster than the original SquirrelFish.

But how about the HTML rendering speed? Or the slowness due to use of lots memory space?

JavaScript is not the only factor which can make web browsers faster. 

Anyway, this is a quite good news for web application developers.

JavaScript Performance : V8, Tracemonkey, SquirrelFish, IE8

     A few days ago, the Google announced a beta version of their web browser, called “Chrome”. 

     It has an interesting name, because the word, “Chrome”, is also used for the XML based GUI representation for the Firefox. Anyway, it looks to me that the Chrome, the Google’s web browser, is targeted for Web applications. As you know Web application is very important nowadays for enterprise market, because you don’t need to worry about what platform you must use. Whatever they are, they can share and use the same intranet infrastructure and in-house software if they are Web apps. Thanks to the Google Docs and the Google map, AJAX showed its edge on performance and also its flexibility in designing Web interface. So, current Web apps look like and behave like desktop apps. Will it mean the dead of desktop apps? Hmm.. I don’t know. But anyway let’s keep focused. In this post, I would like to talk about JavaScript performance of the various web browsers.

    Not long time ago, every others were beaten by the IE’s JavaScript performance, not by great margin, but sufficiently big margin. At that time they were interpreter, or VM based implementation. Sure, the JavaScript is a script language. So, it is reasonable approach. And due to the faster CPUs, the Web apps become more visible and started spreading widely. 

    So, I guess people started wanting more from their Web apps. And there are two strong contenders.

One is the TraceMonkey from the Mozilla and the other is the SquirrelFish from the WebKit. (For people who don’t know what is the WebKit, try thinking the Safari or the KHTML. )

     According to the TraceMonkey’s introduction page, native compilation is added to the JavaScript engine, and it uses a technique called “trace tree” from the UC Irvine. As you can see it from their page, linked above, it will be faster in the end, because they have plan to use SSE and Altivec. You can see that how fast it is compared to its predecessor.

TraceMonkey performance enhancement

(Click the image to read the full article)

    On the other hand, the SquirrelFish from the WebKit adopted bytecode compilation and technique similar to the “trace tree”. (Same link to the above link for the WebKit. ) You can see how fast it is compared to is predecessor from this picture.

 

SquirrelFish performance enhancement

     Or you can see a graph claimed by the Apple Inc here. But it is not for the SquirrelFish. The SquirrelFish is much faster JavaScript engine than the one used for the currently announced Safari browser.

 

Safari vs. IE and other on JavaScript performance

     I did NOT read the paper on the “trace tree”, so I’m not sure how much different the techniques used for the SquirrelFish and the TraceMonkey. If anyone read it and compared them, please post what the differences are.

     Now, it is time for the Chrome’s V8.

According to its introduction page, it compiles the JavaScript source code and thus makes a native code. Let’s take excerpt from the page.

V8 compiles JavaScript source code directly into machine code when it is first executed. There are no intermediate byte codes, no interpreter. Property access is handled by inline cache code that may be patched with other machine instructions as V8 executes.

So, unlike the SquirrelFish, it is compiled to the native code. Therefore it should be faster than the SquirrelFish. It also uses other technique : Fast Property Access, Efficient Garbage Collection

How fast is the V8? Let’s take a look at it.

Performance Comparison

(The unit is in ms. So, the shorter is better)

Performance Comparison

 ( The longer is better )

 

Performance Comparison

( The unit is in ms. So the shorter is better. )

For more detailed explanation, please visit Wayne Pan’s blog.

What is interesting here is that Wayne used FireFox 3.1 Nightly [1.9.1b1pre/200809020331. According to his test, the V8 is faster. But in a mozillazine’s blog, it says the other way.

 

Is the TraceMonkey faster than the V8?

But even at the MozillaZine’s blog, it points out the cases which is slower than the V8.

 

TV vs. V8

 

According to this article, the Mozilla will be 7x faster in the end.

     So, they share something common that they are not based on interpreters anymore. VM can be thought as a better interpreter, but…. anyway.. Especially the TraceMonkey, i.e. TM, shares lots of things with the SquirrelFish. 

     Many of you will think that the TraceMonkey and the V8 are in native code, while the SquirrelFish is in bytecode, so the SquirrelFish is slower. Well.. yeah.. I think so. But probably the SquirrelFish can be faster in the long run. I guess there is reason Apple inc chose the SquirrelFish. In the next version of the Mac OS X, so called the Snow Leopard, more dynamic execution of code will be incorporated, called “Grand Central”. Also, to enhance security in the code and to adapt the performance more to specific cases, the execution of the binary code will be dynamically changed. For example, if clause’s execution path can be different under different cases, even though the whole if.. else.. block is same. So, implementing it in bytecode can have more potential in dynamical executed environment. So, we can’t conclude which approach is better yet.

(How about the Linux? Will it have similar technology like the Grand Central? )

     By the way, don’t forget that you can use the WebKit as a HTML engine while you can choose the SquirrelFish or the V8, as the Google does for its Chrome browser. ( Yeah.. in your code, you can use the WebKit, SquirrelFish and the V8 in your codes! )

     Currently, the Google advertised the Chrome more well than the Mozilla Firefox 3 and the WebKit. So, people are amazed by the Chrome performance, although they use very similar techniques and its performance is similar to those of others. This is the power of marketing or using journalism!

About Firefox 3.0 and Camino

Recently I started using the Safari on my Mac more often than ever.
Consequently I became to use the Firefox less frequently.
What was the cause? I like the “Find-As-You-Type” and “multi-highlighter”, and other extensions for the Firefox a lot. (Oh.. The “Find-As-You-Type” of the Safari 3.0 is very cool, though. ) The Firefox provides better features for reading long articles than any other web browsers.

However, from a certain version of the Firefox, it became painfully slow.
Especially, when you switch input methods, it stops responding. When you make a new tab or open a new window, it slowed down too much. When an HTML page contains a flash media, it halts. Like the Java advocates, the Firefox people also do the same mistake, “Ours is the fastes.”
They may count the HTML rendering speed only. Launching the browser, making new window, closing a window, browsing back & forth, and so on should be considered for reflecting real performance properly.

However, a few days ago, I downloaded the Firefox 3.0 for testing.
It uses the Cairo. It accepted native widget using the Carbon. As a result, switching tabs, windows, and launching become faster. What is even better is that switching input methods are now fast enough to use. Also, the Firefox 3.0 doesn’t hang as often as the Firefox 2.0 did.
So, I guess the widget code based on the XUL was the cause of the serious slow-down, and many other problems. Probably it is the one reason the Apple didn’t choose the Moziila codes.
(Actually the Gecko is good. But what I mean is the Mozilla’s code base. )

Things can be broken again, though. However I hope it would not.

By the way, where is the future of the Camino then?
I don’t think Camino has superior Mac-like UI than the Firefox. To me, Firefox GUI is much better. Now, the Firefox has the native widget, and it shares the HTML rendering engine, Gecko, with the Camino.
There is nothing unique left for the Camino.
Bye, bye, Camino~