Built for
absurd speed.

This test is meant to stress-test how well both frameworks handle extremely large payloads; as well as how efficiently they scale up. By creating a page with *200 thousand* individual `<p>Stress-Testing.</p>` elements, we effectively scale up every miniscule *bit* of baggage both frameworks accumulate, exposing inefficiencies. At first you may think that something is incorrect with the test data, and so did we. However, the byte size *is actually correct*. The page HTML is roughly 4.2Mb in size, but the out-of-the-box Brotli compression in elegance comresses it down to 185 bytes transferred. Elegance also does not ship a VDOM, nor any other unneeded JavaScript. This page also contains no interactive elements, meaning our JS shipped was a mere few kilobytes. For Next.JS, we were shocked to see that the actual page HTML generated by default was a stagerring *18.1 megabytes*! We suspect this is because Next.JS by default includes a serialized VDOM of sorts, GZIP tries it's best, and to it's credit it actually shrinks the page HTML down to about a megabyte. Developer Notes: I think it's interesting, this page actually *doesn't load* with `npm run dev` on Next.JS. I get an OOM-error and the first-request crashes the entire server. We are also aware this is not hyper-realistic in terms of usage, but it's interesting to note, nevertheless. This page also took almost *2.5 minutes* to compile in Next, whereas in Elegance it took roughly 5.5 seconds.

// Elegance and Next.JS: /pages/page.tsx export default function page() { return <div> <h1>Stress-Testing.</h1> {/* ... 200 thousand more times ... */} </div> }

This test is meant to measure raw RPS (requests-per-second) by simulating a primitive GET endpoint that returns `{"message": "Hello, World!", }`. Both frameworks return the exact same paylod, so the only factor which affects RPS is raw framework level overhead and optimizations.

// Elegance: /pages/api/route.ts import type { IncomingMessage, ServerResponse } from "node:http"; export async function GET(req: IncomingMessage, res: ServerResponse) { res.end(JSON.stringify({ message: "Hello, World!", })); } // Next.JS: /pages/api/route.ts export async function GET() { const res = new Response(JSON.stringify({ message: "Hello, World!", })); return res; }

This test attempts to measure raw RPS (requests-per-second) with a minimal static page. The page code looks as follows: - Prod mode uses -prod flag - Dev mode uses -dev flag - Production mode test uses `output: "standalone"` in `next.config.ts`, and was executed with `node .next/standalone/server.js`.

// Next.JS & Elegance: /pages/page.tsx export default function page() { return <div> <h1>Hello World!</h1> </div> }

This test aims to measure how fast both frameworks can render a dynamic server-rendered page. For next, this involves `force-dynamic` to ensure the result isn't cached. On both pages, we read some request headers, and embed them into the response.

// Next.JS: /pages/page.ts import { headers } from 'next/headers' export const dynamic = 'force-dynamic' export default async function page() { const h = await headers() const headerValue = h.get('accept-encoding'); return <div>{headerValue}</div> } // Elegance: /pages/page.ts import type { IncomingMessage, } from "node:http"; export default function page({ req, }: { req: IncomingMessage }) { const headerValue = req.headers["accept-encoding"]; return <div>{headerValue}</div>; } export const isDynamic = true;