Why we migrated from Python to Node.js

Overall reaction to the rewrite

• Many readers see this less as “Python vs Node” and more as “Django async mismatch” plus “use what you know.”
• Several think a 3‑day rewrite early on is fine if it makes the team happier and faster; others see it as premature optimization and weak technical planning.
• Some view the post as thinly veiled marketing / clickbait (“Python to Node” flamebait, “week 1 pivot” narrative).

Python, Django, and async

• Strong consensus that Django is ill-suited for async-heavy, streaming, or high-concurrency workloads; its async story is described as awkward, “a parallel universe API,” and full of footguns.
• Multiple commenters stress this is more about Django than Python: alternatives like FastAPI + SQLAlchemy, green threads (gevent), Celery, or Channels could have addressed many pain points.
• Others argue Python async itself is messy: late arrival, multiple competing async models, confusing integration with libraries, and tricky interactions between anyio/asyncio.
• Some defend Python: async can work well with proper patterns (processes/threads/greenlets, Celery for background work) and Django’s ORM/ecosystem are still huge productivity wins.

Node.js and TypeScript perspectives

• Supporters say Node/TS is a natural fit for IO-bound, LLM/HTTP-heavy workloads: async is first-class, concurrency is straightforward, and TypeScript’s type system and tooling feel more mature than Python’s typing.
• Several practitioners report that large Node+TS codebases have been easier to maintain than comparable Python+async+types setups.
• Skeptics highlight npm dependency bloat, deprecation churn, security/supply-chain risks, and argue that Node is far from the “clean” choice; some would have preferred Go, C#, Java, or Rust if you’re rewriting anyway.

Alternative stacks & async models

• FastAPI is widely mentioned as the more appropriate Python choice for this use case; some say the team should have “just learned async FastAPI.”
• Others propose modern TS stacks (Hono, Elysia, Drizzle, Kysely), or completely different runtimes (Deno, Bun).
• Elixir/BEAM is heavily praised as purpose-built for massive concurrency and async, with Phoenix/LiveView and OTP eliminating a lot of DIY scheduling/queueing—though hiring and ecosystem concerns are noted.
• A few suggest that instead of a wholesale rewrite, they could have introduced Node microservices alongside Django and migrated incrementally.

ORMs and database access

• Divisive topic: some would have dropped ORMs entirely for SQL; others emphasize ORMs’ value (migrations, relations, admin UIs, ecosystem integration).
• Node ORM landscape is seen as fragmented; Django’s ORM is viewed as “complete and proven,” but can become painful off the “happy path.”