6個改變JavaScript的工具分別是什么

這期內容當中小編將會給大家帶來有關6個改變JavaScript的工具分別是什么，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

我已經用靜態類型語言編碼多年了，我從匯編開始，然后轉到C語言，經過Visual  Basic和C#，但是當我轉到JavaScript時，我對軟件的所有理解都改變了。

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

1. TypeScript

主頁上的介紹：

是什么讓我在每個項目中都使用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

他們的主頁的介紹：

如前所述，我開始使用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的庫。主頁介紹：

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

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

我的問題是Redux是一半，不知不覺中我在每個React組件中都在做小狀態機，用Redux做擴展狀態(或者說是無限狀態)，一旦我發現XState，所有設計問題都遇到了有價值的競爭者。

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

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

上述就是小編為大家分享的6個改變JavaScript的工具分別是什么了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。