Nuk ka mënyrë më të shpejtë për të ngadalësuar një faqe interneti (punë e fjalës me qëllim) sesa të përdorni një grup kodesh JavaScript në të. Kur përdorni JavaScript, duhet të paguani për të me performancën e projekteve jo më pak se katër herë. Ja se si kodi JavaScript i faqes ngarkon sistemet e përdoruesve:
- Shkarkimi i një skedari përmes rrjetit.
- Analiza dhe përpilimi i kodit burimor të papaketuar pas shkarkimit.
- Ekzekutimi i kodit JavaScript.
- Konsumi i memories.
Ky kombinim rezulton .
Dhe ne përfshijmë gjithnjë e më shumë kod JS në projektet tona. Ndërsa organizatat lëvizin drejt sajteve të mundësuara nga korniza dhe biblioteka si React, Vue dhe të tjera, ne po e bëjmë funksionalitetin kryesor të sajteve shumë të varur nga JavaScript.
Unë kam parë shumë site shumë të rënda duke përdorur korniza JavaScript. Por vizioni im për këtë çështje është shumë i njëanshëm. Fakti është se kompanitë me të cilat punoj më drejtohen pikërisht sepse përballen me probleme komplekse në fushën e performancës së faqes. Si rezultat, u bëra kurioz se sa i zakonshëm është ky problem dhe çfarë lloj "gjobash" paguajmë kur zgjedhim një ose një kornizë tjetër si bazë për një faqe të caktuar.
Projekti më ndihmoi ta kuptoj këtë. .
Të dhëna
Projekti HTTP Archive gjurmon gjithsej 4308655 lidhje me faqet e zakonshme të desktopit dhe 5484239 lidhje me faqet celulare. Ndër metrikat e shumta që lidhen me këto lidhje është një listë e teknologjive që gjenden në faqet përkatëse. Kjo do të thotë që ne mund të mostrojmë mijëra sajte që përdorin korniza dhe biblioteka të ndryshme dhe të mësojmë se sa kod u dërgojnë klientëve dhe sa ngarkesë krijon ky kod në sistemet e përdoruesve.
Unë mblodha të dhënat e marsit 2020, të cilat ishin të dhënat më të fundit në të cilat kisha akses.
Vendosa të krahasoja të dhënat e grumbulluara të Arkivit HTTP në të gjitha sajtet me të dhënat nga sajtet e gjetura duke përdorur React, Vue dhe Angular, megjithëse konsiderova të përdorja edhe materiale të tjera burimore.
Për ta bërë më interesante, shtova gjithashtu sajte që përdorin jQuery në grupin e të dhënave burimore. Kjo bibliotekë është ende shumë e njohur. Ai gjithashtu prezanton një qasje të ndryshme për zhvillimin e uebit nga modeli i Aplikimit me Një Faqe (SPA) të ofruar nga React, Vue dhe Angular.
Lidhje në Arkivin HTTP që përfaqësojnë sajte që janë gjetur se përdorin teknologji me interes
Korniza ose biblioteka
Lidhje me faqet celulare
Lidhje me faqet e rregullta
jQuery
4615474
3714643
Reagoj
489827
241023
Vue
85649
43691
Këndor
19423
18088
Shpresat dhe endrrat
Para se të kalojmë në analizën e të dhënave, dua të flas për atë që do të dëshiroja të shpresoja.
Unë besoj se në një botë ideale, kornizat duhet të shkojnë përtej plotësimit të nevojave të zhvilluesve dhe të ofrojnë disa përfitime specifike për përdoruesin mesatar që punon me faqet tona. Performanca është vetëm një nga ato përfitime. Këtu hyjnë në lojë aksesueshmëria dhe siguria. Por kjo është vetëm më e rëndësishmja.
Pra, në një botë ideale, një lloj kornize duhet ta bëjë të lehtë krijimin e një faqeje me performancë të lartë. Kjo duhet të bëhet ose për shkak të faktit se korniza i jep zhvilluesit një bazë të mirë mbi të cilën të ndërtojë një projekt, ose për shkak të faktit se ai vendos kufizime në zhvillim, parashtron kërkesa për të që ndërlikojnë zhvillimin e diçkaje që kthehet të jetë i ngadalshëm.
Kornizat më të mira duhet t'i bëjnë të dyja: të japin një bazë të mirë dhe të vendosin kufizime në punë, duke ju lejuar të arrini një rezultat të mirë.
Analizimi i vlerave mesatare të të dhënave nuk do të na japë informacionin që na nevojitet. Dhe, në fakt, kjo qasje na lë jashtë vëmendjes . Në vend të kësaj, unë nxirrja përqindje nga të dhënat që kisha. Këto janë 10, 25, 50 (mesatare), 75, 90 përqindje.
Unë jam veçanërisht i interesuar për përqindjet e 10-të dhe të 90-të. Përqindja e 10-të përfaqëson performancën më të mirë (ose të paktën pak a shumë afër më të mirës) për një kornizë të caktuar. Me fjalë të tjera, kjo do të thotë që vetëm 10% e faqeve që përdorin një kornizë të caktuar arrijnë në këtë nivel, ose më lart. Nga ana tjetër, përqindja e 90-të është ana tjetër e medaljes - na tregon se sa keq mund të bëhen gjërat. Përqindja e 90-të është faqet që mbeten pas - ato 10% e poshtme të sajteve që kanë më shumë kodin JS ose kohën më të gjatë për të përpunuar kodin e tyre në fillin kryesor.
Vëllimet e kodit JavaScript
Për të filluar, ka kuptim të analizohet madhësia e kodit JavaScript të transmetuar nga faqe të ndryshme përmes rrjetit.
Sasia e kodit JavaScript (Kb) të transferuar në pajisjet celulare
përqindjet
10
25
50
75
90
Të gjitha faqet
93.4
196.6
413.5
746.8
1201.6
faqet jQuery
110.3
219.8
430.4
748.6
1162.3
Faqet Vue
244.7
409.3
692.1
1065.5
1570.7
Vende këndore
445.1
675.6
1066.4
1761.5
2893.2
Faqet e reagimit
345.8
441.6
690.3
1238.5
1893.6
Sasia e kodit JavaScript të dërguar në pajisjet celulare
Sasia e kodit JavaScript (Kb) e transferuar në pajisjet desktop
përqindjet
10
25
50
75
90
Të gjitha faqet
105.5
226.6
450.4
808.8
1267.3
faqet jQuery
121.7
242.2
458.3
803.4
1235.3
Faqet Vue
248.0
420.1
718.0
1122.5
1643.1
Vende këndore
468.8
716.9
1144.2
1930.0
3283.1
Faqet e reagimit
308.6
469.0
841.9
1472.2
2197.8
Sasia e kodit JavaScript të dërguar në pajisjet desktop
Nëse flasim vetëm për madhësinë e kodit JS që faqet dërgojnë te pajisjet, atëherë gjithçka duket ashtu siç mund të prisni. Domethënë, nëse përdoret një nga kornizat, kjo do të thotë se edhe në një situatë ideale, vëllimi i kodit JavaScript të faqes do të rritet. Kjo nuk është për t'u habitur - nuk mund të bëni një kornizë JavaScript bazën e një siti dhe të prisni që vëllimi i kodit JS të projektit të jetë shumë i ulët.
Ajo që është e jashtëzakonshme në lidhje me këto të dhëna është se disa korniza dhe biblioteka mund të konsiderohen si një pikënisje më e mirë për një projekt se të tjerët. Faqet me jQuery duken më të mirat. Në versionet desktop të sajteve, ato përmbajnë 15% më shumë JavaScript se të gjitha sajtet, dhe në celular përmbajnë 18% më shumë. (Sigurisht që këtu ka një korrupsion të të dhënave. Fakti është se jQuery është i pranishëm në shumë sajte, kështu që është e natyrshme që sajte të tilla të jenë më të lidhura se të tjerat me numrin total të sajteve. Megjithatë, kjo nuk ndikon në atë se sa të papërpunuara të dhënat dalin për çdo kornizë.)
Ndërsa rritja prej 15-18% në vëllimin e kodit është një shifër e dukshme, duke e krahasuar këtë me kornizat dhe bibliotekat e tjera, mund të konkludohet se "taksa" e vendosur nga jQuery është shumë e ulët. Sajtet këndore në përqindjen e 10-të dërgojnë 344% më shumë të dhëna në desktop se të gjitha sajtet dhe 377% më shumë në celular. Faqet React janë vendet më të rënda, duke dërguar 193% më shumë kod në desktop se të gjitha sajtet dhe 270% më shumë në celular.
Më herët, përmenda se megjithëse përdorimi i një kornize do të thotë që një sasi e caktuar kodi do të përfshihet në projekt, në fillimin e punës për të, shpresoj që korniza të jetë në gjendje të kufizojë disi zhvilluesin. Në veçanti, ne po flasim për kufizimin e sasisë maksimale të kodit.
Është interesante që faqet jQuery ndjekin këtë ide. Ndërsa ato janë pak më të rënda se të gjitha sajtet në përqindjen e 10-të (me 15-18%), ato janë pak më të lehta në përqindjen e 90-të me rreth 3% si në desktop ashtu edhe në celular. Kjo nuk do të thotë se ky është një përfitim shumë domethënës, por mund të thuhet se faqet jQuery, të paktën, nuk kanë madhësi të mëdha kodi JavaScript, edhe në versionet e tyre më të mëdha.
Por e njëjta gjë nuk mund të thuhet për kornizat e tjera.
Ashtu si në rastin e përqindjes së 10-të, në vendet e përqindjes së 90-të në Angular dhe React ndryshojnë nga faqet e tjera, por ato ndryshojnë, për fat të keq, për keq.
Në përqindjen e 90-të, faqet Angular dërgojnë 141% më shumë të dhëna në celular se të gjitha sajtet dhe 159% më shumë në desktop. Faqet React dërgojnë 73% më shumë në desktop se të gjitha sajtet dhe 58% më shumë në celular. Madhësia e kodit të faqeve React në përqindjen e 90-të është 2197.8 KB. Kjo do të thotë që sajte të tilla dërgojnë 322.9 KB më shumë të dhëna në pajisjet celulare sesa konkurrentët e tyre më të afërt bazuar në Vue. Hendeku midis faqeve të desktopit të bazuara në Angular dhe React dhe faqeve të tjera është edhe më i madh. Për shembull, faqet e desktopit React dërgojnë 554.7 KB më shumë kod JS në pajisje sesa sajtet ekuivalente Vue.
Koha e nevojshme për të përpunuar kodin JavaScript në temën kryesore
Të dhënat e mësipërme tregojnë qartë se faqet që përdorin kornizat dhe bibliotekat në studim përmbajnë sasi të mëdha kodi JavaScript. Por sigurisht, kjo është vetëm një pjesë e ekuacionit tonë.
Pasi kodi JavaScript të ketë mbërritur në shfletues, ai duhet të sillet në një gjendje funksionale. Sidomos shumë probleme shkaktohen nga ato veprime që duhet të kryhen me kodin në fillin kryesor të shfletuesit. Fillimi kryesor është përgjegjës për përpunimin e veprimeve të përdoruesit, për llogaritjen e stileve, për ndërtimin dhe shfaqjen e paraqitjes së faqes. Nëse e mbingarkoni temën kryesore me detyra JavaScript, ai nuk do të ketë mundësinë të përfundojë me kohë pjesën tjetër të detyrave. Kjo çon në vonesa dhe "frena" në punën e faqeve.
Baza e të dhënave të Arkivit HTTP ka informacion rreth asaj se sa kohë duhet për të përpunuar kodin JavaScript në fillin kryesor të motorit V8. Kjo do të thotë që ne mund t'i mbledhim këto të dhëna dhe të zbulojmë se sa kohë i duhet fillit kryesor për të përpunuar JavaScript-in e sajteve të ndryshme.
Koha e procesorit (në milisekonda) në lidhje me përpunimin e skriptit në pajisjet celulare
përqindjet
10
25
50
75
90
Të gjitha faqet
356.4
959.7
2372.1
5367.3
10485.8
faqet jQuery
575.3
1147.4
2555.9
5511.0
10349.4
Faqet Vue
1130.0
2087.9
4100.4
7676.1
12849.4
Vende këndore
1471.3
2380.1
4118.6
7450.8
13296.4
Faqet e reagimit
2700.1
5090.3
9287.6
14509.6
20813.3
Koha e procesorit në lidhje me përpunimin e skriptit në pajisjet celulare
Koha e procesorit (në milisekonda) në lidhje me përpunimin e skriptit në pajisjet desktop
përqindjet
10
25
50
75
90
Të gjitha faqet
146.0
351.8
831.0
1739.8
3236.8
faqet jQuery
199.6
399.2
877.5
1779.9
3215.5
Faqet Vue
350.4
650.8
1280.7
2388.5
4010.8
Vende këndore
482.2
777.9
1365.5
2400.6
4171.8
Faqet e reagimit
508.0
1045.6
2121.1
4235.1
7444.3
Koha e procesorit në lidhje me përpunimin e skriptit në pajisjet desktop
Këtu mund të shihni diçka shumë të njohur.
Si fillim, faqet me jQuery shpenzojnë dukshëm më pak në përpunimin e JavaScript në lidhjen kryesore sesa faqet e tjera. Në përqindjen e 10-të, krahasuar me të gjitha sajtet, faqet jQuery në celular shpenzojnë 61% më shumë kohë për të përpunuar kodin JS në temën kryesore. Në rastin e faqeve desktop jQuery, koha e përpunimit rritet me 37%. Në përqindjen e 90-të, faqet e jQuery shënojnë shumë afër rezultateve të përgjithshme. Në mënyrë të veçantë, faqet jQuery në pajisjet celulare shpenzojnë 1.3% më pak kohë në lidhjen kryesore se të gjitha sajtet dhe 0.7% më pak kohë në pajisjet desktop.
Në anën tjetër të vlerësimit tonë janë kornizat që karakterizohen nga ngarkesa më e lartë në fillin kryesor. Kjo është, përsëri, Angular dhe React. Dallimi i vetëm midis të dyjave është se ndërsa faqet Angular dërgojnë më shumë kod në shfletues sesa faqet React, faqet Angular marrin më pak kohë CPU për të përpunuar kodin. Shumë më pak.
Në përqindjen e 10-të, faqet Angular të desktopit shpenzojnë 230% më shumë kohë në përpunimin e kodit JS të fillit kryesor sesa të gjitha sajtet. Për faqet celulare, kjo shifër është 313%. Faqet React janë performuesit më të keq. Në desktop, ata shpenzojnë 248% më shumë kohë për përpunimin e kodit se të gjitha sajtet dhe 658% më shumë në celular. 658% nuk është një gabim shtypi. Në përqindjen e 10-të, faqet e React shpenzojnë 2.7 sekonda të kohës së lidhjes kryesore duke përpunuar kodin e tyre.
Përqindja e 90-të, kur krahasohet me këto shifra të mëdha, duket të paktën pak më mirë. Krahasuar me të gjitha sajtet, projektet Angular shpenzojnë 29% më shumë kohë në pajisjet desktop në lidhjen kryesore dhe 27% më shumë kohë në pajisjet celulare. Në rastin e faqeve React, të njëjtat shifra duken respektivisht si 130% dhe 98%.
Devijimet e përqindjes për përqindjen e 90-të duken më mirë se vlerat e ngjashme për përqindjen e 10-të. Por këtu ia vlen të kujtojmë se numrat që tregojnë kohën duken mjaft të frikshëm. Le të themi 20.8 sekonda në lidhjen kryesore celulare për një faqe interneti të ndërtuar me React. (Unë mendoj se historia e asaj që ndodh në të vërtetë gjatë kësaj kohe është e denjë për një artikull të veçantë).
Ekziston një ndërlikim i mundshëm këtu (faleminderit për të tërhequr vëmendjen time ndaj kësaj veçorie dhe për shqyrtimin e kujdesshëm të të dhënave nga ky këndvështrim). Fakti është se shumë sajte përdorin disa mjete të përparme. Në veçanti, kam parë shumë sajte që përdorin jQuery së bashku me React ose Vue, pasi ato sajte po migrojnë nga jQuery në korniza ose biblioteka të tjera. Si rezultat, godita përsëri bazën e të dhënave, këtë herë duke zgjedhur vetëm ato lidhje që korrespondojnë me faqet që përdorin vetëm React, jQuery, Angular ose Vue, por jo ndonjë kombinim të tyre. Ja çfarë kam marrë.
Koha e procesorit (në milisekonda) në lidhje me përpunimin e skripteve në pajisjet celulare në një situatë ku faqet përdorin vetëm një kornizë ose vetëm një bibliotekë
përqindjet
10
25
50
75
90
Faqet që përdorin vetëm jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Faqet që përdorin vetëm Vue
944.0
1716.3
3194.7
5959.6
9843.8
Faqet që përdorin vetëm Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Faqet që përdorin vetëm React
2443.2
4620.5
10061.4
17074.3
24956.3
Koha e procesorit në lidhje me përpunimin e skripteve në pajisjet celulare në një situatë ku faqet përdorin vetëm një kornizë ose vetëm një bibliotekë
Së pari, diçka që nuk është befasuese: kur një sajt përdor vetëm një kornizë ose një bibliotekë, performanca e një sajti të tillë përmirësohet më shpesh sesa jo. Çdo instrument performon më mirë në përqindjet e 10-të dhe 25-të. Kjo ka kuptim. Një sajt që është krijuar duke përdorur një kornizë duhet të funksionojë më mirë se një sajt që është krijuar duke përdorur dy ose më shumë korniza ose biblioteka.
Në fakt, performanca e secilit mjet të përparmë të studiuar duket më mirë në të gjitha rastet, me përjashtim të një përjashtimi kurioz. Ajo që më befasoi ishte se në përqindjen e 50-të dhe më lart, faqet që përdorin React performojnë më keq kur React është e vetmja bibliotekë që përdorin. Meqë ra fjala, kjo ishte arsyeja që unë i paraqes këto të dhëna këtu.
Kjo është pak e çuditshme, por unë do të përpiqem të kërkoj një shpjegim për këtë çuditshmëri.
Nëse një projekt përdor React dhe jQuery, atëherë ai projekt ka të ngjarë diku në gjysmë të rrugës së kalimit nga jQuery në React. Ndoshta ka një bazë kodesh ku këto biblioteka janë të përziera. Meqenëse e kemi parë tashmë që faqet jQuery shpenzojnë më pak kohë në rrjetin kryesor sesa faqet React, kjo mund të na tregojë se zbatimi i disa funksioneve në jQuery e ndihmon sitin të funksionojë pak më mirë.
Por ndërsa projekti kalon nga jQuery në React dhe mbështetet më shumë në React, gjërat po ndryshojnë. Nëse faqja është me të vërtetë me cilësi të lartë, dhe zhvilluesit e faqes përdorin React me kujdes, atëherë gjithçka do të jetë mirë me një faqe të tillë. Por për faqen mesatare të React, përdorimi i gjerë i React do të thotë që filli kryesor është nën ngarkesë të madhe.
Hendeku midis pajisjeve celulare dhe atyre desktop
Një këndvështrim tjetër nga i cili shikoja të dhënat e hulumtuara ishte të studioja se sa i madh është hendeku midis punës me faqet në pajisjet mobile dhe desktop. Nëse flasim për krahasimin e vëllimeve të kodit JavaScript, atëherë një krahasim i tillë nuk zbulon asgjë të tmerrshme. Sigurisht, do të ishte mirë të shiheshin sasi më të vogla të kodit të shkarkueshëm, por nuk ka shumë dallime në sasinë e kodit celular dhe desktop.
Por nëse analizojmë kohën e nevojshme për përpunimin e kodit, një hendek shumë i madh midis pajisjeve celulare dhe atyre desktop bëhet i dukshëm.
Rritje në kohë (përqindje) në lidhje me përpunimin e skripteve në pajisjet celulare në krahasim me desktopin
përqindjet
10
25
50
75
90
Të gjitha faqet
144.1
172.8
185.5
208.5
224.0
faqet jQuery
188.2
187.4
191.3
209.6
221.9
Faqet Vue
222.5
220.8
220.2
221.4
220.4
Vende këndore
205.1
206.0
201.6
210.4
218.7
Faqet e reagimit
431.5
386.8
337.9
242.6
179.6
Ndërsa pritet njëfarë ndryshimi në shpejtësinë e përpunimit të kodit midis një telefoni dhe një laptopi, shifra kaq të mëdha më thonë se kornizat moderne nuk synohen mjaftueshëm në pajisjet me fuqi të ulët dhe se ata po përpiqen të mbyllin hendekun që kanë zbuluar. Edhe në përqindjen e 10-të, faqet e React shpenzojnë 431.5% më shumë kohë në lidhjen kryesore të celularit sesa në fillin kryesor të desktopit. jQuery ka hendekun më të vogël, por edhe këtu shifra përkatëse është 188.2%. Kur zhvilluesit e faqeve të internetit i bëjnë projektet e tyre në atë mënyrë që përpunimi i tyre kërkon më shumë kohë procesori (dhe kjo ndodh, dhe vetëm përkeqësohet me kalimin e kohës), pronarët e pajisjeve me fuqi të ulët duhet të paguajnë për të.
Rezultatet e
Kornizat e mira duhet t'u japin zhvilluesve një bazë të mirë për ndërtimin e projekteve në internet (përsa i përket sigurisë, aksesit, performancës), ose duhet të kenë kufizime të integruara që e bëjnë të vështirë ndërtimin e diçkaje që shkel ato kufizime.
Kjo nuk duket se zbatohet për performancën e projekteve në internet (dhe me sa duket jo për to ).
Vlen të përmendet se vetëm për shkak se faqet React ose Angular shpenzojnë më shumë kohë CPU për përgatitjen e kodit se të tjerët, nuk do të thotë domosdoshmërisht që faqet React janë më intensive CPU sesa faqet Vue gjatë ekzekutimit. Në fakt, të dhënat që kemi shqyrtuar thonë shumë pak për performancën operacionale të kornizave dhe bibliotekave. Ata flasin më shumë për qasjet e zhvillimit që, me vetëdije ose jo, këto korniza mund t'i shtyjnë programuesit. Po flasim për dokumentacion për kornizat, për ekosistemin e tyre, për teknikat e zakonshme të zhvillimit.
Vlen gjithashtu të përmendet diçka që nuk e kemi analizuar këtu, domethënë, sa kohë shpenzon pajisja për të ekzekutuar kodin JavaScript kur lundroni midis faqeve të faqes. Argumenti në favor të SPA është se sapo aplikacioni me një faqe të ngarkohet në shfletues, përdoruesi teorikisht do të jetë në gjendje të hapë më shpejt faqet e faqes. Përvoja ime më thotë se kjo është larg nga një fakt. Por ne nuk kemi të dhëna për të sqaruar këtë çështje.
Ajo që është e qartë është se nëse jeni duke përdorur një kornizë ose bibliotekë për të krijuar një faqe interneti, ju jeni duke bërë një kompromis për sa i përket ngarkimit fillimisht të projektit dhe përgatitjes së tij për të filluar. Kjo vlen edhe për skenarët më pozitivë.
Është krejtësisht e mundur të bëhen disa kompromise në situata të përshtatshme, por është e rëndësishme që zhvilluesit të bëjnë kompromise të tilla me vetëdije.
Por kemi edhe arsye për optimizëm. Jam i emocionuar të shoh se sa ngushtë po punojnë zhvilluesit e Chrome me zhvilluesit e disa prej veglave të përparme që kemi shqyrtuar në një përpjekje për të ndihmuar në përmirësimin e performancës së atyre mjeteve.
Megjithatë, unë jam një person pragmatik. Arkitekturat e reja krijojnë probleme të performancës aq shpesh sa i zgjidhin ato. Dhe kërkon kohë për të rregulluar gabimet. Ashtu siç nuk duhet ta presim do të zgjidhë të gjitha problemet e performancës, nuk duhet ta prisni këtë nga versionet e reja të kornizave tona të preferuara.
Nëse dëshironi të përdorni një nga mjetet e përparme të diskutuara në këtë artikull, kjo do të thotë se do t'ju duhet të bëni përpjekje shtesë për të mos dëmtuar performancën e projektit tuaj ndërkohë. Këtu janë disa konsiderata që duhen marrë parasysh përpara se të filloni një kornizë të re:
- Provoni veten me sens të përbashkët. A keni vërtet nevojë të përdorni kornizën e zgjedhur? JavaScript i pastër sot është i aftë për shumë.
- A ka ndonjë alternativë më të lehtë ndaj kornizës së zgjedhur (si Preact, Svelte ose diçka tjetër) që mund t'ju japë 90% të aftësive të këtij kuadri?
- Nëse po përdorni tashmë një kornizë, merrni parasysh nëse ka diçka që ofron opsione standarde më të mira, më konservatore (p.sh. Nuxt.js në vend të Vue, Next.js në vend të React, etj.).
- Çfarë do juaj Performanca e JavaScript?
- si mundesh një proces zhvillimi për ta bërë më të vështirë injektimin e më shumë kodit JavaScript në një projekt sesa është absolutisht e nevojshme?
- Nëse jeni duke përdorur një kornizë për lehtësinë e zhvillimit, merrni parasysh dërgoni kodin e kornizës tek klientët. Ndoshta ju mund të zgjidhni të gjitha problemet në server?
Zakonisht këto ide ia vlen të shikohen, pavarësisht se çfarë saktësisht keni zgjedhur për zhvillimin e frontit. Por ato janë veçanërisht të rëndësishme kur jeni duke punuar në një projekt të cilit i mungon performanca që në fillim.
Të nderuar lexues! Si e shihni kornizën ideale të JavaScript?
Burimi: www.habr.com