我覺得用 React (+ Flux) 跟 Angular 是完全兩回事。Flux 基本上沒有任何 framework，只是一個 architecture 而已，React 的 API 也很少。所以 React + Flux 基本上就是一個 pattern 而已，它的 code 也只是 JavaScript。而 Angular 那類是一個需要很大 commitment 的 framework，有一天他們不在流行的時候那些 ng-repeat 也就完全是廢物了。

在我看 React 其實只是一個概念的實作。有去完 React Conf 的人當場就說了：「我現在才知道我不是去了 React 的 Conference ，而是一個 Functional Programming Conference。」[請求來源]

React 現在的實作用 Virtual Dom 和 HTML。Flipboard 的 react-canvas，或者 react-art 其實只是不同實作。 某天 Web Component 真的成了標準，不用幾天就可以有 react-web-component 的 demo 出現吧？ (看過 Netflix React Conf 的 talk1 他們是這樣實作他們的 React Gibbon Widget 的)

React Native 是個很厲害的發明，但只要 Apple 哪天換了個規定，說 XXX 不準用在 iOS 裡，或是 iOS 9 出了別的完全不同的體系，React Native 馬上就死了，就像當初 Flash 的命運一樣。

只要有一天 Apple 有 JavaScriptCore ，無論 iOS 有甚麼變化也不能阻止他們吧，因為 react native 的架構完全是普通 App 會用到的。 Application Logic 因為在 JavaScript，需要改動的部份也就是 render engine，相對來說反而是 native 的開發者更新需要做更多事吧？

又像 AsyncDisplayKit 之所以要重新做那麼多事，不是他們沒事很閒，而是因為 UIKit 只能在 main thread render。要做到 Paper 那種高效能動畫只能把 View 分開在背景 render ，但那要手動做很多工夫， AsyncDisplayKit 就只是把這些抽出來而已。有一天如果 UIKit 支援了 async render ，那 AsyncDisplayKit 自然也無用武之地了。

題外話。

Facebook 是個奇怪的公司，它很大，它擁有廣大的用戶，但是它卻沒有自己的平台。瀏覽器沒它的份，手機 OS 也沒有，桌機也沾不上邊，硬體方面更不用說了。它們曾經做過自己的手機 + launcher ，但是失敗的很難看。

他們是有人材的，是有能力推出新技術的，但是因為沒有平台，他們的技術 被迫 只能限制在一種風格裡 -- 就是依存在別人的平台之上，自己再包一層，重新建立一套標準。不過那個 標準 最後也只是假標準，因為 Facebook 不擁有平台，它沒辦法把他們的創見進入平台的標準中。

比方說最近有一篇講 React is terrible idea1 ，裡面講述 Facebook 的 React 架構種種不是，主要原因是它偏離標準太遠，virtual dom 基本上是把 dom 給丟了，然後還有公司寫了 react canvas，一整個 離題 的概念。瀏覽器平台主推的是 web components，作者呼籲大家應該採用這類標準，而不是走 Facebook 那種偏門，讓開放的大門越走越窄。

那篇文章有點偏激，不過他點出 Facebook 的困境與策略。擁有平台的公司是這樣的：如果 Google 想推行 web component 的概念，他們就在瀏覽器加入這功能，變成原生的，推行一陣子大家接受後，剩下的只要再遊說 mozilla 和 microsoft，讓它進入標準就好了。Google 的 SPDY 到 HTTP/2 的進展也是如此。

Facebook 想擁有自己的東西，但又不像其他大廠擁有平台，可以自己玩。造成發展的方向很奇特，自己弄一套標準和概念，但沒平台買他們的帳，夾在中間前進不了 (不過他們的創新概念會被別人吸收就是)。React Native 是個很厲害的發明，但只要 Apple 哪天換了個規定，說 XXX 不準用在 iOS 裡，或是 iOS 9 出了別的完全不同的體系，React Native 馬上就死了，就像當初 Flash 的命運一樣。

那你要看看 React Native1

雖然要用它就要 commit 去用它整個系統，但不能不說它真的很方便，Reload 就可以更新 App 的效率實在比 Compile, Package, Deploy, Run 快得多了。

看一看還真不錯，期待 F8 啊...

現在寫寫真的覺得現存的開發方式真的很痛苦，尤其兩邊 android 和 iOS 跳來跳去開發，隔一段時間切換時我最常做的就是打開網頁或舊程式碼，重新看一下 view 或是 controller 的生命週期，該不該呼叫或實作 sizeThatFit，viewDidLayout，layoutSubviews，appear，onAttach...這類東西。然後印印看到底是不是不小心搞壞什麼造成元件一直重複在排。

來吧宣告式～

這個好！剛隨便瀏覽就看到幾則最近會碰到的項目，收藏之。

這 history 應該是 Apple 自己要做才是。

Like git, but on the App Store Review Guidelines.

要試過才知 auto layout 是否較慢了。

AsyncDisplayKit, Components, React Native。他們不同的團隊做不同但有部份相似的東西。

Components 和 React native 都是用 react 的概念。而三者都有 background render 。。。(所以説 FB 現在的 iOS 團隊真是很厲害

救星呀～～Autolayout 太慢了

• 利用 Objective C++ 產生易懂的語法
• component 是宣告式設定產生，背後會計算 layout，也會重用物件
• 全都是 immutable, thread-safe
• 事件只有單方向傳遞
• 參照 flexbox 的方式來設計 layout

非常理想的模型，的確讓人很想採用，就不曉得能不能混合舊式的寫法了。

不過我記得 paper 當初是用另一套做法啊，但 react 應該已經贏了內部的戰爭了。

Components 可說是將 React 的概念帶到 iOS 上的專案，在之前他們的演講聽到他們內部已用了一段時間。Facebook's iOS Architecture1 有詳細講它解決的問題。

相信會在月底 F8 會開放吧。