Good question. Telegram's infrastructure and dev ecosystem is vaguely weird, much like its overall technical design.
Originally the bot framework was HTTP-based, in the literal sense that new message new HTTP GET, and you'd have a webserver somewhere printing out a response to send back. (You can either use incoming webhooks or (yay latency+efficiency) periodically poll Telegram for messages since a given time).
Telegram later released the internal C++ shim/proxy that relayed MTProto (Telegram's protocol) to HTTP requests, so you can now colocate both processes on the one machine for better latency, although many implementations still use the old webhook method.
Later-later, Telegram also released a C++ library applications can use to abstract out the process of dealing with MTProto.
Nowadays, MTProto is well-documented enough that there are independent client implementations of the protocol (that support signing in as users and bots), which incidentally are slightly more flexible than the C++ library or bot shim (mostly because Telegram has specific needs and wasn't initially aiming for a general-purpose consumable at design time).
The record-scratch part is that the two leading independent clients are incidentally written in PHP. Yeah. I don't mind PHP myself, but it was definitely an "oh. okay" moment lol. Like I said, Telegram's infra is interesting.
So there's exceedingly-likely a Node helper library you can use (although you obviously don't fundamentally need one) to build bots in JS if you want; the next level after that would be coordinating with the C++ or PHP libraries, and the boss level :P would be connecting to MTProto directly (which isn't the end of the world, just... an "overloaded motor" number of moving parts to take on all at once for what's realistically likely a hobby-level curiosity).