我已经用静态类型语言编码多年了，我从汇编开始，然后转到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，我的状态其实是显式的。
