Firefox 18 vs. Chrome 24

我們的產品以網頁為人機界面。這些日子我最關心的事情之一就是 Firefox 在 javascript performance 上的性能提升。雖然 Chrome 的性能已經滿足產品的需求，我仍希望 Chrome 不是唯一的選擇。畢竟，Firefox 在客製化的能力上略勝一籌。

Firefox 18 採用 IonMonkey 為引擎，首次使得我們的產品能在 Firefox 上使用。雖然切換畫面時，仍有延遲，已是很大的進步。

Google 在去年八月提出新的 javascript 速度評估的基準 octane。經瞭解，他的基準包括了以下幾項新的測試：

• Box2DWeb
• Mandreel
• Pdf.js
• GB emulator
• CodeLoad

其中的 Box2DWeb 測試 2D 繪圖能力。Mandreel 測試 3D 繪圖能力。這兩項對我未來的產品都很重要。

Octane 的連結位於：
http://octane-benchmark.googlecode.com/svn/latest/index.html
只要點選以上連結，就可以進行測試。

以下是使用我的筆電針對 octane v1 測試的結果：

測試	測試內容	Chrome 24	Firefox 18
Richards	Core language features	10474	8991
Deltablue	Core language features	13812	11333
Crypto	Bit and math operations	11485	9111
Raytrace	Core language features	14682	6701
EarlyBoyer	Memory and GC	23679	12388
Regexp	Strings and Arrays	3061	922
Splay	Memory and GC	4355	10431
NavierStokes	Strings and Arrays	15017	15418
pdf.js	Strings and Arrays	10237	3913
Mandreel	Virtual machine	10154	6803
GB emulator	Virtual machine	11111	6212
CodeLoad	Loading and Parsing	10444	8634
Box2DWeb	Bit and math operations	11667	7325

可以看出 Firefox 18 和 Chrome 24 仍有很大差距。

不過，Mozilla 的團隊每日比較 Firefox 和 Chrome 的性能（http://arewefastyet.com/）， 從 2012 年十二月到 2013 年二月初，可以見到 Firefox 一路迫進 Chrome 的性能。該說唉呀已經達到  Chrome 的 90% 的速度了。想來，我的產品上切換畫面的延遲可能已得到解決，只是還得等到 Firefox 19，20。但是，是不是有可能更好，進而和 Chrome 平手？

似乎是可能的。Firefox 的 Generational GC 尚未完成。它的完成將帶來 Firefox 性能的再次提升。

Mozilla 的 Javascript 文件

Mozilla 的 Javascript 文件

Ringojs

有一段時間未寫部落格。但不表示這段時間什麼事都沒發生。

這段時間發生了很多事。

首先，在個人工作方面，已經確定要將 javascript 用於自己的產品中。最主要的工具是 YUI 3 和 RingoJS。

此外，在 javascript 世界也有很多值得注意的變化。由於我較重視 Server side，CommonJS 的風起雲湧以至最後的雲淡風清讓我感到一點憂心。早先，有志於 Server Side Javascript 的人們成立了 CommonJS 社群，建立 module 的架構，以及可以讓程式相容的 libraries。但在 NodeJS 出現後，NodeJS 瞬間抓出大家的眼光。以致於 CommonJS 的努力讓人們漸漸淡忘。

在這段時間，原本我極感興趣的 Helma-NG 改名為 RingoJS，採用了 CommonJS 的規範。現在它可以說是最符合 CommonJS 規範的 Server Side Javascript 平台了。比 Helma-NG 還讓我喜歡，也成了我工作上的選擇。雖然有點兒默默無聞，但它的撰寫者十多年來在 Server Side Javascript 上的堅持讓人信賴。最近，更因一篇「RingoJS vs. NodeJS」，它開始被更多的人注意。

身為 RingoJS 的愛用者，我自然也要加入這場戰局。因此，我將這篇「RingoJS vs. NodeJS」中 RingoJS 的優點翻譯於後，和我的讀者分享，在這翻譯中加上了我自己的修正。

1. RingoJS 是最符合 CommonJS 規範的平台。此點勝過 NarwahlJS 及 NodeJS。
2. RingoJS 的執行速度快。RingoJS在執行前會經過 JVM 的編譯，同時，RingoJS 的模組是動態載入的，這使得它的 start up time很短。
3. RingoJS 成熟、穩定、不會當。這是我自己的使用經驗。我還沒遇過 RingoJS 當掉的情況。
4. 直接使用成千上萬的 Java libraries。Ringo架構在 Rhino javascript 引擎之上，它和 Java 之間的關係真是血溶於水般，它可以直接使用 Java libraries 及物件，就好像它們是以 javascript 寫成的。不像 NodeJS 等，呼叫 C 時必須撰寫各種 wrappers。
5. 程式可以在 Linux/Windows 下執行。跨平台呢。（當然也可以在目前正熱的 Android 上執行囉。）
6. 支援同步(synchronous)及非同步(asynchronous)的程式撰寫風格。NodeJS紅的原因是它強調非同步撰寫風格。但是在絕大多數的場合，以同步風格撰寫最簡單。使用 Ringo，簡單的問題可以簡單解決，複雜的問題一樣能解決。
7. 因為「AppengineJS」提供了大量可以在 Google App Engine 上使用的 libraries，RingoJS 很適合用來開發 Google App Engine 上的雲端運算程式。
8. RingoJS 的 Leader 技術一流，又十分親切，願意傾聽使用者的建議。

Scala vs Javascript

在撰寫 javascript 程式時，我較不習慣的是它缺少靜態型別的檢查。一直希望有一種語言能結合動態型別和靜態型別語言的優點。因此最近看到 Scala 時我充滿興趣。

我花了一些時間瞭解 Scala 並撰寫了一些程式。這語言很容易上手。不過我遇到以下的瓶頸：

1. Netbeans IDE 的 Scala plugin 還不成熟。
2. Scala 並不是為 embedding 設計的。
3. Scala 使用 Java classes 沒問題。但是 Java 使用 Scala 的 classes 會有些問題。

因此，我還是回到 rhino，以 javascript 為我的 scripting language。

解決安裝 narwhal 的問題

在 ubuntu 安裝 narwhal 時遇到以下錯誤訊息：

org.mozilla.javascript.WrappedException: Wrapped java.lang.IllegalArgumentException: Bad language version: 180

搜尋網站找到了以下報告：
https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/255149

執行以下指令可以解決問題：
sudo rm /usr/lib/jvm/java-6-openjdk/jre/lib/rhino.jar

指令只是刪除一了指向 rhino 的連結，因此可以放心，並沒有真正刪除 rhino，只是使得 rhino.jar 不被自動加入 bootclasspath 中，導致無法使用 narwhal 自己的 rhino。

Webkit/Squirrefish/Nitro Extreme

我一直想找一個可以用於我的產品的 Scripting language 及 Virtual machine。我從 Python/Ruby/Lua/Parrot/LLVM/Forth/Scheme 一路看下來，最後看到 Javascript。在 Javascript 中我先看過了 Tracemonkey，今天又看了 Webkit 的 Squirrefish Extreme (Nitro)。

我想 Nitro 是個好選擇。我已經決定在人機界面使用 Javascript+Java了。在 interpreter 或是 motion 使用 javascript 也會是個好方法。而 Squirrefish 使用 direct threaded codes，這些概念我從 Forth 學過。Squirrefish 有 bytecodes ，這些 bytecodes 可以考慮用在 PLC。

這會是一個長期的學習工作。我甚至想開始一個 Squirrefish 和 Gobo Eiffel 結合，Gobo Eiffel 使用 Squirrefish 的 garbage collector 的計劃呢。

rhino-debugger

目前我的網路遊戲是以 plt-scheme 寫成，有以下兩個原因使得 plt-scheme 難以被取代：

1. 它的 at-exp 容易讓我描述遊戲的劇本。
2. 它的 continuation based web server 使得我容易撰寫遊戲的流程。
   

但未來遊戲若要做成 GUI 的形式，我會期待用 javascript 完成。此時，我會選擇以下的工具：

1. rhino, 以 JAVA 實現的 javascript interpreter。
2. JAVA 的 Swing。因為它的無所不在，因為 Java Web Start。我不選擇 Eclipse 的 SWT，並不是有 JAVA 的地方就有 SWT。

 為未來做準備，我因此必須多瞭解一點 rhino，以及 JAVA。以下是我今日拜訪的連結：
Rhino + Javascript + Swing, Look Ma no Java ，很好，這樣短短的一篇，就給了我一個好開頭。

依據這篇文章，我寫了以下小小的 GUI 程式於 launch.js 中，以 rhino launch.js 成功地執行。

importPackage(Packages.javax.swing);
importPackage(Packages.javax.swing.border);
importPackage(Packages.java.awt.event);
importPackage(Packages.java.awt);
importPackage(Packages.java.util);

importClass(Packages.java.beans.EventHandler);

function runApp() {
        var lframe = new JFrame("MapaView");
        lframe.setSize(500, 400);
        lframe.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        var panel = new JPanel();
        panel.border = BorderFactory.createEmptyBorder(30, 30, 10, 30);
        panel.setLayout(new java.awt.GridLayout(0, 2, 10, 10));
        var exitButton = new JButton("Done");
        exitButton.addActionListener( function() {
                java.lang.System.exit(0);
        });

        panel.add(new JLabel("done yet?"));
        panel.add(exitButton);

        lframe.add(panel);
        lframe.pack();
        lframe.show();

}
runApp();

此外，我也瞭解了一下 rhino-debugger。rhino-debugger 這命令在 Debian Linux 下是一個 script 檔。閱讀後多多少少讓我知道要如何呼叫 Java。呼叫 Java？唉，是啊，我完全不懂 Java，我不屬於新生代的軟體工程師了。

從 Helma NG 到 Jack

為了瞭解為何 Helma NG 無法顯示中文，我繼續走在探索道路上。

我必須瞭解 Jack 。因為 Helma NG 架構在 Jack 上。

我試著執行一下 Jack。只是修改它的 jack/examples/example.js ，加幾個中文字。結果 Jack.Lint 告訴我 Error: Content-Length header was 24, but should be 20 。

我想是 Jack.Lint 的 bug 。

不禁嘆息。看來 javascript 的中文之旅還在初階段呢。

有趣的是，看 jack 的寫作風格和 Helma NG 是完全不同的。

Helma NG 0.4 在 App Engine 上無法顯示中文

很不幸的。無法顯示中文。這迫使我必須瞭解原因。為了瞭解原因，我必須學很多本來不必學習的東西。

本來，我的計劃只要使用 Helma NG 和 javascript 就能搞定。現在，我必須探就 Helma NG 的底層，瞭解到底發生了什麼事，為何 java 可以正確顯示中文，而建立在 Java 之上的 Helma NG 卻不可以。

我先瞭解 rhino 及 app engine 的關係。以免被 Helma NG 的複雜性嚇到。以下這篇文章，給了我一個不錯的開始。

Javascript on Rhino on Java on App Engine

這時開始感到困難了。

我不會 Java。

又回到了年輕時什麼都不會的時候。

努力之後，我學會了：

1. 使用 Eclipse 的 Project->Property 來增加一個 jar file。
2. 在 src 中增加一個新的 .java 檔。
3. 如何 embeds rhino。
4. 使用 FileInputStream 及 InputStreamReader 來讀取 .js 檔，以便設定 encoding。FileReader 雖然較容易用但無法設定 encoding 。
5. ContentType 要加上 charset=UTF-8。
   

It works!! 我寫的小小的 Rhino Servlet 可以在 App Engine 上顯示中文了。

核對 Helma NG 的程式，其 file.js 及 MarkdownProcessor.java 都使用 FileReader。這應該就是 Helma NG 無法在 App Engine 顯示中文的原因。