Nėra greitesnio būdo sulėtinti svetainės veikimą (neskirtas kalambūras), nei paleisti joje krūvą „JavaScript“ kodo. Kai naudojate „JavaScript“, už tai turite mokėti bent keturis kartus. Štai ką svetainės „JavaScript“ kodas įkelia į vartotojų sistemas:
- Failo įkėlimas per tinklą.
- Išpakuoto šaltinio kodo analizavimas ir kompiliavimas po atsisiuntimo.
- Vykdomas JavaScript kodas.
- Atminties suvartojimas.
Šis derinys pasirodo .
Į savo projektus įtraukiame vis daugiau JS kodų. Organizacijoms pereinant prie svetainių, kurias teikia sistemos ir bibliotekos, pvz., „React“, „Vue“ ir kitos, pagrindinės svetainių funkcijos labai priklauso nuo „JavaScript“.
Mačiau daug labai sunkių svetainių, naudojančių „JavaScript“ sistemas. Tačiau mano vizija šiuo klausimu yra labai šališka. Faktas yra tai, kad įmonės, su kuriomis dirbu, ateina pas mane būtent todėl, kad turi sudėtingų svetainės veikimo problemų. Dėl to man tapo smalsu sužinoti, kiek ši problema išplitusi ir kokias „baudas“ mokame, kai pasirenkame vieną ar kitą karkasą kaip tam tikros svetainės pagrindą.
Šis projektas man padėjo tai išsiaiškinti. .
Duomenys
HTTP archyvo projektas iš viso stebi 4308655 5484239 XNUMX nuorodas į įprastas darbalaukio svetaines ir XNUMX XNUMX XNUMX nuorodas į svetaines mobiliesiems. Tarp daugelio su šiomis nuorodomis susijusių rodiklių yra atitinkamose svetainėse esančių technologijų sąrašas. Tai reiškia, kad galime atrinkti tūkstančius svetainių, kuriose naudojamos skirtingos sistemos ir bibliotekos, ir sužinoti, kiek kodo jos siunčia klientams ir kiek tas kodas apkrauna vartotojų sistemas.
Rinkau duomenis nuo 2020 m. kovo mėnesio – tai buvo naujausi duomenys, prie kurių turėjau prieigą.
Nusprendžiau palyginti sukauptus visų svetainių HTTP archyvo duomenis su duomenimis apie svetaines, kuriose naudojamos „React“, „Vue“ ir „Angular“, nors svarsčiau naudoti ir kitą šaltinio medžiagą.
Kad būtų įdomiau, prie šaltinio duomenų rinkinio pridėjau svetaines, kuriose naudojamas jQuery. Ši biblioteka vis dar labai populiari. Taip pat pristatomas požiūris į interneto svetainių kūrimą, kuris skiriasi nuo vieno puslapio aplikacijos (SPA) modelio, kurį siūlo React, Vue ir Angular.
HTTP archyvo nuorodos, atstovaujančios svetaines, kuriose, kaip nustatyta, naudojamos mus dominančios technologijos
Karkasas arba biblioteka
Nuorodos į svetaines mobiliesiems
Nuorodos į įprastas svetaines
JQuery
4615474
3714643
Reaguoti
489827
241023
Vue
85649
43691
Kampinis
19423
18088
Viltys ir svajonės
Prieš pereinant prie duomenų analizės, noriu pakalbėti apie tai, ko norėčiau tikėtis.
Manau, kad idealiame pasaulyje sistemos būtų ne tik kūrėjų poreikių tenkinimas, bet ir suteiktų tam tikros naudos kasdieniams mūsų svetainių naudotojams. Produktyvumas yra tik vienas iš šių privalumų. Čia taip pat reikia prisiminti apie prieinamumą ir saugumą. Bet tai tik pats svarbiausias dalykas.
Taigi idealiame pasaulyje tam tikra sistema turėtų palengvinti didelio našumo interneto svetainės kūrimą. Tai turėtų būti daroma dėl to, kad karkasas suteikia kūrėjui tinkamą pagrindą projektui kurti, arba dėl to, kad ji nustato plėtros apribojimus, iškeldama jam reikalavimus, dėl kurių sunku ką nors sukurti. kad pasirodo esąs lėtas.
Geriausios sistemos turėtų daryti abu: sudaryti gerą pagrindą ir nustatyti darbo apribojimus, kurie leistų pasiekti padorų rezultatą.
Duomenų vidutinių verčių analizė nesuteiks mums reikalingos informacijos. Ir, tiesą sakant, šis požiūris nepalieka mūsų dėmesio . Vietoj to, iš turimų duomenų išvedžiau procentilių balus. Tai yra 10, 25, 50 (mediana), 75, 90 procentiliai.
Mane ypač domina 10 ir 90 procentiliai. 10 procentilis rodo geriausią konkrečios sistemos našumą (arba bent jau beveik arti geriausią). Kitaip tariant, tai reiškia, kad tik 10 % svetainių, naudojančių tam tikrą sistemą, pasiekia šį arba aukštesnį lygį. Kita vertus, 90 procentilis yra kita medalio pusė – jis parodo, kokie blogi dalykai gali būti. 90-asis procentilis yra paskutinės svetainės – paskutinės 10 % svetainių, kuriose yra didžiausias JS kodo kiekis arba ilgiausias laikas, reikalingas kodui apdoroti pagrindinėje gijoje.
JavaScript kodo tomai
Pirmiausia prasminga išanalizuoti „JavaScript“ kodo, kurį tinkle perduoda įvairios svetainės, dydį.
„JavaScript“ kodo kiekis (KB), perkeltas į mobiliuosius įrenginius
Procentiliai
10
25
50
75
90
Visos svetainės
93.4
196.6
413.5
746.8
1201.6
jQuery svetaines
110.3
219.8
430.4
748.6
1162.3
Vue svetainės
244.7
409.3
692.1
1065.5
1570.7
Kampinės svetainės
445.1
675.6
1066.4
1761.5
2893.2
Reaguoti į svetaines
345.8
441.6
690.3
1238.5
1893.6
Į mobiliuosius įrenginius išsiųsto „JavaScript“ kodo kiekis
„JavaScript“ kodo kiekis (KB), perkeltas į stalinius įrenginius
Procentiliai
10
25
50
75
90
Visos svetainės
105.5
226.6
450.4
808.8
1267.3
jQuery svetaines
121.7
242.2
458.3
803.4
1235.3
Vue svetainės
248.0
420.1
718.0
1122.5
1643.1
Kampinės svetainės
468.8
716.9
1144.2
1930.0
3283.1
Reaguoti į svetaines
308.6
469.0
841.9
1472.2
2197.8
„JavaScript“ kodo, perkelto į stalinius įrenginius, kiekis
Jei kalbėsime tik apie JS kodo, kurį svetainės siunčia į įrenginius, dydį, viskas atrodo taip, kaip galima tikėtis. Būtent, jei naudojamas vienas iš karkasų, tai reiškia, kad net ir idealioje situacijoje svetainės JavaScript kodo apimtis padidės. Tai nenuostabu – jūs negalite padaryti „JavaScript“ sistemos svetainės pagrindu ir tikėtis, kad projekto JS kodo kiekis bus labai mažas.
Įdomūs šie duomenys yra tai, kad kai kurios sistemos ir bibliotekos gali būti laikomos geresniais projekto pradžios taškais nei kiti. Svetainės su jQuery atrodo geriausiai. Jų staliniams kompiuteriams skirtose svetainėse yra 15 % daugiau JavaScript nei visose svetainėse, o svetainėse mobiliesiems yra 18 % daugiau JavaScript. (Tiesa, čia yra tam tikras duomenų iškreipimas. Faktas yra tas, kad jQuery yra daugelyje svetainių, todėl natūralu, kad tokios svetainės yra labiau susijusios su bendru svetainių skaičiumi nei kitos. Tačiau tai neturi įtakos tam, kaip šaltinio duomenys išvedami kiekvienai sistemai.)
Nors 15–18% kodo augimas yra reikšmingas skaičius, palyginti su kitomis sistemomis ir bibliotekomis, „jQuery“ taikomas mokestis yra labai mažas. 10 procentilio kampinės svetainės siunčia 344 % daugiau duomenų į stalinius įrenginius nei visos svetainės ir 377 % daugiau į mobiliuosius įrenginius. „React“ svetainės yra kitos sunkiausios, siunčiančios 193 % daugiau kodo į stalinius įrenginius nei visos svetainės, o į mobiliuosius įrenginius – 270 % daugiau.
Anksčiau minėjau, kad nors karkaso naudojimas reiškia, kad tam tikras kiekis kodo bus įtrauktas į projektą pačioje darbo pradžioje, tikiuosi, kad karkasas sugebės kažkaip apriboti kūrėją. Visų pirma kalbame apie maksimalaus kodo kiekio apribojimą.
Įdomu tai, kad „jQuery“ svetainės laikosi šios idėjos. Nors jos 10 procentilio lygiu yra šiek tiek sunkesnės už visas svetaines (15–18 %), 90 procentilio lygiu jos yra šiek tiek lengvesnės nei visos svetainės – apie 3 % tiek staliniams kompiuteriams, tiek mobiliesiems skirtose versijose. Tai nereiškia, kad tai labai reikšminga nauda, tačiau galima teigti, kad jQuery svetainėse bent jau nėra didžiulių JavaScript kodų dydžių net ir didžiausiose jų versijose.
Tačiau to negalima pasakyti apie kitas sistemas.
Kaip ir 10-ojo procentilio atveju, 90-ojo procentilio vietose Angular ir React skiriasi nuo kitų vietų, tačiau jos skiriasi, deja, blogiau.
90 procentų kampinės svetainės siunčia 141 % daugiau duomenų į mobiliuosius įrenginius nei visos svetainės ir 159 % daugiau į stalinius įrenginius. „React“ svetainės į stalinius įrenginius siunčia 73% daugiau nei visos svetainės ir 58% daugiau į mobiliuosius įrenginius. „React“ svetainių kodo dydis 90 procentiliu yra 2197.8 KB. Tai reiškia, kad šios svetainės siunčia 322.9 KB daugiau duomenų į mobiliuosius įrenginius nei jų artimiausi „Vue“ pagrįsti konkurentai. Atotrūkis tarp darbalaukio svetainių, pagrįstų Angular ir React, ir kitų svetainių yra dar didesnis. Pavyzdžiui, „React“ darbalaukio svetainės į įrenginius siunčia 554.7 KB daugiau JS kodo nei panašios „Vue“ svetainės.
Laikas, reikalingas „JavaScript“ kodui pagrindinėje gijoje apdoroti
Aukščiau pateikti duomenys aiškiai rodo, kad svetainėse, kuriose naudojamos tirtos sistemos ir bibliotekos, yra daug JavaScript kodo. Bet, žinoma, tai tik viena mūsų lygties dalis.
Kai „JavaScript“ kodas patenka į naršyklę, jis turi būti įjungtas į veikiančią būseną. Ypač daug problemų sukelia tie veiksmai, kuriuos reikia atlikti su kodu pagrindinėje naršyklės gijoje. Pagrindinė gija yra atsakinga už vartotojo veiksmų apdorojimą, stilių skaičiavimą ir puslapio išdėstymo kūrimą bei rodymą. Jei perpildysite pagrindinę giją JavaScript užduotimis, ji neturės galimybės laiku atlikti kitų užduočių. Dėl to puslapių veikimas vėluoja ir „stabdo“.
HTTP archyvo duomenų bazėje yra informacijos apie tai, kiek laiko reikia apdoroti JavaScript kodą pagrindinėje V8 variklio gijoje. Tai reiškia, kad galime rinkti šiuos duomenis ir sužinoti, kiek laiko užtrunka pagrindinė gija apdorodama įvairių svetainių JavaScript.
CPU laikas (milisekundėmis), susijęs su scenarijaus apdorojimu mobiliuosiuose įrenginiuose
Procentiliai
10
25
50
75
90
Visos svetainės
356.4
959.7
2372.1
5367.3
10485.8
jQuery svetaines
575.3
1147.4
2555.9
5511.0
10349.4
Vue svetainės
1130.0
2087.9
4100.4
7676.1
12849.4
Kampinės svetainės
1471.3
2380.1
4118.6
7450.8
13296.4
Reaguoti į svetaines
2700.1
5090.3
9287.6
14509.6
20813.3
CPU laikas, susijęs su scenarijaus apdorojimu mobiliuosiuose įrenginiuose
CPU laikas (milisekundėmis), susijęs su scenarijaus apdorojimu staliniuose įrenginiuose
Procentiliai
10
25
50
75
90
Visos svetainės
146.0
351.8
831.0
1739.8
3236.8
jQuery svetaines
199.6
399.2
877.5
1779.9
3215.5
Vue svetainės
350.4
650.8
1280.7
2388.5
4010.8
Kampinės svetainės
482.2
777.9
1365.5
2400.6
4171.8
Reaguoti į svetaines
508.0
1045.6
2121.1
4235.1
7444.3
CPU laikas, susijęs su scenarijaus apdorojimu staliniuose įrenginiuose
Čia galite pamatyti kažką labai pažįstamo.
Pradedantiesiems svetainės, kuriose yra „jQuery“, išleidžia žymiai mažiau „JavaScript“ pagrindinėje gijoje nei kitos. 10 procentiliu, palyginti su visomis svetainėmis, jQuery svetainės mobiliuosiuose įrenginiuose praleidžia 61 % daugiau laiko apdorodamos JS kodą pagrindinėje gijoje. Staliniams kompiuteriams skirtose „jQuery“ svetainėse apdorojimo laikas pailgėja 37%. 90-ajame procentilyje „jQuery“ svetainių balai yra labai artimi bendriems balams. Tiksliau, jQuery svetainės mobiliuosiuose įrenginiuose pagrindinėje gijoje praleidžia 1.3 % mažiau laiko nei visos svetainės, o staliniuose įrenginiuose – 0.7 % mažiau laiko pagrindinėje gijoje.
Kitoje mūsų reitingo pusėje yra karkasai, kuriems būdinga didžiausia pagrindinio sriegio apkrova. Tai vėlgi yra „Angular and React“. Vienintelis skirtumas tarp jų yra tas, kad nors „Angular“ svetainės siunčia naršyklėms didesnį kodo kiekį nei „React“ svetainės, „Angular“ svetainių kodui apdoroti reikia mažiau procesoriaus laiko. Kur kas mažiau.
10 procentilyje kampinės darbalaukio svetainės praleidžia 230 % daugiau laiko JS kodui apdoroti nei visos svetainės. Svetainėse mobiliesiems šis skaičius yra 313%. „React“ svetainių našumas yra prasčiausias. Staliniuose įrenginiuose jie praleidžia 248 % daugiau laiko apdorodami kodą nei visose svetainėse, o mobiliuosiuose įrenginiuose jie praleidžia 658 % daugiau laiko apdoroti kodą. 658% nėra rašybos klaida. Dešimtajame procentilyje „React“ svetainės praleidžia 10 sekundės pagrindinės gijos laiko apdorodamos esamą kodą.
90 procentilių skaičiai atrodo bent šiek tiek geriau, palyginti su šiais didžiuliais skaičiais. Kampiniai projektai, palyginti su visomis svetainėmis, praleidžia 29 % daugiau laiko pagrindinėje gijoje staliniuose įrenginiuose ir 27 % daugiau laiko mobiliuosiuose įrenginiuose. „React“ svetainių atveju panašūs rodikliai atrodo atitinkamai 130% ir 98%.
90-ojo procentilio nuokrypio procentai atrodo geriau nei panašios 10-ojo procentilio vertės. Tačiau čia verta prisiminti, kad laiką nurodantys skaičiai atrodo gana baisūs. Tarkime – 20.8 sekundės pagrindinėje mobiliojo įrenginio gijoje, skirtoje „React“ sukurtai svetainei. (Manau, kad istorija apie tai, kas iš tikrųjų vyksta per šį laiką, verta atskiro straipsnio).
Čia yra viena galima komplikacija (ačiū už tai, kad atkreipiau mano dėmesį į šią savybę ir atidžiai išnagrinėjau duomenis šiuo požiūriu). Faktas yra tas, kad daugelyje svetainių naudojami keli priekiniai įrankiai. Visų pirma, mačiau, kad daug svetainių naudoja „jQuery“ kartu su „React“ ar „Vue“, nes šios svetainės perkeliamos iš „jQuery“ į kitas sistemas ar bibliotekas. Dėl to grįžau į duomenų bazę, šį kartą pasirinkdamas tik tas nuorodas, kurios atitiko svetaines, kurios naudojo tik React, jQuery, Angular ar Vue, bet ne bet kokį jų derinį. Štai ką aš gavau.
Procesoriaus laikas (milisekundėmis), susijęs su scenarijaus apdorojimu mobiliuosiuose įrenginiuose, kai svetainės naudoja tik vieną sistemą arba tik vieną biblioteką
Procentiliai
10
25
50
75
90
Svetainės, kuriose naudojama tik „jQuery“.
542.9
1062.2
2297.4
4769.7
8718.2
Svetainės, kuriose naudojamas tik „Vue“.
944.0
1716.3
3194.7
5959.6
9843.8
Svetainės, kuriose naudojamas tik kampinis
1328.9
2151.9
3695.3
6629.3
11607.7
Svetainės, kuriose naudojama tik „React“.
2443.2
4620.5
10061.4
17074.3
24956.3
Procesoriaus laikas, susijęs su scenarijų apdorojimu mobiliuosiuose įrenginiuose, kai svetainės naudoja tik vieną sistemą arba tik vieną biblioteką
Pirma, nenuostabu: kai svetainė naudoja tik vieną sistemą arba vieną biblioteką, tokios svetainės našumas pagerėja dažniau nei ne. Kiekvieno instrumento našumas geriau atrodo 10 ir 25 procentiliuose. Tai logiška. Svetainė, sukurta naudojant vieną sistemą, turėtų būti greitesnė nei svetainė, sukurta naudojant dvi ar daugiau sistemų ar bibliotekų.
Tiesą sakant, kiekvieno mūsų išnagrinėto priekinio įrankio balai atrodė geresni visais atvejais, išskyrus vieną keistą išimtį. Mane nustebino tai, kad esant 50 ir daugiau procentilių, svetainių, naudojančių „React“, našumas blogesnis, kai „React“ yra vienintelė jų naudojama biblioteka. Tai, beje, buvo priežastis, kodėl aš čia pateikiu šiuos duomenis.
Tai šiek tiek keista, bet vis tiek pabandysiu ieškoti šio keistumo paaiškinimo.
Jei projektas naudoja ir „React“, ir „jQuery“, greičiausiai tas projektas yra perėjimo iš „jQuery“ į „React“ proceso pusiaukelėje. Galbūt jis turi kodų bazę, kurioje šios bibliotekos yra sumaišytos. Kadangi jau matėme, kad „jQuery“ svetainės prie pagrindinės gijos praleidžia mažiau laiko nei „React“ svetainės, tai gali reikšti, kad kai kurių „jQuery“ funkcijų įdiegimas padeda šiek tiek pagerinti svetainės našumą.
Tačiau projektui pereinant nuo „jQuery“ prie „React“ ir vis labiau pasikliaujant „React“, situacija keičiasi. Jei svetainė sukurta tikrai kokybiškai, o svetainės kūrėjai React naudojasi atsargiai, tada su tokia svetaine viskas bus gerai. Tačiau vidutinei „React“ svetainei platus „React“ naudojimas reiškia, kad pagrindinis sriegis yra labiau apkrautas.
Atotrūkis tarp mobiliųjų ir stalinių įrenginių
Kitas būdas, kuriuo peržiūrėjau duomenis, buvo ištirti, koks didelis skirtumas tarp naudojimosi mobiliaisiais ir staliniais kompiuteriais. Jeigu kalbėtume apie JavaScript kodo apimčių palyginimą, tai toks palyginimas nieko baisaus neatskleidžia. Žinoma, būtų malonu matyti mažesnius atsisiunčiamo kodo kiekius, tačiau mobiliojo ir darbalaukio kodo kiekis nesiskiria.
Bet jei analizuojate kodo apdorojimo laiką, pastebimas labai didelis atotrūkis tarp mobiliųjų ir stalinių įrenginių.
Padidėjęs laikas (procentais), susijęs su scenarijaus apdorojimu mobiliuosiuose įrenginiuose, palyginti su staliniais įrenginiais
Procentiliai
10
25
50
75
90
Visos svetainės
144.1
172.8
185.5
208.5
224.0
jQuery svetaines
188.2
187.4
191.3
209.6
221.9
Vue svetainės
222.5
220.8
220.2
221.4
220.4
Kampinės svetainės
205.1
206.0
201.6
210.4
218.7
Reaguoti į svetaines
431.5
386.8
337.9
242.6
179.6
Nors galima tikėtis tam tikro telefono ir nešiojamojo kompiuterio kodų apdorojimo greičio skirtumo, tokie dideli skaičiai man rodo, kad šiuolaikinės sistemos nėra pakankamai nukreiptos į mažos galios įrenginius ir norą užpildyti nustatytą spragą. Netgi esant 10 procentiliui, „React“ svetainės pagrindinėje mobiliojo ryšio gijoje praleidžia 431.5 % daugiau laiko nei darbalaukio pagrindinėje gijoje. „jQuery“ turi mažiausią atotrūkį, tačiau net ir čia atitinkamas skaičius yra 188.2%. Kai svetainių kūrėjai savo projektus kuria taip, kad jiems apdoroti reikia daugiau procesoriaus laiko (o taip nutinka, o laikui bėgant tai tik blogėja), mažos galios įrenginių savininkai turi už tai susimokėti.
rezultatai
Geros sistemos turėtų suteikti kūrėjams gerą pagrindą kuriant žiniatinklio projektus (saugumo, prieinamumo, našumo atžvilgiu) arba turėtų turėti įmontuotus apribojimus, kurie apsunkintų tuos apribojimus pažeidžiančio turinio kūrimą.
Atrodo, kad tai netaikoma žiniatinklio projektams (ir, matyt, jų ).
Verta paminėti, kad vien todėl, kad „React“ ar „Angular“ svetainės praleidžia daugiau procesoriaus laiko ruošdamos kodą nei kitos, nebūtinai reiškia, kad veikiant „React“ svetainėse reikia daugiau procesoriaus nei „Vue“ svetainėse. Tiesą sakant, duomenys, kuriuos peržiūrėjome, labai mažai pasako apie sistemų ir bibliotekų veikimo efektyvumą. Jie daugiau kalba apie kūrimo būdus, kurių, sąmoningai ar ne, šios sistemos gali pastūmėti programuotojus. Kalbame apie struktūrų dokumentaciją, jų ekosistemą ir bendrus kūrimo būdus.
Taip pat verta paminėti tai, ko čia neanalizavome, ty kiek laiko įrenginys praleidžia vykdydamas JavaScript kodą, kai pereina iš vieno svetainės puslapių į kitą. Argumentas SPA naudai yra tas, kad kai į naršyklę bus įkelta vieno puslapio programa, vartotojas teoriškai galės greičiau pasiekti svetainės puslapius. Mano patirtis rodo, kad tai toli gražu nėra tiesa. Tačiau mes neturime duomenų šiai problemai išsiaiškinti.
Akivaizdu, kad jei kurdami svetainę naudojate sistemą ar biblioteką, darote kompromisą, pirmiausia įkeldami projektą ir paruošdami jį pradėti. Tai galioja net ir pozityviausiam scenarijui.
Tam tikrose situacijose galima leistis į kompromisus, tačiau svarbu, kad kūrėjai tokius kompromisus darytų sąmoningai.
Tačiau mes taip pat turime pagrindo optimizmui. Džiaugiuosi, kaip glaudžiai „Chrome“ kūrėjai bendradarbiauja su kai kurių mūsų aptartų sąsajų įrankių kūrėjais, kad padėtų pagerinti tų įrankių našumą.
Tačiau aš esu pragmatiškas žmogus. Naujos architektūros sukuria veikimo problemų taip dažnai, kaip jas išsprendžia. O trūkumams pašalinti reikia laiko. Kaip ir neturėtume to tikėtis išspręs visas našumo problemas, neturėtumėte to tikėtis iš naujų mėgstamiausių sistemų versijų.
Jei norite naudoti vieną iš šioje medžiagoje aptartų priekinių įrankių, tai reiškia, kad turėsite dėti papildomas pastangas, kad užtikrintumėte, jog, beje, nepakenksite savo projekto našumui. Štai keletas dalykų, į kuriuos reikia atsižvelgti prieš pradedant naudoti naują sistemą:
- Patikrinkite save sveiku protu. Ar tikrai reikia naudoti pasirinktą sistemą? Grynas „JavaScript“ šiandien gali daug nuveikti.
- Ar yra lengvesnė jūsų pasirinktos sistemos alternatyva (pvz., Preact, Svelte ar kažkas kita), kuri gali suteikti jums 90% tos sistemos galimybių?
- Jei jau naudojate karkasą, pagalvokite, ar yra kažkas, kas siūlo geresnes, konservatyvesnes, standartines parinktis (pvz., Nuxt.js vietoj Vue, Next.js vietoj React ir pan.).
- Kas bus tavo „JavaScript“ našumas?
- Kaip tu gali kūrimo procesą, kad būtų sunkiau į projektą įtraukti daugiau JavaScript kodo, nei būtina?
- Jei naudojate sistemą, kad būtų lengviau kurti, apsvarstykite siųsti sistemos kodą klientams. Gal galite išspręsti visas serverio problemas?
Paprastai į šias idėjas verta pažvelgti atidžiau, neatsižvelgiant į tai, ką tiksliai pasirenkate kurti priekinę dalį. Tačiau jie ypač svarbūs, kai dirbate su projektu, kuriam iš pradžių trūksta našumo.
Mieli skaitytojai! Kokia, jūsų nuomone, yra ideali „JavaScript“ sistema?
Šaltinis: www.habr.com