Hvorfor "The Descent" er en historie halvvejs fortalt

For nylig cirkulerede et genereret blogindlæg med titlen "The Descent" i udviklerkredse. Det maler et pænt narrativ: Udviklere skrev før HTML, uploadede via FTP, og så blev alt komplekst og bliver bare mere komplekst. Tesen er klar. Tidslinjen er ryddelig. Problemet er bare, at det lyder som et greatest hits-album, hvor halvdelen af kunstnerne er skåret fra.

I 2008 – året hvor indlægget tager sit udgangspunkt – sad jeg ikke og stirrede på en FTP-progresslinje. Jeg var dybt nede i WordPress-skabelonfiler og byggede sider, hvor mine kunder kunne logge ind, skrive indhold og trykke udgiv uden at vide, hvad FTP overhovedet betød. Og jeg var ikke alene. CMS-æraen var ikke en fodnote. Det var øjeblikket, hvor nettet demokratiserede publicering i stor skala.

De værktøjer vi bruger i dag dukkede ikke op fra et tomrum af "værktøjer der løser værktøjsproblemer." De dukkede op fra menneskelige behov, kulturelle skift, platformsudvikling og ja, ægte ingeniørfremskridt. At forstå den forskel betyder noget, når du beslutter hvad du vil bygge med og hvordan.

De glemte formidlere: Platforme der underviste en generation

Her er hvad "Descent"-narrativet ignorerer: Millioner af mennesker lærte HTML og CSS før de nogensinde rørte en kodeeditor. De lærte det på MySpace, hvor det at tilpasse sin profil betød at skrive inline styles og opdage, hvad der skete når man indlejrede for mange marquee-tags. De lærte det på LiveJournal, hvor tekstboksen var deres IDE og gem-knappen var deres deploy-pipeline.

Neopets, LiveJournal, tidlig Blogger, MySpace – disse var ikke bare sociale netværk. De var hands-on webudviklings-bootcamps forklædt som underholdning. Du ville have en brugerdefineret markør? Du fandt ud af CSS. Du ville have dit navn i en speciel skrifttype? Du lærte font-tags (og følte dig meget snedig mens du gjorde det).

Denne æra betyder noget, fordi den viser at webudviklingslæsning spredte sig gennem tilgængelighed, ikke gennem formel uddannelse eller professionelle værktøjer. Nettet lærte sig selv.

Flash og drømmen om "app-lignende" oplevelser

Og så var der Flash. Indlægget nævner det knapt, hvilket føles som at skrive om moderne JavaScript-frameworks uden at nævne jQuery eller Node.js. Flash var sådan udviklere leverede interaktive oplevelser, som HTML og CSS ikke kunne hamle op med i slutningen af 90'erne og starten af 2000'erne. Animationer, streaming video, webapplikationer med tilstand – Flash klarede det.

iPhone dræbte det, ja. Men før det formede Flash en hel generations mentale model af, hvad en weboplevelse kunne være. Det beviste, at brugere ville have app-lignende interaktioner, før vi havde browserkapabiliteterne til at levere dem nativt. Efterspørgslen kom først. Teknologien fulgte.

At forstå denne historie forklarer, hvorfor udviklere i slutningen af 2000'erne var så begejstrede for JavaScript-frameworks. Endelig havde vi browser-API'erne til at bygge det, Flash havde lovet.

Hvorfor "værktøjer avler værktøjer" er en ufuldstændig historie

"Descent" argumenterer for, at moderne frontend-kompleksitet eksisterer, fordi hver løsning skaber nye problemer der kræver nye løsninger. Det er ikke forkert, præcis. Men det er som at forklare hvorfor byer har trafikproppe ved at beskrive, hvordan hver ny vej skaber mere trafik. Teknisk korrekt. Går glip af de menneskelige grunde til at folk bliver ved med at bygge byer.

De virkelige drivere for webudviklingens evolution inkluderer:

Selve webplatformen. Browserkapabiliteter udvidede sig. WebGL gjorde 3D mulig. Service Workers gjorde offline-oplevelser mulige. WebAssembly åbnede nye performancedøre. Hver udvidelse af hvad browsere kunne gjorde, inviterede ny værktøjer til at udnytte de kapabiliteter.

Kulturelle samtaler. Konferencer, blogindlæg, Stack Overflow-tråde og til sidst Reddit og Twitter formede, hvordan problemer blev rammesat, og hvilke løsninger der vandt indpas. De "best practices" vi citerer blev ikke opdaget – de blev forhandlet, nogle gange diskuteret i årevis, og til sidst kodificeret til konventionel visdom.

Forretningsøkonomi. Virksomheder skalerede. Engineering-teams voksede fra tre personer til tre hundrede. De problemer der betød noget skiftede fra "hvordan bygger vi denne funktion" til "hvordan vedligeholder vi denne kodebase på tværs af tyve ingeniører." Værktøjer fulgte pengene og smertepunkterne.

Mentale modeller og principper. DRY, KISS, YAGNI, LIFT-navngivningskonventionen – disse idéer dukkede ikke op fra det tomme rum. De krystalliserede fra års erfaring, hvor udviklere oplevede smerte og gav det et navn. De blev det ordforråd, som nye udviklere arvede.

Pendulnarrativet behandler frontend-historie som en løkke. Jeg vil argumentere for, at det mere ligner en spiral – vi vender tilbage til lignende idéer på højere niveauer, med mere kontekst, bedre værktøjer og nogle gange (men ikke altid) mere visdom.

Hvad dette betyder for udviklere i dag

Hvis du er en udvikler der bygger i dag, befinder du dig på et bestemt punkt på den spiral. Du har adgang til frameworks, værktøjer og kapabiliteter som udviklere i 2008 ikke kunne forestille sig. Du står også over for problemer, de ikke kunne have forudset.

Konklusionen bør ikke være, at kompleksitet er dårlig, eller at simple værktøjer altid er bedre. Konklusionen er, at de værktøjer du bruger er svar på virkelige problemer, og at forståelse af disse problemer – hvor de kom fra, hvem der oplevede dem, hvilke løsninger de prøvede først – gør dig til en bedre praktiker.

Når din build-pipeline fejler, kæmper du ikke mod tilfældig kompleksitet. Du står ved skæringspunktet mellem års beslutninger taget af mennesker, der forsøgte at løse virkelige problemer under virkelige begrænsninger.

Om AI-genereret historie (inklusiv denne)

Her er det ubehagelige spørgsmål, "Descent"-indlægget rejser: Hvad sker der, når historien om webudvikling bliver skrevet af systemer trænet på nettet? Indlægget selv var delvist genereret. Mine idéer her er formet af det, jeg har læst, som i stigende grad er AI-influeret tekst.

Vi bør være tankefulde omkring dette. AI-systemer kan syntetisere eksisterende viden, men oplever ikke smerten ved at debugge et produktionsproblem kl. 2 om natten eller triumfen ved at sende noget afsted, der faktisk virker for brugere. Historie skrevet af AI kan være sammenhængende men hul.

Det betyder ikke, vi skal afvise AI-assistance. Det betyder, vi skal forblive forankret i de menneskelige oplevelser, der formede de værktøjer vi bruger. Tal med seniorudviklere. Læs primære kilder når du kan. Oplev problemerne selv når det er muligt.

Nettet blev ikke til det, det er gennem værktøjer alene. Det blev til det, det er gennem mennesker – rodede,议事, samarbejdsvillige, nogle gange frustrerede mennesker – der løste problemer sammen over årtier.

Vi var alle sammen at se. Vi så bare fra forskellige hjørner af den samme udviklende platform.

Hvilke æraer føler du mangler fra de almindelige narrativer om webudvikling? Jeg er på X @[handle] – lad os sammenligne noter om den historie vi har levet igennem.