和其他框架的比较

虽然 grammY 使用了一些其他 bot 框架（和 web 框架）中已知的概念，但为了获得最佳的可读性和性能，它是从零开始写的。

尽管我们试图为你提供一个客观的描述，说明使用 grammY 和使用其他库的优缺点，但请假设这种比较是存在偏见的。 我们会努力使本文中的内容保持最新。 如果你发现有一些信息已经过时了，可以使用底部的链接编辑这个页面。

与其他 JavaScript 框架的比较

请先选择你的编程语言

鉴于你正在阅读 JavaScript 生态系统中的一个框架的文档，你可能正在寻找能在 Node.js（或 Deno）上运行的东西。 但是，如果你不是的话，请 向下滚动，比较哪些编程语言适合于 bot 开发。 当然，你也会发现与其他语言的框架（主要是 Python）的简单比较。

grammY 主要从两个项目中获取灵感，即 Telegraf 和 NTBA。 我们现在先重点关注它们，但我们（或者你？）可能会在未来增加与其他框架的比较。

Telegraf

grammY 起源于 Telegraf，所以在这里简单介绍一下这两个框架的历史关系。

在 grammY 创建时，Telegraf 是一个令人惊叹的库，没有它，grammY 就不会达到现在的水平。 然而，Telegraf 曾经是使用 JavaScript 写的（v3 版本）。 类型注释是通过手动添加的，并且维护得很差，所以它们并不完整、正确且过时。 强类型注释对于一个严肃认真的库来说是非常重要的，因为它们能提供工具支持，并且可以显著地加快你的代码库的迭代速度。 在开发一个复杂的 bot 时，大部分人都喜欢类型安全，而且对一部分人来说，不提供类型安全是一件令人无法接受的事情。

Telegraf v4 试图通过将整个代码库迁移到 TypeScript 来解决这个问题。 不幸的是，许多由此产生的类型非常复杂，复杂到无法理解（但是正确的）。 此外，迁移过程中发现了代码库中无数的怪异现象（例子），这使得为现有代码找到正确的类型变得非常痛苦。

因此，尽管 4.0 版本试图 改进 正确性和工具支持，它最终还是使 Telegraf 比它的非类型化版本更加难用。 可以理解的是，许多 Telegraf 3 的现有用户不愿意升级。 新用户上手也变得更加困难。

grammY 后退了一步，重新思考一个以可行性优先的类型安全的 bot 框架。 这使得我们可以跳过许多关于如何处理奇怪的内部类型的令人沮丧的讨论。 它使项目具有干净、一致、可编译的代码，为用户提供优秀的类型（= 编辑器支持）。 类型安全反过来允许更多高级特性，这些特性从根本上改变了我们对 bot 开发的看法，比如 Bot API Transformers。

尽管 Telegraf 3 仍然被许多活跃的 bot 使用，但该库已经过时了。 此外，Telegraf 的插件生态系统已转移到 Telegraf 4（至少那些未迁移到 grammY 的插件是这样的）。

这里我们仅比较 grammY 与 Telegraf 4。

以下是你应该使用 grammY 而不是 Telegraf 的原因列表。

• grammY 始终支持最新版本的 Bot API。 Telegraf 经常落后几个版本。
• grammY 有 一个文档。 Telegraf 则没有————取而代之的是缺少解释的、自动生成的 API 参考，而且现有的指南并不完整，而且很难找到。
• grammY 拥抱 TypeScript，类型推导 正常运作 并且它们会遵循你的代码。 在 Telegraf 中，你经常需要以某种方式编写代码，否则它无法编译（即使它实际上可以正常运行）。
• grammY 集成了来自 官方 Bot API 参考 的内联提示，在你写代码时能够帮助你。 Telegraf 则不会给你的代码提供任何解释。
• 还有更多的东西，例如更好的性能、大型插件生态系统、为数十亿人翻译的文档、与数据库和 web 框架更好的集成、更好的运行时兼容性、VS Code 扩展，以及许多你在使用过程中会发现的其他内容。

以下是你应该使用 Telegraf 而不是 grammY 的原因列表。

• 你已经有了一个用 Telegraf 编写的大型 bot，但你不再在它上面投入更多精力。 在这种情况下，从长远来看，迁移到 grammY 可能会花费比你节省的时间更多的时间，无论迁移多么顺利。
• 你对 Telegraf 了如指掌，你并不想改变你的技术栈。 grammY 引入了许多新颖的概念，如果你只使用过 Telegraf，这些概念可能会感到陌生，而使用 grammY 意味着你将接触到新事物。
• Telegraf 和 grammY 在一些细节上使用不同的语法来实现相同的目的，而你只是碰巧更喜欢一种风格而不是另一种风格。 例如，Telegraf 使用 bot.on(message("text")) 而 grammY 使用 bot.on("message:text") 来监听文本消息。

NTBA

node-telegram-bot-api 是影响 grammY 发展的第二个大项目。 与其他框架相比，它的主要优势在于它非常简单。 它的架构可以用一句话来描述，而 grammY 需要在文档网站上用一个 指南 来做同样的描述。 我们相信，grammY 网站上的所有这些解释有助于人们轻松入门，但是拥有一个不需要任何解释的库是很诱人的。

从坏的方面来看，这只在短期内有好处。 把所有东西都放在一个巨大的文件里，用一个原始的 EventEmitter 来处理复杂的对象流（又称网络请求），这种想法给 Telegram bot 的世界带来了很多痛苦，也阻碍了一些好的想法的实现。

bot 总是从小规模开始，但一个负责任的框架必须为它们提供一条清晰的增长和扩展的路径。 不幸的是，NTBA 在这方面做的很差。 任何超过 50 行使用 NTBA 的代码库最终都会变成一堆像意大利面条一样的交叉引用。 你不会想要这样的。

其他框架

目前没有其他值得用于构建 bot 的 TypeScript 库。 除了 grammY、Telegraf 和 NTBA 之外的库基本上都严重缺乏维护，因此已经远远过时了。

你是否刚刚创建了一个很棒的新库而我们还不知道？ 请随时编辑本页面并添加对比，或者在 群聊 中告诉我们你的想法！

与其他编程语言的框架比较

你可以有你自己的理由赞成使用不同的编程语言而不是 TypeScript。 最重要的是你喜欢使用你的工具和语言。 如果你决定使用别的语言，那么你可以不要继续往下看了。

鉴于你还在阅读，你可能想知道为什么 grammY 是用 TypeScript 编写的，以及为什么你也应该考虑为你的 bot 选择这种语言。

本节将概述 TypeScript 在开发 Telegram bot 时与其他语言相比有哪些优势。 这里的对比仅限于 Python、Go 和 Rust。 如果你想将 TypeScript 与其他语言进行对比，请随意添加更多内容。

以下一些观点仅部分基于个人观点。 每个人的观点都不一样，所以请对这一部分持保留态度。

用 Python 编写的框架

TypeScript 与 Python 的对比还是比较明显的。 选择 TypeScript，你将享受到：

1. 更好的编辑工具 grammY 的类型注释非常出色。 虽然 Python 在 3.5 版本中引入了类型，但它们在生态系统中的使用并不像 JavaScript/TypeScript 那样普遍。 因此，它们无法与 grammY 及其配套库的开箱即用的功能相比。 这些类型会在开发的每一步自动完成，以及带有解释和链接的有用提示。

2. 更容易扩展代码库 类型系统还有第二个优势——它允许你扩展 bot 的代码库。 对于用类型安全较差的语言编写的项目来说，这很难做到。

3. 更容易扩大负载 如果你的 bot 开始流行起来，那么用 JS 编写的 bot 比用 Python 编写的 bot 更容易扩展。

4. 更快的响应速度 目前，V8 及其竞争对手使 JavaScript 成为世界上最快的脚本语言。 如果你希望你的 bot 尽可能的快，同时仍然享受动态语言，那么 grammY 是你的最佳选择。

与往常一样，编程语言在某些任务上表现出色，而在其他任务上则应避免使用。 这也不例外。

例如，根据生态系统的当前状态，任何与机器学习相关的事情都不应该在 JavaScript 中完成。 然而，当涉及到 web 服务器时，TypeScript 往往是更好的选择。

用 Go 编写的框架

如果你精通 TypeScript 和 Go，那么为你的 bot 选择语言的合理指标是开发速度和运行速度之间的平衡。

如果你不太确定自己正在构建什么，请选择 grammY。 TypeScript 可让你以令人难以置信的速度迭代代码库。 它非常适合快速原型设计、尝试新事物、了解 bot 以及快速完成工作。 根据经验，使用 TypeScript 每天可以轻松处理约 100,000,000 个 update，但超出这个范围将需要额外的工作，例如再使用一个 grammY 插件。

如果你已经非常了解你将要构建的内容（你不需要太多帮助），并且你已经知道你的 bot 将处理大量 update，请选择一个用 Go 编写的库。 作为一种原生编译语言，Go 在原始 CPU 速度下的性能比 TypeScript 高出几个数量级。 当你编写 bot 时，这一点就不那么重要了，因为大部分时间都花在等待网络上，但最终，你的 bot 解析 JSON 的速度将开始变得重要。 在这些情况下，Go 可能是更好的选择。

另一个指标是开发者体验（DX）。 一般来说，Go 和 TypeScript 都拥有非常好的工具和编辑器支持。 然而，grammY 明显优于用 Go 编写的任何库，特别是对于 Bot API。 这主要是由于 grammY 以复杂的方式利用了 TypeScript 先进的类型系统。 因此，你可以直接在编辑器内以交互方式浏览 Bot API。 使用任何用 Go 编写的库都无法达到同样的程度。 如果你想要最好的 DX，请使用 grammY。

用 Rust 编写的框架

类似的观点也可以 像 Go 一样 提出，但 Rust 的观点甚至更强。 在某种程度上，你会花费更多的时间来编写 Rust，但你的 bot 也会更快。

另外，请注意，使用 Rust 很有趣，但对于 bot 来说很少有必要。 如果你想使用 Rust，那就用吧，但请考虑是你喜欢 Rust，而不是说它是适合这项工作的工具。

如何反驳这种比较

如果你认为这个页面上有什么问题，不要失望！ 请在 群聊 中告诉我们！ 我们很希望你能用你的观点来教育我们。 当然，你也可以直接在 GitHub 上编辑这个页面，或者提交一个 issue 指出我们的错误或者提出你的建议。 这个页面永远留有空间变得更客观、更公平。