最早的技術擁有者應該是 Netscape, 但 KDE 用了一套自訂的 Javascript engine – KJS 和 webcore engine – KHTML. 其中 KHTML 做得比 Netscape Navigator 的 Gecko 還小, 所以被 Apple 相中拿來開發 Webkit. KDE 原本沒有做 webview 的部分, 所以 Webkit 的名稱是 Apple 取的.
Apple 除了開發 Webkit, 又以兩手策略開發封閉性的 Safari. 到了 2010 年, Apple 做出 multi-process 的技術, 把 main process 和 render process 分開, 因此把 Webkit 改為不相容的 Webkit 2.0.
Google 的策略是借用 Webkit 的 Webcore, 其他自己搞. 後來開發出 V8 Javacript engine, 算是有了重大突破. 接著 Google 又做出 Blink engine, 把 webcore 換掉, 這些好料都放進了 Chrome. 當然 Google 也是兩手策略, 不會平台讓 Apple 佔便宜.
QT 和 GTK 都基於 Webkit 2.0 做出新版. 同理, WPE (Wayland for Webkit) 當然也是 ‘for’ Webkit 2.0 才聰明.
那 Chrome 有 multi-process 嗎? Chrome (Chromium) 的做法是起好幾個 Webkit [1]. 以空間換取時間. 至於沒有 mutli-process 的弱點, 據說是用 timer 來多工執行, 沒有用到多核的優點 [3].
那 Blink 比起原來的 Webcore 差多少? 根據 [2], Blink 從 Webkit 裡面刪掉 8.8 百萬行的 source code…身輕如燕, 難怪叫做 blink. 不意外地, Qt 等等上層 API 也 port 到了 Blink.
對了, Chromium 是鉻, Cobalt 是鈷, 看起來是兄弟關係. 那麼 Google 的 Cobalt 又是做甚麼的? 這個資訊很難找, keyword 下錯絕對搜尋不到, 客官要看這裡 [4]. Cobalt 的作者本來是負責維護 Chromium 裡面的一段代碼, 叫做 H5VCC (HTML5 Video Container for Consoles). 他在各種平台 porting 這段 9 百萬行的 code 好幾年後, 終於受不了了. 決定要推出符合下面特色的功能:
- Limited Memory. 記憶體少.
- Slow CPUs. CPU 慢.
- Fewer cores. 更少核.
- Sometimes No GPU. 可能沒 GPU.
- Sometimes No JIT. 考量安全性, 也不需要支援 just in time 代碼.
- Heterogenous Development Environments. 跨平台環境.
- No navigation. 不用瀏覽, 只要呈現.
- No scrolling. 不需要捲動畫面.
因為 Cobalt 弱弱地不用處理很多事情, 連 Javascript engine 都可以偷掉. We have, perhaps surprisingly, not written our own JavaScript Engine from scratch. Because of the JITing constraint, we have to be flexible with which engine(s) we work with. We have a bindings layer that interfaces with the JS Engine so that application script can interface with natively-backed objects (like DOM elements). 因此近來成為 porting Youtube 的主流.
[REF]
Cash Chou's Blog 