我的JavaScript工具鏈，6個改變了我的JavaScript的工具
我已經用靜態類型語言編碼多年了，我從匯編開始，然后轉到C語言，經過Visual Basic和C#，但是當我轉到JavaScript時，我對軟件的所有理解都改變了。
在給出我現在的工具鏈之前，有一個建議：自己練習自己想掌握的語言，不受任何強加的限制，在這之后，找一份符合自己喜好的工作，否則，你可能最后會覺得很痛苦，因為你會用錯了自己的工具，從而永遠無法發揮出自己的潛力。
1. TypeScript
主頁上的介紹：
| TypeScript是JavaScript的類型化超集，可編譯為純JavaScript。 |
是什么讓我在每個項目中都使用TypeScript?
(1) 編譯錯誤
在編譯時發現錯誤是一件好事，愚蠢的錯誤，莫名其妙的運行時錯誤，顯示得太遲的錯誤的無奈使我對這個職業的熱愛減少了，但是TypeScript再次帶來了歡樂。
(2) 類型
表現力和依從性，意圖和一致性，設計和力量，類型需要時間來掌握，但是，孩子們，他們是值得的。Every、Single、Time，我太想念那些類型了。TypeScript既兼容面向對象類型，也兼容函數類型，非常棒。
當你有類型的時候，你會省去很多時間給試圖理解和使用你的代碼的人，你會變得能夠在不看手冊的情況下發現整個庫的使用方法，而且由于類型的約束，你可以確定事情會被按他們應該使用的那樣使用。
TypeScript中的類型還有很長的路要走，但是今天的類型系統已經為前端帶來了很多強大的功能。沒有類型系統的感覺就像試圖用腳跑過賽車一樣。它給人一種工程化的感覺，這是JavaScript所缺少的，我用類型來設計和強制執行正確的接口使用，而我每花一個小時寫類型的時間就能讓我安全地度過幾天(好吧，這主要是我的看法)。
(3) 減輕我的挫敗感
有了TypeScript，我每小時的錯誤以及因此而感到沮喪的機會大大減少了，僅此部分就值得了。
TypeScript也越來越好，它迅速采用了新的ECMAScript功能。
所以，我放棄了用普通的JavaScript進行編碼，TypeScript有JavaScript的所有優點。
2. Visual Studio Code
這不是一個IDE，而是一個文本編輯器，最好的前端文本編輯器，來自他們的首頁的介紹：
|
代碼編輯。重新定義。免費的。基于開放源碼構建。可以在任何地方運行。 |
為什么選擇VSCode?
(1) 到處運行，無處不在
這句話是對的，我已經在需要使用的每個操作系統上可靠地使用了VSCode，它速度很快，并且在所有地方都有很多優點，無需擔心平臺支持。
(2) IntelliSense
它在JavaScript中的效果非常好，但在TypeScript中，它就像神一樣，快速，可靠，并且在編譯之前就能發現錯誤!我認為這是VSCode最好的功能之一。我認為這是VSCode最好的功能之一，它就像多了一雙眼睛。
(3) 減輕我的挫敗感
當年Sublime的每一個插件都很慢，而且缺乏IntelliSense，VSCode的速度很快，而且越發布越快，說實話，我很驚訝這么好的軟件竟然是免費的。
一切都按預期運行，它有我能想到的所有功能，那些不應該是核心的，都是擴展，說實話，掌握它是值得的。
最后，用一句話來形容我的VSCode代碼體驗：我沒有任何怨言。
3. React
他們的主頁的介紹：
| 一個用于構建用戶界面的JavaScript庫 |
如前所述，我開始使用AngularJS，全功能強大的前端框架，但轉到React對我來說是不可避免的，下面是原因。
(1) 不是框架
沒錯，這不是框架，而這是我最喜歡的事情之一，我通常編寫小型程序，不需要大量的框架，只需要一點幫助我就可以構建小型UI。
(2) 擁抱函數式編程
最好的賣點是，React接受了函數式編程，與我對JavaScript的新認識保持一致。
React在簡潔方面做了很大的努力，我很欣賞這一點;React用最小的語法表達了復雜的概念，像 useState 和高階組件這樣的東西就是一個例子，說明了擁有正確的抽象比擁有一堆可能最終會用錯的工具要好得多。
(3) 全部加起來+TypeScript
我不使用Svelte或Vue的原因是我不喜歡模板，而我喜歡類型。在模板文件中，你沒有TypeScript，也沒有JavaScript，你有模板腳本，一些特殊的標記，可以幫助你做一些事情，無類型的，用不同的推理。
我確實喜歡React的整體特性。也就是說，我用JSS代替了CSS，而不是HTML+JS，我用TSX，所有的CSS、HTML、JS都在一個文件中的TypeScript中，我喜歡它，所有的東西都有IntelliSense，編譯錯誤，類型，沒有上下文切換。
在我看來，小的組件是CSS+HTML+JS的混合體，將它們全部合并到TypeScript中，對我來說是有利的。
它更優秀的一面是?它的性能很好，而且每一個新版本都在不斷地改進，更多的JSS被移植到靜態CSS中，更多的TSX被優化，等等，所以你可以用它來編程，隨著時間的推移，移植器的輸出也會越來越好。
在我工作過的公司里，我們在小的程序中編出高層次的概念，而不是低層次的東西，我相信公司在大多數時候并不是花錢給程序員優化什么，他們要的是可用的、可靠的、快速的軟件。
4. Ramda
Ramda是一款實用的 JavaScript 函數式編程庫。
(1) 代碼可重用性
我在上面抱怨過重復的代碼，大部分的代碼都是一些小的實用程序函數，當我成功地擁有了一個文件夾，如果我開始了另一個項目，我必須重新編寫它們，所以我一直在尋找一個好的實用程序庫。
現在，我在抽象函數的時候，幾乎沒有想到要讓函數變得更可重用，因為所有的通用可重用函數都在Ramda中，有一個非常強大的函數優先的接口。
(2) 純函數，無副作用且不變
一個實用程序應該包含純粹的函數，這意味著這些函數需要：無副作用，并將數據視為不可變的。這些東西與實用程序庫不一致，哎呀，甚至在JavaScript內置Array函數中也不一致，不相信我嗎?看這個：
原生數組的sort方法改變了原始數據，而 Ramda的sort方法不會。
(3) 轉換器(Transducers)/
實事求是地描述轉換器：轉換器消除了組合多個數組函數的性能損失。
我認為圖像勝于文字，轉換器難以理解：
Ramda充滿了轉換器函數，這意味著性能非常好，您可以堆疊多個 filter，map 和21個其他功能，它將僅迭代數組并應用一次功能，而不是N次。
(4) 缺點
Ramda很棒，但是所有的好東西都是有代價的……如果你正在考慮使用TypeScript。
Ramda的類型、類型推理和類型解析的復雜度是非常高的;;除此之外，主要的貢獻者對TypeScript根本不感興趣。
他們似乎是一群了不起的開發人員，他們在沒有TypeScript的情況下就馴服了JavaScript，并且對將這個令人驚嘆的庫移植到TypeScript的興趣為零。
盡管如此，Ramda仍然是我樂于使用的最精良的實用程序庫之一，在我馴服JavaScript的過程中，它讓我非常感動。
5. FP-TS
雖然Ramda是一個很好的解決方案，只要我們停留在JavaScript領域，一旦我完全采用了TypeScript，它就會變得...........使用起來很尷尬，類型推理也不是很好，所以我尋找了其他考慮到TypeScript的解決方案，或者說最好是用TypeScript寫的。
幸運的是，我從他們的主頁上找到了fp-ts，這是庫的奇跡，他們的主頁：
- TypeScript中的類型化函數式編程。
- fp-ts為開發者提供了TypeScript中的類型化函數式語言中的流行模式和可靠的抽象。
老實說，fp-ts是一個杰作，它為TypeScript帶來了很多好處，并且以一種不引人注目的方式，它的類型也是完全慣用語的。
為什么我在100%的項目中使用fp-ts?
(1) 管道(Pipe)
我故意避免談論Ramda的管道，因為類型分析從左到右的性質，fp-ts版本更……是TypeScript和IntelliSense的慣用語。
這是沒有管道的代碼：
在 main 中，我需要使用中間變量來分配中間結果，在 main2 中，要從右到左讀取執行順序是很尷尬的。
有了管道，我們不需要中間變量，所有的數據都是流動的，但是，TypeScript在使用Ramda的管道時，大多數時候會產生錯誤，因為輸入值放在最后，所以不能推斷出什么是輸入的第一個函數，以此類推，因為TypeScript從左到右推斷。而Ramda的管道要起作用，推理應該從左到右和從右到左，Ramda的管道類似于Haskell、OCalm和F#等函數式語言的類型推理系統中的常見特征，但在TypeScript中卻沒有，雖然在JavaScript中完全不是問題。
現在看一下fp-ts版本的管道：
不同的是，fp-ts 將pipe的輸入放在第一位，讓TypeScript的推理變得很開心。在JavaScript領域，Ramdas的方法是100%有效的慣用代碼，但TypeScript缺乏從右到左的推理，使得它 "無效 "或者說一般情況下很難使用，所以我一般傾向于使用fp-ts版本的pipe，而不是Ramda的。
6. XState
讓我來介紹一下XState這個應該已經取代Redux的庫。主頁介紹：
| 用于現代web的JavaScript和TypeScript有限狀態機和狀態轉換。 |
很長時間以來，我的Redux商店都缺少一些東西，我試圖制作一些小的中間件來幫助我馴服Redux，但是感覺……不完整。直到我找到XState。
為什么我在100%的React項目中使用XState?
我的問題是Redux是一半，不知不覺中我在每個React組件中都在做小狀態機，用Redux做擴展狀態(或者說是無限狀態)，一旦我發現XState，所有設計問題都遇到了有價值的競爭者。
是否應該顯示一個按鈕?啟用?顯示文字A還是B? 所有這些 "域" 的規格都不外乎是幾個狀態，有限的，事先指定好的;如果明確寫出這樣的狀態，讀取和升級組件就成了一件樂事。
用AngularJS和模板，我的狀態是由一堆交織在一起的變量組成的，無法讀取，用React和Redux，所有的數據都在一個地方，但狀態沒有任何表示，是對數據的一種解釋，但用XState，我的狀態其實是顯式的。
