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 klare mig uden 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 på dagen ville webudviklere implementere frontend-logik ved at stole stærkt på vanille JS og jQuery. Men da applikationer i frontend blev mere og mere komplekse, steg værktøjerne til at imødekomme denne kompleksitet.

De rammer, der er populære i dag, har nogle få fællesfællesskaber. De fleste frontend-rammer / 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. De er dog meget nyttige værktøjer.

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

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

For at undersøge dette yderligere udviklede jeg en enkelt sideapplikation, der kun bruger vanilje JavaScript, native Web Components og Parcel. Der var en håndfuld faldgruber og vanskeligheder undervejs, der fremhævede styrkerne ved JS-rammerne.

På samme tid blev jeg overrasket over, hvor enkelt det var at oprette en enkelt sideapplikation med bare vanille JS, når jeg bestod de indledende forhindringer.

Oversigt

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

Komponenter

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

Du kan også gøre brug af livscykluskroge, såsom connectedCallback, disconnectedCallback, attributeChangedCallback.

Routing

Routingen til applikationen til opskrifter er også ret enkel. I betragtning af en navigationsbegivenhed indstillede jeg applikationens indhold til den tilsvarende webkomponent.

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

Det er et hurtigt resume. Jeg vil holde denne artikel i en rimelig længde. Jeg skriver muligvis et opfølgende indlæg med en mere detaljeret forklaring af ansøgningen. Jeg implementerede nogle sjove funktioner som uendelig rulning, en brugerdefineret træk og slip-uploader og meget mere!

Tilbagevirkende kraft

Efter at have oprettet applikationen tog jeg mig tid til 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 bevægelse

Specifikationen for webkomponenter 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 skubbet bag webkomponenter virkelig vokset det sidste år eller to. Som sådan er der stadig meget uro i spec. For eksempel er HTML-import blevet opgivet, selvom det meste af dokumentationen / ressourcerne stadig henviser til dem.

Testning

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

Skift detektion

At have et underliggende system, der automatisk holder synet synkroniseret med datamodellen, er utroligt. Det er, hvad der tiltrak mange til kantede og andre rammer i første omgang.

At holde tilstanden synkroniseret med udsigten er ikke så vanskelig i lille skala. Men det kan komme ud af kontrol meget hurtigt, og du finder dig selv at tilføje masser af begivenhedslyttere og forespørgselsvælgere.

Shadow DOM

Jeg er virkelig revet over 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 osv. Det giver dog også problemer, når du ønsker, at visse ting skal trænge igennem den indkapsling (såsom 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 pragtværdien af ​​rammer / biblioteker som Angular og React er, at de er mestre i deres DOMain. Det vil sige, de er fremragende til effektivt at gengive og gengive strukturer i DOM. Fra Angular University-bloggen:

Angular genererer ikke HTML og sender den derefter til browseren for at få den analyseret, i stedet genererer Angular DOM-datastrukturer direkte!

Vinklet gengiver f.eks. DOM-datastrukturer direkte i modsætning til jQuery. Det vil sige i stedet for at overføre HTML til browseren, der skal parses, og derefter gengives i DOM-datastrukturer. Dette er mere performant, da det eliminerer dette analyseringstrin. Den virtuelle DOM er også ret nyttig, da de forhindrer dig i at gengive alt, 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:

Bundtstørrelse

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

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

Forståelse

Hvis du kun virkelig har udviklet dig med en ramme og dens CLI, kan det være en god øvelse at lave 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å mere praktisk erfaring med byggeværktøjer, browser-API'er, designmønstre osv.

Ydeevne

Hvad disse frontend rammer og biblioteker laver bag kulisserne er forbløffende. Du kan dog betale en præstationspris, hvis du beslutter at bruge nogen af ​​dem; der er ikke sådan noget som en gratis frokost. Der er mange potentielle ydeevne trækker i målestok: hvad enten det er spildte re-gengivelser, overflødige lyttere, sammenligning af dybe objekter eller unødvendige og store DOM-manipulationer. Du kan skære meget kompleksitet ud her ved at implementere ting fra bunden.

Angular- og React-holdene ser ud til at være opmærksomme på disse faldgruber og har leveret ting som shouldUpdate method overrides og onPush ChangeDetection som et middel til yderligere at optimere ydeevnen.

Enkelhed og kodeejerskab

Du tager en risiko, når du indfører tredjepartskode. Denne risiko reduceres med afprøvede og testede biblioteker / rammer, men fjernes aldrig rigtigt. Hvis du kan komme væk med at skrive kode selv eller med dit team, kan du reducere denne risiko og opretholde en kodebase, som du kender ind og ud.

Noter og interessante godbidder

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

Det er også klart for mig, at mange betegner React som et 'bibliotek' og Vue som 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 udtrykket 'rammer.'

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

Der er sikkert mange andre måder at udvikle en SPA eller frontend-applikation generelt uden en større ramme eller et bibliotek, jeg prøvede en måde her, og jeg vil meget gerne høre om andre!

Resumé

En stor heuristik for beslutningen om at bruge eller ikke bruge en ramme er, hvad jeg kalder "vippepunktet". Der kommer et punkt, når din applikation vokser, hvor du ender med at skabe 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, skal du beslutte, om det er værd at investere tiden i at skabe systemer til at udrette det, du hurtigt kan opnå med en ramme eller et 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, bliver meget af, hvad rammer gør, sandsynligvis lettere at gøre med mindre biblioteker og / eller indbygget 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 ændre sig, tilpasse sig og holde fast. Hvis ikke, kan de ende som jQuery - et fortidens værktøj for det meste.

Konklusion

Afslutningsvis er der lovende måder at udvikle komplekse frontend-applikationer uden rammer på. Specifikationen for ting som webkomponenter udvikler sig stadig, og der er knæk, der skal udarbejdes. Rammerne gør stadig en masse fantastiske ting og kan gøre udviklingen meget glattere.

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

Ressourcer

Vejledning til begyndere: Hvorfor kantet? De største fordele

Bemærk: Dette indlæg er en del af den igangværende Angular for Beginners-serie, her er den komplette serie: Angular For Beginners… blog.angular-university.io Sammenligning med andre rammer - Vue.js

Vue.js - The Progressive JavaScript Framework vuejs.org Optimering af ydeevne - Reager

Internt React anvendelser flere smarte teknikker til at minimere antallet af kostbare DOM operationer kræves for at opdatere ... reactjs.org Web Components

Som udviklere ved vi alle, at det er en god ide at genbruge kode så meget som muligt. Dette har traditionelt ikke været så ... developer.mozilla.org Den dybeste grund til, at der findes moderne JavaScript-rammer

Jeg har set mange, mange mennesker bruger en moderne ramme som React, Angular eller Vue.js blindt. Disse rammer giver ... medium.com Styling-webkomponenter ved hjælp af et delt stilark

Webkomponenter er en forbløffende ny funktion på nettet, der giver udviklere mulighed for at definere deres egne tilpassede HTML-elementer ... www.smashingmagazine.com