Utility desktop-applikationer \u00e4r ett minne blott eftersom allt kan g\u00f6ras i en webbl\u00e4sare. Faktum \u00e4r att applikationer som beh\u00f6ver anv\u00e4nda API:er p\u00e5 l\u00e4gre niv\u00e5 som inte \u00e4r tillg\u00e4ngliga i webbl\u00e4saren ocks\u00e5 skrivs med hj\u00e4lp av webbl\u00e4sarmotorer och spr\u00e5k eftersom det g\u00f6r dem enklare att underh\u00e5lla.<\/p>\n
Mobila applikationer kan l\u00e4tt ers\u00e4ttas av verktyg som anv\u00e4nds f\u00f6r webb<\/a> utveckling - se React<\/a> Inf\u00f6dd<\/strong>, NativeScript. Dessutom har vi PWA, som enkelt \"imiterar\" driften av mobilapplikationer. Dessutom kan komponenter som driver en applikation skriven i Vue<\/a><\/strong> eller React<\/strong> enkelt kan dela med sig av olika kod<\/a> element mellan plattformar. <\/p>\n Vi m\u00e5ste erk\u00e4nna en sak - webbapplikationer \u00e4r f\u00f6r n\u00e4rvarande ett kraftpaket som kommer att bli sv\u00e5rt att f\u00e5 ner p\u00e5 bottenv\u00e5ningen. Som anv\u00e4ndare ser jag mig sj\u00e4lv anv\u00e4nda dem praktiskt taget \u00f6verallt: kommunicera via Slack, anv\u00e4nda en kodredigerare, g\u00f6ra presentationer eller till och med skriva en bloggartikel.<\/p>\n Det \u00e4r sv\u00e5rt att f\u00f6rutsp\u00e5 vad som kommer att h\u00e4nda om n\u00e5gra \u00e5r. WebAssembly \u00e4r p\u00e5 v\u00e4g in i bilden, och det kommer att g\u00f6ra det m\u00f6jligt oss<\/a> att flytta applikationer som kr\u00e4ver mer komplexa ber\u00e4kningar till webbl\u00e4sarv\u00e4rlden. Ett faktum f\u00f6rblir dock of\u00f6r\u00e4ndrat - det \u00e4r verkligen sv\u00e5rt att hitta ett hinder f\u00f6r att med hj\u00e4lp av webbteknik bygga en s\u00e5dan applikation som vi bara kan dr\u00f6mma om. <\/p>\n F\u00f6r att komma till saken - l\u00e5t oss g\u00e5 tillbaka till det f\u00f6rflutna f\u00f6r ett \u00f6gonblick, innan de f\u00f6rsta mer betydande webbramverken d\u00f6k upp och applikationer utvecklades p\u00e5 ett tvingande s\u00e4tt. Varje interaktiv mekanik p\u00e5 en sida hanterades manuellt och var ansvarig f\u00f6r en specifik \u00e5tg\u00e4rd.<\/p>\n Det b\u00e4sta exemplet som kan n\u00e4mnas \u00e4r jQuery-biblioteket - p\u00e5 den tiden en av de mest popul\u00e4ra l\u00f6sningarna f\u00f6r att hantera enkla h\u00e4ndelser. Med dess hj\u00e4lp implementerades olika rullgardinsmenyer, \u00f6verg\u00e5ngar, animationer, kalkylatorer och liknande mekanik.<\/p>\n Det \u00e4r v\u00e4rt att n\u00e4mna att problem i mer komplexa applikationer uppm\u00e4rksammades redan d\u00e5 - p\u00e5 platser d\u00e4r olika, oberoende delar var tvungna att reagera p\u00e5 t.ex. ett riktigt klick eller att skriva n\u00e5got. De flesta applikationer hade inget explicit tillst\u00e5nd, utan r\u00e4ddades ist\u00e4llet av t.ex. elementens attribut eller de klasser de hade.<\/p>\n Vid den tidpunkten stod det klart att den nuvarande metoden saknade reaktivitet - ett strukturerat s\u00e4tt f\u00f6r komponenter att kommunicera med varandra och dela t.ex. sitt tillst\u00e5nd eller olika h\u00e4ndelser, vilket gjorde applikationer enklare att underh\u00e5lla och gjorde det m\u00f6jligt att ge en bra anv\u00e4ndarupplevelse till en l\u00e5g kostnad.<\/p>\n Med tiden b\u00f6rjade de f\u00f6rsta frontend-ramverken dyka upp i horisonten, med m\u00e5let att strukturera arkitekturen f\u00f6r mer komplexa applikationer.<\/p>\n Dessa ramverk var huvudsakligen baserade p\u00e5 MVC-m\u00f6nstret - vissa f\u00f6reslog ett mer manuellt tillv\u00e4gag\u00e5ngss\u00e4tt, till exempel Backbone.js, medan andra, till exempel Knockout.js, kopplade in tv\u00e5v\u00e4gs data<\/a> bindning.<\/p>\n Man kan \u00e4nd\u00e5 tycka att det var sv\u00e5rare att skriva applikationen, att det kr\u00e4vdes mycket mer kodning och att det inte n\u00f6dv\u00e4ndigtvis gav de resultat som var avsedda eller kompenserade f\u00f6r den tid som gick f\u00f6rlorad i applikationsutvecklingen.<\/p>\n Det fr\u00e4msta sk\u00e4let till att hitta den gyllene medelv\u00e4gen i JS<\/a> ekosystemet var sv\u00e5rt var att det var lite av en udda f\u00e5gel bland v\u00e4lk\u00e4nda programmeringsspr\u00e5k<\/a> som f\u00f6r l\u00e4nge sedan har f\u00e5tt sina stigar asfalterade.<\/p>\n Och jag vill inte dr\u00f6ja h\u00e4r p\u00e5 exakt vilka v\u00e4gar som f\u00f6ljde utvecklingen av olika ramar genom historien. Det \u00e4r dock viktigt att notera en sak - mognadstiden f\u00f6r JS-ekosystemet i webbl\u00e4sarna var inte l\u00e4tt och stod inf\u00f6r m\u00e5nga pr\u00f6vningar.<\/p>\n Detta \u00e4r det enda sk\u00e4let till att vi idag kan bygga webbapplikationer och utveckla dem p\u00e5 ett mycket enkelt och sm\u00e4rtfritt s\u00e4tt.<\/p>\n Ist\u00e4llet f\u00f6r att kasta k\u00f6tt, som \u00e4r brukligt p\u00e5 Internet, l\u00e5t oss ta en titt p\u00e5 b\u00e5da biblioteken, samla information om dem och j\u00e4mf\u00f6ra dem - b\u00e5de i teorin och i praktiken.<\/p>\n OBS: Beskrivningen av mekanismer som fungerar i Vue <\/strong>h\u00e4nvisar specifikt till version 2. Version 3 introducerar m\u00e5nga viktiga f\u00f6r\u00e4ndringar, men \u00e4r inte en riktig konkurrent till React<\/strong> just nu, om bara p\u00e5 grund av dess mognad - Vue 3 sl\u00e4ppdatum: 18 september 2020.<\/p>\n L\u00e5t oss g\u00f6ra en sak klar - n\u00e4r du gr\u00e4ver djupare i b\u00e5da biblioteken kan du se att det faktiskt finns fler likheter \u00e4n skillnader. Om man bortser fr\u00e5n s\u00e4ttet att anv\u00e4nda biblioteken som s\u00e5dana - b\u00e5da har mycket liknande begrepp f\u00f6r hur de fungerar. B\u00e5da drivs av ett liknande ekosystem och deras anv\u00e4ndning \u00e4r inte diametralt annorlunda.<\/p>\n \u25cf Dj\u00e4vulen finns i detaljerna - ju oftare vi anv\u00e4nder ett verktyg, desto st\u00f6rre nackdelar med dess olika l\u00f6sningar m\u00e4rker vi. Ett bra exempel h\u00e4r kan vara tv\u00e5v\u00e4gs databindning, som oftast anv\u00e4nds i Vue<\/strong> som en v-modellegenskap: den g\u00f6r ofta saker enklare, tar hand om m\u00e5nga saker automatiskt och kr\u00e4ver inte att man kodar in ytterligare st\u00f6d f\u00f6r att \u00e4ndra v\u00e4rden.<\/p>\n Det finns dock fall d\u00e4r vi specifikt m\u00e5ste sp\u00e5ra ett f\u00f6r\u00e4ndringsf\u00f6rs\u00f6k och reagera d\u00e4refter, och i s\u00e5dana fall tvingar de v-modellbaserade komponenterna oss ofta att r\u00f6ra runt med andra Vue<\/strong> mekanik, t.ex. ber\u00e4kningsegenskaper, vilket g\u00f6r att den uppn\u00e5dda effekten ofta ser mycket s\u00e4mre ut \u00e4n med en manuell metod;<\/p>\n En annan intressant aspekt \u00e4r JSX, som \u00e4r ett \"vagrant\" s\u00e4tt att skapa mallar f\u00f6r renderat inneh\u00e5ll med hj\u00e4lp av React<\/strong>. Det har olika \u00e5sikter i utvecklargemenskapen.<\/p>\n Enligt mina observationer verkar det som om utvecklare som anv\u00e4nder andra milj\u00f6er \u00e4n JS, t.ex. PHP<\/a> eller C#, \u00e4r mer ben\u00e4gna att anv\u00e4nda mallar p\u00e5 ett s\u00e4tt som Vue<\/strong> g\u00f6r.<\/p>\n Sammanfattningsvis - mallar k\u00e4nda fr\u00e5n Vue<\/strong> g\u00f6r det m\u00f6jligt att definiera vyer p\u00e5 ett mycket tydligt och elegant s\u00e4tt, medan React:s JSX g\u00f6r det m\u00f6jligt att bygga dem i m\u00e5nga fall snabbare, skr\u00e4ddarsydda f\u00f6r specifika behov och ofta kr\u00e4ver mindre kod f\u00f6r att bygga olika strukturer;<\/p>\n \u25cf L\u00e5t oss ocks\u00e5 titta p\u00e5 ekosystemen i dessa tv\u00e5 verktyg. I princip kan vi s\u00e4ga att de inte skiljer sig \u00e5t p\u00e5 n\u00e5got s\u00e4tt. B\u00e5da kallas bibliotek av en anledning - de ger ett minimum av st\u00f6d f\u00f6r reaktiva webbapplikationer.<\/p>\n Medan resten, som r\u00f6rde kommunikation med API<\/a>, datafl\u00f6de, UI-komponenter som anv\u00e4nds runt olika undersidor, \u00e4r de s\u00e5 kallade leverant\u00f6rerna - bibliotek som h\u00e4mtas utifr\u00e5n och som m\u00e5ste kopplas p\u00e5 r\u00e4tt s\u00e4tt till projekt<\/a>. Det \u00e4r lite som i Lego-v\u00e4rlden: om man vill bygga en sammanh\u00e4ngande helhet m\u00e5ste man s\u00e4tta ihop den av enskilda, sm\u00e5 klossar.<\/p>\n Denna allegori h\u00e4nvisar till exakt bifogade komponenter, som \u00e4r kraften i applikationer som skapats med React<\/strong> eller Vue<\/strong>;<\/p>\n \u25cf En viktig sak, s\u00e4rskilt f\u00f6r personer som inte \u00e4r s\u00e5 erfarna i JS-milj\u00f6n, \u00e4r niv\u00e5n p\u00e5 intr\u00e4det i ett visst bibliotek. Med andra ord - verktygets komplexitet, som best\u00e5r av den direkta tid du beh\u00f6ver spendera p\u00e5 att f\u00f6rst\u00e5 dess mekanik.<\/p>\n Jag tror att en sak m\u00e5ste s\u00e4gas otvetydigt h\u00e4r - i fallet med Vue<\/strong>\u00e4r det mycket enklare. Vi har tv\u00e5v\u00e4gs databindning, vi har en elegant specificerad mall som \u00e4r f\u00f6rvillande lik l\u00f6sningar i andra spr\u00e5k, t.ex. twig, och slutligen - vi har ingen huvudv\u00e4rk som orsakas av att l\u00e4ra sig om teorier om hur enskilda krokar fungerar och i vilka fall specifika mekaniker m\u00e5ste anv\u00e4ndas.<\/p>\n Att g\u00e5 direkt p\u00e5 folkmassans r\u00f6st \u00e4r inte precis ett bra val. Ett bra steg mot att fatta ett bra beslut \u00e4r dock att analysera vad m\u00e4nniskor som har interagerat med dessa bibliotek s\u00e4ger.<\/p>\n Och ja... stj\u00e4rnor p\u00e5 github <\/a> kan vara en indikator p\u00e5 hur mycket samh\u00e4llet i ett visst bibliotek \u00e4r involverat i dess utveckling, hur det uppfattas av utvecklare och om de \u00e4r intresserade av vart det \u00e4r p\u00e5 v\u00e4g. Ingenj\u00f6rer<\/a> som startar ett visst arkiv f\u00e5r ofta meddelanden om nya utg\u00e5vor eller kod\u00e4ndringar, vilket inneb\u00e4r att de har direkt kunskap om biblioteket.<\/p>\n Antalet stj\u00e4rnor p\u00e5 github ska dock inte ses som ett orakel - inte alla utvecklare som gillar ett verktyg kommer att l\u00e4mna ett m\u00e4rke - utan jag skulle ist\u00e4llet se det som ett tecken p\u00e5 ren passion som utvecklare har f\u00f6r ett visst open source-projekt.<\/p>\n Google Trender <\/a> \u00e4r en v\u00e4lk\u00e4nd tj\u00e4nst som g\u00f6r det m\u00f6jligt f\u00f6r oss att studera intresset f\u00f6r specifika \u00e4mnen \u00f6ver tid. \u00c4ven om det inte \u00e4r en rationell indikator p\u00e5 kvalitet eller anv\u00e4ndning, kan det ge alla typer av analyser.<\/p>\n Det \u00e4r l\u00e4tt att se att de senaste 5 \u00e5rens utveckling har varit ganska likartad n\u00e4r det g\u00e4ller att j\u00e4mf\u00f6ra de tv\u00e5 huvudpersonerna i dagens artikel. Den grundl\u00e4ggande slutsatsen som kan dras fr\u00e5n diagrammet \u00e4r att React<\/strong> \u00e4r h\u00f6gre n\u00e4r det g\u00e4ller s\u00f6kpopularitet i f\u00f6rh\u00e5llande till sin motst\u00e5ndare.<\/p>\n F\u00f6r att vara tydlig - att ligga i topp p\u00e5 Google Trends betyder inte att ett bibliotek \u00e4r b\u00e4ttre. Det handlar om publikens popularitet, som jag n\u00e4mnde tidigare - f\u00f6rmodligen har fler m\u00e4nniskor h\u00f6rt talas om det h\u00e4r verktyget, det kan ha v\u00e4ckt mer intresse bland CTO:er<\/a>, Programvaruutvecklare<\/a> <\/strong>eller personer som bara vill l\u00e4ra sig ett visst verktyg.<\/p>\n St\u00e4mmer detta diagram \u00f6verens med verkligheten? Till viss del, ja. Generellt sett - bland de tillfr\u00e5gade personerna \u00e4r det fler som uppvisar olika sofistikerade kunskaper om React<\/strong> \u00e4n Vue<\/strong>. Vilka \u00e5sikter kan du f\u00e5 genom att prata med dessa m\u00e4nniskor? Jag ska f\u00f6rs\u00f6ka beskriva detta i n\u00e4sta stycke.<\/p>\n Staten JS\u00a0<\/a> \u00e4r en webbplats som varje \u00e5r unders\u00f6ker personer som arbetar med JavaScript-relaterad teknik. M\u00e5let \u00e4r att samla in information fr\u00e5n utvecklare om hur de ser p\u00e5 de verktyg som de arbetar med dagligen.<\/p>\n Fr\u00e5gorna handlar om enskilda verktyg f\u00f6r olika \u00e4ndam\u00e5l - t.ex. verktyg som anv\u00e4nds i frontend och backend, men \u00e4ven verktyg f\u00f6r testning, hantering av applikationstillst\u00e5nd osv. Var och en av dessa fr\u00e5gor \u00e4r inte ett enkelt ja\/nej-svar, utan webbplatsen st\u00e4ller en rad fr\u00e5gor om sj\u00e4lva verktyget, intressen, erfarenheter och en \u00f6vergripande utv\u00e4rdering som kokar ner till meningen \"Skulle du anv\u00e4nda det h\u00e4r verktyget i framtida projekt?\"<\/p>\n Webbplatsen i sig g\u00f6r att du kan g\u00f6ra m\u00e5nga analyser, j\u00e4mf\u00f6ra relevanta verktyg och ibland f\u00e5 reda p\u00e5 mindre k\u00e4nda bibliotek som b\u00f6rjar g\u00f6ra bra ifr\u00e5n sig i JS-v\u00e4rlden, samla popularitet samtidigt som de har en h\u00f6g \"anv\u00e4ndargl\u00e4dje\". Jag uppmuntrar dig verkligen att bl\u00e4ddra igenom inneh\u00e5llet p\u00e5 den h\u00e4r webbplatsen.<\/p>\n L\u00e5t oss sammanfatta avsnittet med statistik. Att analysera olika typer av grafer kan ofta vara ett mycket bra alternativ f\u00f6r att j\u00e4mf\u00f6ra olika aspekter av givna \u00e4mnen. Det \u00e4r dock viktigt att ta h\u00e4nsyn till att det inte n\u00f6dv\u00e4ndigtvis \u00e4r det smartaste att f\u00f6lja folkmassans r\u00f6st. Ist\u00e4llet kan du fatta ett v\u00e4lgrundat beslut med hj\u00e4lp av n\u00e5gra av de l\u00e4rdomar du kan dra av diagramanalyser.<\/p>\n Tidigare n\u00e4mnde jag den l\u00e4gre tr\u00f6skeln f\u00f6r intr\u00e4de till Vue<\/strong> - Det g\u00f6r att du kan fokusera lite snabbare p\u00e5 den faktiska utvecklingen av applikationen, anv\u00e4nda verktyget och minimera den tid som kr\u00e4vs f\u00f6r att bekanta dig med milj\u00f6n, mekaniken och olika anv\u00e4ndningsfall.<\/p>\n Generellt sett \u00e4r min \u00e5sikt att Vue<\/strong> \u00e4r mer l\u00e4mpad f\u00f6r personer som \u00e4nnu inte har arbetat med front-end-bibliotek. Det kommer s\u00e4kert att g\u00f6ra det m\u00f6jligt f\u00f6r dig p\u00e5 ett mer uppmuntrande s\u00e4tt att f\u00e5 tillfredsst\u00e4llande resultat p\u00e5 kort tid.<\/p>\n Men l\u00e5t oss s\u00e4ga det h\u00f6gt - bristen p\u00e5 kunskap om det spr\u00e5k d\u00e4r vi anv\u00e4nder specifika verktyg kommer att skada oss f\u00f6rr eller senare. Det \u00e4r ett f\u00f6rsumbart element f\u00f6r enkla saker, men n\u00e4r komplexiteten i de skapade applikationerna \u00f6kar kommer det att bli sv\u00e5rare och sv\u00e5rare att bygga applikationer p\u00e5 ett anst\u00e4ndigt s\u00e4tt utan god kunskap om JavaScript<\/a>.<\/p>\n Jag syftar egentligen inte p\u00e5 att kunna skriva n\u00e5gra sofistikerade funktioner, eftersom denna del till stor del kan ers\u00e4ttas av t.ex. leverant\u00f6rer. Jag syftar p\u00e5 n\u00e5gra vanliga misstag som kan g\u00f6ras i spr\u00e5ket och att man inte \u00e4r medveten om att det felaktiga beteendet inte beror p\u00e5 anv\u00e4ndningen av biblioteket utan p\u00e5 anv\u00e4ndningen av spr\u00e5ket. Det vanligaste misstaget som manifesterar sig h\u00e4r \u00e4r den s\u00e5 kallade of\u00f6r\u00e4nderligheten - det vill s\u00e4ga kunskapen om referensmekanismen i JavaScript.<\/p>\n Jag kan inte f\u00f6resl\u00e5 vilket bibliotek som \u00e4r b\u00e4ttre f\u00f6r utvecklare som \u00e4r mer eller mindre bekanta med JavaScript. Men jag vet en sak - om du vill ha en verklig uppfattning om hur utveckling med b\u00e5da verktygen ser ut \"fr\u00e5n insidan\" - f\u00f6rs\u00f6k att skriva applikationer i var och en av dem. Detta kommer att ge dig en id\u00e9, s\u00e5 att du kan se vilka mekanismer som tilltalar dig mer och vad som \u00e4r ett b\u00e4ttre val f\u00f6r dig.<\/p>\n Som jag n\u00e4mnde tidigare - b\u00e5da biblioteken drivs av liknande ekosystem och har liknande syn p\u00e5 att bygga applikationer med sm\u00e5 komponenter. B\u00e5da biblioteken g\u00e5r bra - det finns inget som tyder p\u00e5 att n\u00e5got av dem kommer att f\u00f6rsvinna inom en snar framtid. F\u00f6ljaktligen kommer jobberbjudanden i dem b\u00e5da att f\u00f6rbli p\u00e5 en liknande niv\u00e5.<\/p>\n Slutsatserna \u00e4r enkla - anv\u00e4nd det som passar dig, samla erfarenhet och utv\u00e4rdera. Detta kommer att hj\u00e4lpa dig att utveckla ett rationellt f\u00f6rh\u00e5llningss\u00e4tt till om det \u00e4r b\u00e4ttre att anv\u00e4nda det ena eller det andra biblioteket i ett visst projekt. F\u00f6rs\u00f6k ocks\u00e5 att experimentera - ingenting l\u00e4r ut s\u00e5 djupt som de misstag som gjorts i det f\u00f6rflutna.<\/p>\n Det \u00e4r ingen hemlighet att det inte finns n\u00e5gon gyllene medelv\u00e4g som \u00e4r den b\u00e4sta l\u00f6sningen f\u00f6r ett visst projekt. S\u00e4rskilt p\u00e5 frontend-sidan blir de verktyg som anv\u00e4nds f\u00f6r att bygga applikationer snabbt gamla och det \u00e4r ofta sv\u00e5rt att hitta r\u00e4tt i de senaste trenderna.<\/p>\n Valet av teknik \u00e4r dock inte, eller borde \u00e5tminstone inte vara, en fr\u00e5ga om vad som passar in i de aktuella trenderna. Ist\u00e4llet b\u00f6r vi rikta det mot specifika f\u00f6rv\u00e4ntningar och antaganden om den applikation vi ska bygga. Var och en av de j\u00e4mf\u00f6rda biblioteken har sina styrkor och svagheter, som matchade med anv\u00e4ndningsfallet g\u00f6r att vi kan g\u00f6ra det mest rimliga valet.<\/p>\n Ett intressant alternativ kan visa sig vara tekniksammanfattningar fr\u00e5n stora f\u00f6retag, som ofta beskriver sina anv\u00e4ndningsfall, hur utvecklingen av stora applikationer gick eller g\u00e5r och vilka misstag de gjort tidigare. Kanske hittar vi bland dem fall som \u00e4r s\u00e4rskilt intressanta n\u00e4r det g\u00e4ller att v\u00e4lja ett bibliotek f\u00f6r ett visst projekt.<\/p>\n De egenskaper som vi b\u00f6r ta h\u00e4nsyn till f\u00f6r att v\u00e4lja r\u00e4tt verktyg f\u00f6r den applikation som ska byggas \u00e4r: tiden f\u00f6r applikationsutveckling, hur l\u00e4tt det \u00e4r att underh\u00e5ll av applikationer<\/a>, applikationens komplexitet och utvecklarnas erfarenhet av att anv\u00e4nda specifika bibliotek.<\/p>\n Utvecklare \u00e4r de personer som tillbringar mest tid i de verktyg jag j\u00e4mf\u00f6r och det \u00e4r de som kan ge de b\u00e4sta r\u00e5den och hj\u00e4lpa dig att g\u00f6ra det b\u00e4sta valet i den stora krocken av bibliotek. Det \u00e4r under applikationsutvecklingen som man ser de olika problem som uppst\u00e5r direkt av valet av teknik, och har den b\u00e4sta \u00f6verblicken \u00f6ver vilka saker som undergr\u00e4ver anv\u00e4ndningen av ett visst verktyg f\u00f6r vissa funktioner.<\/p>\n Som jag n\u00e4mnde tidigare - b\u00e5da biblioteken verkar inte f\u00f6rsvinna fr\u00e5n marknad<\/a>\u00e5tminstone inte under de n\u00e4rmaste \u00e5ren. Ist\u00e4llet f\u00f6r att fatta beslut baserade p\u00e5 statistik och \u00e5sikter Presentera f\u00f6r dem vad de f\u00f6rv\u00e4ntar sig av applikationen, vilken tid vi har p\u00e5 oss f\u00f6r leverans och ge dem m\u00f6jlighet till ett fritt meningsutbyte om vad de tycker om b\u00e5da l\u00f6sningarna innan vi fattar det slutliga beslutet.<\/p>\n Internetkrig \u00e4r vanligtvis - eller kanske i alla fall - meningsl\u00f6sa. Det kommer alltid att finnas m\u00e4nniskor som envist h\u00e4vdar att deras val \u00e4r b\u00e4ttre utan att ge n\u00e5gra rationella argument som bekr\u00e4ftar deras beslut.<\/p>\n I st\u00e4llet f\u00f6r att f\u00f6rblindas av specifika val - l\u00e5t oss fokusera p\u00e5 analys, f\u00f6rs\u00f6ka dra l\u00e4mpliga slutsatser och anv\u00e4nda dem f\u00f6r att justera eller f\u00f6rkasta en specifik l\u00f6sning.<\/p>\n Precis som titeln antyder - jag har inte f\u00f6r avsikt att lyfta fram n\u00e5got s\u00e4rskilt bibliotek som ett botemedel mot alla problem. Ist\u00e4llet presenteras n\u00e5gra hypoteser och de starka och svaga sidorna hos b\u00e5da biblioteken avsl\u00f6jas. Jag har gett n\u00e5gra r\u00e5d om vad man b\u00f6r t\u00e4nka p\u00e5 n\u00e4r man v\u00e4ljer mellan dem f\u00f6r att fatta ett klokt beslut och inte l\u00e5ta sig v\u00e4gledas av trender eller slumpm\u00e4ssiga personer fr\u00e5n internet.<\/p>\n Varje verktyg kan passa projektets behov tillr\u00e4ckligt bra. Inget av dem kommer att f\u00f6rsvinna fr\u00e5n marknaden snabbt under de kommande \u00e5ren. B\u00e5da har starka communities och en hel del mognad, vilket visar oss att dessa tv\u00e5 klarar sig ganska bra.<\/p>\n Det slutliga valet ligger i dina h\u00e4nder. Men om du har n\u00e5gra tvivel eller bara vill diskutera ditt fall med Codest<\/a> - kontakta oss g\u00e4rna!<\/p>\n L\u00e4s mer om detta:<\/b><\/p>\n Varf\u00f6r du (f\u00f6rmodligen) b\u00f6r anv\u00e4nda Typescript<\/a><\/p>\n Hur undviker man att d\u00f6da ett projekt med d\u00e5liga kodningsrutiner?<\/a><\/p>\nBig bang i internetverkligheten <\/h2><\/p>\n
F\u00f6rsta stegen mot v\u00e4lk\u00e4nda ramverk<\/h2><\/p>\n
Grundl\u00e4ggande information och en liten j\u00e4mf\u00f6relse<\/h2><\/p>\n
![\"React](\"\/app\/uploads\/2024\/05\/tabela-art-.jpg\")
<\/p>\nVad s\u00e4ger statistiken?<\/h2><\/p>\n
![\"vue](\"\/app\/uploads\/2024\/05\/bez-tytulu.png\")
<\/p>\n![\"react](\"\/app\/uploads\/2024\/05\/aaaaaabbb.png\")
<\/p>\n![\"Rangordning](\"\/app\/uploads\/2024\/05\/1.png\")
<\/p>\n![\"tillst\u00e5nd](\"\/app\/uploads\/2024\/05\/2.png\")
<\/p>\n![\"React](\"\/app\/uploads\/2024\/05\/3.png\")
<\/p>\nB\u00e4sta valet f\u00f6r utvecklare<\/h2><\/p>\n
B\u00e4sta valet f\u00f6r CTO<\/a> <\/h2><\/p>\n
\nav olika m\u00e4nniskor fr\u00e5n internet - kanske ett b\u00e4ttre alternativ \u00e4r att helt enkelt prata med utvecklarna.<\/p>\nSlutsatser<\/h2><\/p>\n