Zonble 裡面提到一開始會用 iOS 的思考模式去寫 flutter (在 on create 這類的 method 做事)
這讓我想到如果單寫一個平台太久，的確容易在不同平台發生搞錯方向的問題。現在的工程師分工太細，有點太專了 (只寫 iOS, 只寫 react .... 等等)，想法容易僵化。有時候還是要逼一下自己學一些跟專長完全不同的東西…
Flutter 不能算 Android 原生，因為完全不相容，而且很多低階的事做不到。
Google 的專案就算投入資源，也很容易變成只有它們內部使用，短期雖然不會死，但 community 最後會變死水。Dart 本身在 Flutter 出現之前就陷入這個問題。
而做個 Flutter 真的需要龐大的資源，期待 open source 的社群能延續這個專案不太實際 (react-native 也有一樣的問題，沒有 FB 在背後撐著根本養不起來)。
Flutter 最理想的狀況就是它本身變成某平台的原生，例如 Fuchsia 後來爆紅，那 Flutter 自然變第一把交椅，這樣的狀況下原罪就消失了。
flutter 做的在好, 也是背著兩個原罪
- google 旗下死亡率高
- 歷史告訴我們跨平台的技術一直都沒有超越原生
不過我覺得可以活絡個三年就很夠了, 所以個人還是會跳這個火坑
其實這就是個完整的 state machine 實作。寫 state machine 本來就要考慮到要拆成多少 state。還好這件事是可以慢慢成長的，不用一開始就知道要多少 state
然後寫多了就免不了會出現 hierarchy state machine (一層包一層)，這時候問題就更複雜了。
不過我猜 mobile app 用不太到 hierarchy ，因為狀態複雜到這種程度其實用戶的理解成本也會上升。還是傾向一個頁面只做一兩件事就好。只有遊戲族群願意學習複雜的互動/狀態。
state machine 很適合處理複雜的狀態切換，但如果 UI 只是個 if 就能搞定的話，它就算 over kill (你要多寫很多 state/event class)。也就是說這個 pattern 可大，但不可小。
因為戰場現在在雲端
雲端用什麼 Microsoft 就會 愛 什麼，連 Microsoft love linux 這種話都說得出口，所以花更多時間在企業用的 Java 很正常。
後續還會有更多動作吧
放心，語法就學 kotlin 就好了，java 再怎麼改也追不上。
至於其他標準就是看 Spring ，Spring 有搞的再去學，其他先跳過。
Java ecosystem 就是個 boring tech.
就不要寫 js 就對了, js 太垃圾 (戰
以前只有 coffeescript, GWT (java), Dart 可選. 現在簡單多了, 都寫 Typescript 就好.