How grammY Compares to Other Bot Frameworks
While grammY uses some concepts known from other bot frameworks (and web frameworks), it was written from scratch for optimal readability and performance. In other words, it does not use any code of competing projects, but it will still feel familiar to users of some frameworks.
Please assume that this comparison is biased, even though we’re trying to provide you with an objective description of the advantages and disadvantages of using grammY over using other libraries. We are trying to keep things in this article up-to-date. If you notice that anything is outdated, please edit this page using the link at the bottom.
Choose Your Programming Language First
grammY has its roots in Telegraf, so here is a brief summary of how these frameworks relate historically.
Telegraf v4 attempted to fix this by migrating the entire code base to TypeScript. Unfortunately, many of the resulting types were so complex that they were too hard to understand (but correct). Moreover, the migration revealed countless oddities (example) in the code base that made it painful to even find correct typings for the existing code at all.
As a result, even though version 4.0 tried to improve correctness and tooling support, it ended up making Telegraf substantially harder to use than its untyped predecessor. Understandably, many existing users of Telegraf 3 were unwilling to upgrade. It also got harder for new users to get started.
grammY takes a step back and rethinks a type-safe bot framework with approachability first. This allowed to skip a lot of the frustrating discussions around how to cope with strange internal typings. It enabled the project to have clean, consistent, compiling code that provides users with excellent types (=editor support). Type safety in turn permits more advanced features that fundamentally change how we think about bot development, such as API transformers.
Today, Telegraf 3 is outdated. There are some unofficial forks out there that try to keep the legacy code base up to date with the evolvement of the Bot API, but their compatibility is unknown. Furthermore, the plugin ecosystem of Telegraf has moved on to Telegraf 4. Most plugins developers do not maintain versions for third-party forks of old Telegraf versions.
Based on the fact that Telegraf hangs somewhere between version 3 and 4, it makes sense to compare grammY to both versions individually.
Comparison to v3
Given their shared history, grammY and Telegraf have a lot in common. They both have a middleware system in their core. They also share a lot of their basic syntax:
// Works with both grammY and Telegraf. bot.on("message", (ctx) => ctx.reply("Hi!"));
Any code written in Telegraf will work in grammY with minimal changes. (Note that the opposite is not true as many grammY features are not available to Telegraf users.)
In contrast, grammY is written in pure TypeScript. This allows your code editor (e.g. VSCode) to analyze your code while you are typing, and assist you. In addition, it can show the complete Telegram Bot API inline—the website’s documentation will be available right at your fingertips when hovering your mouse over any name or element of your code.
Another remarkable advantage is that you are finally able to write your own bots in TypeScript. This was hard to do because the wrong type annotations of Telegraf were preventing perfectly correct code from compiling, thus effectively encouraging users not to check their code in the first place. However, type-safe code is a major advantage for any non-trivial code base.
grammY and Telegraf have distinct code bases. Being freed from the legacy, grammY could also make substantial contributions to the underlying middleware system, enabling exciting use cases such as filter queries, error boundaries, API transformers, and many more. This also enables the development of valuable plugins that are impossible to work under Telegraf.
The main advantage of Telegraf over grammY is that it is still known by a lot more people. The Telegraf community may be divided between the versions, but most of these groups have created more bots with their version of Telegraf than there are grammY bots. This also means that you can find more stories on the internet about Telegraf users, and you will find more unofficial tutorials by other coders.
Comparison to v4
The main advantage of grammY over Telegraf 4.x is that it is simply a lot easier. For example:
- grammY has a documentation. Telegraf does not (it was replaced by a generated API reference that lacks explanations).
- Types in grammY just work and they will follow your code. In Telegraf, you will often need to write your code a certain way, otherwise it does not compile (even though it would actually work fine).
- grammY integrates hints from the official Bot API reference inline that help you while you’re coding. Telegraf does not give you any explanations on your code.
Advantages of grammY
- Easier to use than Telegraf 3 and 4
- Proper TypeScript support
- Has both a documentation and a generated API reference
- Significantly faster on long polling (with grammY runner)
- United community and ecosystem
- More plugins
- Better integrations with databases and web frameworks
- More actively developed
- Helpful error messages
- Much harder to run into dangerous race conditions
- Designed to protect you from making programming mistakes
- Runs on Node.js, but also on Deno and in the browser
Advantages of Telegraf
- Older, thus more mature
- Many more example bots, both in the repository and in the wild
node package is the second big project that impacted the development of grammY. Its main advantage over other frameworks is that it just is dead simple. Its architecture can be described in a single sentence, while grammY needs a guide on its documentation website to do the same. We believe that all these explanations on the grammY website help people to get started easily, but it is tempting to have a library which does not need any explanations in the first place.
On the downside, this is only good in the short-term perspective. The idea of putting everything in a gigantic file, and using a primitive
Event to process streams of complex objects (aka. web requests) has brought a lot of pain to the world of Telegram bots, and it certainly prevented a number of good ideas from being implemented.
Bots always start small, but a responsible framework must provide them a clear path to grow, and to scale up. Unfortunately, NTBA fails horribly at doing that. Any code base with more than 50 lines that uses NTBA ends up being a terrible mess of spaghetti-like cross-references. You don’t want that.
Do you think that your favorite framework is better than grammY in some respect? Feel free to edit this page and add a comparison—or tell us what you think in the group chat!
Comparison With Frameworks in Other Programming Languages
There are reasons to favor a different programming language over TypeScript. The most important thing is that you like working with your tools and languages. If you are determined to stick with something else, then you can stop reading here.
Given that you’re still reading, you may want to know why grammY is written in TypeScript, and why you should maybe consider picking this language for your bot, too.
This section will outline how TypeScript has a few advantages over other languages when it comes to developing Telegram bots. The main other language that is used to develop chat bots for Telegram is Python, so we will limit ourselves to this for now. Some of the following points are rather personal opinions than objective facts. People have different taste, so take this section with a grain of salt.
Easier to scale up code base. The type system has a second advantage—it lets you scale the code base of your bot. This is much harder to do for projects written in a language with worse type safety.
Easier to scale up load. If your bot actually starts to get popular, it is significantly easier to scale bots written in JS rather than in Python.
awaitsupport. This is a very popular programming pattern to tame concurrency. The recent years show a strong trend towards asynchronous programming. The largest bot framework for Python, PTB, announced its migration to asynchronous programming in January 2021, which is expected to maybe take “2 years”. grammY is already there. (Other less-known Python frameworks may be faster at transitioning. Disregard this point if you are using a Python framework that has support for
How to Disagree With This Comparison
If you think that something is wrong on this page, don’t despair! Please let us know in the group chat! We’d love for you to educate us about your perspective. Naturally, you can also just edit this page on GitHub, or file an issue there to point out mistakes or suggest other things. This page will always have room to be more objective, and more fair.