Utility desktop-applikasjoner h\u00f8rer fortiden til fordi alt kan gj\u00f8res i en nettleser. Applikasjoner som m\u00e5 bruke API-er p\u00e5 lavere niv\u00e5 som ikke er tilgjengelige i nettleseren, blir ogs\u00e5 skrevet ved hjelp av nettlesermotorer og -spr\u00e5k fordi det gj\u00f8r dem enklere \u00e5 vedlikeholde.<\/p>\n
Mobilapplikasjoner kan lett erstattes av verkt\u00f8y som brukes til nett<\/a> utvikling - se React<\/a> Innf\u00f8dt<\/strong>, NativeScript. I tillegg har vi PWA, som enkelt \"imiterer\" driften av mobilapplikasjoner. I tillegg kan komponenter som driver en applikasjon skrevet i Vue<\/a><\/strong> eller React<\/strong> enkelt kan dele ulike kode<\/a> elementer mellom plattformer. <\/p>\n Vi m\u00e5 innr\u00f8mme \u00e9n ting - nettapplikasjoner er for tiden et kraftverk som det vil v\u00e6re vanskelig \u00e5 f\u00e5 ned p\u00e5 bakkeplan. Som bruker ser jeg meg selv bruke dem praktisk talt overalt: kommunisere via Slack, bruke en kodeditor, lage presentasjoner eller til og med skrive en bloggartikkel.<\/p>\n Det er vanskelig \u00e5 forutsi hva som vil skje om noen \u00e5r. WebAssembly er p\u00e5 vei inn, og det vil gj\u00f8re det mulig oss<\/a> \u00e5 flytte applikasjoner som krever mer komplekse beregninger inn i nettleserverdenen. Ett faktum forblir imidlertid uendret - det er virkelig vanskelig \u00e5 finne et hinder for \u00e5 bygge med bruk av webteknologier en slik applikasjon som vi bare kan dr\u00f8mme om. <\/p>\n La oss g\u00e5 tilbake til fortiden et \u00f8yeblikk, f\u00f8r de f\u00f8rste mer betydningsfulle webrammeverkene dukket opp, og applikasjoner ble utviklet p\u00e5 en tvingende n\u00f8dvendig m\u00e5te. Hver interaktive mekaniker p\u00e5 en side ble h\u00e5ndtert manuelt og var ansvarlig for en bestemt handling.<\/p>\n Det beste eksemplet er jQuery-biblioteket, som p\u00e5 den tiden var en av de mest popul\u00e6re l\u00f8sningene for h\u00e5ndtering av enkle hendelser. Med hjelp av det ble ulike rullegardinmenyer, overganger, animasjoner, kalkulatorer og lignende mekanikk implementert.<\/p>\n Det er verdt \u00e5 nevne at man allerede den gang oppdaget problemer i mer komplekse applikasjoner - p\u00e5 steder der ulike, uavhengige deler for eksempel m\u00e5tte reagere p\u00e5 et klikk eller en inntasting. De fleste applikasjoner hadde ikke en eksplisitt tilstand, og ble i stedet reddet av for eksempel attributtene til elementene eller klassene de hadde.<\/p>\n P\u00e5 den tiden var det klart at den n\u00e5v\u00e6rende tiln\u00e6rmingen manglet reaktivitet - en strukturert m\u00e5te for komponenter \u00e5 kommunisere med hverandre p\u00e5 og dele f.eks. tilstand eller ulike hendelser, noe som gjorde applikasjonene enklere \u00e5 vedlikeholde og gjorde det mulig \u00e5 gi en god brukeropplevelse til en lav kostnad.<\/p>\n Etter hvert begynte de f\u00f8rste frontend-rammeverkene \u00e5 dukke opp i horisonten, med sikte p\u00e5 \u00e5 strukturere arkitekturen for mer komplekse applikasjoner.<\/p>\n Disse rammeverkene var hovedsakelig basert p\u00e5 MVC-m\u00f8nsteret - noen foreslo en mer manuell tiln\u00e6rming, som Backbone.js, mens andre, som Knockout.js, koblet seg til toveis data<\/a> bindende.<\/p>\n Likevel kan man f\u00f8le at det var vanskeligere \u00e5 skrive applikasjonen, at det krevde mye mer koding, og at det ikke n\u00f8dvendigvis ga de resultatene som var tiltenkt eller kompenserte for den tiden som gikk tapt i applikasjonsutviklingen.<\/p>\n Hovedgrunnen til at det \u00e5 finne den gylne middelvei i JS<\/a> \u00f8kosystemet var vanskelig, var at det var litt av en raritet blant velkjente programmeringsspr\u00e5k<\/a> som for lengst har funnet sin vei.<\/p>\n Og jeg vil ikke dvele her p\u00e5 n\u00f8yaktig hvilke stier som fulgte utviklingen av forskjellige rammer gjennom historien. Det er imidlertid viktig \u00e5 merke seg en ting - modningstiden for JS-\u00f8kosystemet i nettleserne var ikke lett og sto overfor mange pr\u00f8velser.<\/p>\n Dette er den eneste grunnen til at vi i dag kan bygge webapplikasjoner og utvikle dem p\u00e5 en veldig enkel og smertefri m\u00e5te.<\/p>\n I stedet for \u00e5 kaste med kj\u00f8tt, slik det er vanlig p\u00e5 Internett, la oss ta en titt p\u00e5 begge bibliotekene, samle informasjon om dem og sammenligne dem - b\u00e5de i teori og praksis.<\/p>\n MERK: Beskrivelsen av mekanismer som fungerer i Vue <\/strong>refererer spesifikt til versjon 2. Versjon 3 introduserer mange viktige endringer, men er ikke en reell konkurrent til React<\/strong> for \u00f8yeblikket, om ikke bare p\u00e5 grunn av modenhet - Vue 3 utgivelsesdato: 18. september 2020.<\/p>\n La oss f\u00e5 \u00e9n ting p\u00e5 det rene - n\u00e5r du graver dypere i begge bibliotekene, ser du at det faktisk er flere likheter enn forskjeller. Hvis vi ser bort fra hvordan bibliotekene brukes som s\u00e5dan - begge har veldig like konsepter for hvordan de fungerer. Begge er drevet av et lignende \u00f8kosystem, og bruken av dem er ikke diametralt forskjellig.<\/p>\n Djevelen ligger i detaljene - jo oftere vi bruker et verkt\u00f8y, desto st\u00f8rre ulemper med de ulike l\u00f8sningene legger vi merke til. Et godt eksempel her kan v\u00e6re toveis databinding, som oftest brukes i Vue<\/strong> som en v-modellegenskap: Den gj\u00f8r ofte ting enklere, tar seg av mange ting automatisk og krever ikke at man koder inn ekstra st\u00f8tte for endring av verdier.<\/p>\n Det finnes imidlertid tilfeller der vi spesifikt m\u00e5 spore et endringsfors\u00f8k og reagere deretter, og i slike tilfeller tvinger de v-modellbaserte komponentene oss ofte til \u00e5 rote med andre Vue<\/strong> mekanikk som beregnede egenskaper, noe som gj\u00f8r at den oppn\u00e5dde effekten ofte ser mye d\u00e5rligere ut enn med en manuell tiln\u00e6rming;<\/p>\n Et annet interessant aspekt er JSX, som er en \"vagant\" m\u00e5te \u00e5 lage mal for gjengitt innhold ved hjelp av React<\/strong>. Det er ulike meninger om dette i utviklermilj\u00f8et.<\/p>\n Ut fra mine observasjoner ser det ut til at utviklere som bruker andre milj\u00f8er enn JS, f.eks. PHP<\/a> eller C#, er mer tilb\u00f8yelige til \u00e5 bruke malvisninger p\u00e5 en m\u00e5te som Vue<\/strong> gj\u00f8r det.<\/p>\n For \u00e5 oppsummere - maler kjent fra Vue<\/strong> gj\u00f8r det mulig \u00e5 definere visninger p\u00e5 en sv\u00e6rt tydelig og elegant m\u00e5te, mens Reacts JSX gj\u00f8r det mulig \u00e5 bygge dem i mange tilfeller raskere, skreddersydd til spesifikke behov og krever ofte mindre kode for \u00e5 bygge ulike strukturer;<\/p>\n La oss ogs\u00e5 se p\u00e5 \u00f8kosystemene til disse to verkt\u00f8yene. I prinsippet kan vi si at de ikke skiller seg fra hverandre p\u00e5 noe punkt. Det er en grunn til at begge kalles biblioteker - de gir et minimum av st\u00f8tte for reaktive webapplikasjoner.<\/p>\n Mens resten, som er knyttet til kommunikasjon med API<\/a>, dataflyt, UI-komponenter som brukes rundt forskjellige undersider, er de s\u00e5kalte leverand\u00f8rene - biblioteker hentet utenfra, som m\u00e5 knyttes riktig til prosjekt<\/a>. Det er litt som i Lego-verdenen: Hvis du vil bygge en sammenhengende helhet, m\u00e5 du sette den sammen av sm\u00e5, individuelle klosser.<\/p>\n Denne allegorien refererer til nettopp vedlagte komponenter, som er kraften i applikasjoner som er laget med React<\/strong> eller Vue<\/strong>;<\/p>\n En viktig ting, spesielt for folk som ikke har s\u00e5 mye erfaring med JS-milj\u00f8et, er hvor lett det er \u00e5 komme inn i et bestemt bibliotek. Med andre ord - verkt\u00f8yets kompleksitet, som best\u00e5r av den direkte tiden du trenger \u00e5 bruke p\u00e5 \u00e5 forst\u00e5 mekanikken.<\/p>\n Jeg tror \u00e9n ting m\u00e5 sl\u00e5s fast her - n\u00e5r det gjelder Vue<\/strong>er det mye enklere. Vi har toveis databinding, vi har en elegant spesifisert mal som er til forveksling lik l\u00f8sninger i andre spr\u00e5k, f.eks. twig, og til slutt - vi slipper \u00e5 l\u00e6re oss teorier om hvordan de enkelte krokene fungerer og i hvilke tilfeller spesifikke mekanikker m\u00e5 brukes.<\/p>\n Det er ikke akkurat et godt valg \u00e5 f\u00f8lge folkemeningen. Et godt skritt p\u00e5 veien mot \u00e5 ta en god beslutning er imidlertid \u00e5 analysere hva folk som har hatt kontakt med disse bibliotekene, sier.<\/p>\n Og ja... stjerner p\u00e5 github <\/a> kan v\u00e6re en indikator p\u00e5 hvor mye lokalsamfunnet i et bestemt bibliotek er involvert i utviklingen av det, hvordan det oppfattes av utviklere og om de er interessert i hvor det er p\u00e5 vei. Ingeni\u00f8rer<\/a> som har et bestemt repository som stjerne, f\u00e5r ofte varsler om nye utgivelser eller kodeendringer, noe som betyr at de har direkte kjennskap til biblioteket.<\/p>\n Antall stjerner p\u00e5 github b\u00f8r imidlertid ikke ses p\u00e5 som et orakel - ikke alle utviklere som liker et verkt\u00f8y, vil legge igjen et merke - i stedet vil jeg ta det som et tegn p\u00e5 ren lidenskap som utviklere har for et bestemt \u00e5pen kildekode-prosjekt.<\/p>\n Google Trends <\/a> er en velkjent tjeneste som gj\u00f8r det mulig \u00e5 studere interessen for bestemte temaer over tid. Selv om det ikke er en rasjonell indikator p\u00e5 kvalitet eller bruk, kan det gi alle slags analyser.<\/p>\n Det er lett \u00e5 se at forl\u00f8pet de siste fem \u00e5rene har v\u00e6rt ganske likt n\u00e5r det gjelder sammenligningen av de to hovedpersonene i dagens artikkel. Den grunnleggende konklusjonen som kan trekkes fra diagrammet, er at React<\/strong> er h\u00f8yere n\u00e5r det gjelder s\u00f8kepopularitet i forhold til motstanderen.<\/p>\n For \u00e5 gj\u00f8re det klart - \u00e5 ligge p\u00e5 topp i Google Trends betyr ikke at et bibliotek er bedre. Det handler om popularitet, som jeg nevnte tidligere - sannsynligvis har flere h\u00f8rt om dette verkt\u00f8yet, det kan ha vekket mer interesse blant CTO-er<\/a>, programvareutviklere<\/a> <\/strong>eller folk som bare \u00f8nsker \u00e5 l\u00e6re seg et bestemt verkt\u00f8y.<\/p>\n Gjenspeiles denne grafen i virkeligheten? Til en viss grad, ja. Generelt sett - blant de spurte i unders\u00f8kelsen er det flere som har mer eller mindre sofistikerte kunnskaper om React<\/strong> enn Vue<\/strong>. Hvilke meninger kan du f\u00e5 ved \u00e5 snakke med disse menneskene? Jeg vil pr\u00f8ve \u00e5 skissere dette i neste avsnitt.<\/p>\n Staten JS\u00a0<\/a> er et nettsted som hvert \u00e5r gjennomf\u00f8rer sp\u00f8rreunders\u00f8kelser blant folk som jobber med JavaScript-relatert teknologi. M\u00e5let er \u00e5 samle informasjon fra utviklere om hvordan de ser p\u00e5 verkt\u00f8yene de jobber med til daglig.<\/p>\n Sp\u00f8rsm\u00e5lene dekker individuelle verkt\u00f8y for ulike form\u00e5l - f.eks. verkt\u00f8y som brukes p\u00e5 front-end og back-end, men ogs\u00e5 verkt\u00f8y for testing, applikasjonstilstandsstyring osv. Hvert av disse sp\u00f8rsm\u00e5lene er ikke et enkelt ja\/nei-svar, nettstedet stiller en rekke sp\u00f8rsm\u00e5l om selve verkt\u00f8yet, interesser, erfaringer og en samlet evaluering som koker ned til setningen \"Vil du bruke dette verkt\u00f8yet i fremtidige prosjekter?\"<\/p>\n P\u00e5 selve nettstedet kan du gj\u00f8re mange analyser, sammenligne relevante verkt\u00f8y og noen ganger finne ut om mindre kjente biblioteker som begynner \u00e5 gj\u00f8re det bra i JS-verdenen, og som blir stadig mer popul\u00e6re samtidig som de har en h\u00f8y \"happiness to use\"-rate. Jeg oppfordrer deg til \u00e5 bla gjennom innholdet p\u00e5 dette nettstedet.<\/p>\n La oss oppsummere avsnittet med statistikk. \u00c5 analysere ulike typer grafer kan ofte v\u00e6re et sv\u00e6rt godt alternativ for \u00e5 sammenligne ulike aspekter ved et gitt tema. Det er imidlertid viktig \u00e5 v\u00e6re klar over at det ikke n\u00f8dvendigvis er det smarteste \u00e5 f\u00f8lge folk flest. I stedet kan du ta en informert beslutning ved \u00e5 bruke noen av l\u00e6rdommene fra diagramanalyser.<\/p>\n Tidligere nevnte jeg den lavere terskelen for \u00e5 komme inn p\u00e5 Vue<\/strong> - Det gj\u00f8r at du kan fokusere litt raskere p\u00e5 selve utviklingen av applikasjonen, bruke verkt\u00f8yet og redusere tiden som trengs for \u00e5 bli kjent med milj\u00f8et, mekanikken og ulike brukstilfeller til et minimum.<\/p>\n Generelt er jeg av den oppfatning at Vue<\/strong> er mer egnet for personer som enn\u00e5 ikke har jobbet med frontend-biblioteker. Det vil helt sikkert gi deg en mer oppmuntrende m\u00e5te \u00e5 f\u00e5 tilfredsstillende resultater p\u00e5 kort tid.<\/p>\n La oss imidlertid si det h\u00f8yt - mangelen p\u00e5 kunnskap om spr\u00e5ket der vi bruker spesifikke verkt\u00f8y vil skade oss f\u00f8r eller senere. Det er et ubetydelig element for enkle ting, men etter hvert som kompleksiteten i de opprettede applikasjonene \u00f8ker, vil det bli vanskeligere og vanskeligere \u00e5 bygge applikasjoner p\u00e5 en anstendig m\u00e5te uten god kunnskap om JavaScript<\/a>.<\/p>\n Jeg sikter egentlig ikke til det \u00e5 kunne skrive noen sofistikerte funksjoner, for denne delen kan i stor grad erstattes av f.eks. leverand\u00f8rer. Jeg sikter til noen vanlige feil som kan gj\u00f8res i spr\u00e5ket, og at man ikke er klar over at den feilaktige oppf\u00f8rselen ikke skyldes bruken av biblioteket, men bruken av spr\u00e5ket. Den vanligste feilen som manifesterer seg her, er den s\u00e5kalte uforanderligheten - det vil si kunnskapen om referansemekanismen i JavaScript.<\/p>\n Jeg kan ikke foresl\u00e5 hvilket bibliotek som er best for utviklere som er mer eller mindre kjent med JavaScript. Men \u00e9n ting vet jeg - hvis du vil f\u00e5 et inntrykk av hvordan utvikling med begge verkt\u00f8yene ser ut \"fra innsiden\", b\u00f8r du pr\u00f8ve \u00e5 skrive programmer i hvert av dem. Dette vil gi deg en id\u00e9, slik at du kan se hvilke mekanismer som appellerer mer til deg og hva som er et bedre valg for deg.<\/p>\n Som jeg nevnte tidligere - begge bibliotekene drives av lignende \u00f8kosystemer, og har lignende syn p\u00e5 \u00e5 bygge applikasjoner med sm\u00e5 komponenter. Begge bibliotekene gj\u00f8r det bra - det er ingen indikasjoner p\u00e5 at noen av dem vil forsvinne i n\u00e6r fremtid. F\u00f8lgelig vil jobbtilbudene i begge forbli p\u00e5 et lignende niv\u00e5.<\/p>\n Konklusjonen er enkel - bruk det som passer deg, samle erfaring og evaluer. Dette vil hjelpe deg med \u00e5 utvikle en rasjonell tiln\u00e6rming til om det er bedre \u00e5 bruke det ene eller det andre biblioteket i et bestemt prosjekt. Pr\u00f8v ogs\u00e5 \u00e5 eksperimentere - ingenting l\u00e6rer deg s\u00e5 mye som feilene du har gjort tidligere.<\/p>\n Det er ingen hemmelighet at det ikke finnes noen gylden middelvei som er den beste l\u00f8sningen for et bestemt prosjekt. Spesielt p\u00e5 frontend-siden blir verkt\u00f8yene som brukes til \u00e5 bygge applikasjoner, fort gamle, og det er ofte vanskelig \u00e5 finne seg til rette i de nyeste trendene.<\/p>\n Valg av teknologi er imidlertid ikke, eller b\u00f8r i det minste ikke v\u00e6re, et sp\u00f8rsm\u00e5l om hva som passer inn i dagens trender. I stedet b\u00f8r vi rette det mot spesifikke forventninger og antakelser om applikasjonen vi skal bygge. Hvert av de sammenlignede bibliotekene har sine styrker og svakheter, som sammen med bruksomr\u00e5det vil gj\u00f8re det mulig for oss \u00e5 ta det mest fornuftige valget.<\/p>\n Et interessant alternativ kan vise seg \u00e5 v\u00e6re teknologisammendrag fra store selskaper, som ofte beskriver deres use-cases, hvordan utviklingen av store applikasjoner gikk eller g\u00e5r, og hvilke feil de har gjort tidligere. Kanskje finner vi blant dem tilfeller som er spesielt interessante i forbindelse med valg av bibliotek for et bestemt prosjekt.<\/p>\n De funksjonene vi b\u00f8r ta hensyn til for \u00e5 velge riktig verkt\u00f8y for applikasjonen som skal bygges, er: tiden det tar \u00e5 utvikle applikasjonen, hvor enkelt det er \u00e5 vedlikehold av applikasjoner<\/a>, kompleksiteten i applikasjonen og utviklernes erfaring med bruk av spesifikke biblioteker.<\/p>\n Det er utviklerne som tilbringer mest tid i de verkt\u00f8yene jeg sammenligner, og det er de som kan gi de beste r\u00e5dene og hjelpe deg med \u00e5 ta det beste valget i den store mengden av biblioteker. Det er under applikasjonsutviklingen at man ser de ulike problemene som oppst\u00e5r direkte som f\u00f8lge av valg av teknologi, og har best oversikt over hvilke ting som undergraver bruken av et bestemt verkt\u00f8y for bestemte funksjoner.<\/p>\n Som jeg nevnte tidligere - begge bibliotekene ser ikke ut til \u00e5 forsvinne fra marked<\/a>i hvert fall ikke de n\u00e6rmeste \u00e5rene. I stedet for \u00e5 ta beslutninger basert p\u00e5 statistikk og meninger Presenter for dem hva som forventes av s\u00f8knaden, hvor lang tid vi har p\u00e5 oss til \u00e5 levere den, og gi dem mulighet til \u00e5 utveksle meninger om hva de synes om begge l\u00f8sningene f\u00f8r vi tar den endelige avgj\u00f8relsen.<\/p>\n Internett-kriger er som regel - eller kanskje i alle tilfeller - meningsl\u00f8se. Det vil alltid v\u00e6re noen som hardnakket vil hevde at deres valg er bedre, uten \u00e5 komme med noen rasjonelle argumenter som bekrefter deres beslutning.<\/p>\n I stedet for \u00e5 la oss blinde av spesifikke valg - la oss fokusere p\u00e5 analyse, pr\u00f8ve \u00e5 trekke passende konklusjoner og bruke dem til \u00e5 justere eller forkaste en spesifikk l\u00f8sning.<\/p>\n Akkurat som tittelen antyder - jeg har ikke til hensikt \u00e5 utpeke noe bestemt bibliotek som en kur mot alle smerter. I stedet presenteres noen hypoteser, og de sterke og svake sidene ved begge bibliotekene avdekkes. Jeg har ogs\u00e5 gitt noen r\u00e5d om hva man b\u00f8r se etter n\u00e5r man skal velge mellom dem, slik at man kan ta en klok beslutning og ikke la seg lede av trender eller tilfeldige personer p\u00e5 internett.<\/p>\n Hvert verkt\u00f8y kan passe godt nok til prosjektets behov. Ingen av dem vil forsvinne fra markedet i l\u00f8pet av de kommende \u00e5rene. Begge har sterke milj\u00f8er og en viss modenhet, noe som viser oss at de gj\u00f8r det ganske bra.<\/p>\n Det endelige valget ligger i dine hender. Men hvis du er i tvil eller bare \u00f8nsker \u00e5 diskutere saken din med The Codest<\/a> - Ta gjerne kontakt med oss!<\/p>\n Les mer om dette:<\/b><\/p>\n Derfor b\u00f8r du (sannsynligvis) bruke Typescript<\/a><\/p>\n Hvordan unng\u00e5r man \u00e5 drepe et prosjekt med d\u00e5rlig kodingspraksis?<\/a><\/p>\nDet store smellet i internettvirkeligheten <\/h2><\/p>\n
F\u00f8rste skritt mot velkjente rammeverk<\/h2><\/p>\n
Grunnleggende informasjon og en liten sammenligning<\/h2><\/p>\n
![\"React](\"\/app\/uploads\/2024\/05\/tabela-art-.jpg\")
<\/p>\nHva sier statistikken?<\/h2><\/p>\n
![\"vue](\"\/app\/uploads\/2024\/05\/bez-tytulu.png\")
<\/p>\n![\"react](\"\/app\/uploads\/2024\/05\/aaaaaabbb.png\")
<\/p>\n![\"Rangering](\"\/app\/uploads\/2024\/05\/1.png\")
<\/p>\n![\"tilstanden](\"\/app\/uploads\/2024\/05\/2.png\")
<\/p>\n![\"React](\"\/app\/uploads\/2024\/05\/3.png\")
<\/p>\nBeste valg for utviklere<\/h2><\/p>\n
Beste valg for CTO<\/a> <\/h2><\/p>\n
\nav ulike personer fra internett - kanskje et bedre alternativ er \u00e5 bare snakke med utviklerne.<\/p>\nKonklusjoner<\/h2><\/p>\n