T\u00f6\u00f6lauarakendused kuuluvad minevikku, sest k\u00f5ike saab teha veebilehitsejas. Tegelikult kirjutatakse ka rakendusi, mis peavad kasutama madalama taseme APIsid, mis ei ole brauseris k\u00e4ttesaadavad, kasutades brauserimootoreid ja -keeli, sest see muudab nende hooldamise lihtsamaks.<\/p>\n
Mobiilirakendusi saab h\u00f5lpsasti asendada vahenditega, mida kasutatakse veeb<\/a> areng - vt React<\/a> Emakeelne<\/strong>, NativeScript. Lisaks on meil PWA, mis kergesti \"imiteerib\" mobiilirakenduste toimimist. Lisaks on komponendid, mis toidavad rakendust, mis on kirjutatud Vue<\/a><\/strong> v\u00f5i React<\/strong> saab h\u00f5lpsasti jagada erinevaid kood<\/a> elemente platvormide vahel. <\/p>\n Peame tunnistama \u00fcht - veebirakendused on praegu v\u00f5imsad, mida on raske alla tuua. Kasutajana n\u00e4en end neid praktiliselt k\u00f5ikjal kasutamas: Slacki kaudu suhtlemisel, koodiredaktori kasutamisel, esitluste tegemisel v\u00f5i isegi blogiartikli kirjutamisel.<\/p>\n Raske on ennustada, mis juhtub m\u00f5ne aasta p\u00e4rast. WebAssembly tuleb m\u00e4ngu ja see v\u00f5imaldab us<\/a> keerulisemaid arvutusi n\u00f5udvate rakenduste \u00fcleviimiseks brauserimaailma. \u00dcks asjaolu j\u00e4\u00e4b siiski muutumatuks - on t\u00f5esti raske leida takistust, et ehitada veebitehnoloogiate abil selline rakendus, millest me ainult unistada oskame. <\/p>\n Asja juurde - l\u00e4heme korraks tagasi minevikku, enne esimeste olulisemate veebiraamistike ilmumist ja rakenduste imperatiivset arendamist. Iga interaktiivset mehhanismi lehel k\u00e4sitleti k\u00e4sitsi ja see oli vastutav konkreetse tegevuse eest.<\/p>\n Parim n\u00e4ide, mida v\u00f5ib tuua, on jQuery raamatukogu - omal ajal \u00fcks populaarsemaid lahendusi lihtsate s\u00fcndmuste k\u00e4sitlemiseks. Selle abil on rakendatud erinevaid rippmen\u00fc\u00fcsid, \u00fcleminekuid, animatsioone, kalkulaatoreid ja muud sarnast mehaanikat.<\/p>\n Tasub mainida, et probleeme keerulisemates rakendustes m\u00e4rgati juba siis - kohtades, kus erinevad, iseseisvad osad pidid n\u00e4iteks reageerima korralikule kl\u00f5psule v\u00f5i millegi sisestamisele. Enamikul rakendustest ei olnud selges\u00f5nalist olekut, vaid neid p\u00e4\u00e4stsid n\u00e4iteks elementide atribuudid v\u00f5i nende klassid.<\/p>\n Sel ajal oli selge, et praegusel l\u00e4henemisviisil puudus reaktiivsus - struktureeritud viis, kuidas komponendid omavahel suhelda ja jagada n\u00e4iteks oma olekut v\u00f5i erinevaid s\u00fcndmusi, mis lihtsustas rakenduste hooldamist ja v\u00f5imaldas neil pakkuda head kasutajakogemust v\u00e4ikeste kuludega.<\/p>\n Aja jooksul hakkasid ilmuma esimesed front-end raamistikud, mille eesm\u00e4rk oli struktureerida arhitektuuri keerukamate rakenduste jaoks.<\/p>\n Need raamistikud p\u00f5hinesid peamiselt MVC-mustril - m\u00f5ned pakkusid v\u00e4lja rohkem manuaalset l\u00e4henemist, nagu Backbone.js, samas kui teised, nagu Knockout.js, haakusid kahesuunalise andmed<\/a> sidumine.<\/p>\n Siiski v\u00f5is tunda, et rakenduse kirjutamine oli keerulisem, n\u00f5udis palju rohkem kodeerimist ja ei andnud tingimata soovitud tulemusi ega kompenseerinud rakenduse arendamisele kaotatud aega.<\/p>\n Peamine p\u00f5hjus, miks kuldse kesktee leidmine on JS<\/a> \u00f6kos\u00fcsteem oli raske oli see, et see oli natuke veider seas tuntud programmeerimiskeeled<\/a> mis on juba ammu oma teed sillutanud.<\/p>\n Ja ma ei taha siinkohal pikemalt peatuda sellel, millised teed on erinevate raamistike arenguga l\u00e4bi ajaloo kaasnenud. Siiski on oluline m\u00e4rkida \u00fcht - JS-\u00f6kos\u00fcsteemi k\u00fcpsemise aeg brauserites ei olnud lihtne ja seisis silmitsi paljude katsumustega.<\/p>\n See on ainus p\u00f5hjus, miks me saame t\u00e4nap\u00e4eval ehitada veebirakendusi ja arendada neid v\u00e4ga lihtsalt ja valutult.<\/p>\n Selle asemel, et visata liha, nagu internetis kombeks, vaatame m\u00f5lemad raamatukogud \u00fcle, kogume nende kohta infot ja v\u00f5rdleme neid - nii teoorias kui ka praktikas.<\/p>\n M\u00c4RKUS: mehhanismide kirjeldus, mis t\u00f6\u00f6tavad Vue <\/strong>viitab konkreetselt versioonile 2. Versioon 3 toob palju olulisi muudatusi, kuid ei ole t\u00f5eline konkurent React<\/strong> hetkel, kui ainult oma k\u00fcpsuse t\u00f5ttu - Vue 3 ilmumiskuup\u00e4ev: 18. september 2020.<\/p>\n Tehkem \u00fcks asi selgeks - kui s\u00fcveneda m\u00f5lemasse raamatukogusse, siis n\u00e4ete, et tegelikult on sarnasusi rohkem kui erinevusi. J\u00e4ttes k\u00f5rvale raamatukogude kasutamise viisi kui sellise - m\u00f5lemal neist on v\u00e4ga sarnased kontseptsioonid, kuidas nad t\u00f6\u00f6tavad. M\u00f5lemad p\u00f5hinevad sarnasel \u00f6kos\u00fcsteemil ja nende kasutamine ei ole diametraalselt erinev.<\/p>\n \u25cf Kurat peitub detailides - mida sagedamini me mingit vahendit kasutame, seda suuremaid puudusi selle erinevatest lahendustest m\u00e4rkame. Heaks n\u00e4iteks v\u00f5ib siinkohal olla kahesuunaline andmete sidumine, mida kasutatakse k\u00f5ige sagedamini Vue<\/strong> kui v-mudeli omadus: see muudab sageli asjad lihtsamaks, hoolitseb paljude asjade eest automaatselt ja ei n\u00f5ua v\u00e4\u00e4rtuste muutmise lisatoe kodeerimist.<\/p>\n Siiski on juhtumeid, kus meil on vaja konkreetselt j\u00e4lgida muutmiskatset ja sellele vastavalt reageerida, mille puhul v-mudelil p\u00f5hinevate komponentide puhul oleme sageli sunnitud segama teiste Vue<\/strong> mehaanika, nagu n\u00e4iteks arvutatud vara, mist\u00f5ttu saavutatud efekt n\u00e4eb sageli palju halvem v\u00e4lja kui manuaalse l\u00e4henemise puhul;<\/p>\n \u25cf Teine huvitav aspekt on JSX, mis on selline \"vagrantne\" viis renderdatud sisu mallimiseks, kasutades React<\/strong>. Arendajaskonnas on erinevad arvamused.<\/p>\n Minu t\u00e4helepanekute p\u00f5hjal tundub, et arendajad, kes kasutavad muud keskkonda kui JS, nt. PHP<\/a> v\u00f5i C#, kalduvad rohkem mallivaateid nii, et Vue<\/strong> teeb.<\/p>\n Kokkuv\u00f5tteks - mallid, mis on tuntud alates Vue<\/strong> v\u00f5imaldavad m\u00e4\u00e4ratleda vaateid v\u00e4ga selgelt ja elegantselt, samas kui React JSX v\u00f5imaldab neid paljudel juhtudel kiiremini ehitada, kohandada neid konkreetsetele vajadustele ja n\u00f5uab sageli v\u00e4hem koodi erinevate struktuuride loomiseks;<\/p>\n \u25cf Vaadakem ka nende kahe vahendi \u00f6kos\u00fcsteeme. P\u00f5him\u00f5tteliselt v\u00f5ime \u00f6elda, et nad ei erine millegi poolest. M\u00f5lemaid nimetatakse raamatukogudeks mitte ilma p\u00f5hjuseta - nad pakuvad reaktiivsete veebirakenduste toetuseks minimaalset vajalikku.<\/p>\n samas kui \u00fclej\u00e4\u00e4nud, mis on seotud suhtlemisega API<\/a>, andmevoog, erinevate alamlehtede \u00fcmber kasutatavad UI komponendid, on nn m\u00fc\u00fcjad - v\u00e4ljastpoolt v\u00f5etud raamatukogud, mis tuleb korralikult kinnitada projekt<\/a>. See on natuke nagu Lego maailm: kui tahad ehitada \u00fchtset tervikut, pead selle kokku panema \u00fcksikutest v\u00e4ikestest klotsidest.<\/p>\n See allegooria viitab t\u00e4pselt lisatud komponentidele, mis on v\u00f5imsad rakendused, mis on loodud koos React<\/strong> v\u00f5i Vue<\/strong>;<\/p>\n \u25cf Oluline asi, eriti inimeste jaoks, kes ei ole JS-keskkonnas nii kogenud, on konkreetse raamatukogu sisenemise tase. Teisis\u00f5nu - t\u00f6\u00f6riista keerukus, mis koosneb otsesest ajast, mida peate kulutama selle mehaanika m\u00f5istmiseks.<\/p>\n Ma arvan, et \u00fcks asi tuleb siinkohal \u00fchem\u00f5tteliselt v\u00e4lja \u00f6elda - juhul kui tegemist on Vue<\/strong>see on palju lihtsam. Meil on kahesuunaline andmete sidumine, meil on elegantselt m\u00e4\u00e4ratletud mall, mis on petlikult sarnane teiste keelte lahendustega, nt twig, ja l\u00f5puks - meil ei ole peavalu, mida p\u00f5hjustab \u00fcksikute konksude toimimist puudutavate teooriate \u00f5ppimine ja juhtumid, mille puhul tuleb kasutada spetsiifilist mehaanikat.<\/p>\n Otse rahvah\u00e4\u00e4le j\u00e4rgi minek ei ole just hea valik. Hea samm hea otsuse tegemiseks on siiski anal\u00fc\u00fcsida, mida \u00fctlevad inimesed, kes on nende raamatukogudega suhelnud.<\/p>\n Ja jah - t\u00e4hed githubis <\/a> v\u00f5ib olla n\u00e4itaja selle kohta, kui palju on konkreetse raamatukogu kogukond selle arendamisse kaasatud, kuidas arendajad seda tajuvad ja kas nad on huvitatud sellest, kuhu raamatukogu areneb. Insenerid<\/a> kes staariks konkreetset repositooriumi, saavad sageli teateid uute versioonide v\u00f5i koodimuudatuste kohta, mis t\u00e4hendab, et nad teavad otseselt raamatukogu.<\/p>\n Siiski ei tohiks githubi t\u00e4rnide arvu pidada oraakliks - mitte iga arendaja, kellele t\u00f6\u00f6riist meeldib, ei j\u00e4ta m\u00e4rki - selle asemel v\u00f5taksin seda kui m\u00e4rki puhtast kirest, mida arendajad konkreetse avatud l\u00e4htekoodiga projekti vastu tunnevad.<\/p>\n Google Trends <\/a> on tuntud teenus, mis v\u00f5imaldab uurida huvi konkreetsete teemade vastu aja jooksul. Kuigi see ei ole ratsionaalne kvaliteedi v\u00f5i kasutamise n\u00e4itaja, v\u00f5ib see pakkuda igasuguseid anal\u00fc\u00fcse.<\/p>\n T\u00e4nase artikli kahe peategelase v\u00f5rdlemisel on lihtne n\u00e4ha, et viimase 5 aasta kulg on olnud \u00fcsna sarnane. P\u00f5hiline j\u00e4reldus, mille v\u00f5ib graafiku p\u00f5hjal teha, on, et React<\/strong> on otsingupopulaarsuse poolest k\u00f5rgem v\u00f5rreldes oma konkurendiga.<\/p>\n Selgituseks - Google Trends'i edetabelis esikohal olemine ei t\u00e4henda, et raamatukogu on parem. K\u00fcsimus on rahvahulga populaarsuses, nagu ma juba mainisin - t\u00f5en\u00e4oliselt on rohkem inimesi sellest t\u00f6\u00f6riistast kuulnud, see v\u00f5ib olla \u00e4ratanud rohkem huvi seas CTOs<\/a>, tarkvaraarendajad<\/a> <\/strong>v\u00f5i inimesed, kes soovivad lihtsalt \u00f5ppida mingit konkreetset t\u00f6\u00f6riista.<\/p>\n Kas see graafik kajastab tegelikkust? M\u00f5nev\u00f5rra, jah. \u00dcldiselt - k\u00fcsitletud inimeste seas on rohkem neid, kes n\u00e4itavad mitmekesiselt keerulisi teadmisi React<\/strong> kui Vue<\/strong>. Milliseid arvamusi saab nende inimestega r\u00e4\u00e4kides? P\u00fc\u00fcan seda j\u00e4rgmises l\u00f5igus visandada.<\/p>\n JS riik\u00a0<\/a> on sait, mis uurib igal aastal inimesi, kes t\u00f6\u00f6tavad JavaScript-ga seotud tehnoloogiate valdkonnas. Selle eesm\u00e4rk on koguda arendajatelt teavet selle kohta, kuidas nad suhtuvad t\u00f6\u00f6riistadesse, millega nad igap\u00e4evaselt t\u00f6\u00f6tavad.<\/p>\n K\u00fcsimused h\u00f5lmavad \u00fcksikuid vahendeid eri eesm\u00e4rkidel - nt vahendeid, mida kasutatakse front-end'is ja back-end'is, aga ka vahendeid testimiseks, rakenduse seisundi haldamiseks jne. Igale k\u00fcsimusele ei saa vastata lihtsalt jah\/ei, vaid saidil esitatakse rida k\u00fcsimusi t\u00f6\u00f6riista enda, huvide, kogemuste ja \u00fcldise hinnangu kohta, mis taandub lausele \"Kas te kasutaksite seda t\u00f6\u00f6riista tulevastes projektides?\".<\/p>\n Sait ise v\u00f5imaldab teil teha palju anal\u00fc\u00fcse, v\u00f5rrelda asjakohaseid vahendeid ja m\u00f5nikord teada saada v\u00e4hemtuntud raamatukogudest, mis hakkavad JS-maailmas h\u00e4sti hakkama saama, kogudes populaarsust, nautides samal ajal k\u00f5rget \"kasutamise r\u00f5\u00f5mu\" m\u00e4\u00e4ra. Soovitan siiralt sirvida selle saidi sisu.<\/p>\n V\u00f5tame l\u00f5igu kokku statistika abil. Erinevat t\u00fc\u00fcpi graafikute anal\u00fc\u00fcs v\u00f5ib sageli olla v\u00e4ga hea v\u00f5imalus antud teemade erinevate aspektide v\u00f5rdlemiseks. Siiski tuleb arvestada, et rahvahulga h\u00e4\u00e4le j\u00e4rgimine ei pruugi olla k\u00f5ige targem. Selle asemel saate teha teadliku otsuse, kasutades m\u00f5ningaid graafikute anal\u00fc\u00fcsist saadud \u00f5ppetunde.<\/p>\n Varem mainisin madalamat sisenemisl\u00e4vendit, et Vue<\/strong> - see v\u00f5imaldab t\u00f5epoolest keskenduda veidi kiiremini rakenduse tegelikule arendamisele, kasutades t\u00f6\u00f6riista ja v\u00e4hendades miinimumini aega, mis on vajalik keskkonna, mehaanika ja erinevate kasutusjuhtumitega tutvumiseks.<\/p>\n \u00dcldiselt on minu arvamus, et Vue<\/strong> on sobivam inimestele, kes ei ole veel tegelenud front-end raamatukogudega. Kindlasti v\u00f5imaldab see teil julgemalt saada rahuldavaid tulemusi l\u00fchikese aja jooksul.<\/p>\n Kuid \u00fctleme seda valjusti - keeleoskuse puudumine, milles me kasutame konkreetseid vahendeid, teeb meile varem v\u00f5i hiljem haiget. Lihtsate asjade puhul on see t\u00e4htsusetu element, kuid kui loodavate rakenduste keerukus kasvab, siis on \u00fcha raskem ehitada rakendusi korralikult ilma hea teadmisteta JavaScript<\/a>.<\/p>\n Ma ei viita tegelikult sellele, et ma suudan kirjutada mingeid keerulisi funktsioone, sest seda osa saab suures osas asendada n\u00e4iteks m\u00fc\u00fcjate poolt. Ma pean silmas m\u00f5ningaid tavalisi vigu, mida v\u00f5ib keeles teha ja mitte teadvustada, et vale k\u00e4itumine ei tulene mitte raamatukogu, vaid keele kasutamisest. K\u00f5ige tavalisem viga, mis siin avaldub, on nn muutumatus - see t\u00e4hendab, et JavaScript-s on teada viitamismehhanism.<\/p>\n Ma ei oska soovitada, milline raamatukogu on parem arendajatele, kes on rohkem v\u00f5i v\u00e4hem tuttavad JavaScript-ga. Aga ma tean \u00fchte asja - kui soovite saada t\u00f5elist ettekujutust sellest, kuidas areng m\u00f5lema t\u00f6\u00f6riistaga \"seestpoolt\" v\u00e4lja n\u00e4eb - proovige kirjutada rakendusi m\u00f5lemas neist. See annab teile ettekujutuse, v\u00f5imaldab teil n\u00e4ha, millised mehhanismid teile rohkem meeldivad ja mis on teie jaoks parem valik.<\/p>\n Nagu ma varem mainisin - m\u00f5lemad raamatukogud p\u00f5hinevad sarnastel \u00f6kos\u00fcsteemidel, neil on sarnased vaated rakenduste loomisele v\u00e4ikeste komponentidega. M\u00f5lemal raamatukogul l\u00e4heb h\u00e4sti - ei ole mingeid m\u00e4rke, et kumbki neist l\u00e4hitulevikus kaduma hakkab. J\u00e4relikult j\u00e4\u00e4vad ka t\u00f6\u00f6pakkumised m\u00f5lemas sarnasel tasemel.<\/p>\n J\u00e4reldused on lihtsad - kasutage seda, mis teile sobib; koguge kogemusi ja hinnake. See aitab teil arendada ratsionaalset l\u00e4henemist sellele, kas konkreetses projektis on parem kasutada \u00fcht v\u00f5i teist raamatukogu; proovige ka katsetada - miski ei \u00f5peta nii p\u00f5hjalikult kui minevikus tehtud vead.<\/p>\n Ei ole saladus, et ei ole olemas kuldset keskmist, mis oleks konkreetse projekti jaoks parim lahendus. Eriti front-endis vananevad rakenduste ehitamiseks kasutatavad t\u00f6\u00f6riistad kiiresti ja tihti on raske leida jalga uusimatele suundumustele.<\/p>\n Kuid tehnoloogia valik ei ole v\u00f5i v\u00e4hemalt ei tohiks olla s\u00f5ltuvuses sellest, mis sobib praeguste suundumustega. Selle asemel peaksime selle suunama konkreetsete ootuste ja eelduste j\u00e4rgi, mis on seotud rakendusega, mida me ehitame. Igal v\u00f5rreldud raamatukogul on oma tugevad ja n\u00f5rgad k\u00fcljed, mida sobitades kasutuskohaga saame teha k\u00f5ige m\u00f5istlikuma valiku.<\/p>\n Huvitavaks v\u00f5imaluseks v\u00f5ivad osutuda suurettev\u00f5tete tehnoloogilised kokkuv\u00f5tted, kus sageli kirjeldatakse nende kasutusjuhtumeid, kuidas suurte rakenduste arendamine kulges v\u00f5i kulgeb ja milliseid vigu nad minevikus tegid. V\u00f5ib-olla leiame nende hulgast juhtumeid, mis on eriti huvitavad konkreetse projekti jaoks raamatukogu valimise kontekstis.<\/p>\n Omadused, mida peaksime arvestama, et valida \u00f5iged t\u00f6\u00f6riistad loodava rakenduse jaoks, on: rakenduse arendamise aeg, lihtsus ja rakenduse hooldus<\/a>, rakenduse keerukus ja arendajate kogemus konkreetsete raamatukogude kasutamisel.<\/p>\n Arendajad on need inimesed, kes veedavad k\u00f5ige rohkem aega t\u00f6\u00f6riistadega, mida ma v\u00f5rdlen, ja nad on need, kes saavad anda parimat n\u00f5u ja aidata teil teha parim valik raamatukogude suures kokkup\u00f5rkes. Just rakenduse arendamise k\u00e4igus n\u00e4ed erinevaid probleeme, mis tulenevad otseselt tehnoloogia valikust, ja sul on parim \u00fclevaade sellest, millised asjad \u00f5\u00f5nestavad konkreetse t\u00f6\u00f6riista kasutamist konkreetsete funktsioonide puhul.<\/p>\n Nagu ma varem mainisin - m\u00f5lemad raamatukogud ei tundu kaduvat v\u00e4lja turg<\/a>, v\u00e4hemalt mitte l\u00e4hiaastatel. Selle asemel, et teha otsuseid statistika ja arvamuste p\u00f5hjal Tutvustage neile, mida taotlustelt oodatakse, milline aeg meil selle tarnimiseks on ja lubage enne l\u00f5pliku otsuse tegemist vabalt vahetada arvamusi selle kohta, mida nad m\u00f5lemast lahendusest arvavad.<\/p>\n Interneti-s\u00f5jad on tavaliselt - v\u00f5i v\u00f5ib-olla igal juhul - m\u00f5ttetud. Alati leidub inimesi, kes v\u00e4idavad kangekaelselt, et nende valik on parem, ilma et nad esitaksid oma otsust kinnitavaid ratsionaalseid argumente.<\/p>\n Selle asemel, et olla pimestatud konkreetsetest valikutest - keskendume anal\u00fc\u00fcsile, p\u00fc\u00fcame teha asjakohaseid j\u00e4reldusi ja kasutada neid konkreetse lahenduse kohandamiseks v\u00f5i tagasil\u00fckkamiseks.<\/p>\n Nagu pealkiri viitab - ma ei kavatse kroonida \u00fchtegi konkreetset raamatukogu kui ravimit igale valule. Selle asemel esitatakse m\u00f5ned h\u00fcpoteesid ning tuuakse v\u00e4lja m\u00f5lema raamatukogu tugevad ja n\u00f5rgad k\u00fcljed. Olen andnud m\u00f5ned n\u00f5uanded, mida nende vahel valides otsida, et teha tark otsus ja mitte juhinduda trendidest v\u00f5i juhuslikest inimestest internetist.<\/p>\n Iga t\u00f6\u00f6riist v\u00f5ib projekti vajadustele piisavalt h\u00e4sti sobida. Kumbki neist ei kao l\u00e4hiaastatel kiiresti turult. M\u00f5lemal on v\u00f5imsad kogukonnad ja \u00fcsna k\u00fcpsed, mis n\u00e4itab meile, et neil kahel l\u00e4heb p\u00e4ris h\u00e4sti.<\/p>\n L\u00f5plik valik on teie k\u00e4es. Kui teil on siiski mingeid kahtlusi v\u00f5i soovite lihtsalt arutada oma juhtumit koos The Codest<\/a> - v\u00f5tke meiega julgelt \u00fchendust!<\/p>\n Loe edasi:<\/b><\/p>\n Miks peaksite (t\u00f5en\u00e4oliselt) kasutama Typescript'i<\/a><\/p>\n Kuidas mitte tappa projekti halbade kodeerimistavadega?<\/a><\/p>\nSuur pauk internetireaalsuses <\/h2><\/p>\n
Esimesed sammud tuntud raamistike suunas<\/h2><\/p>\n
P\u00f5hiteave ja v\u00e4ike v\u00f5rdlus<\/h2><\/p>\n
![\"React](\"\/app\/uploads\/2024\/05\/tabela-art-.jpg\")
<\/p>\nMida \u00fctleb statistika?<\/h2><\/p>\n
![\"vue](\"\/app\/uploads\/2024\/05\/bez-tytulu.png\")
<\/p>\n![\"react](\"\/app\/uploads\/2024\/05\/aaaaaabbb.png\")
<\/p>\n![\"Raamistike](\"\/app\/uploads\/2024\/05\/1.png\")
<\/p>\n![\"JS](\"\/app\/uploads\/2024\/05\/2.png\")
<\/p>\n![\"React](\"\/app\/uploads\/2024\/05\/3.png\")
<\/p>\nParim valik arendaja jaoks<\/h2><\/p>\n
Parim valik CTO<\/a> <\/h2><\/p>\n
\nerinevatest inimestest internetist - v\u00f5ib-olla on parem variant lihtsalt r\u00e4\u00e4kida arendajatega.<\/p>\nJ\u00e4reldused<\/h2><\/p>\n