這陣子有兩件事情引起我的一些注意，覺得值得寫下，兩件事情我覺得其實本質上是同一件事情，先來看一下第一件事情，就是 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 這種內容為主的產品性質是不該放棄親和力的。