[slow-development] very weird and frustrating development experience with lots of time wasted in compiling and rendering...

[nishatislam04]

[pouriya73]

Hi @nishatislam04

Fix it in a way that proves what’s wrong

1. Stop the self-inflicted compile storm

"dev": "next dev"

2. Remove the experimental caching stack for dev

In next.config.mjs, for development only:

• set cacheComponents: false

• set reactCompiler: false

• disable turbopack custom rules temporarily

const isDev = process.env.NODE_ENV === "development";

const nextConfig = {
  cacheComponents: !isDev ? true : false,
  reactCompiler: !isDev ? true : false,
  turbopack: !isDev ? { /* your rules */ } : undefined,
};

3. Bring Prisma watch back (carefully)

bunx --bun prisma generate --watch

[nishatislam04]

hey thanks for the reply. i have created a new branch and stripping out implementaion like in package.json, next.config.mjs and layout files and simple html inputs rather than shadcn components etc. and this operation is still ongoing.

can you help me a bit? do you use telegram or messenger? i want to have a conversation with you about this case
please let me know what you think

[pouriya73]

@nishatislam04 I’d appreciate it if you could raise any issues or concerns right here, so we can review them properly and share them with the rest of the team.

[nishatislam04]

thanks for the guidance sir!!!
i have simplified my dev script and nuked my next.config.mjs
now everything is faster than before
here is my current terminal log

$ bun --bun next dev
▲ Next.js 16.1.3 (Turbopack)
- Local:         http://localhost:3000
- Network:       http://192.168.1.108:3000
- Environments: .env.local, .env

✓ Starting...
✓ Ready in 959ms
○ Compiling /admin/user-info ...
 GET /admin/user-info 200 in 9.7s (compile: 6.2s, render: 3.5s)
○ Compiling /admin/social-links ...
 GET /admin/social-links 200 in 9.2s (compile: 8.1s, render: 1055ms)
 GET /admin/user-info 200 in 568ms (compile: 252ms, render: 316ms)
 GET /admin/social-links 200 in 1008ms (compile: 433ms, render: 575ms)
○ Compiling /admin/work-experience ...
 GET /admin/work-experience 200 in 7.8s (compile: 7.1s, render: 665ms)
 GET /admin/user-info 200 in 521ms (compile: 158ms, render: 363ms)

i cant use react-compiler and cache component.
i dont understand why. and i needed the cache component feature.
my second issue is - it still takes a lot of time to render different state of a route
take a look at the cold start, first visit, sub-sequent request for compile and render logic
i still dont understand why it takes so much of times, when i am in local development mode. can you please help me with that?
i am using docker-postgres and prisma v7
any suggestions is much appreciated
thanks

[pouriya73]

Thanks for the update @nishatislam04

Both features can add extra work at compile / render time, and in dev that cost can be paid more often because files/components are frequently invalidated.

• cacheComponents: it changes how parts of caching/PPR/dynamic IO are handled. The official docs even note it may introduce additional latency vs serving pre-rendered content.

• reactCompiler: it’s a compile-time transform. If your project is already on the edge of “many modules / heavy transforms,” dev can feel slower. (It’s designed to help runtime perf; it’s not guaranteed to speed up dev iteration.)

Recommendation: keep both enabled for prod builds, but disable them for development:

const isDev = process.env.NODE_ENV === "development";

/** @type {import('next').NextConfig} */
const nextConfig = {
  reactCompiler: !isDev,
  cacheComponents: !isDev,
};

export default nextConfig;

Your logs still show “first-hit per route” compilation — that part is expected

In App Router dev, each route (and what it imports) can trigger compilation the first time you hit it.

Run Webpack dev (comparison)

Next has a webpack dev option — if webpack is dramatically faster/slower, that tells us where to dig.

bun --bun next dev --webpack

React Compiler is a feature of React / Next.js.
bun is just a runtime, package manager, and task runner.

That means:

• bun itself does not run or manage the React Compiler.

• But if Next.js supports the React Compiler, bun does not interfere with it and works just fine.

In other words, React Compiler is enabled and executed by Next.js, and bun simply runs Next.js.

[maxoliverbr]

Its been like that from years:
#58889

For sometime I thought I was coding wrong, but no. Its slow. period.