Integrationens usynlige pris

Lad os snakke om noget, der frustrerer enhver udvikler, der har prøvet at bygge en seriøs webapplikation: integrationens skjulte omkostninger.

Du kender det. Du har valgt din server-ramme, din ORM, dit valideringsbibliotek, dit frontend-framework, dit build-værktøj. Alt ser godt ud på papiret. Men så begynder du at bygge rigtige features og opdager, at dit valideringsbibliotek ikke helt forstår den datastruktur, din ORM returnerer. Din serverside-rendering fra frontend-frameworket spiller ikke pænt med din servers middleware. Din session-håndtering laver antagelser, der bryder sammen, når du prøver at deploye til edge.

Hvert enkelt værktøj er fremragende. Samttingene er et mareridt.

Hvordan vi endte her

JavaScript-økosystemet har altid værdsat komponerbarhed over sammenhæng. Det er ikke inherently forkert — UNIX-filosofien har tjent os godt i årtier. Problemet er, at webapplikationer ikke er pipelines af isolerede datatransformationer. De er sammenvævede net af delte antagelser: request-formater, valideringsgrænser, authentication-flows, rendering-kontekster, deploy-targets.

Django kom i 2005 og tog et væddemål: udviklere ville bytte noget fleksibilitet for et sammenhængende system. Man kunne stadig række uden for stacken, når man havde brug for det, men indeni var alt designet til at fungere sammen. Den ejerandel betød færre overraskelser.

PHP-frameworks forstod det også. Laravel, Symfony, Yii — de gav alle den "ét sammenhængende system"-følelse. Man vidste, hvad der var officielt territorium, og hvad der krævede eventyr i vildmarken.

Så spiste JavaScript serveren, og vi mistede det meste af det.

Meta-Framework-fælden

Moderne meta-frameworks forbedrede ting på nogle måder. Next.js, Nuxt, SvelteKit — de gav dig en sammenhængende stack igen. Men de gjorde det ved at indsnævre dine valg snarere end at udvide dem.

Her er hvad jeg mener: Next.js er en god React-stack. Men hvis du forelsker dig i Solids performance-karakteristika eller Sveltes enkelhed, kan du ikke bare bytte view-laget ud. Du adopterer et andet meta-framework med forskellige konventioner, forskellige routing-mønstre, forskellige backend-antagelser. Du lærer de samme problemer, du allerede har løst, at kende igen — bare med anden syntaks.

Det skaber en bizarr situation. Frontend-økosystemet innoverer hele tiden, men at skifte mellem tilgange kræver næsten at starte forfra. React-udviklere og Svelte-udviklere løser de samme backend-problemer uafhængigt af hinanden, på lidt forskellige måder, for evigt.

Runtime-lotteriet

Og så er der runtime-fragmentering. Node.js, Deno, Bun — de er alle capable platforms, men de fleste frameworks er reelt runtime-specifikke. Når et framework hævder Deno-understøttelse, betyder det ofte bare "Deno kan køre vores Node-kode." Det er ikke det samme som, at frameworket er designet omkring Deno's native APIs og execution model.

Det betyder mere, end det måske lyder. Din runtime påvirker performance-karakteristika, deployment-mål og sikkerhedsmodeller. At låse sig selv fast til et framework, der kun virker rigtigt på én runtime, begrænser dine muligheder, efterhånden som økosystemet udvikler sig.

Hvad vi faktisk har brug for

Her er sagen: webapplikationer har naturlige lag, der ikke behøver at være koblede.

Frontends beskriver browser-UI. Backends håndterer requests, data og applikationslogik. Runtimes er eksekveringtargets. Disse bekymringer bør kunne variere uafhængigt af hinanden.

Forestil dig at bygge én route med React, fordi du har brug for dens komponent-økosystem. Bygge en anden med Svelte, fordi performance betyder mere der. Køre dine Node.js-routes i dag, men deploye dine TypeScript-routes til Bun, når du har brug for hastigheden. Alt i den samme applikation, med den samme backend-model, den samme validering, de samme sessions.

Det er ikke magisk tænkning. Det er at behandle bekymringer som separate bekymringer — og sådan har god software altid været bygget.

Frameworket bør tage ejerskab over samlingerne

Jeg argumenterer ikke for ét framework til at herske over dem alle. Jeg argumenterer for, at et framework bør tage ansvar for at få sine dele til at fungere sammen. Du bør stadig kunne række uden for den officielle stack, når du har brug for det — ingen shipper perfekte defaults til enhver brugssituation. Men når du bliver inden for frameworket, bør samlingerne være frameworkets problem at løse, ikke dit.

Et framework, der får dig til at tænke på routing, validering, data-adgang og rendering som separate problemer, du selv skal lime sammen, er ikke et framework. Det er et forslag.

De bedste frameworks giver dig ejerskab over din forretningslogik, mens de tager ejerskab over alt andet.

Hos NameOcean har vi set, hvordan hosting-kompleksitet kan mangedoble sig, når din stack er fragmenteret. At vælge et framework, der respekterer adskillelse af bekymringer — der lader dig ændre dele uden at omskrive alt — gør deployment, skalering og vedligeholdelse dramatisk enklere.

Spørgsmålet er ikke, om man skal bruge et framework. Det er, om dit framework arbejder for dig, eller bare tilføjer endnu et lag af beslutninger, du ikke havde brug for at træffe.

Hvad ville det betyde at bygge din næste applikation med et værktøj, der tager ejerskab over samlingerne? Det er værd at tænke over, før du scaffolder dit næste projekt.