D-Link 友訊科技工程師。喜好戶外運動、2008 年 5 月完成「跑步環島」。對於新技術跟程式碼有著強烈的偏執狂。
沒想到是這樣的排場,得跟兩位大大: JavaScript 之神 Douglas Crockford、台灣知名的 Perl/JavaScript 開發者 gugod 做在最前面的長板凳上。看來當初實在答應的太草率啦 ,小咖還是應該輕鬆地坐在下面發問就好了 XD 不過能跟大師近距離問答,機會真的很難得,所以我也把握了機會問了不少問題 :-D
在 The End of All Things 中,有一句 It protects the page from widget, but not protect the widgets from page.,對 Widget 在此的定義我不甚理解:是指物件導向上的限制?或者是來自不同網域的 JavaScript?
Douglas 的回答讓我蠻驚訝的:ECMAScript 5 的實作跟 Caja 的概念(將所有 HTML、CSS、JavaScript 轉換成安全的 JavaScript)相同,但不需要利用 Server 端的資源(所以不會有 Performance Penalty)。聽起來真的是超神奇的,但我還是要看到實作才能瞭解。已經有一些 Browsers 像是 Chrome 4 與 Webkit Nightly Build 實作了 ES5 的部份規格,但是這塊最讓人關注的安全性還沒有 Browser 實作出來。我很期待!
如果已經實作了 Browser 版的 Caja,那麼還有什麼東西要努力的呢?其實就是 Cross Site Script 的問題... Same Origin Policy 是現今網站非常依賴的東西:基本的外部函式庫引用、部落格常用的 Widget、跨網域存取資料的 Script Tag Hack 都是藉由此種方式運作的。大家可以想像拿掉會有多大的影響。要能夠不破壞網頁並改善 Same Origin Policy 的問題,是相當大的一個課題。
最近在工作上特別有這樣的感覺:工程師通常希望 Normalize:先把基礎建好再往上加東西、有時不方便是需要妥協的。但實際的產品設計通常是 Specialize:需一開始就完整規劃、考量到各種情況、希望與眾不同。所以做出來的東西通常過於複雜、元件不易重複運用。
但看到 Douglas 先提出了 ES3.1(考慮相容性、只修改語言本身的問題)與 ES4(類似 JAVA )相抗衡、接者 ES4 被廢棄而 ES 3.1 成功、再接者有今天簡潔好用的 ES5... 不禁想問:專案中有這麼多不同的成員與角色(Mozilla、Microsoft、IBM...),大家一定都會想要把自己的意見融入專案中,在多數決的議事方式,通常一定會把東西複雜化。他到底是怎麼說服大家、最後達到簡單的目標?
他回答一開始所有人都反對他,但有時所有人反對並不代表他們的意見就是正確的。而他單獨一個人所提出的 ES3.1 成功了、ES4 看到了也瞭解到過於複雜的東西是沒辦法被成功的,於是開始不斷地丟棄各種功能、但一開始決策的錯誤,最後還是導致 ES4 走向廢棄。藉由 ES3.1 的成功、加上 ES5 的參與者都從 ES4 學到了教訓、Douglas 便能夠順勢主導這一切往正確、簡單的方向走。不同意時提出更好的作法、錯誤的東西適時的失敗、持之以恆的耐力,真的缺一不可。
但他也說,下一個版本的 ECMAScript 也許有可能故態復萌,因人們往往容易因為成功而忘記教訓,回復到多數決的情況,把每個大家提出的 Idea 都納入,那可能又是錯誤的開始了... 真的是值得我們好好警惕啊。
目前沒有。唯一的入門點會是從 ECMAScript 5 的規格書開始。他也有在跟 ECMA 提倡希望有可執行、全部用 ECMAScript 5 所寫成的規格書。畢竟有程式可實際執行,大家理解與上手的速度將會加快許多。另外沒記錯的話,他也提到 The Definitive Guide 有在寫 ECMAScript 5 的書,不過還是得等環境成熟才會出版。我自己是有找到 2 篇 John Resig 的文章可以給初學者作參考:
由主持人 Adam 所準備的問題之一,其實 Douglas、我、gugod 的回答都差不多。雖然都很贊同 Unit Test 的概念,也有像 YUI Test 這樣的函式庫... 但是大多時候我們並不是在對 JavaScript 做 Unit Test,而是對瀏覽器的環境做 Unit Test。所以除了寫 Test Case 外、還必須利用 Selenium 來對每個不同的瀏覽器執行,要做自動化是非常非常困難的。
不過有開發者提到了 vgod 大大所開發的 Sikuli。gugod 也花了些時間介紹:一個安裝在系統的應用程式,把截圖作為變數,軟體會做影像比對,如此就可以做到自動化,概念相當不錯。
這是我本來就想要問的問題,Douglas 在一開始就自己講完了。仍然是批評 A big step in wrong direction。但一個蠻有趣的資訊是,他目前的目標是改善 Cross Site Script 所造成的安全性問題,但是由於 HTML 是掌握在 W3C,但 ECMAScript 與 HTML5 之間並沒有任何的合作,變得什麼都沒辦法做。現在 Douglas 批評 W3C 已經失控了,從話裡行間可以感覺他已經差不多決定再幹一次他在 ECMAScript 所做的事情了:反其道而行、提出改善安全性議題的 HTML 4.2。
Presentation 大部分的時間都在講 ECMAScript 的歷史。其實從 1999 年到 2008 前,都只有 ECMAScript 4 這個專案(語法看起來很類似 Java,唯一的實作為 Adobe ActionScript),曾經中斷,後來又因為 AJAX 盛行而再度聚會。Douglas 認為有許多窒礙難行之處:例如 ECMAScript 4 的語法是不向前相容的、而且把原本簡單的架構變得過於龐大與複雜。所以他另外提倡了 ECMAScript 3.1 的版本,不像 4 大改而只修正語言本身的問題、讓它用起來更好。雖然兩條線同時在開會,在 2008 年 8 月時 ECMAScript 4 專案宣布終止、而 ECMAScript 3.1 卻開始成為了 ECMAScript 5 的候選、並在 2009 年 9 月通過成為標準。下一個版本叫 Harmony 而非 ECMAScript 6(不應該用版號作為專案 Code Name,不然就會有類似 ECMAScript 4 的情況發生。)
Douglas 也提了許多關於 JavaScript 浮點數運算的問題(例如 0.1 + 0.2 不等於 0.3),從原本的 IEEE 745、IBM 強烈主張要整合慢 100 倍的 IEEE 745r(他以近似譴責的方式建議 IBM, 超屌)、9E6、DEC64 等等的解法。
已經成為標準的 ECMAScript 5 仍然保有原本的簡單與鬆散的彈性,但改善了正確的語法(以 let 與 constant 取代 var)、正確的 Scope 實作({ })、安全性(第三方程式碼嵌入)、函式的參數處理等...。我覺得 ECMAScript 的改進不可能有令人驚艷的感覺,但卻是很實在地考慮相容性、不讓這好用的程式語言毀於一旦、也唯有影響不會太大時,Browser 廠商才有可能去實作。
關於下一個版本的 Harmony,Douglas 還沒有太多的想法,他比較確定要做的是安全性、讓 Caja 的概念可以直接被實踐到 Harmony 裡,在 The End of All Things 他花了許多篇幅在講 Security 可能可以利用 Callback 的方式實作,並透過移除 Global Object 的方式、保護資訊不會被第三方程式碼取得。
這是我比較意外的部份,他對 HTML5 有非常多的批評。「A big step in the wrong direction」、「Just insisting that it is the inevitable winner」、「a lot of it is way wrong and should be start over」。其實 HTML5 並沒有經過 W3C 以外團體的審核、就通過了。而且它的東西過多且過於複雜,最大的問題就是完全沒有處理安全性的問題、新功能反而讓使用者資訊暴露的更多。他認為「標準」的訂立,完全不應該考慮實作新的點子、而是應該考慮向前與向後相容性、讓語言變得更好用。甚至他也不排除像 ECMAScript 3.1 一樣,提一個 HTML 4.2 的可能性。
HTML5 對我來說一直還是個問號,但主要是實作上的問題,IE6、7、甚至 8 是主流瀏覽器的一天,我就越不可能一頭栽進去,沒這樣的時間去處理差異化、只能實作在一些特別的情況上(例如 iPhone 的 Web 介面)。聽到 Douglas 這樣講也讓人更疑惑了,究竟 HTML5 是否能成為一個未來的解決方案呢?以 IE9 與 Google Chorme 已經實作來看,似乎是一條不可逆的道路... 或許是當天可以討論的一個議題。