“The Sound of Music” kan prædike: “Lad os begynde helt fra begyndelsen, et meget godt sted at begynde.” Men næsten alle udviklere ved, at det er en tåbelig plan. Det rigtige sted at starte er med et solidt fundament, der er bygget af et godt team af open source-udviklere. Klon deres hårde arbejde og tilføj derefter lige nok kode til at gøre det til dit eget. Der er ingen grund til at gentage det, som alle har gjort før.
Det er en nem plan – når først du vælger. Desværre kan det være næsten lige så svært at vælge dette fundament som at starte helt fra begyndelsen. Verdenen af webframeworks er et meget aktivt udviklingsområde, og der kan være snesevis af gode open source-projekter, som ville være en god start for dit projekt.
For at gøre tingene endnu værre, har de forskellige hold, der har skabt disse forskellige projekter, sat sig ud på en anden vej, fordi de havde alvorlige filosofiske forskelle i forhold til de andre muligheder. De kiggede på de andre frameworks og besluttede, at de kunne gøre det bedre. Med andre ord, de gjorde det af en grund, og du er måske eller måske ikke enig i deres beslutning.
Listen over gode steder at starte nedenfor udelader med vilje markedslederne React, Angular og Vue, blot for at gøre tingene lidt enklere. Det betyder ikke, at de tre store er dårlige. De kan stadig være det rigtige for dig. Det er bare det, at der konstant tales om dem, og disse diskussioner udelader nogle ret gode andre muligheder.
Der er masser af gode grunde til at vælge de mest populære. Mange mennesker i dine sko kiggede rundt, og mange af dem valgte React, Angular eller Vue af en god grund. Men det var dengang. I mellemtiden har nogle kloge mennesker skabt nyere frameworks, der er hurtigere, enklere, stærkere eller en hvilken som helst af en stor række superlativer.
I de fleste af nedenstående tilfælde har holdene skabt noget spændende og kraftfuldt ved at gentænke frameworkets natur. Det er en fancy måde at sige, at de endte med at slette en funktion og dermed gøre rammen mere effektiv og dermed reducere mængden af hukommelse, den har brug for, fremskynde opstartstiden eller generelt gøre den mere adræt. Eller i nogle få tilfælde tilføjede de nye idéer, som måske bliver standard i fremtiden.
Hvis du har tid til at investere, er her en liste over nogle af de andre interessante valg. De er ikke nødvendigvis rigtige for nogle mennesker, og de er bestemt ikke det bedste valg for alle, men de er måske et bedre valg for dig. Din opgave, hvis du vælger at tage imod den, er at lave en solid beskrivelse af din webapplikation, skrive en forholdsvis fast beskrivelse af de forskellige use cases ned og derefter evaluere disse værktøjer med dette i baghovedet.
Måske kan du lide en bestemt tilgang til at designe kode. Måske har din applikation ikke brug for nogle af funktionerne i de tykkere, mere populære frameworks. Der er dusinvis af grunde til at investere i en af disse andre veje. Måske finder du bare ud af, at en af dem gør underværker for din applikation.
Petit DOM
Hvis du er vild med idéen om en virtuel DOM, men ikke ønsker alle de begrænsninger, der følger med, når du overtager tankegangen hos folkene i React, Vue eller dit andet framework med et stort navn, så er Petit DOM den rette vej at gå. Du får en lille mængde kode, der giver dig mulighed for at manipulere en virtuel samling af tags og derefter migrere dem til den rigtige DOM. Alt andet om komponenternes struktur og rendering er op til dig. Hvis dine komponenter er enkle, eller hvis du vil skabe et superkomplekst renderingshierarki, som kun vil være dit, kan dette være dit fundament, fordi det eneste, det giver, er et værktøj til virtualisering af DOM.
Surplus
Den virtuelle DOM er måske ikke for alle. Det optager plads, så hvis dine manipulationer ikke er alt for komplekse, kan du lige så godt lede dine instruktioner direkte videre til den officielle DOM. Surplus-biblioteket gør netop dette. Det tager alles foretrukne markup JSX og kompilerer det til noget kode, der vil manipulere den rigtige DOM. Som de siger i reklamebranchen, så er der ingen mellemmand. Ingen diffing. Intet hemmeligt ekstra lag. Bare ren manipulation af den rigtige DOM. Hvis din kode er enkel og direkte nok til kun at gøre nogle få ting ved DOM’en, hvorfor så bekymre sig om den virtuelle distraktion?
RE:DOM
En anden mulighed for dem, der ikke ønsker at investere hukommelse i en virtuel DOM, er et lillebitte bibliotek (2 KB) kaldet RE:DOM. RE:DOM indeholder nogle grundlæggende rutiner, hvormed du kan oprette alle dine tags og komponenter med nogle få simple JavaScript-opkald. Syntaksen er meget tættere på CSS, så du kan specificere ret udførlige tags med ID’er og klasser med blot et par tastetryk. Dine “mindre end”- (<) og “større end”- (>)-taster vil takke dig.
Mithril
Det er ikke alle alternativerne, der er små og minimalistiske. Mithril kan i denne sammenhæng kaldes et “mellemstort” framework, selv om det kun vejer omkring 8 KB. Hele denne kode opbygger en virtuel DOM med en effektiv opdateringsmekanisme ligesom de andre, men den leveres også med et standardiseret sæt værktøjer til håndtering af mange af standardudfordringerne såsom routing og XMLHttpRequest-opkald. Projektdesignerne ønsker, at Mithril-projekter skal være relativt standardiserede, og de mener, at tilføjelsen af denne kode til hovedbiblioteket øger standardiseringen. Hvis det ikke er nok, skubber de også til nogle standardformater og idiomatiske strukturer.
Bobril
Hvis du kan lide React’s virtuelle DOM og stateful-komponenter, og du kan lide at programmere i TypeScript, så kan Bobril eller dens Angular-venlige fætter ngBobril måske være lige sagen. Rammerne er konsekvent meget hurtigere end enten React eller Angular i nogle af benchmarks, måske på grund af de hurtigere diff-algoritmer og den manglende understøttelse af isomorfisk JavaScript. Der er også shorthand-funktioner til CSS-manipulation og et komplet tilstandshåndteringslag, BobX, hvis du har brug for det.
Marko
Hvis du har brugt noget tid på at byde på Pez-dispensere eller andre samlerobjekter, har du oplevet kraften i Marko, en slank, hurtig ramme, som eBay deler via en open source-licens. Den pæneste del er måske en meget let templating-syntaks, der på en smart måde fjerner det meste af det overskydende fedt fra HTML, så strukturen er defineret af indrykning og ikke meget andet. Og renderingsmotoren er meget hurtig og er i stand til at køre udførlige konstellationer af dansende DIV’er, der opdateres hurtigere end 60fps.
Svelte
Din standardwebramme leveres med en compiler og et downloadet bibliotek, der på køretid håndterer det, som compileren producerer. Den totrins-proces giver mulighed for meget udførlig kode til den pris, at man skal vente på, at runtime-biblioteket hentes og analyseres, hver gang siden åbnes. Svelte-kompileren slipper for denne kompleksitet ved at spytte tæt på rent JavaScript ud, som næsten er klar til at køre på egen hånd, om end kun i nogle af de nyere browsere (f.eks. Chrome, Firefox, Opera og IE10). Det er en smart arkitektonisk gambit, der giver meget lette websteder, der bruger meget lidt hukommelse.
Inferno
Inferno er en anden ramme, der er skabt til at gøre meget af det, som React gør, men med en mindre download og en hurtigere køretid. Det opnår meget af dette ved at smide den udførlige syntetiske begivenhedsmekanisme væk og kun koncentrere sig om de mest essentielle som onClick. Mange andre dele af API’et er ens, hvis ikke det samme, hvilket gør det relativt nemt at flytte din kode over, hvis den ikke har brug for hændelsesoptimeringslaget.
Preact
En af de mindste af React-afkommerne er Preact, en hyldest, der tilbyder de fleste af de mest værdifulde funktioner som et virtuelt DOM og sofistikerede komponenter, men fjerner de syntetiske hændelseshåndteringsmekanismer og noget af props-arveringen. Mens Inferno kun forsøger at implementere de vigtigste begivenheder som onClick, gider Preact ikke forsøge at gøre noget med begivenhederne, så du må forlade dig på browserens native addEventListener. Ved at udelade funktioner, der ikke tilføjer meget (efter deres mening), gør de deres download endnu mindre. Det er lidt af en afvejning, fordi benchmarks viser, at Preact er en smule langsommere end Inferno. Selvfølgelig kan din applikation være anderledes, og din kilometertal kan variere. Hvis du virkelig har brug for ren kompatibilitet med React, er der endda et bibliotek (preact-compat), der løser de fleste problemer under build.
Hapi
Mange frameworks ankommer i en enkelt klump. Hapi er mere en samling af plug-ins, en konstellation af snesevis af kodestykker, som du kan blande ind i din stak, som du finder det passende. Autentifikation, autorisering og logning er opgaver, som kan løses med et vilkårligt antal muligheder. Hvis du opbygger en mikrotjenestearkitektur fuld af API’er, vil det standardiserede Swagger-plugin automatisk generere Swagger-dokumentationen fra din grundkode.
Koa
Sommetider har du brug for en ret kompleks samling af rutiner, der jonglerer med indkommende anmodninger og oversætter dem til flere ændringer, hvoraf nogle af dem er udførlige. Koa er designet til at gøre organiseringen af alt dette arbejde en smule enklere. Dens hemmelighed er, at den forvandler de callback-funktioner, der normalt dominerer JavaScript, til et sæt asynkrone funktioner, der affyres, når tiden er inde. De indlejrede spaghetti-callbackstacks bliver forvandlet til noget lidt renere.
Nest
En anden mulighed for at tæmme kompleksiteten af serveren kommer fra Nest-holdet, som tilbyder en arkitektur fyldt med controllere, pipes og providers med nogle vagter, interceptors og undtagelsesfiltre smidt ind for at holde orden. Rammerne er moderne og klar til at håndtere GraphQL- og microserviceforespørgsler lige fra starten.
Drupal, WordPress og Rails
Frameworks, der er bygget i JavaScript, og som kører oven på Node.js, fylder det psykologiske centrum i webudviklingsverdenen i disse dage. Men det kan være en fejl at ignorere den tidligere generation, der er bygget på PHP, et fundament, der er hurtigere end nogensinde før, nu hvor det også har en just-in-time compiler ligesom JavaScript. Og Ruby og dets Rails-framework fungerer fortsat som hjørnestenene i klippefaste websteder.
Den sidste generation er kampskadet og velafprøvet af mere end et årti med kontinuerlig udvikling og arbejde. Der er sofistikerede designere, som kan lave temaer og skins til appsene. Der er en god chance for, at nogen allerede har bygget modulerne med den funktionalitet, du har brug for. Så før du udforsker et smart Node.js framework, bør du overveje, om en af de gamle kendinge allerede kan gøre meget, hvis ikke alt det, du har brug for.
Vanilla JS
Du kan måske se det som en ondskabsfuld graver eller måske en satire på niveau med “Kejserens nye klæder”, men det er svært at argumentere for dens succes. Vanilla JS er et websted, der praler med, at dets framework bruges på flere websteder end “jQuery, Prototype JS, MooTools, YUI og Google Web Toolkit-kombineret”. Dette er måske eller måske ikke sandt i betragtning af udbredelsen af jQuery, men lad os grine af det brændte. Webstedet kommer også med en sød lille selector, der lader dig bundle et brugerdefineret arkiv af forskellige komponenter som Math, DOM, closures eller regulære udtryk. Uanset hvad du vælger, er resultatet et ufatteligt nul bytes langt. Prøv at slå den!
Pointen med vittigheden er, at det nogle gange giver mening bare at bruge et par af standardelementerne i JavaScript og springe ekstramaterialet over. Biblioteker og frameworks som jQuery eller React begyndte til dels på grund af de vanvittige forskelle mellem browserne. Mange af disse forskelle er forsvundet takket være standardiseringen.
Vanilla JS-tilhængerne konfronterer naturligvis ikke det faktum, at forkortede funktioner som $() ikke blot er praktiske, de sparer også plads i vores egen kode. Men hvis du kun skal bruge document.getElementById lejlighedsvis, er det måske ligegyldigt. Hvis du kun skal tilføje et par funktioner til din webside, og disse funktioner skal udføre nogle få grundlæggende ting, er almindelig vanilla JavaScript måske den hurtigste ramme for dig.