我的JavaScript工具链，6个改变了我的JavaScript的工具

发布时间：2025-11-05 12:11:59 来源：云智核 作者：域名

我已经用静态类型语言编码多年了，的工我从汇编开始，工个改然后转到C语言，具链具经过Visual Basic和C#，的工但是工个改当我转到JavaScript时，我对软件的具链具所有理解都改变了。

在给出我现在的的工工具链之前，有一个建议：自己练习自己想掌握的工个改语言，不受任何强加的具链具限制，在这之后，的工找一份符合自己喜好的工个改工作，否则，具链具你可能最后会觉得很痛苦，的工因为你会用错了自己的工个改工具，从而永远无法发挥出自己的具链具潜力。

1. TypeScript

主页上的介绍：

是IT技术网什么让我在每个项目中都使用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，这是库的奇迹，他们的主页：

老实说，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，我的状态其实是显式的。

相关文章