Utility desktop-applikationer h\u00f8rer fortiden til, fordi alt kan g\u00f8res i en browser. Faktisk skrives applikationer, der skal bruge API'er p\u00e5 lavere niveau, som ikke er tilg\u00e6ngelige i browseren, ogs\u00e5 ved hj\u00e6lp af browsermotorer og -sprog, fordi det g\u00f8r dem lettere at vedligeholde.<\/p>\n
Mobilapplikationer kan nemt erstattes af v\u00e6rkt\u00f8jer, der bruges til web<\/a> udvikling - se React<\/a> Indf\u00f8dt<\/strong>NativeScript. Derudover har vi PWA, som let \"efterligner\" driften af mobilapplikationer. Derudover kan komponenter, der driver en applikation skrevet i Vue<\/a><\/strong> eller React<\/strong> kan nemt dele forskellige Kode<\/a> elementer mellem platforme. <\/p>\n Vi m\u00e5 indr\u00f8mme \u00e9n ting - webapplikationer er i \u00f8jeblikket et kraftcenter, som det bliver sv\u00e6rt at f\u00e5 ned p\u00e5 jorden. Som bruger ser jeg mig selv bruge dem praktisk talt overalt: kommunikere via Slack, bruge en kodeditor, lave pr\u00e6sentationer eller endda skrive en blogartikel.<\/p>\n Det er sv\u00e6rt at forudsige, hvad der vil ske om et par \u00e5r. WebAssembly kommer i spil, og det vil give mulighed for os<\/a> til at flytte applikationer, der kr\u00e6ver mere komplekse beregninger, ind i browserverdenen. En kendsgerning forbliver dog u\u00e6ndret - det er virkelig sv\u00e6rt at finde en hindring for at bygge en s\u00e5dan applikation, som vi kun kan dr\u00f8mme om, med brug af webteknologier. <\/p>\n Lad os g\u00e5 tilbage til fortiden et \u00f8jeblik, f\u00f8r de f\u00f8rste mere betydningsfulde webframeworks dukkede op, og applikationer blev udviklet p\u00e5 en tvingende m\u00e5de. Hver interaktiv mekaniker p\u00e5 en side blev h\u00e5ndteret manuelt og var ansvarlig for en bestemt handling.<\/p>\n Det bedste eksempel, der kan n\u00e6vnes, er jQuery-biblioteket - p\u00e5 det tidspunkt en af de mest popul\u00e6re l\u00f8sninger til h\u00e5ndtering af simple begivenheder. Med dets hj\u00e6lp blev forskellige drop-down-menuer, overgange, animationer, regnemaskiner og lignende mekanik implementeret.<\/p>\n Det er v\u00e6rd at n\u00e6vne, at man allerede dengang bem\u00e6rkede problemer i mere komplekse applikationer - p\u00e5 steder, hvor forskellige, uafh\u00e6ngige dele f.eks. skulle reagere p\u00e5 et rigtigt klik eller p\u00e5 at skrive noget. De fleste applikationer havde ikke en eksplicit tilstand, men blev i stedet reddet af f.eks. elementernes attributter eller de klasser, de havde.<\/p>\n P\u00e5 det tidspunkt stod det klart, at den nuv\u00e6rende tilgang manglede reaktivitet - en struktureret m\u00e5de for komponenter at kommunikere med hinanden og dele f.eks. deres tilstand eller forskellige h\u00e6ndelser, hvilket gjorde applikationer lettere at vedligeholde og gav dem mulighed for at give en god brugeroplevelse til en lav pris.<\/p>\n Med tiden begyndte de f\u00f8rste front-end frameworks at dukke op i horisonten med det form\u00e5l at strukturere arkitekturen for mere komplekse applikationer.<\/p>\n Disse frameworks var hovedsageligt baseret p\u00e5 MVC-m\u00f8nsteret - nogle foreslog en mere manuel tilgang, s\u00e5som Backbone.js, mens andre, s\u00e5som Knockout.js, koblede sig p\u00e5 tovejs data<\/a> bindende.<\/p>\n Alligevel kunne man f\u00f8le, at det var sv\u00e6rere at skrive applikationen, at det kr\u00e6vede meget mere kodning, og at det ikke n\u00f8dvendigvis gav de \u00f8nskede resultater eller kompenserede for den tid, der gik tabt i applikationsudviklingen.<\/p>\n Hoved\u00e5rsagen til at finde den gyldne middelvej i JS<\/a> \u00d8kosystemet var sv\u00e6rt, fordi det var lidt af en sj\u00e6ldenhed blandt velkendte programmeringssprog<\/a> der for l\u00e6ngst har fundet deres vej.<\/p>\n Og jeg vil ikke her dv\u00e6le ved pr\u00e6cis, hvilke veje der har ledsaget udviklingen af forskellige frameworks gennem historien. Det er dog vigtigt at bem\u00e6rke \u00e9n ting - modningstiden for JS-\u00f8kosystemet i browserne var ikke let og stod over for mange pr\u00f8velser.<\/p>\n Det er den eneste grund til, at vi i dag kan bygge webapplikationer og udvikle dem p\u00e5 en meget nem og smertefri m\u00e5de.<\/p>\n I stedet for at smide om os med k\u00f8d og blod, som man plejer at g\u00f8re p\u00e5 internettet, s\u00e5 lad os se p\u00e5 begge biblioteker, samle information om dem og sammenligne dem - b\u00e5de i teori og praksis.<\/p>\n BEM\u00c6RK: Beskrivelsen af mekanismer, der fungerer i Vue <\/strong>henviser specifikt til version 2. Version 3 introducerer en masse v\u00e6sentlige \u00e6ndringer, men er ikke en reel konkurrent til React<\/strong> i \u00f8jeblikket, om ikke andet s\u00e5 p\u00e5 grund af dens modenhed - Vue 3 udgivelsesdato: 18. september 2020.<\/p>\n Lad os f\u00e5 \u00e9n ting p\u00e5 det rene - n\u00e5r man graver dybere ned i begge biblioteker, kan man se, at der faktisk er flere ligheder end forskelle. Hvis man ser bort fra, hvordan man bruger bibliotekerne som s\u00e5dan, s\u00e5 har de begge meget ensartede koncepter for, hvordan de fungerer. Begge er drevet af et lignende \u00f8kosystem, og deres brug er ikke diametralt forskellig.<\/p>\n Dj\u00e6vlen ligger i detaljen - jo oftere vi bruger et v\u00e6rkt\u00f8j, jo st\u00f8rre ulemper ved dets forskellige l\u00f8sninger opdager vi. Et godt eksempel her kan v\u00e6re tovejs databinding, som oftest bruges i Vue<\/strong> som en v-model-egenskab: Det g\u00f8r ofte tingene lettere, tager sig af mange ting automatisk og kr\u00e6ver ikke kodning af yderligere underst\u00f8ttelse af \u00e6ndring af v\u00e6rdier.<\/p>\n Der er dog tilf\u00e6lde, hvor vi har brug for specifikt at spore et \u00e6ndringsfors\u00f8g og reagere i overensstemmelse hermed, og i s\u00e5 fald tvinger de v-modelbaserede komponenter os ofte til at rode rundt med andre Vue<\/strong> mekanik s\u00e5som beregnede egenskaber, hvilket g\u00f8r, at den opn\u00e5ede effekt ofte ser meget v\u00e6rre ud end med en manuel tilgang;<\/p>\n Et andet interessant aspekt er JSX, som er s\u00e5dan en \"vagant\" m\u00e5de at skabelonere gengivet indhold p\u00e5 ved hj\u00e6lp af React<\/strong>. Det er der forskellige meninger om i udviklermilj\u00f8et.<\/p>\n Ud fra mine observationer ser det ud til, at udviklere, der bruger andre milj\u00f8er end JS, f.eks. PHP<\/a> eller C#, er mere tilb\u00f8jelige til at bruge skabelonvisninger p\u00e5 en m\u00e5de, der Vue<\/strong> g\u00f8r.<\/p>\n For at opsummere - skabeloner kendt fra Vue<\/strong> g\u00f8r det muligt at definere visninger p\u00e5 en meget klar og elegant m\u00e5de, mens React's JSX i mange tilf\u00e6lde g\u00f8r det muligt at opbygge dem hurtigere, skr\u00e6ddersyet til specifikke behov og ofte kr\u00e6ver mindre kode for at opbygge forskellige strukturer;<\/p>\n Lad os ogs\u00e5 se p\u00e5 \u00f8kosystemerne i disse to v\u00e6rkt\u00f8jer. I princippet kan vi sige, at de ikke adskiller sig p\u00e5 noget som helst. Der er en grund til, at de begge kaldes biblioteker - de giver det absolutte minimum af st\u00f8tte til reaktive webapplikationer.<\/p>\n Mens resten, der er relateret til kommunikation med API<\/a>, data flow, UI-komponenter, der bruges omkring forskellige undersider, er de s\u00e5kaldte vendors - biblioteker hentet udefra, som skal knyttes korrekt til projekt<\/a>. Det er lidt ligesom Lego-verdenen: Hvis man vil bygge en sammenh\u00e6ngende helhed, m\u00e5 man s\u00e6tte den sammen af enkelte, sm\u00e5 klodser.<\/p>\n Denne allegori henviser til pr\u00e6cist vedh\u00e6ftede komponenter, som er kraften i applikationer, der er skabt med React<\/strong> eller Vue<\/strong>;<\/p>\n En vigtig ting, is\u00e6r for folk, der ikke er s\u00e5 erfarne i JS-milj\u00f8et, er indgangsniveauet til et bestemt bibliotek. Med andre ord - v\u00e6rkt\u00f8jets kompleksitet, der best\u00e5r af den direkte tid, du skal bruge p\u00e5 at forst\u00e5 dets mekanik.<\/p>\n Jeg tror, at \u00e9n ting skal siges helt klart her - i tilf\u00e6ldet med Vue<\/strong>Det er meget enklere. Vi har tovejs databinding, vi har en elegant specificeret skabelon, der til forveksling ligner l\u00f8sninger i andre sprog, f.eks. twig, og endelig - vi har ingen hovedpine for\u00e5rsaget af at l\u00e6re om teorier om driften af individuelle kroge og tilf\u00e6lde, hvor specifikke mekanikker skal bruges.<\/p>\n Det er ikke ligefrem et godt valg at g\u00e5 direkte efter m\u00e6ngdens stemme. Men et godt skridt i retning af at tr\u00e6ffe en god beslutning er at analysere, hvad folk, der har interageret med disse biblioteker, siger.<\/p>\n Og ja... stjerner p\u00e5 github <\/a> kan v\u00e6re en indikator for, hvor meget lokalsamfundet i et bestemt bibliotek er involveret i dets udvikling, hvordan det opfattes af udviklere, og om de er interesserede i, hvor det er p\u00e5 vej hen. Ingeni\u00f8rer<\/a> der har et bestemt repository som stjerne, f\u00e5r ofte meddelelser om nye udgivelser eller kode\u00e6ndringer, hvilket betyder, at de har direkte kendskab til biblioteket.<\/p>\n Antallet af stjerner p\u00e5 github skal dog ikke ses som et orakel - ikke alle udviklere, der kan lide et v\u00e6rkt\u00f8j, vil efterlade et m\u00e6rke - i stedet vil jeg tage det som et tegn p\u00e5 ren passion, som udviklere har for et bestemt open source-projekt.<\/p>\n Google Trends <\/a> er en velkendt tjeneste, der giver os mulighed for at studere interessen for specifikke emner over tid. Selv om det ikke er en rationel indikator for kvalitet eller brug, kan det give alle slags analyser.<\/p>\n Det er let at se, at forl\u00f8bet af de sidste 5 \u00e5r er blevet skitseret ret ens, n\u00e5r det drejer sig om at sammenligne de to hovedpersoner i dagens artikel. Den grundl\u00e6ggende konklusion, der kan drages af diagrammet, er, at React<\/strong> er h\u00f8jere, n\u00e5r det g\u00e6lder s\u00f8gepopularitet i forhold til sin modstander.<\/p>\n For at g\u00f8re det klart - at ligge \u00f8verst i Google Trends betyder ikke, at et bibliotek er bedre. Det handler om publikums popularitet, som jeg n\u00e6vnte f\u00f8r - sandsynligvis har flere mennesker h\u00f8rt om dette v\u00e6rkt\u00f8j, det kan have vakt st\u00f8rre interesse blandt CTO'er<\/a>, softwareudviklere<\/a> <\/strong>eller folk, der bare gerne vil l\u00e6re et bestemt v\u00e6rkt\u00f8j.<\/p>\n Afspejler denne graf sig i virkeligheden? Til en vis grad, ja. Generelt set - blandt de adspurgte personer er der flere, der udviser en varieret og sofistikeret viden om React<\/strong> end Vue<\/strong>. Hvilke meninger kan du f\u00e5 ved at tale med disse mennesker? Jeg vil fors\u00f8ge at skitsere dette i n\u00e6ste afsnit.<\/p>\n Staten JS\u00a0<\/a> er et websted, der hvert \u00e5r unders\u00f8ger folk, der arbejder med JavaScript-relaterede teknologier. M\u00e5let er at indsamle oplysninger fra udviklere om, hvordan de ser p\u00e5 de v\u00e6rkt\u00f8jer, de arbejder med til daglig.<\/p>\n Sp\u00f8rgsm\u00e5lene d\u00e6kker individuelle v\u00e6rkt\u00f8jer til forskellige form\u00e5l - f.eks. v\u00e6rkt\u00f8jer, der bruges i front-end og back-end, men ogs\u00e5 v\u00e6rkt\u00f8jer til test, styring af applikationsstatus osv. Hvert af disse sp\u00f8rgsm\u00e5l er ikke et simpelt ja\/nej-svar, siden stiller en r\u00e6kke sp\u00f8rgsm\u00e5l om selve v\u00e6rkt\u00f8jet, interesser, erfaringer og en samlet evaluering, der kan koges ned til s\u00e6tningen \"Ville du bruge dette v\u00e6rkt\u00f8j i fremtidige projekter?\"<\/p>\n Selve sitet giver dig mulighed for at lave en masse analyser, sammenligne relevante v\u00e6rkt\u00f8jer og nogle gange finde ud af om mindre kendte biblioteker, der begynder at klare sig godt i JS-verdenen og bliver mere og mere popul\u00e6re, mens de nyder godt af en h\u00f8j \"happiness to use\"-rate. Jeg vil oprigtigt opfordre dig til at gennemse indholdet p\u00e5 denne side.<\/p>\n Lad os opsummere afsnittet med statistik. At analysere forskellige typer grafer kan ofte v\u00e6re en rigtig god mulighed for at sammenligne forskellige aspekter af givne emner. Det er dog vigtigt at tage h\u00f8jde for, at det ikke n\u00f8dvendigvis er det smarteste at f\u00f8lge m\u00e6ngdens stemme. I stedet kan du tr\u00e6ffe en informeret beslutning ved at bruge nogle af de erfaringer, du har gjort dig med analyser af diagrammer.<\/p>\n Tidligere n\u00e6vnte jeg den lavere adgangst\u00e6rskel til Vue<\/strong> - Det giver dig faktisk mulighed for at fokusere lidt hurtigere p\u00e5 den faktiske udvikling af applikationen ved at bruge v\u00e6rkt\u00f8jet og reducere den tid, der er n\u00f8dvendig for at s\u00e6tte sig ind i milj\u00f8et, mekanikken og de forskellige brugssituationer, til et minimum.<\/p>\n Generelt er min holdning, at Vue<\/strong> er mere velegnet til folk, der endnu ikke har besk\u00e6ftiget sig med front-end-biblioteker. Det vil helt sikkert give dig mulighed for p\u00e5 en mere opmuntrende m\u00e5de at f\u00e5 tilfredsstillende resultater p\u00e5 kort tid.<\/p>\n Men lad os sige det h\u00f8jt - manglende kendskab til det sprog, vi bruger specifikke v\u00e6rkt\u00f8jer p\u00e5, vil skade os f\u00f8r eller siden. Det er et ubetydeligt element for enkle ting, men efterh\u00e5nden som kompleksiteten af de oprettede applikationer stiger, bliver det mere og mere vanskeligt at bygge applikationer p\u00e5 en anst\u00e6ndig m\u00e5de uden godt kendskab til JavaScript<\/a>.<\/p>\n Jeg taler ikke om at kunne skrive nogle sofistikerede funktioner, for den del kan i h\u00f8j grad erstattes af f.eks. leverand\u00f8rer. Jeg taler om nogle almindelige fejl, der kan beg\u00e5s i sproget, og at man ikke er klar over, at den forkerte opf\u00f8rsel ikke skyldes brugen af biblioteket, men brugen af sproget. Den mest almindelige fejl, der manifesterer sig her, er den s\u00e5kaldte uforanderlighed - det vil sige kendskabet til referencemekanismen i JavaScript.<\/p>\n Jeg er ikke i stand til at foresl\u00e5, hvilket bibliotek der er bedst for udviklere, der er mere eller mindre fortrolige med JavaScript. Men jeg ved \u00e9n ting - hvis du vil have en reel id\u00e9 om, hvordan udvikling med begge v\u00e6rkt\u00f8jer ser ud \"indefra\" - s\u00e5 pr\u00f8v at skrive programmer i hver af dem. Det vil give dig en id\u00e9 og give dig mulighed for at se, hvilke mekanismer der tiltaler dig mest, og hvad der er et bedre valg for dig.<\/p>\n Som jeg n\u00e6vnte tidligere, er begge biblioteker drevet af lignende \u00f8kosystemer og har samme syn p\u00e5 opbygning af applikationer med sm\u00e5 komponenter. Begge biblioteker klarer sig godt - der er intet, der tyder p\u00e5, at nogen af dem vil forsvinde i den n\u00e6rmeste fremtid. Derfor vil jobtilbuddene i dem begge forblive p\u00e5 et lignende niveau.<\/p>\n Konklusionerne er enkle - brug det, der passer dig; saml erfaring og evaluer. Det vil hj\u00e6lpe dig med at udvikle en rationel tilgang til, om det er bedre at bruge det ene eller det andet bibliotek i et bestemt projekt; pr\u00f8v ogs\u00e5 at eksperimentere - intet er s\u00e5 l\u00e6rerigt som de fejl, der er beg\u00e5et i fortiden.<\/p>\n Det er ikke nogen hemmelighed, at der ikke findes en gylden middelvej, som er den bedste l\u00f8sning til et bestemt projekt. Is\u00e6r p\u00e5 front-end bliver de v\u00e6rkt\u00f8jer, der bruges til at bygge applikationer, hurtigt gamle, og det er ofte sv\u00e6rt at finde fodf\u00e6ste i de nyeste trends.<\/p>\n Men valget af teknologi er ikke, eller b\u00f8r i hvert fald ikke v\u00e6re, et sp\u00f8rgsm\u00e5l om, hvad der passer ind i de aktuelle trends. I stedet b\u00f8r vi rette det mod specifikke forventninger og antagelser om den applikation, vi skal bygge. Hvert af de sammenlignede biblioteker har sine styrker og svagheder, som matchet med brugssagen vil give os mulighed for at tr\u00e6ffe det mest fornuftige valg.<\/p>\n En interessant mulighed kan vise sig at v\u00e6re teknologisammendrag fra store virksomheder, som ofte beskriver deres use-cases, hvordan udviklingen af store applikationer foregik eller foreg\u00e5r, og hvilke fejl de har beg\u00e5et i fortiden. M\u00e5ske finder vi blandt dem cases, som er s\u00e6rligt interessante i forbindelse med valg af bibliotek til et bestemt projekt.<\/p>\n De funktioner, vi b\u00f8r overveje for at v\u00e6lge de rigtige v\u00e6rkt\u00f8jer til den applikation, der skal bygges, er: tiden for applikationsudvikling, hvor let det er at vedligeholdelse af applikationer<\/a>, applikationens kompleksitet og udviklernes erfaring med at bruge specifikke biblioteker.<\/p>\n Udviklere er de mennesker, der bruger mest tid p\u00e5 de v\u00e6rkt\u00f8jer, jeg sammenligner, og det er dem, der kan give de bedste r\u00e5d og hj\u00e6lpe dig med at tr\u00e6ffe det bedste valg i det store sammenst\u00f8d mellem biblioteker. Det er under applikationsudviklingen, at man ser de forskellige problemer, der opst\u00e5r direkte af valget af teknologi, og har det bedste overblik over, hvilke ting der underminerer brugen af et bestemt v\u00e6rkt\u00f8j til bestemte funktioner.<\/p>\n Som jeg n\u00e6vnte tidligere - begge biblioteker ser ikke ud til at forsvinde fra marked<\/a>I hvert fald ikke inden for de n\u00e6ste par \u00e5r. I stedet for at tr\u00e6ffe beslutninger baseret p\u00e5 statistikker og meninger Pr\u00e6senter for dem, hvad der forventes af ans\u00f8gningen, hvilken tid vi har til at levere den, og giv mulighed for en l\u00f8s udveksling af meninger om, hvad de synes om begge l\u00f8sninger, f\u00f8r vi tr\u00e6ffer den endelige beslutning.<\/p>\n Internetkrige er som regel - eller m\u00e5ske i alle tilf\u00e6lde - meningsl\u00f8se. Der vil altid v\u00e6re folk, som st\u00e6digt vil h\u00e6vde, at deres valg er bedre, uden at give nogen rationelle argumenter, der bekr\u00e6fter deres beslutning.<\/p>\n I stedet for at lade os forbl\u00e6nde af specifikke valg - lad os fokusere p\u00e5 analyse, fors\u00f8ge at drage passende konklusioner og bruge dem til at justere eller forkaste en specifik l\u00f8sning.<\/p>\n Som titlen antyder, er det ikke min hensigt at udr\u00e5be et bestemt bibliotek som en kur mod enhver smerte. I stedet pr\u00e6senteres et par hypoteser, og begge bibliotekers st\u00e6rke og svage sider afsl\u00f8res. Jeg har givet nogle r\u00e5d om, hvad man skal kigge efter, n\u00e5r man v\u00e6lger mellem dem, s\u00e5 man kan tr\u00e6ffe en klog beslutning og ikke lade sig lede af trends eller tilf\u00e6ldige mennesker fra internettet.<\/p>\n Hvert v\u00e6rkt\u00f8j kan passe godt nok til projektets behov. Ingen af dem vil forsvinde hurtigt fra markedet i de kommende \u00e5r. Begge har st\u00e6rke f\u00e6llesskaber og en hel del modenhed, hvilket viser os, at disse to klarer sig ganske godt.<\/p>\n Det endelige valg ligger i dine h\u00e6nder. Men hvis du er i tvivl eller bare gerne vil diskutere din sag med Codest<\/a> - Du er velkommen til at kontakte os!<\/p>\n L\u00e6s mere om det:<\/b><\/p>\n Hvorfor du (sandsynligvis) b\u00f8r bruge Typescript<\/a><\/p>\n Hvordan dr\u00e6ber man ikke et projekt med d\u00e5rlig kodningspraksis?<\/a><\/p>\nBig bang i internet-virkeligheden <\/h2><\/p>\n
F\u00f8rste skridt mod velkendte rammer<\/h2><\/p>\n
Grundl\u00e6ggende information og en lille sammenligning<\/h2><\/p>\n
![\"React](\"\/app\/uploads\/2024\/05\/tabela-art-.jpg\")
<\/p>\nHvad siger statistikkerne?<\/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![\"tilstand](\"\/app\/uploads\/2024\/05\/2.png\")
<\/p>\n![\"React](\"\/app\/uploads\/2024\/05\/3.png\")
<\/p>\nBedste valg for udviklere<\/h2><\/p>\n
Bedste valg til CTO<\/a> <\/h2><\/p>\n
\naf forskellige mennesker fra internettet - m\u00e5ske er det en bedre mulighed at tale med udviklerne.<\/p>\nKonklusioner<\/h2><\/p>\n