Similarly to my post about Bun, I want to start a list about Next.js things that drive me insane. I love the page rendering, SSR and static generation of React that give Next.js great performance boost.

Unfortunately, Next.js falls short in almost all aspects of a web framework that I would expect. As a backend developer that uses MVC frameworks a lot (especially Symfony), I have a lot of problems with Next.js. Here is a non-complete list in no particular order. I will try to update this post as time goes on.

• Sitemap generation does not generate a sitemap index, making it pretty useless
• No built-in auth layer
• No built-in i18n layer
• No built-in event system
  • Makes integration of an ecosystem unnecessarily hard. Look at Symfony’s bundles and event system which is very plug and play. Symfony lets you add 2FA authentication with one composer command. Next.js couldn’t even dream of that.
• Getting the current request outside of a server component or endpoint file is near-impossible
  • This makes building a custom auth or event layer even harder. These are things you can’t build in one file and you are forced to pass the request to every function that needs it manually. A global would fix this. Symfony does this with dependency injection.
• You only get one middleware
  • This one sucks a lot, because a lot of features like auth and i18n that come built-in with other frameworks rely on a middleware. You need one for auth and one for i18n, yet Next.js only lets you have one. You need to combine them and there’s no proper way to do that. On top of that, the concept of middleware and weird regex-ing you have to do for it is horrible on its own.
• Random, unreadable and undebuggable errors
• Almost no dev tools or profiling
  • Compare this to Symfony’s amazing profiler
• React 19 broke next/link
  • Found nothing about this online, but updating to React 19 completely broke this component for me. Downgrading to React 18 fixed it.
• No built-in form handling
  • Need to rely on third party stuff for something so basic

This list, together with the list of problems with Bun, shows to me how the JavaScript ecosystem vastly prefers new and shiny innovations over any sort of support and stability. If I had the time and money, I would probably just build my own framework.

A while ago, I started using Bun instead of Node.js, because of a lot of DX improvements. Not having to worry about TypeScript files or ESM support is really good. Unfortunately, bun has a lot of edge cases with no solutions, that make using it a nightmare. I intend to collect these things in this article over time.

Since I have already committed to using Bun in production, I can’t simply switch back to Node.js now. But it is important to keep these things in mind, when making your decision. At the time of writing this article, Deno 2.0 looks much more promising than Bun. And while Node.js has a lot of annoying quirks, it is certainly much more stable than Bun.

• Bun does not support Alpine Linux (Docker)
  • Seems to be fixed in Bun 1.1.35
• oven-sh/setup-bun has been broken for a long time
  • Workaround: always download either latest or a specific version
• The new AWS SDK seems to be incompatible with Bun (random segfaults all the time)
  • Workaround: old SDK works fine
• bun build is super broken, especially minifying
  • Workaround: stick to esbuild
• bun build –compile doesn’t work with wasm dependencies (e.g. when using ink for CLIs)
  • haven’t found a workaround yet
• bun test is just as broken, especially mocking
  • Workaround: stick to vitest
• Installing the current project as a local global dependency does not work in bun
  • haven’t found a workaround yet
• bun install randomly fails
• Running bun via npm on Windows does not work
• No support for pnpm workspaces
  • This occurred because I moved package management back to pnpm since bun’s was too broken