Why Node.js + TypeScript Perform Poorly as Background Processes and Why I'm Considering Rewriting My Bots

Hello fellow developers,

I want to share some thoughts about using Node.js with TypeScript for running Telegram bots as background services—especially when running more than three Node.js(as telegram bots) processes concurrently on the same server.

At first glance, this stack seems ideal: fast development, a massive community, and using one language both on the backend and frontend. But in practice, there are significant performance challenges that are worth understanding.

Why Node.js + TypeScript Cause Performance Issues When Running in the Background

1. Memory Management and the Event Loop
   
   Node.js runs on a single-threaded event loop per process. This means each Node.js process can only handle one task at a time. Under heavy load—such as many Telegram bots sending and receiving events—tasks queue up and have to wait their turn. While you can run multiple processes (via clustering or process managers like pm2), each process consumes its own memory and CPU resources.

2. Limited Number of Processes and High Resource Usage
   
   Running more than three Node.js processes creates a significant load on the server—even if it’s relatively powerful (8 GB RAM, 4 CPU cores, NVMe SSD). Each process requires its own memory, garbage collection cycles, and runs its own event loop. Additionally, inter-process communication and network I/O add to the overall overhead.

3. TypeScript Adds Complexity at Development, Not Runtime
   
   TypeScript is transpiled to JavaScript, so runtime performance is mostly that of JavaScript. However, complex TypeScript codebases with heavy typing and large frameworks can sometimes result in less optimized JavaScript output, affecting memory usage and performance indirectly.

4. Concurrency Management is Limited
   
   Node.js does not natively support true multithreading (except for worker threads, which add complexity). Managing high concurrency with many bots competing for CPU and memory becomes challenging and can lead to bottlenecks and instability.

Why I'm Considering Rewriting Bots in Golang, Rust, C++, or Erlang

• Golang: Easy to learn, highly efficient performance, built-in concurrency with goroutines, low memory footprint, and great scalability.
• Rust: Offers performance close to C++, memory safety without a garbage collector, ideal for creating stable and fast services that can handle heavy loads.
• C++: The fastest and most performant option, but more complex to develop and maintain, and less flexible for rapid changes.
• Erlang: A mature language designed for distributed, concurrent systems with high uptime and real-time load management.

Why Even a Powerful Server Struggles Under Load

Despite having a relatively powerful server (8 GB RAM, 4 CPU cores, 150 GB NVMe SSD), performance bottlenecks occur not just because of hardware limitations but due to Node.js and JavaScript's architecture. Heavy memory consumption, single-threaded event loops, and multiple Node.js processes competing for the same resources cause these bottlenecks.

Also, each bot may use different libraries, external connections, and frequent API calls—all adding to the cumulative load.

In summary, I am seriously considering rewriting my bots in more performant, resource-efficient languages to reduce server load, improve stability and scalability, and ultimately provide a better user experience.

I’d love to hear your thoughts, experiences, and advice for improve node.js performance.

Thanks,

Alexander