GitHub 提供專案授權簡介與概要

Do What The F*ck You Want To Public License,

大概上週看到有人在 Twitter 講到 GitHub 現在會在專案上顯示該專案所使用授權條款的摘要,長的像是上面那樣,官方也有發表公告,其實這個修改是結合之前的授權偵測Choose a License

Choose a License 也是一個 GitHub 的附加服務,用來協助使用者挑選適合的授權條款,現在在 GitHub 建立新的專案時,可以順便初始化專案,包括建立 README、產生.gitignore和挑選要使用的授權條款:

Initialize Project

授權條款旁邊的 i 點下去其實就會送到 Choose a License 網站去了(不過兩邊沒有連動接起來就是),Choose a License 網站則針對每種條款都一份重點摘要,分為 Permissions、Conditions 和 Limitations 三個區塊,分別條列出該條款可以做什麼(例如商業使用)、有什麼條件(例如需要也使用相同條款授權)和條款的限制(例如免責),而現在 GitHub 上顯示的條款摘要其實就是這邊的資訊搬過來的:

Choose a License

Choose a License 網站其實有很多授權條款的整理,而不是只有常見的幾種,可以看appendix頁面有完整清單,可惜裡面沒有Vim License,另外特別想說的是 GitHub 自己(應該沒錯)提供的Unlincense,相似於創作領域的CC0,就類似丟到 Public Domain 的意思,不過保留了免責條款,講到免責聲明,就還要順便提一下WTFPL,它其實也是超自由的 License,差別就是連免責聲明都沒,其實是更加接近丟到 Public Domain 吧?

最後想說的是 GitHub 用來判斷專案使用的授權,用的是licensee這個 Ruby Gem,看起來完全就是為了做這些事情寫的,我看好像也沒其他類似功能的專案,作者 Ben Balter 其實也是 GitHub 員工。


Guetzli: A New Open Source JPEG Encoder

Guetzli

今天一早起來就看到 Google發表的新的 JPEG 壓縮程式,叫 Guetzli(一種瑞士餅乾),這是 Google 繼ZopfliBrotli之後,算是第三個比較容易被大家廣為使用的新的節省網路流量的工具,這次主要針對 JPEG 圖片格式,和之前 Mozilla 的mozjpeg的作法一樣,保持目前 JPEG decoder 的相容性,然後看能加強 JPEG 圖檔到什麼程度,我稍微測試了一下,結果還不錯,目前還沒有 homebrew formula,如果要自己 build 的可以參考這篇,基本上就是用 bazel 來編譯,然後可能會需要先裝 libpng 和 gflags,這兩個可以用 homebrew 安裝:

brew install libpng gflags

然後裝bazel

brew install bazel

然後到專案目錄下執行編譯指令:

bazel build -c opt //:guetzli

結果就會把執行檔放到bazel-bin/guetzli這位置,就可以拿來用了,不過其實官方 GitHub repo 上的release那邊就有編譯好的版本,抓下來用 Terminal 執行chmod +x也可以用(我是自己丟到/usr/local/bin/裡面),指令很簡單,可以加上--quality,預設是 95,不過最小只能 84,設更小的值會跟你說,真的想要的話自己去改原始碼...

速度就如大家所說的,和其它工具比起來真的慢很多,感覺是有一些 recursive 找最佳解的過程,輸出的結果我覺得最讓人印象深刻的是對於純色色塊的處理,也比 mozjpeg 好上不少,輸出檔案的大小不一定會是最小的,不過品質好很多,差異是達到我可以放棄這點容量差距,而寧願要這畫質改進,然後就是 Quality 100 可能會體積暴漲,我隨便測試了幾張圖片,看起來設到 90 品質就蠻不錯的,看來目前通行的圖片最佳化工具又要有一輪更新了。


網路發佈資料之最佳實踐

Data on the Web Best Practices

前幾天 W3C 發佈了這份文件Data on the Web Best Practices(DWBP),內容是關於在網路上發佈資料時的最佳實踐(公開或非公開的都適用),讓我想到了之前的 g0v summit 羅佩琪分享提到的一個重點,開放是有成本的,當時演講的影片:

稍微看過這份文件後,覺得之前確實蠻缺乏這份整理好的文件,每點看了就都覺得,確實是應該要這樣的,不過沒有這種整理好的 checklist 其實真的要做的時候還蠻容易漏東漏西的,然後就是,每一點都是成本啊!!

整份文件還蠻有翻譯的價值的,比較不像是 HTML Spec 會常常更新,不過我自然沒這麼多時間可以翻譯,所以就先把重點標題翻起來放,以後有人要開始就先有個基礎了,DWBP 整份文件有 35 點 Best Practice,每一點都有標題、簡述、原因、預期結果、可能實做方法、如何測試、證據、好處、範例等內容,其中好處的部分是分成八種:

  • Comprehension,人類容易理解理解
  • Processability,可程式自動處理
  • Discoverability,可讓程式自動發現
  • Reuse,容易重複使用
  • Trust,可靠
  • Linkability,可連結
  • Access,容易存取
  • Interoperability,容易互動(發佈者和使用者之間)

我只翻譯了其中的標題和簡述,順便附上每一點的好處(上面的八種好處),以下就是這 35 點 Best Practice:

閱讀「網路發佈資料之最佳實踐」全文

Safari 10 for Developer

Safari 10 跟著 macOS 一起出來了,這次更新了不少東西(對於網頁開發者來說),Apple 也依舊放了一份文件在他們的 Developer Library 裡面,以下列出我覺得比較有趣的:

CSP 2.0

CSP 2.0 和之前的版本相比,最主要是多了非常多可以控制的權限,也有幾個名稱有改掉,不過基本上格式是相容的。

Shadow DOM

Shadow DOM 1.0 標準,這也讓 Web Component 的理想又往前賣進一步了。

ES 6

號稱支援度 100%,看起來是依據ECMAScript compatable table的,不過在 module 的面前,還沒有真的 100% 的啊,另外主流瀏覽器其實支援度都蠻高了,之前 Edge 還放話說領先的,沒想到現在就已經被 Safari 10 和 Chrome 超過了,而 Chrome 看來也之差 tail call 而已,接下來應該又要開始效能比拼了吧。

Inline and Auto Video Playback in iOS

這也是等很久的功能,之前就有先開放靜音影片能直接在 iOS Safari 上自動播放,主要的考量是,gif 和 mp4 相比,還是 gif 比較吃資源啊。

ES Internationalization

ECMA-402 支援,這也是希望快點普及的東西啊,不然數字、日期什麼的搞本地化實在很麻煩。

WOFF 2.0 Support

令人意外的有點慢,不過還算很有誠意的把很新的CSS Font Loading Module Level 3的 API 做好了。

#RRGGBBAA

新的 CSS color 格式,也是前陣子才 propose 出來而已,這樣以後就可以讓 CSS 裡的顏色格式統一點了。

Right-to-Left Language Support

主要是 RTL 頁面 scrollbar 的位置終於會換邊了。

Media Query for Wide Color Gamut Support

廣色域的 CSS media query,主要是因為最新的 iMac 和 iPhone 7 都有支援 P3 色域了。

WebDriver Support

主流瀏覽器最後一個支援的...

Apple Pay for the Web

這真的蠻兇狠的,不過 Google 也有在 Android 做類似的就是了。

大概就這些了,其實也列出超過一半的項目了,Safari 這種更新頻率其實比起其它幾家來說吃虧不少,不過還是一直有跟上最新進度,其實也蠻厲害的,更何況現在 Google 都把人拉到 Blink 去,有回到 Webkit 的貢獻似乎比例上不高。


7 Bit Encoding and Email

最近工作上比較常接觸到 email 的東西,然後比較認真的看了 HTML email 信件的內容,以前我以為都要用 base64 編碼來處理,可是用 base64 來處理 HTML email 我一直覺得很不合理,一來大小會變 1.33 倍,二來整個 HTML 原始碼傳送時會變的幾乎無法辨識,收信軟體還要先解碼一次才可以 parse HTML,感覺完全不需要多此一舉,總之就是覺得為什麼要做這麼愚蠢的事情,明明看起來MIME就沒這樣限制,所以我應該可以這樣寫:

Content-Type: text/html; charset=utf-8

然後內文直接放 HTML 原始碼,可是不知道為什麼沒人這樣做,事實上也不 work;最近多看了一些郵件原始碼才發現其實還有個 Quoted-Printable encoding 也很常用,看起來比 Base64 的結果還要接近原始碼許多了,所以就研究了一下它到底是什麼格式。

Quoted-Printable encoding 的基本原理就是用=作為 escape 字元,然後可以把要轉換的字元轉成=字碼的形式,例如 Big5 中文的就要轉成=A7=DA,規範上要轉換的是除了可見(printable)ASCII字元以外的字元都要轉,而 ASCII 是個 7bit 編碼,字碼只有從 0 到 127 而已,而 email 要用 Quoted-Printable encoding 的主要原因其實就是為了讓文件內的每個字元編碼都維持在 7bit 編碼範圍內,現在大家常用的編碼像是 UTF-8 和以前常用的 Big5 等都是 8bit 編碼,兩者差別就在於每個傳輸的 byte 中有沒有使用到第 8 個 bit,轉成二進位的時候,7bit 系統編碼不會用到最左(higher-order)邊的那個 bit。

為什麼需要用 7bit 的文字編碼呢?主因是計算機和電信網路早期很多系統是只支援 7bit 編碼的,SMTP 的規範就直接要求 TCP 傳輸時,每個 byte 最左邊的 higher-order bit 要填 0:

The TCP connection supports the transmission of 8-bit bytes. The SMTP data is 7-bit ASCII characters. Each character is transmitted as an 8-bit byte with the high-order bit cleared to zero.

當然這規範很落後時代,所以在MIME(Multipurpose Internet Mail Extensions)規範其實也有Content-Transfer-Encoding可以指定傳輸用的是什麼編碼:

Content-Transfer-Encoding: 8bit

不過為了相容舊系統,還是很少真的這樣使用的信件在傳遞,因為要是傳到了 7bit 系統,小則亂碼、大則程式當機。不過這就帶出另外一個問題了,難道 7bit 系統只能傳輸 ASCII 字集嗎?因為我還蠻常看到日文的純文字郵件,就去找了一些來看看,結果發現到有的是用ISO-2022-JP,而且是使用 7bit 的傳輸:

Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

信件內容的文字也都很正確,沒有亂碼:

iso-2022-jp

於是就看一下ISO-2022的介紹,發現原來是個很早就有的 7bit 編碼方法,後來根據這方法有訂出了 CN、JP、KR 等語言的編碼,不過比較通行的看來只有 ISO-2022-JP,然後我也找到 HTML email 用 ISO-2022-JP 的:

ISO-2022-JP

看起來就像是我理想中的 HTML email 原始碼啊,所以問題的癥結其實是,大家為了相容於舊系統,所以都用 7bit 傳輸,要 7bit safe 的 encoding 選擇有限,除了比較通行的 ISO-2022-JP 可以給日文用、字元太少只能給英文用的 ASCII 之外,其它語言就只能用 Base64 encoding 和 Quoted-Printable encoding 了,所以事實上其它 7bit 編碼的內容,也是可以直接透過 SMTP 協定來傳輸的,只是要看收信端的軟體能不能支援解碼,像是已經不太有人用的UTF-7就是 7bit 的 unicode 編碼。

最後,就是假設我們已經不用擔心老舊系統的時候,其實只要這樣寫在 MIME header 裡就可以直接傳 UTF-8 的 HTML source,不用再經過任何編碼處理了:

Content-Transfer-Encoding: 8bit
Content-Type: text/html; charset=utf-8

不過距離這一步不知道還有多遠就是了。


Web Push

前兩天要研究一下 Chrome 接 GCM 的實做,發現到 Google 又出一個新的服務叫 Firebase,然後新的 cloud messaging 服務就叫Firebase Cloud Messaging(FCM),隨便看了一下 Google 官方的文件,結果發現有提到另外一個正在制訂中的Web Push Protocol,照文件的說法,FCM 也只是個過渡時期的方案,最終目標還是用這個 Web Push Protocol,於是我就研究了一下他的設計,發現設計的還蠻漂亮的。

整個 Web Push Protocol 的基本架構如下圖:

Web Push Protocol

User Agent(UA) 通常是行動端的應用程式、Application 則是自家服務的後台;整個流程首先是 UA 透過 HTTP/1.1 POST 去跟 Push Service 訂閱(第一條橫線 Subscribe),然後會拿到一個 subscription resource,可能長成:

https://push.example.net/subscription/LBhhw0OohO-Wl4Oi971UG

另外還會拿到一個發訊息用的 push resource:

https://push.example.net/push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV

可以注意到兩個 resource 後面的 token 是不一樣的,兩者之間的 mapping 就是 Push Service 來負責;然後 UA 拿到這兩個網址後,發訊息用的 push resource 要交給自家服務的後台,也就是圖上第三條橫線 Distribute Push Resource,另外一個 subscription resource 則是要自己使用,UA 用 HTTP/2 打 GET 到 subscription resource,然後 push service 會把連線保持住不關掉,這就是圖上的第二條橫線 Monitor;自家服務後台的要送訊息的時候,就打 POST 去 push resource,也就是第四條橫線,從 Application 到 Push Service 間的 Push Message,push service 收到這個訊息時,就利用 HTTP/2 的 Server Push 機制主動傳送訊息,最後這個動作就是第五條橫線的 Push Message 了。

就這樣很漂亮的用 HTTP/1.1 + HTTP/2 把一個基本的 Cloud Message Service 的協定建構起來,而除了這最基本的訊息傳遞外,這份文件還有定義像是訊息重要度、訊息回條、群組訊息等等的方法,設計都還蠻漂亮的,安全性的部分則是限制走 HTTPS over TLS,還有 operation 相關的說明,像是實際上要跑起這個服務,需要大量的 TCP connection 等等(因為都走 HTTP 了),有興趣的可以加減看一下。

補充:Firefox 目前實做的似乎就是這個協定更早版本的草案


My First Patch to Firefox

zh download dialog

OSX 自從升級到 10.10 之後,繁體中文版 Firefox 就冒出了一個 bug,一堆使用到作業系統原生的視窗,像是下載圖片,開啟檔案等等的,都會變成簡體中文介面,這個問題在 Bugzilla 上的編號是1089363,畫面看起來就像上面的圖一樣,這個問題的狀況,推測是 OSX 本來在這種系統對話框,會使用使用者現在設定的系統 locale,但是 10.10 改成應用程式正在運作的 locale,然後 Firefox 本來會用 localeAB_CD中的AB段而已,所以zh_TWzh_CN就都會變成zh,然後 OSX 的zh又會變成簡體中文,結果就變成這樣了。

其實這個 bug 的解法, Steven Michaud 很早就提出了,就是把本來 locale 的 resource 目錄的名稱改成zh_TW,大概 diff 如下:

AB_CD = $(MOZ_UI_LOCALE)

-AB := $(firstword $(subst -, ,$(AB_CD)))
+ifeq (zh-TW,$(AB_CD))
+LPROJ_ROOT := $(subst -,_,$(AB_CD))
+else
+LPROJ_ROOT := $(firstword $(subst -, ,$(AB_CD)))
+endif
+LPROJ := Contents/Resources/$(LPROJ_ROOT).lproj

其實不會很難,不過因為 Firefox 的程式碼變動很快,連 build script 也常常變動,那個 patch 檔出來的時候已經不能用了,然後又沒人處理就這樣一直拖下去,前陣子 Moztw 那邊又被提出來一次,剛好我為了弄 WebIDL 相關應用的時候有 build 過 Firefox,想說應該可以處理看看,就接下來嘗試了,build 本身蠻簡單的,就照著網路上的文件就好,比較難的是要 build 成特定語系的,找很久才在 Moztw 討論區找到答案,要在.mozconfig裡面加上:

ac_add_options --with-l10n-base=/d/lang
ac_add_options --enable-ui-locale=zh-TW

其中第一行設定的路徑要指定到你指定的位置,而且要絕對路徑,然後在該目錄 clone 翻譯的 repository 下來,可以在l10n-central那邊找自己的語系,以zh-TW來說:

cd /d/lang
git clone http://hg.mozilla.org/l10n-central/zh-TW/

然後這樣就可以 build 中文版了,build 完執行就看到精美的黃底紅字 XML 解析錯誤視窗。

Firefox Missing String

還好我有點經驗,知道 Firefox 的介面是 XUL 寫的,然後字串是用 XML entity 方式存在,所以很快就想到是翻譯問題,於是上去找了 l10n dashboard 看看繁體中文的狀況,看的是 fx_central 這棵樹下的字串:

Firefox l10n stat

可以看到目前有缺哪些字串,因為字串還沒穩定所以也還不會有翻譯,所以就需要手動進去把這些 entity 的定義補上,內容隨便填,然後重新 build 一次,結果就修好了!

nightly zh_TW download dialog

然後就開始想辦法生 patch 檔案了,中間也有用過hg mq,最後都固定改好,commit 後用hg export . > fix.patch,總之改好我就丟上 bugzilla 了,結果第一個 patch 只改到一個檔案,實際上應該有五個檔案要改,而且才隔一天,Makefile 就被別人改過了,只好重新找位置修改,重新生 patch,到最後一個 review 過,build 也過的 patch 中間還發生了不少事情,包括 Makefile 被別人又改動一次,用ABorLPROJ的命名問題,字串的變化造成假翻譯又要增加,還有 build 工具 mach 被人改壞,和推上去之後有 build 失敗的狀況等等,非常的一波三折。

其中 build 失敗是 b2g 的 build 失敗,原因是我有地方改錯,不過要測試也是要重新設定,參考的是Building the Firefox OS Simulator這份文件,把.mozconfig改成:

. "$topsrcdir/b2g/config/mozconfigs/common"

mk_add_options MOZ_OBJDIR=../build
mk_add_options MOZ_MAKE_FLAGS="-j9 -s"

ac_add_options --enable-application=b2g
ac_add_options --disable-libjpeg-turbo

重新 build 看能不能過。

改完產生的 patch 檔上傳到 bugzilla 時,要勾選 Content Type 是 patch,然後 review flag 設定成?,選一個 reviewer,通常會有 mentor 來跟你說選誰好,我的情形是timdream在幫忙,接著就等 reviewer review,他 review 過的話, review flag 就會變成+,然後就會收到一封「Congratulations on having your first patch approved」的信件,說了一些後續可以做的事情,接著要做的就是讓 patch 真的進去 repository,可以在票的 keyword 加上checkin-needed,就會有機器人自己來把你的 patch check in 進 mozilla-inbound 這個 repository,然後丟上機器人自動編譯和測試,例如這個我 B2G build 失敗的例子,都過了就會進 mozilla-central,之後才照順序進 mozilla-aurora、mozilla-beta、mozilla-release,現在進去 mozilla-central 的大概要等 Firefox 42 才會上線了,應該是和 OSX 10.11 同時吧。


webappsec

Safety first.

這幾天才注意到 W3C 的 Web Application Security Working Group,簡稱為 webappsec,專門負責安全相關的規範制訂,是2011年就成立的,算是很後知後覺吧,其實現在很多已經很廣為人知的 Web 安全機制都是出自他們之手,像是CORSCSP,然後他們現在也很跟的上潮流,把標準的制訂也移到Github上了,其實會發現這個 Github repo 是因為最近在看 fetch 的 spec,裡面多了蠻多內容,而且有不少引用到其它新標準的地方,然後看這看著就看到 webappsec 這邊,順便就看了一下,有幾個新草稿好像還蠻有趣的,想說可以介紹一下,不過這些東西大部分都還不能用就是了。

第一個是Secure Contexts,這個新東西目的很簡單,就是判斷現在的連線狀況是否安全,以前的話,前端只能看是不是使用 https protocol 連線,不過 Secure Context 有比較多的判斷流程,例如用 SSL 就不會被當成是安全的,要 TLS 才會被認為是安全,如果不是 TLS 連線則還會判斷連到哪裡,看看白名單黑名單之類的機制。

第二個是Credential Management,主要是為了因應現在瀏覽器很多都有記下使用者填的表單資料,包括登入的表單,而這等於是把使用者某個網站的帳號密碼都記錄下來,不過其實瀏覽器要做這些功能也是會遇到很多問題,像是他要怎麼判斷現在的表單是登入表單,哪些欄位是帳號密碼,或是網站用不一樣的機制,例如 XHR 來登入,這樣瀏覽器如果無法知道是什麼機制,就無法替這些特殊機制的網站的使用者提供方便的功能,所以 webappsec 就提出 Credential Management 這個功能讓網站開發者可以透過設計好的介面來告訴瀏覽器他們的網站是怎樣登入的,然後可以儲存帳號密碼在瀏覽器端,之後提供 API 給 JavaScript 呼叫出來送到 Server 端驗證,不過說是呼叫出來,其實 JavaScript 也看不到密碼明碼,而只能直接送出 login 的 request:

navigator.credentials.get({ "password": true }).then(
  function(credential) {
    if (!credential) {
      // The user either doesn't have credentials for this site, or
      // refused to share them. Insert some code here to show a basic
      // login form (or, ideally, do nothing, since this API should
      // really be progressive enhancement on top of an existing form).
      return;
    }
    if (credential.type == "password") {
      credential.send("https://example.com/loginEndpoint")
        .then(function (response) {
          // Notify the user that signin succeeded! Do amazing, signed-in things!
        });
    } else {
      // See the Federated Sign-in example
    }
  }
);

這是從 spec 內複製出來的 sample code,一個重點是,JavaScript 程式碼其實碰不到你的密碼,只能直接把 credential send 出去,其它也還支援像是 Facebook 那種第三方登入的設計,以及把 credential 存進 store 等等機制。

第三個是Subresource Integrity

<script src="https://analytics-r-us.example.com/v1.0/include.js"
        integrity="sha256-Rj/9XDU7F6pNSX8yBddiCIIS+XKDTtdq0//No0MH0AE="
        crossorigin="anonymous"></script>

這是個看範例馬上就能理解幹什麼用的,就是對網頁要用到的其它 resource 檔案包括:js、css 等加上驗證檔案正確性的 hash,為的是避免有第三方的檔案內容被惡意攻擊者修改過。

第四個是Upgrade Insecure Requests,這是唯一目前已經可以用的,為的是解決 mixed content 的問題,也就是有的網站可能最近才改為 HTTPS 連線,但是網站內部用到的一些內容還是寫死 URL 用 HTTP,這時候瀏覽器就會跳出說網頁內容可能不安全,然而,這些使用 HTTP 的檔案其實可能用 HTTPS 連線也找的到,像是 Flickr、TED 等都有支援 HTTPS 連線,而 Upgrade 就是跟瀏覽器說如果這些內容找得到 HTTPS 的就用 HTTPS 的,而不是只看寫死的 URL,目前 Chrome 43 已經開始支援了,有個線上demo可以看,設定方法可以透過 CSP header 加上upgrade-insecure-requests或是寫到 meta 標籤裡面(demo 用的)

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

其實這個標準我一開始以為是類似 HSTS,是對現在開的網址本身做判斷是不是有 HTTPS 可供選擇,有的話就改用 HTTPS 連線,仔細看之後才發現是用來處理 mixed content ,可是又看一看發現也有一部份比較新的草稿有講到這個功能,目前討論的版本是用 header:

HTTPS: 1

很簡潔不過還沒瀏覽器支援就是了。


Aster 與 PostCSS

台南

前端為了 performance 需求,把網站推上 server 時會需要把 JavaScript、CSS 之類的文字檔案合併和最小化,如果開發時寫的是 CoffeeScript 或是 SASS 之類的還需要先轉成 JavaScript 和 CSS 這些主流格式,要做這些動作其實第一個想到的是可以用 Makefile,優點是常見、各平台都有,不過寫起來並不像這幾年流行的 build tool 那樣直覺,而前端領域流行的主要是GruntGulp這兩個,兩者之中我個人是比較喜歡後起的 Gulp,不過前陣子意外發現一個看起來超正確的 build tool,叫aster,是 Ingvar Stepanyan 做的,他在 Zurich 的 Frontend Conference 2014 的演講算是比較大規模的發佈:

閱讀「Aster 與 PostCSS」全文

For the Entire Web

這陣子有兩件事情引起我的一些注意,覺得值得寫下,兩件事情我覺得其實本質上是同一件事情,先來看一下第一件事情,就是 Daniel Yoder 寫了篇文章React Is A Terrible Idea,這篇文章在 React 當紅的時間出現,自然引起很多人的不滿,隨便在 Google 上搜尋就可以找到一堆回應,我自己對於 React 其實是沒特別感覺,沒有喜歡也沒有覺得它做錯什麼,真的要說的話大概還有點覺得它方向正確,我是認為 React 和 Angular 的 directive 都在把 component 的觀念引入前端工程師的視野之中,而這對於 Web Component 的發展應該會是有正面影響的。

再回到 Terriable Idea 這篇文章,作者對 React 的評論我其實不完全認同,最後面有提到用 Web Component 而不要用 React,這部分我覺得是作者誤會了 React 的角色,不過有些地方有人說 React 明明就可以和 Web Component 合作,還附上 ng-conf 的演講影片,我到覺得他們也完全沒搞清楚作者的重點在哪裡;提到 Flipboard 的react-canvas那部分算是我認為最能表現出作者想要講什麼的,作者想說的重點是現在的網路環境有限制、有問題,但是遇到時不要用一些旁門左道的方法來處理,因為這些問題終究會被解決,而問題被解決時,你之前所花的時間和資源就等於是完全浪費掉,與其要浪費在走旁門左道,還不如把這些時間和資源用在從正確的地方解決這個問題,而最後受惠的不只是自己,還有所有網際網路的開發者、使用者,這是從一個很高等生命體的角度來看事情,就如同這篇文章的標題:「For the Entire Web」,要你犧牲自己的部分利益去成就整體網際網路的利益,當然這是有些理想化,很多商業公司可能要短時間就有產品出來,不太可能所有的開發在遇到問題時都停下來等瀏覽器或是標準齊備,但是對於不少的大型企業,我就覺得他們確實應該要好好正確的回饋網路環境來解決這些問題,像是文中提到 Facebook,還有接下來要說的 Google,不過他說 Facebook 是為了和 Google 競爭才開發 React 之類的論點我就不予評論了,太多臆測~

可能有人會說,有沒有這些資源的投入應該差距也不大吧,最近就剛好有另外一件事情可以佐證,Dart for the Entire Web這篇 Dart 官方的公告說到,Dart VM 將不會進入到 Chrome 裡面,也就是說要在瀏覽器上跑 Dart,將還是只有轉成 JavaScript 這個選項,這件事其實是蠻大的一件事,上一個在網頁裡面跑的另外一種語言是微軟的 VBScript,最大的問題不在於好不好寫,而是在於他被單一企業把持,不過後來結果大家也都知道,所以當 Google 推出 Dart 而且說以後 Chrome 會可以直接跑 Dart 的時候,我想大部分人都是都不看好的,甚至部分人是覺得 Google 怎麼做微軟做過的蠢事。而剛好在這個官方公告出來後幾天內,Brendan Eich 在 Hacker News 上回應一串討論回應的蠻激動的,這串本來是在說 ECMAScript 新版本有很多東西根本是從 Dart 來的,Brendan Eich 則是反駁說很多東西在 Dart 出來前就已經在討論有 Proposal 了,然後到後來寫了一篇幾乎都在抱怨 Dart,還提到 V8 team reset 的事情,從這邊看起來,似乎是因為新的 V8 team 不打算作 Dart VM 進去,才有了 Dart 那篇公告;而 Brendan Eich 抱怨的重點,其實就是前面那段提到的,Google 花了超多人力資源去搞 Dart,而不是來幫忙改進既有的 ECMAScript,而這確實有實際的影響,他舉了一個例子,就是大數(bignums)的支援,Dart 有支援,在 ES 這邊目前有一點可能性會在 ES7(2016) 中出來,但這東西其實從 2010 就已經開始有討論了,如果有人來將這些討論規格化,並實做起來,那大數應該在現在的 ES6(2015) 就有了。

最後再回到 Terriable Idea 這篇文章,我雖然不完全認同他對 React 的看法,但是我認為他的重點沒錯,如果他拿 Dart 出來講可能就不會引出這麼多砲火吧(可是可能也比較沒人注意),其實 react-canvas 我覺得也是很有趣的實驗,不過做成正式產品上線就是另外一回事了,最大的問題,他為了終會被解決的次要問題(畫面不流暢)完全放棄了親和力的問題,而 Flipboard 這種內容為主的產品性質是不該放棄親和力的。


此類別所有文章