A developer ripped Next.js out of their blog and immediately hit 100 on every Lighthouse category. That’s performance, accessibility, best practices, and SEO. Perfect scores across the board.

The post from Korin Diehacker doesn’t waste time on theory. They migrated from Next.js to a simpler static setup and documented what changed. The result? Faster load times, better Core Web Vitals, and no client-side JavaScript doing things that don’t need JavaScript.

This isn’t an anti-Next.js screed. Next.js is great when you need what it does: server components, dynamic routing, API routes, incremental static regeneration. But for a blog? It’s overkill. You’re shipping a framework to render markdown that could’ve been HTML from the start.

The lesson here is about reaching for the right tool. If your site is mostly static content, you don’t need a React framework. You need HTML, CSS, and maybe a build step for templates. The simpler stack means less to load, less to parse, and less that can go wrong.

Lighthouse scores aren’t everything. But they’re a decent proxy for whether you’re shipping unnecessary code. If you’re pulling in megabytes of JavaScript to display text, that’s worth questioning.

C++26 Contracts Rejected Again

The C++ standards committee just wrapped up the C++26 DIS ballot, and contracts didn’t make it in. Again.

Contracts would let you write preconditions, postconditions, and invariants directly in C++ code. Think assert() but as a language feature with compile-time support. The idea is to catch bugs earlier and make code behavior more explicit.

This is the second time contracts have been proposed and rejected for a C++ standard. They were pulled from C++20 after disagreements about syntax and semantics. The C++26 proposal tried to address those concerns, but it still didn’t get consensus.

The main sticking points are about what contracts should actually do. Should they be checked at compile time, runtime, or both? Should they affect optimization? What happens when a contract is violated? Different committee members have different answers, and without agreement, the feature doesn’t ship.

For developers writing C++, this means you’re still stuck with manual assertions and external tools like static analyzers. Contracts would’ve made these checks part of the language itself, with better compiler integration and clearer semantics. But that’s not happening in C++26.

The next chance is C++29, assuming someone proposes them again and the committee finds common ground. Until then, C++ contracts remain a good idea that can’t get standardized.

A Few Tools Worth Checking Out

Proc-CLI is a new command-line tool for managing processes and ports. It’s designed to be agent-friendly, which means structured output, predictable behavior, and JSON responses. If you’re writing scripts or automation that needs to kill processes or check what’s listening on a port, it handles the annoying stuff cleanly. proc-cli.com

PaperPilot is a PDF engine written in Rust that runs entirely in WASM. No cloud, no server uploads. It also supports MCP, so AI agents can interact with PDFs directly in the browser. If you’re building something that needs to parse or manipulate PDFs without sending them anywhere, this is a solid option. GitHub

TitleArt lets you make text look like it’s 1997. Beveled edges, drop shadows, gradient fills. It’s completely pointless and kind of delightful. titleart.dvy.io

The Next.js story and the C++26 contracts decision are both about the same thing: knowing when complexity is worth it. Sometimes you need the framework. Sometimes you need the language feature. And sometimes you’re better off keeping it simple.