《TO》導讀：想必各位開發者都會有這種煩惱，開發工具的演進變化速度很快，工具種類又多，當你有太多選項的時候，就沒辦法下決定了。這其實是種好處，但同時又讓人覺得挺困擾的。以下由稀土掘金授權刊載。
我是一名全職開發者。我大部分工作的內容是網站的全棧開發。
偶爾，我也用 Python 或 Ruby 寫寫後端的服務器，有時寫點兒 C# ，我還用 C++ 或 Node.js 開發一些命令行工具；我發現 Clojure 很有意思，我接觸 Web 開發是在多年以前，那時用的是 Perl 和 PHP 。
而在我首次進入職業開發道路的時候，我寫了幾年 Java 。
在我第一次接觸 JavaScript 時，它主要用來往網頁上寫「現在是幾點」這樣的東西。我說的是上個世紀 90 年代，每個人都想讓自己的頁面變得更加有趣，動態地告訴偶爾到來的訪客今天是周幾（哇！），並以此為樂。
這些年來，我們都發現 JavaScript 能做的遠不止這些，我們都想要全效的 DHTML (Dynamic HTML)。
是的，我們的 HTML 變得充滿動態效果了！
在過去的幾年中，我用過一些不同的框架開發過幾個比較大型的單頁應用，有時候忙起來，JavaScript 代碼組織的極爛，把 jQuery 調用寫得到處都是。
大概 10 天前，我想開發一個簡單的 SPA 給自己用，把一個小工具改寫成一個小項目。這一般也就是兩三天的功夫。
在過去的這半年，我一直在用 C# 寫一個桌面應用。這是一個相當無聊的工作流管理程序，有一個網絡服務後台和 winform 客戶端。
當我起念要開發這個小型 Web 應用的時候，我便預見這是一個嘗試新技術的好機會，我曾在網上讀到過一些，以此刷新我的 web 開發工具庫並收穫一點樂趣。
想想都覺得激動，沒什麼太複雜的東西，也不用太費勁。
可事實證明，我根本無法著手編寫這個簡單的項目，因為我陷入了一種分析癱瘓循環。
到目前為止，我已經有了四到五次「失敗的開始」。問題的核心是在選擇上，以及要如何從過度繁多的工具庫中挑選出合適的工具。
誰想寫這樣的代碼：
ES6 都快落地了，它有了近似真正的類，並且差不多得到了完好的支持？市面上有那麼多的打包工具，誰還想寫十行？：
在頁面的頂部？有那麼多的框架幫我們組織應用，誰還要寫這樣的代碼？：
誰又想忽視如今編寫瀏覽器端 Javascript 代碼有了 Node.js 命令行工具輔助的事實？
所以我深入研究這些新事物，這些我曾經用過現在忘了或是發展了的事物。可天知道，除了一點 HTML 表單，我一直沒能取得任何的進展。
請記住，這是一個簡單的個人項目，我主要是想找點兒樂子，因此我的腦袋被設置為零容忍模式。一旦什麼東西令我厭煩，我就拋開它去尋找其它的東西來撫平我的體驗。
這是今天在 Javascript 領域嘗試新技術我所期待的幾個東西，例舉如下：
首先，我想試試 Typescript 。
在過去幾個月中我一直寫的是 C# ，我知道有一門靜態類型的語言是多麼棒的一件事：它讓你對自己的代碼更加自信，重構起來更為便利。IDE 自動補全，不論你寫的類有多麼的混亂，你都只要寫一半的代碼。
我需要兩個外部的庫來實現核心功能。它們不在 DefinitelyTyped 中，因此我花了半天時間學習.d.ts 文件以及為這幾個庫寫包裝類。談不上富有成效，但我還是寫出來了。
我一開始就想用 Mocha 添加一些測試。這裡是噩夢的開端。我嘗試為項目添加多個.tsconfig.json 文件，但 JetBrains WebStorm 不支持，因此編譯器不斷地把測試代碼和實際代碼打包在一起。
我開始閱讀指導，查看 gist 以及 StackOverflow 上的相關問題。使用這個 Gulp 配置文件。你必須先編譯腳本，然後再對它們進行測試。但如果你測試也是用 Typescript 寫，那你還得使用這個 Gulp 插件，不過它對 watchify 的支持不好。
第一天過後，我有了一堆被合併、編譯過的文件，src 和 dest 、test 文件夾觸發了一些不必要的任務。我已經弄不懂底層究竟是怎麼一回事。當編譯代碼時，依賴在哪裡，我是應該 import 還是 require 或是 reference 這個文件？我去他大爺的。
之前，我曾在一個小項目中簡單地用過一點 React ，體驗還不錯。我想再試試它。為此我添加了一些 Gulp 配置。這裡的問題出在了 React 本身。我已經設計好了我的數據模型，但是 React.js 喜歡把數據模型、狀態、屬性混在一起，為此我不得不重新思考這個問題。
我的應用很簡單但是表單很密集。你猜怎麼著，React 官方文檔說：
如果你是初次使用這套框架，注意 ReactLink 在絕大多數的應用中是用不到的，而且你應該小心使用它。在 React 中，數據單向流動：從擁有者到子對象。這是因為在馮·諾依曼計算模型中數據只能單向流動。你可以把它當做「單向數據綁定」。
說得很有道理的樣子，但是一個表單，尤其是一個重表單，本質上就是一個雙向綁定的東西。因此，React 在沒有插件和 mixin 的情況下，對大量輸入的支持不好。你得裝飾所有的 input 框來支持這個功能。很快，事情就變得讓人厭煩起來。
還有，說到 mixin ，我用的是 ES6 但 React 的類不支持。去他大爺的。
所以，我需要大量的雙向數據綁定，對嗎？Knockout 在這方面做得很出色，我也有過一點使用它的經驗。再一次，我嘗試使用 ES6 的類，但是 this 的綁定又亂作一團。不用類的話，代碼很快變得混亂起來。
在嘗試了 React 後，Javascript 和 HTML 混起來看醜的一逼。HTML 包含在 Javascript 中，不過這還算有點道理。至少你能夠組織合理的邏輯單元，並使它們內聚。
Ps 這是一條憤怒的旁注，似乎不論我選擇什麼構建工具，都需要有一些觀察任務跑在後台，來進行編譯，檢查，打包，測試。我在編輯器裡寫了一些東西，然後 Cmd+S 保存，Cmd+Tab 切回瀏覽器，再 Cmd+R 刷新頁面，可我並沒有察覺到有什麼變化。你猜怎麼著，有時候我動作比編譯器快，或者是“觀察”任務沒有檢測到我的編輯動作，抑或是它拋出了一個異常。
所以，甚至在我開始寫一行代碼之前，就不得不先選好我所要用到的工具（依賴管理，打包，測試，構建等等），而且每一種選擇都有眾多的替代品，它們要么相互競爭，要么相互補充，或多或少更接近標準，或多或少更為成熟，又或者兩個合在一起用效果多多少少更好一點。
你想使用哪種風格的 Javascript ？你要用轉譯器嗎？用什麼語言？要用 Grunt 嗎？Gulp？Bower？Yeoman？Browserify？Webpack？Babel？Common.js？Amd？Angular？Ember？Linting？
我究竟在說什麼？我是不是把東西給搞混了？我困惑了嗎？去他大爺的？對，去他大爺的。
如果你還認同我所說的話，現如今，製作一個 Web-App 就好像在玩一個非常困難的互動小說遊戲（如魔城）。讓我們穿回多年以前來開發一個程序：
你置身於一個程序房間。你只能開發命令行程序。出現在你面前的是 C 語言和 Assembly 語言
> 用 C 語言
好的，你可以開始編寫你的程序
現在，讓我們回到 2016 年：
你置身於一個 web 應用的房間。
> 開發 web 應用
你是要開發遊戲嗎？不妨考慮使用 Unity 或者 GameMaker 或類似的可為 web 導出的軟件
> 開發 web 應用
你有沒有想過用 web 技術來開發桌面程序呢？比如，你可以使用 NW.js 或 Electron
> 開發 web 應用
幾門語言出現在了你的面前。你看到 Javascript，Coffescript，Typescript，Clojurescript，Dart，asm.js。如果你想瀏覽總共 127 種可用語言，輸入「更多」。
> 用 javascript
出現了兩門語言：ES5 和 ES6
> 用 ES6
你來到一間轉譯器的屋子。你看到了 Babel，Traceur 或者你可以寄希望於瀏覽器已經支持了你將要用到的特性。輸入「更多」查看更多轉譯器或者閱讀「轉譯器工具（又名——死靈之書）」
> 使用 Babel
你來到任務走廊。你看到一隻 Grunt 在一個角落，一隻 Gulp 在另一角。一隻 Babelify 攻擊了你，眾多 Webpack 正在聚集。在附近的房間裡，你聽到 Browserify 在叫喊，它正在與 Require.js 戰鬥。在你的背包中有「轉譯保存」。
> 離開這裡
在近處的壁龕中有一隻 Yeoman 在發光。你手握 npm 但你的 project.json 壞了。在地板上還躺著 Gruntfile，.jshitrc，.babelrc 和 tsconfig.json。你遠遠聽見一隻 Broccoli 和一隻 Jasmine 在呼號。
> 操他大爺
你不能操他大爺，因為七個房間以前你選擇了「npm install node-jsx」，而它目前還不兼容你的配置「操他大爺」
> 退出。
更新
這篇文章在 Hacker News 上受到了一些關注。我發現有些評論還真是夠諷刺的：
> 我已經設計好了我的數據模型，但是 React.js 喜歡把數據模型、狀態、屬性混在一起，因此我又不得不重新思考這個問題。
用 Redux
> 這個 Gulp 配置文件…
用 Webpack
ClojureScript。好好學吧；ClojureScript 社區會積極跟上時代潮流，又或許偶爾你也可以為社區盡一份力。是的，你得做一些底層的調試工作，不過以你的技術背景應該是小菜一碟。
你該使用哪種組合工具？如果你不知道從何下手，可以試試 Ember ——這裡沒有其它工具有的那些問題，也可以在這裡找到解決那些問題的工具。
由此，我猜測，跟社區討論我因從過量工具庫中選取和調研工具所導致的“分析癱瘓循環”的結果是被社區建議去嘗試，花時間學習和再多研究四門我先開始沒想到過的技術。Javascript，幹得漂亮！