我已經(jīng)用靜態(tài)類型語言編碼多年了，我從匯編開始，然后轉(zhuǎn)到C語言，經(jīng)過Visual Basic和C#，但是當(dāng)我轉(zhuǎn)到JavaScript時，我對軟件的所有理解都改變了。

在給出我現(xiàn)在的工具鏈之前，有一個建議：自己練習(xí)自己想掌握的語言，不受任何強加的限制，在這之后，找一份符合自己喜好的工作，否則，你可能最后會覺得很痛苦，因為你會用錯了自己的工具，從而永遠(yuǎn)無法發(fā)揮出自己的潛力。

[[326577]]

1. TypeScript

主頁上的介紹：

是什么讓我在每個項目中都使用TypeScript?

(1) 編譯錯誤

在編譯時發(fā)現(xiàn)錯誤是一件好事，愚蠢的錯誤，莫名其妙的運行時錯誤，顯示得太遲的錯誤的無奈使我對這個職業(yè)的熱愛減少了，但是TypeScript再次帶來了歡樂。

(2) 類型

表現(xiàn)力和依從性，意圖和一致性，設(shè)計和力量，類型需要時間來掌握，但是，孩子們，他們是值得的。Every、Single、Time，我太想念那些類型了。TypeScript既兼容面向?qū)ο箢愋停布嫒莺瘮?shù)類型，非常棒。

當(dāng)你有類型的時候，你會省去很多時間給試圖理解和使用你的代碼的人，你會變得能夠在不看手冊的情況下發(fā)現(xiàn)整個庫的使用方法，而且由于類型的約束，你可以確定事情會被按他們應(yīng)該使用的那樣使用。

TypeScript中的類型還有很長的路要走，但是今天的類型系統(tǒng)已經(jīng)為前端帶來了很多強大的功能。沒有類型系統(tǒng)的感覺就像試圖用腳跑過賽車一樣。它給人一種工程化的感覺，這是JavaScript所缺少的，我用類型來設(shè)計和強制執(zhí)行正確的接口使用，而我每花一個小時寫類型的時間就能讓我安全地度過幾天(好吧，這主要是我的看法)。

(3) 減輕我的挫敗感

有了TypeScript，我每小時的錯誤以及因此而感到沮喪的機會大大減少了，僅此部分就值得了。

TypeScript也越來越好，它迅速采用了新的ECMAScript功能。

所以，我放棄了用普通的JavaScript進(jìn)行編碼，TypeScript有JavaScript的所有優(yōu)點。

2. Visual Studio Code

這不是一個IDE，而是一個文本編輯器，最好的前端文本編輯器，來自他們的首頁的介紹：

為什么選擇VSCode?

(1) 到處運行，無處不在

這句話是對的，我已經(jīng)在需要使用的每個操作系統(tǒng)上可靠地使用了VSCode，它速度很快，并且在所有地方都有很多優(yōu)點，無需擔(dān)心平臺支持。

(2) IntelliSense

它在JavaScript中的效果非常好，但在TypeScript中，它就像神一樣，快速，可靠，并且在編譯之前就能發(fā)現(xiàn)錯誤!我認(rèn)為這是VSCode最好的功能之一。我認(rèn)為這是VSCode最好的功能之一，它就像多了一雙眼睛。

(3) 減輕我的挫敗感

當(dāng)年Sublime的每一個插件都很慢，而且缺乏IntelliSense，VSCode的速度很快，而且越發(fā)布越快，說實話，我很驚訝這么好的軟件竟然是免費的。

一切都按預(yù)期運行，它有我能想到的所有功能，那些不應(yīng)該是核心的，都是擴(kuò)展，說實話，掌握它是值得的。

最后，用一句話來形容我的VSCode代碼體驗：我沒有任何怨言。

3. React

他們的主頁的介紹：

如前所述，我開始使用AngularJS，全功能強大的前端框架，但轉(zhuǎn)到React對我來說是不可避免的，下面是原因。

(1) 不是框架

沒錯，這不是框架，而這是我最喜歡的事情之一，我通常編寫小型程序，不需要大量的框架，只需要一點幫助我就可以構(gòu)建小型UI。

(2) 擁抱函數(shù)式編程

最好的賣點是，React接受了函數(shù)式編程，與我對JavaScript的新認(rèn)識保持一致。

React在簡潔方面做了很大的努力，我很欣賞這一點;React用最小的語法表達(dá)了復(fù)雜的概念，像 useState 和高階組件這樣的東西就是一個例子，說明了擁有正確的抽象比擁有一堆可能最終會用錯的工具要好得多。

(3) 全部加起來+TypeScript

我不使用Svelte或Vue的原因是我不喜歡模板，而我喜歡類型。在模板文件中，你沒有TypeScript，也沒有JavaScript，你有模板腳本，一些特殊的標(biāo)記，可以幫助你做一些事情，無類型的，用不同的推理。

我確實喜歡React的整體特性。也就是說，我用JSS代替了CSS，而不是HTML+JS，我用TSX，所有的CSS、HTML、JS都在一個文件中的TypeScript中，我喜歡它，所有的東西都有IntelliSense，編譯錯誤，類型，沒有上下文切換。

在我看來，小的組件是CSS+HTML+JS的混合體，將它們?nèi)亢喜⒌絋ypeScript中，對我來說是有利的。

它更優(yōu)秀的一面是?它的性能很好，而且每一個新版本都在不斷地改進(jìn)，更多的JSS被移植到靜態(tài)CSS中，更多的TSX被優(yōu)化，等等，所以你可以用它來編程，隨著時間的推移，移植器的輸出也會越來越好。

在我工作過的公司里，我們在小的程序中編出高層次的概念，而不是低層次的東西，我相信公司在大多數(shù)時候并不是花錢給程序員優(yōu)化什么，他們要的是可用的、可靠的、快速的軟件。

4. Ramda

Ramda是一款實用的 JavaScript 函數(shù)式編程庫。

(1) 代碼可重用性

我在上面抱怨過重復(fù)的代碼，大部分的代碼都是一些小的實用程序函數(shù)，當(dāng)我成功地?fù)碛辛艘粋€文件夾，如果我開始了另一個項目，我必須重新編寫它們，所以我一直在尋找一個好的實用程序庫。

現(xiàn)在，我在抽象函數(shù)的時候，幾乎沒有想到要讓函數(shù)變得更可重用，因為所有的通用可重用函數(shù)都在Ramda中，有一個非常強大的函數(shù)優(yōu)先的接口。

(2) 純函數(shù)，無副作用且不變

一個實用程序應(yīng)該包含純粹的函數(shù)，這意味著這些函數(shù)需要：無副作用，并將數(shù)據(jù)視為不可變的。這些東西與實用程序庫不一致，哎呀，甚至在JavaScript內(nèi)置Array函數(shù)中也不一致，不相信我嗎?看這個：

 

原生數(shù)組的sort方法改變了原始數(shù)據(jù)，而 Ramda的sort方法不會。

(3) 轉(zhuǎn)換器(Transducers)/

實事求是地描述轉(zhuǎn)換器：轉(zhuǎn)換器消除了組合多個數(shù)組函數(shù)的性能損失。

我認(rèn)為圖像勝于文字，轉(zhuǎn)換器難以理解：

Ramda充滿了轉(zhuǎn)換器函數(shù)，這意味著性能非常好，您可以堆疊多個 filter，map 和21個其他功能，它將僅迭代數(shù)組并應(yīng)用一次功能，而不是N次。

(4) 缺點

Ramda很棒，但是所有的好東西都是有代價的……如果你正在考慮使用TypeScript。

Ramda的類型、類型推理和類型解析的復(fù)雜度是非常高的;;除此之外，主要的貢獻(xiàn)者對TypeScript根本不感興趣。

他們似乎是一群了不起的開發(fā)人員，他們在沒有TypeScript的情況下就馴服了JavaScript，并且對將這個令人驚嘆的庫移植到TypeScript的興趣為零。

盡管如此，Ramda仍然是我樂于使用的最精良的實用程序庫之一，在我馴服JavaScript的過程中，它讓我非常感動。

5. FP-TS

雖然Ramda是一個很好的解決方案，只要我們停留在JavaScript領(lǐng)域，一旦我完全采用了TypeScript，它就會變得...........使用起來很尷尬，類型推理也不是很好，所以我尋找了其他考慮到TypeScript的解決方案，或者說最好是用TypeScript寫的。

幸運的是，我從他們的主頁上找到了fp-ts，這是庫的奇跡，他們的主頁：

• TypeScript中的類型化函數(shù)式編程。
• fp-ts為開發(fā)者提供了TypeScript中的類型化函數(shù)式語言中的流行模式和可靠的抽象。

老實說，fp-ts是一個杰作，它為TypeScript帶來了很多好處，并且以一種不引人注目的方式，它的類型也是完全慣用語的。

為什么我在100%的項目中使用fp-ts?

(1) 管道(Pipe)

我故意避免談?wù)揜amda的管道，因為類型分析從左到右的性質(zhì)，fp-ts版本更……是TypeScript和IntelliSense的慣用語。

這是沒有管道的代碼：

在 main 中，我需要使用中間變量來分配中間結(jié)果，在 main2 中，要從右到左讀取執(zhí)行順序是很尷尬的。

有了管道，我們不需要中間變量，所有的數(shù)據(jù)都是流動的，但是，TypeScript在使用Ramda的管道時，大多數(shù)時候會產(chǎn)生錯誤，因為輸入值放在最后，所以不能推斷出什么是輸入的第一個函數(shù)，以此類推，因為TypeScript從左到右推斷。而Ramda的管道要起作用，推理應(yīng)該從左到右和從右到左，Ramda的管道類似于Haskell、OCalm和F#等函數(shù)式語言的類型推理系統(tǒng)中的常見特征，但在TypeScript中卻沒有，雖然在JavaScript中完全不是問題。

現(xiàn)在看一下fp-ts版本的管道：

不同的是，fp-ts 將pipe的輸入放在第一位，讓TypeScript的推理變得很開心。在JavaScript領(lǐng)域，Ramdas的方法是100%有效的慣用代碼，但TypeScript缺乏從右到左的推理，使得它 "無效 "或者說一般情況下很難使用，所以我一般傾向于使用fp-ts版本的pipe，而不是Ramda的。

6. XState

讓我來介紹一下XState這個應(yīng)該已經(jīng)取代Redux的庫。主頁介紹：

很長時間以來，我的Redux商店都缺少一些東西，我試圖制作一些小的中間件來幫助我馴服Redux，但是感覺……不完整。直到我找到XState。

為什么我在100%的React項目中使用XState?

我的問題是Redux是一半，不知不覺中我在每個React組件中都在做小狀態(tài)機，用Redux做擴(kuò)展?fàn)顟B(tài)(或者說是無限狀態(tài))，一旦我發(fā)現(xiàn)XState，所有設(shè)計問題都遇到了有價值的競爭者。

是否應(yīng)該顯示一個按鈕?啟用?顯示文字A還是B? 所有這些 "域" 的規(guī)格都不外乎是幾個狀態(tài)，有限的，事先指定好的;如果明確寫出這樣的狀態(tài)，讀取和升級組件就成了一件樂事。

用AngularJS和模板，我的狀態(tài)是由一堆交織在一起的變量組成的，無法讀取，用React和Redux，所有的數(shù)據(jù)都在一個地方，但狀態(tài)沒有任何表示，是對數(shù)據(jù)的一種解釋，但用XState，我的狀態(tài)其實是顯式的。