如何評價Facebook推出的flow.js？

01-03

官網在此：http://flowtype.org/
感覺好像是在Javascript語法上添加了type annotation，與typescript相比簡單一些。大家覺得這個工具好用嗎？另外Javascript有沒有在下一版語言設計(ES2016, ES7)中添加type annotation 和 type checking的打算呢？

首先，還是強調一下，使用 Flow Annotation 標記後的代碼是一門新語言，不是 JavaScript。。

從字面上來說，嚴謹的說法是，Flow.js 是工具，它提供的類型標註語言是一門語言，但 Flow.js 本身並不是一門語言。。但這樣繞來繞去又有什麼意思呢，說的好像有多少人只用 Flow.js 但不用它的類型標註一樣。。

有的人會說，Flow.js 的類型標註是可選的。。但這樣說的話 TypeScript 也是呀，把 allowJS 開關打開就可以當普通的 JS 編譯器來用，畢竟大家都是 JS 的超集嘛。。TypeScript 除了一個非 const 的 enum 會留下運行時痕迹外，也基本就完全是一個 JavaScript with Type，以及，enum 這種東西不做成 const 又能得到什麼好處呢。。

說用了 Flow 還是 JS 的就省省吧，除非要真的只用類型推導完全不加類型標註那樣暴殄天物。。

Flow.js 本身是一個好東西，一個非常方便的地方就是採用基於 Babel 的擴展而非一個獨立的編譯器，可以極大地簡化工具鏈的成本。。以及靜態檢查確實是大勢所趨。。

似乎 react 內部在用這個東西，但我比較傾向於 typescript，畢竟後者提供了一個完整一點的語法系統，可以看作是ES6+類型語法，實際上 ts 有些語法特性超過 ES6，ES7 里才會出現。

這個問題應該邀請賀老回答... @賀師俊

吐個槽, 不喜歡用, JavaScript 里加上類型基本就往 Java C# 發展, 語言越來越重, 我估計大家對於寫代碼的興趣都會減少. 不過同時呢, 類型真心能讓程序安全很多, 我用 ClojureScript 里提供的簡單的類型檢測就已經很明顯地改善開發的穩定性了. 有利有弊吧.

類型系統的話, 常見的一般看到兩種(...說法不嚴謹), 一種是為了編譯到類型要求嚴格的彙編或者位元組碼而在程序當中加入的類型, 比如 C, Java, 另一種是研究方向的函數式編程語言當中的代數類型系統, 比如 Flow 是通過 OCaml 實現的, 這類語言有比較完善的類型推導機制, 而且程序中一切都抽象成運算, 而不是 C 這種類似指令序列的寫法. 我猜測用 OCaml 也是為了能把它強大的類型系統帶到 JavaScript 開發當中來. 只是兩者嫁接在一起不自然.

type annotation是動態類型語言的發展趨勢之一，並且越來越重要，最直接的優勢

在運行前能確定很多低級錯誤
在模塊化中有效確定介面（或者函數簽名）

不難么明顯的優勢

類型化有望作出更好的運行時平台、JIT之類的
更好的IDE支持（auto complete, code refactoring）
更多的編程技巧

另外，目前業界已經有比較好type inference方法，只用寫很少的必要的type annotation

不過估計ES不會有type check，但是大型js項目幾乎不可避免的會走向類型化

另外並不是很同意樓上

最好的「類型說明」是命名

參見Fortran...

好的介面聲明，或者說函數簽名也能有效降低注釋量（現在很多時候我都直接看.d.ts，不用看文檔了）

類型定義的重要性這些年在不斷地降低。現代語言，例如 Rust，Swift，都在嘗試減少需要類型定義的地方，大量地引入類型推斷。其原因在於以下幾點：

1. 最好的「類型說明」是命名。例如："age"，肯定意味著數字，『firstName』意味著字元串。命名是給人看的，類型聲明大部分情況是給機器看的。如果機器夠聰明，也就沒必要給人添亂了。

2. 類型聲明開始變得越來越礙事了，由於函數式編程範式的廣泛採用，現代語言編程時往往會大量使用 lambda 函數，如果還要堅持保留每個參數的類型信息、甚至返回值類型聲明、可能的異常類型聲明...，你還有什麼心情自由地使用 lambda? （js中原本『function』保留字，也被大家詬病，慢慢被 =&> 替代了）。

所以總體來說，減少類型聲明是編程語言的一個大趨勢。

Facebook 推出 flow.js 原因其實很像交通警示牌，通過「可選「（注意是可選的）類型聲明，可以讓當前代碼開發者告訴別人，這裡」事故多發「，需要特別注意。有時很難通過"命名"完全規避可能產生的含義模糊或者誤解。類型聲明在這裡不僅讓機器可以幫你檢查，也讓其他讀者了解"必要"的附加信息。

作為一個開發者，我自己的原則就是：

1. 命名能清楚表達的地方，絕對不加類型聲明。

2. 盡量用注釋說清楚含糊的地方。

3. 實在不行引入可選的類型聲明，例如 flow（畢竟還是 JS）。但不是 typescript，因為那是另外一種語言了。

* 當年 OOP 活的時候，我曾經是一個強類型強迫症，連資料庫返回的每個 Dataset 都要搞成強類型的，生活好艱難啊...

！！

呃呃~~不少答案都表示『我不喜歡用』『TS好』==&> (?: 所以 Flow 很爛？)

Flow 在 facebook 內部深度使用，如果是崇拜 React 神教的，那必須好用，無條件的。

React 威武，React 是最好的，React 最快最厲害，React 是世界上最好的前端框架！

有一些場景非常適合用，參考 Vue 作者的相關回答：

Vue 2.0 為什麼選用 Flow 進行靜態代碼檢查而不是直接使用 TypeScript？ - 前端開發

我就提一種情況：它能檢測潛在的 null 相關問題，這對我太重要了，說不定團隊哪個人狀態一不好，沒寫條件保護，那是要犯錯誤的呀，我可不要把獎金押在腦力 review 上！！！

至於 Flow 能做的一些地方，TS 也是能做，是的，嗯嗯，呵呵，然後呢！

另外我對 Flow 官網 Flow | A static type checker for JavaScript 作了翻譯 Flow | 一個 JavaScript 靜態類型檢測器

！！

IDE對類型的支持可以很大程度方便碼農的開發；類型檢查可以極大減少運行時錯誤；另外，簡單的頁面不檢查類型沒問題，但是Node端，桌面端，APP端用JS寫的話，強制類型檢查，提高穩定性，非常合理啊。