Har vi stadig brug for JavaScript-rammer?

Som webudvikler prøver jeg regelmæssigt at vurdere min værktøjskasse og afgøre, om jeg kan undvære dette eller det andet værktøj. For nylig har jeg undersøgt, hvor let det er at udvikle en kompleks frontend-applikation uden en frontend-ramme.

Hvad er en JavaScript-ramme?

Kort sagt er en JavaScript-ramme et værktøj, som du kan udnytte til at udvikle avancerede webapplikationer, især SPA'er.

Tilbage i dagen implementerede webudviklere frontend-logik ved at stole stærkt på vanille JS og jQuery. Men da frontend-applikationer blev mere og mere komplekse, steg værktøjerne til at imødekomme denne kompleksitet.

De rammer, der er populære i dag, har et par kernefæller. De fleste frontendrammer / biblioteker, fra Vue til React, giver en kombination af følgende:

  • Synkronisering af tilstand og visning
  • Routing
  • Et skabelonsystem
  • Genanvendelige komponenter

Er rammer stadig nødvendige?

Det afhænger af, hvordan du understreger det nødvendige ord. Mange vil hævde, at frontend-rammer ikke er og aldrig har været nødvendige. Men de er meget nyttige værktøjer.

Så spørgsmålet er: er rammer i dagens jQuery? Vil de problemer, de løser, blive løst ved ændringer som dem i DOM API?

Det er svært at sige, men fremskridt inden for native JS, webkomponentspecifikationen og let konfigurerbare build-værktøjer, har gjort det at udvikle et SPA uden en ramme så let som det nogensinde har været.

For at undersøge dette yderligere udviklede jeg en enkelt sides applikation, der kun anvendte vanilje JavaScript, oprindelige webkomponenter og pakke. Der var en håndfuld faldgruber og vanskeligheder undervejs, der fremhævede styrkerne i JS-rammer.

På samme tid, når jeg passerede de indledende forhindringer, blev jeg overrasket over, hvor simpelt det var at oprette en enkelt sides applikation med bare vanilla JS.

Oversigt

Ansøgningen er enkel. Det er en opskriftsapplikation med grundlæggende CRUD-muligheder. Brugeren kan oprette, redigere, slette, foretage og filtrere en liste med opskrifter.

StartskærmenOpret opskriftsskærm

komponenter

Oprettelse af en webkomponent er også ligetil. Du opretter en klasse, der udvider HTMLElement (eller HTMLParagraphElement og så videre), og bruger derefter klassen til at definere et brugerdefineret element.

Du kan også gøre brug af livscykluskroge, f.eks. ConnectCallback, disconnectedCallback, attributeChangedCallback.

Routing

Routingen til opskriftsapplikationen er også ganske enkel. I betragtning af en navigationshændelse satte jeg applikationens indhold til den tilsvarende webkomponent.

Oprindeligt brugte jeg en npm-pakke kaldet Vanilla JS Router. Med browserhistorik-API'et er det ikke så komplekst at implementere din egen i mindre end 100 kodelinjer! Bemærk: Jeg implementerer ikke rigtig kompliceret logik såsom rutevagter.

Det er en hurtig oversigt. Jeg vil holde denne artikel til en rimelig længde. Jeg skriver muligvis et opfølgende indlæg med en mere grundig forklaring af applikationen. Jeg implementerede nogle sjove funktioner såsom uendelig rulning, en brugerdefineret træk og slip uploader og mere!

Tilbagevirkende kraft

Efter at have oprettet applikationen tog jeg nogen tid at tænke på fordele og ulemper ved hele processen fra start til slut. Jeg starter med de dårlige nyheder.

Ulemper

Specifikationen er stadig i flux

Webkomponentspecifikationen er både gammel og ny. Det har eksisteret meget længere, end jeg oprindeligt havde troet. Webkomponenter blev introduceret af Alex Russell på Fronteers Conference 2011 for første gang. Imidlertid er push bag webkomponenter virkelig vokset i det sidste år eller to. Som sådan er der stadig en masse uro i spec. For eksempel er HTML-import blevet forladt, skønt de fleste af dokumentationen / ressourcerne stadig henviser til dem.

Test

Der er ikke mange dedikerede ressourcer til test af native webkomponenter derude. Der er nogle lovende værktøjer såsom skatejs ssr og webkomponenttesten fra Polymer. Men disse værktøjer er virkelig beregnet til brug med deres respektive biblioteker. Dette giver nogle vanskeligheder ved brug med indbyggede webkomponenter.

Skift detektion

Det er utroligt at have et underliggende system, der automatisk holder synspunktet synkroniseret med datamodellen. Det var det, der trak mange til vinkelformede og andre rammer i første omgang.

At holde tilstand synkroniseret med visningen er ikke så svært i lille skala. Men det kan komme ud af kontrol meget hurtigt, og du finder dig selv tilføje en masse begivenhedslyttere og forespørgselsvalgere.

The Shadow DOM

Jeg er virkelig revet med skyggen DOM. På den ene side elsker jeg ideen om indkapsling. Det er et fornuftigt designmønster, gør din stilkaskade mere håndterbar, forenkler dine bekymringer og så videre. Dog giver det også problemer, når du ønsker, at visse ting skal trænge ind i den indkapsling (f.eks. Et delt stilark), og der er løbende debatter om den bedste måde at gøre dette på.

Generering af DOM-strukturer

En del af storslåelsen af ​​rammer / biblioteker som Angular and React er, at de er mestre i deres DOMain. Det vil sige, de er fremragende til effektiv gengivelse og gengivelse af strukturer i DOM. Fra bloggen Angular University:

Angular genererer ikke HTML og overfører det derefter til browseren for at få det analyseret, i stedet genererer Angular direkte DOM-datastrukturer!

Vinklet gengiver for eksempel i modsætning til jQuery DOM-datastrukturer direkte. Det vil sige i stedet for at videresende HTML til browseren, der skal analyseres, og derefter gengives til DOM-datastrukturer. Dette er mere performant, da det fjerner det parsingstrin. Den virtuelle DOM er også ganske nyttig, da de forhindrer dig i at gengive alt igen, hver gang du har brug for at opdatere din visning.

Fordele

På den anden side er der nogle ubestridelige fordele ved at udvikle applikationer på denne måde:

Bundle størrelse

Det endelige produkt kan være (vægt på dåse) så meget mindre og mere kompakt end noget, der er udviklet med moderne rammer. For eksempel var den endelige opbygning af min fuldt udstyrede opskriftsapp mindre end halvdelen af ​​størrelsen på en frisk kantet bygning.

Vinkelformet bundtestørrelseOpskrifter app bundt

Bemærk: Dette er de opdaterede, optimerede bundstørrelser.

forståelse

Hvis du kun virkelig har udviklet dig med en ramme og dens CLI, kan det være en god øvelse at oprette en webapplikation uden ekstra værktøjer. Som en person, der ønsker at opnå et vist niveau af mestring (i det omfang det er muligt) af webudvikling, har det været vigtigt for mig at få en mere praktisk oplevelse med build-værktøjer, browser-API'er, designmønstre osv.

Ydeevne

Hvad disse front-end rammer og biblioteker laver bag kulisserne er forbløffende. Du kan dog betale en ydelsespris, hvis du beslutter at bruge nogen af ​​dem; der er ikke sådan noget som en gratis frokost. Der er mange potentielle ydelser, der trækkes i skala: Uanset om det er spildt gengivelser, overflødige lyttere, dyb genstands-sammenligning eller unødvendige og store DOM-manipulationer. Du kan skære ud meget kompleksitet her ved at implementere ting fra bunden.

Vinkel- og reaktionsholdene synes at være opmærksomme på disse faldgruber og har leveret ting som shouldUpdate-metodeoverskridelser og onPush ChangeDetection som et middel til yderligere at optimere ydelsen.

Enkelhed og kodeejerskab

Du tager en risiko, hver gang du indtaster tredjepartskode. Denne risiko reduceres med afprøvede biblioteker / rammer, men aldrig rigtig elimineret. Hvis du kan slippe af sted med at skrive kode selv eller med dit team, kan du reducere denne risiko og vedligeholde en kodebase, som du kender ind og ud.

Noter og interessante spidser

Jeg arbejdede sammen med Parcel. Det føltes lidt mere begrænset end Webpack til tider, når jeg forsøgte at arbejde omkring visse kanttilfælde, men jeg fandt, at 'zero config' taglinjen for at holde sandt for det meste.

Det er også klart for mig, at mange etiketter Reagerer et 'bibliotek' og viser en 'progressiv' ramme. Mens jeg forstår årsagerne til dette, tror jeg, at React, Vue og Angular løser mange af de samme problemer. Således overvejer jeg dem alle sammen under betegnelsen 'rammer'.

Hvorfor ikke bruge stencil eller polymer? Jeg ville undgå brugen af ​​pakker, biblioteker og rammer så meget som muligt. Jeg ønskede at se, hvor langt webstandarder var steget for at imødekomme moderne udvikling (bortset fra at bygge værktøjer).

Der er jeg sikker på, at mange andre måder at udvikle en SPA eller front-end-applikation generelt uden en større ramme eller bibliotek, jeg prøvede en måde her, og jeg ville meget gerne høre om andre!

Resumé

En stor heuristik for beslutningen om at bruge eller ikke bruge en ramme er det, jeg kalder "tipvinklen". Der kommer et punkt, når din applikation vokser, hvor du ender med at oprette dine egne rammer for at genbruge funktionalitet og struktur. For eksempel har du en masse formularer, og du vil oprette genanvendelig logik til reaktiv validering.

Hvis du ender på dette tidspunkt, er du nødt til at beslutte, om det er værd at investere tiden i at oprette systemer for at udføre det, du hurtigt kan udrette med et ramme eller bibliotek. Der vil være forskellige vippepunkter, afhængigt af hvad dine tidsbegrænsninger eller budgetbegrænsninger er, men rammer er stadig meget relevante i betragtning af de rigtige scenarier.

Når det er sagt, vil meget af, hvad rammer gør, sandsynligvis blive lettere at gøre med mindre biblioteker og / eller indfødt kode, når tiden går. Tag min ansøgning som et eksempel. På samme tid, hvis de store rammer og biblioteker forbliver alsidige, kan de forme, tilpasse sig og holde sig rundt. Hvis ikke, kan de ende som jQuery - et værktøj fra fortiden for det meste.

Konklusion

Afslutningsvis er der lovende måder at udvikle komplekse frontend-applikationer uden rammer. Specifikationen for ting som webkomponenter er dog stadig under udvikling, og der er kinks, der skal udarbejdes. Rammerne gør stadig en masse fantastiske ting og kan gøre udviklingen meget glattere.

På dette tidspunkt, så vidt jeg kan fortælle, opvejer fordelene ved at bruge en ramme ofte ulemperne. Hvis rammer imidlertid ikke begynder at løse nye problemer og fortsætter med at udvikle sig, vil de til sidst forsvinde.

Ressourcer