Why constraint-first, and why now
Every framework encodes an assumption about the environment its output will run in. For most of the internet, that assumption is wrong. Here is the case for making the constrained environment the default target.
Why constraint-first, and why now
Every framework encodes assumptions about the environment in which its output will run. One of the most consequential is rarely stated: that the network is fast, stable, and cheap; that the device is capable; that power is reliable; and that teams are large enough for engineers to specialise.
For the majority of internet users in Africa — and for a large population in emerging and rural markets worldwide — none of these conditions hold.
The developer-discipline tax
Building software that works is possible, but only through sustained manual vigilance: auditing bundle sizes, hand-splitting code, choosing light dependencies, wiring and securing a backend, integrating payments, handling offline, remembering accessibility and localization. Each is a discretionary act the developer must remember, atop the domain problem they were hired to solve.
Constraint-first development is, at core, a proposal to abolish this tax by moving budgets, integrations, and inclusions from the developer's discipline into the framework's defaults.
// doing nothing special still ships a page that works on the Baseline Device
export default function Home() {
return <main><h1>Karibu</h1></main>; // zero JavaScript, by default
}
Designing for the hardest environment yields software better for nearly everyone. The constrained case is a superset of good practice, not a niche.