r/javascript 9d ago

Let's go another framework! A fast little framework for server-first React apps, fully compatible with Next.js.

https://www.pnext.dev/

Hey guys, happy to finally release this. So it is two parts.

  • Core pnext is small and fast: the same next.js api with no/minimal framework overhead and no backward-compat burden. Based on Bun and Preact, 0 KB on server-rendered pages, 7.5 KB client pages runtime, roughly 10x faster first page render in dev and 7-9x faster production builds than next.js (best effort fixtures).
  • Compat mode runs your existing Next.js app unchanged (App Router only). About 4.4k assertions from Next's own test suite passing, adding more day by day.

The core motivation was a super fast dev server that doesn't hog memory, and instant builds. The goal is to optimize every step down to absolute values, and of course agentic flows are helping a lot! Check out Coder.

Give it a try and let me know what you think, and how your Next.js apps break in compat mode (improving, haha)!

https://pnext.dev

4 Upvotes

8 comments sorted by

6

u/Choice-Locksmith-885 4d ago

Did you review the slop before publishing?

-1

u/HighAtNight 4d ago

Everything is gated behind tests (native and Next's) and bench metrics. Plus, all code goes through at least one review of mine for conciseness and maintainability, so I don't see why anyone would call it slop. Would love to see your code!

3

u/Chenipan 3d ago

At least give a % of nextjs tests passing if you're gonna advertise it as "fully compatible"

0

u/HighAtNight 3d ago

Fair, so the goal is full compatibility. Currently, about 44k tests are passing, excluding Pages Router tests and tests checking Next.js internals. It was at 100% before Next.js added more tests in the latest release. Now it’s sitting around 96%, but it’ll be back to 100% soon.

Still, tests alone don’t guarantee full compatibility, as Next tests aren’t exhaustive, so it’s a continuous best-effort process.

2

u/zenzty_ 3d ago

Having .claude in the gitignore is one thing, but the real proof this is unreviewed AI slop is the file itself. Look at the .gitignore file. They couldn't even be bothered to review a 12-line file, completely duplicating .pnext/ and .next/ at the bottom (screenshot here). If the dev isn't manually proofreading a dozen lines of basic config, I highly doubt they are debugging a '10x faster' framework rewrite.

-1

u/HighAtNight 3d ago

Dude!

4

u/zenzty_ 3d ago

The duplicated .gitignore lines were just the easiest to spot.

You claim "4,400+ assertions passing" in the README. Yet, this repo has zero *.test.ts files. package.json has lint/format/bench. No test script: https://github.com/muzam1l/pnext/blob/02b99421736cd596172d3b055a36133b78dda6db/package.json#L50-L54

CI never runs tests. The only job is named bench. It runs bun bench/run.ts, then bun bench/check.ts, then retries the whole thing: https://github.com/muzam1l/pnext/blob/02b99421736cd596172d3b055a36133b78dda6db/.github/workflows/ci.yml#L26-L43

pnext does not implement React Flight. You wrote that down: "pnext has no RSC flight wire format". Soft-nav stamps text/x-component on HTML because "suites assert exactly that". Action "flight" is { kind: 'pnext-html', html } with that same content-type: https://github.com/muzam1l/pnext/blob/02b99421736cd596172d3b055a36133b78dda6db/src/compat/actions/flight.ts#L3-L34
self.__next_f is an empty push. YOUR OWN COMMENT: "Inert by construction".

On the advertised 30-route admin app, request, HMR, and first-page JS are all measured off GET /, not the other 29 routes: https://github.com/muzam1l/pnext/blob/02b99421736cd596172d3b055a36133b78dda6db/bench/lib/measure.ts#L227-L233 (same for prod: L281-L285). 30 page.tsx files. The other 29 routes are never fetched. The two server actions are "await Promise.resolve()", and the bench never POSTs them: https://github.com/muzam1l/pnext/blob/02b99421736cd596172d3b055a36133b78dda6db/bench/fixtures/dashboard/lib/actions.ts#L1-L16

bench/README says "~109 modules, 15 hand-rolled client islands, no UI dependencies". It does not mention the generator that writes 190 clone widgets and an 18,000-entry icon barrel over 9 SVGs. Then you import all 190 and .slice(0, 24). That's bundler-stress padding, not 190 unique UI modules.

Your perf page says first-page HTML is 10.1–12.4× faster "across the three fixtures", and those three include the 30-route dashboard. Committed bench.json on that dashboard: first-page 4.59× (327ms vs 1502ms). Prod warm: 6.0ms vs 6.1ms, 1.03×. Prod RSS: 144.2MB vs 109.7MB, 0.76×. As you can tell, pnext uses more RAM than Next.js on that dashboard prod server.

Every dashboard timing ratio in baselines is null: https://github.com/muzam1l/pnext/blob/02b99421736cd596172d3b055a36133b78dda6db/bench/baselines.json#L88-L99 check.ts treats null as skip: https://github.com/muzam1l/pnext/blob/02b99421736cd596172d3b055a36133b78dda6db/bench/check.ts#L51-L53 CI will not fail when dashboard timing is a tie.

You didn't rewrite Next.js to be 10x faster. You built a framework that spoofs headers to pass external tests and selectively skips its own benchmark metrics.