JavaScript ietvaru cena

Nav ātrāka veida, kā palēnināt tīmekļa vietnes darbību (paredzēts vārdu spēlei), kā izmantot tajā JavaScript kodu. Lietojot JavaScript, par to ir jāmaksā ar projektu izpildi ne mazāk kā četras reizes. Lūk, kā vietnes JavaScript kods ielādē lietotāju sistēmas:

  • Faila lejupielāde tÄ«klā.
  • Neiesaiņota pirmkoda parsÄ“Å”ana un kompilÄ“Å”ana pēc lejupielādes.
  • JavaScript koda izpilde.
  • Atmiņas patēriņŔ.

Šī kombinācija izrādās ļoti dārgs.

JavaScript ietvaru cena

Un mēs savos projektos iekļaujam arvien vairāk JS koda. Tā kā organizācijas virzās uz vietnēm, kuras nodroÅ”ina ietvari un bibliotēkas, piemēram, React, Vue un citas, mēs padarām vietņu pamatfunkcionalitāti ļoti atkarÄ«gu no JavaScript.

Esmu redzējis daudzas ļoti smagas vietnes, kurās izmanto JavaScript ietvarus. Bet mans redzējums par Å”o jautājumu ir ļoti tendenciozs. Fakts ir tāds, ka uzņēmumi, ar kuriem es strādāju, vērÅ”as pie manis tieÅ”i tāpēc, ka viņi saskaras ar sarežģītām problēmām vietnes veiktspējas jomā. Rezultātā man radās interese par to, cik Ŕī problēma ir izplatÄ«ta, un par to, kādus "sodus" mēs maksājam, izvēloties vienu vai otru karkasu par pamatu noteiktai vietnei.

Projekts man palīdzēja to saprast. HTTP arhīvs.

Dati

HTTP arhÄ«va projekts kopumā izseko 4308655 5484239 XNUMX saites uz parastajām darbvirsmas vietnēm un XNUMX XNUMX XNUMX saites uz mobilajām vietnēm. Starp daudzajiem rādÄ«tājiem, kas saistÄ«ti ar Ŕīm saitēm, ir attiecÄ«gajās vietnēs atrodamo tehnoloÄ£iju saraksts. Tas nozÄ«mē, ka mēs varam atlasÄ«t tÅ«kstoÅ”iem vietņu, kurās tiek izmantoti dažādi ietvari un bibliotēkas, un uzzināt, cik daudz koda tās nosÅ«ta klientiem un cik lielu slodzi Å”is kods rada lietotāju sistēmās.

Es apkopoju 2020. gada marta datus, kas bija jaunākie dati, kuriem man bija piekļuve.

Es nolēmu salīdzināt apkopotos HTTP arhīva datus visās vietnēs ar datiem no vietnēm, kas atrastas, izmantojot React, Vue un Angular, lai gan apsvēru iespēju izmantot arī citus avota materiālus.

Lai padarÄ«tu to interesantāku, es avota datu kopai pievienoju arÄ« vietnes, kurās tiek izmantots jQuery. Å Ä« bibliotēka joprojām ir ļoti populāra. Tas arÄ« ievieÅ” atŔķirÄ«gu pieeju tÄ«mekļa izstrādei nekā vienas lapas lietojumprogrammas (SPA) modelis, ko piedāvā React, Vue un Angular.

Saites HTTP arhÄ«vā, kas pārstāv vietnes, kurās tiek izmantotas interesējoŔās tehnoloÄ£ijas

Ietvars vai bibliotēka
Saites uz mobilajām vietnēm
Saites uz parastajām vietnēm

jQuery
4615474
3714643

Reaģēt
489827
241023

Vue
85649
43691

leņķa
19423
18088

Cerības un sapņi

Pirms pārejam uz datu analīzi, es vēlos runāt par to, uz ko es vēlētos cerēt.

Es uzskatu, ka ideālā pasaulē ietvariem ir jāsniedz ne tikai izstrādātāju vajadzÄ«bas, bet arÄ« jāsniedz kāds Ä«paÅ”s ieguvums vidusmēra lietotājam, kurÅ” strādā ar mÅ«su vietnēm. Veiktspēja ir tikai viena no Ŕīm priekÅ”rocÄ«bām. Å eit spēlē pieejamÄ«ba un droŔība. Bet tas ir tikai vissvarÄ«gākais.

Tātad ideālā pasaulē kāda veida sistēmai vajadzētu atvieglot augstas veiktspējas vietnes izveidi. Tas jādara vai nu tāpēc, ka ietvars sniedz izstrādātājam pienācīgu bāzi, uz kura būvēt projektu, vai arī tāpēc, ka tas nosaka attīstības ierobežojumus, izvirza tam prasības, kas sarežģī tā izstrādi, kas pagriežas. būt lēnam.

Labākajiem ietvariem vajadzētu darīt abus: dot labu bāzi un uzlikt ierobežojumus darbam, ļaujot sasniegt pienācīgu rezultātu.

Datu vidējo vērtÄ«bu analÄ«ze nesniegs mums nepiecieÅ”amo informāciju. Un patiesÄ«bā Ŕī pieeja atstāj mÅ«su uzmanÄ«bu daudz svarÄ«ga. Tā vietā es atvasināju procentus no maniem datiem. Tās ir 10, 25, 50 (vidējā), 75, 90 procentiles.

Mani Ä«paÅ”i interesē 10. un 90. procentile. 10. procentile atspoguļo vislabāko veiktspēju (vai vismaz vairāk vai mazāk tuvu labākajam) konkrētai sistēmai. Citiem vārdiem sakot, tas nozÄ«mē, ka tikai 10% vietņu, kas izmanto noteiktu sistēmu, sasniedz Å”o vai augstāku lÄ«meni. Savukārt 90. procentile ir medaļas otra puse ā€” tā parāda, cik slikti var kļūt. 90. procentile ir vietnes, kas atrodas aiz muguras ā€” tās ir 10% vietņu, kurām ir visvairāk JS koda vai kurām ir visilgākais laiks koda apstrādei galvenajā pavedienā.

JavaScript koda apjomi

Vispirms ir lietderīgi analizēt JavaScript koda lielumu, ko tīklā pārraida dažādas vietnes.

Uz mobilajām ierīcēm pārsūtītā JavaScript koda apjoms (Kb).

Procentiles
10
25
50
75
90

Visas vietnes
93.4 
196.6 
413.5 
746.8 
1201.6 

jQuery vietnes
110.3 
219.8 
430.4 
748.6 
1162.3 

Vue vietnes
244.7 
409.3 
692.1 
1065.5 
1570.7 

Leņķiskās vietas
445.1 
675.6 
1066.4 
1761.5 
2893.2 

Reaģēt vietnes
345.8 
441.6 
690.3 
1238.5 
1893.6 

JavaScript ietvaru cena
Uz mobilajām ierīcēm nosūtītā JavaScript koda daudzums

Uz galddatoriem pārsūtītā JavaScript koda daudzums (Kb).

Procentiles
10
25
50
75
90

Visas vietnes
105.5 
226.6 
450.4 
808.8 
1267.3 

jQuery vietnes
121.7 
242.2 
458.3 
803.4 
1235.3 

Vue vietnes
248.0 
420.1 
718.0 
1122.5 
1643.1 

Leņķiskās vietas
468.8 
716.9 
1144.2 
1930.0 
3283.1 

Reaģēt vietnes
308.6 
469.0 
841.9 
1472.2 
2197.8 

JavaScript ietvaru cena
Uz galddatoriem nosūtītā JavaScript koda daudzums

Ja mēs runājam tikai par JS koda lielumu, ko vietnes nosÅ«ta ierÄ«cēm, tad viss izskatās apmēram tā, kā jÅ«s varētu gaidÄ«t. Proti, ja tiek izmantots kāds no ietvariem, tas nozÄ«mē, ka pat ideālā situācijā palielināsies vietnes JavaScript koda apjoms. Tas nav pārsteidzoÅ”i - jÅ«s nevarat izveidot JavaScript ietvaru par vietnes pamatu un gaidÄ«t, ka projekta JS koda apjoms bÅ«s ļoti zems.

Å ajos datos ir ievērojams tas, ka dažus ietvarus un bibliotēkas var uzskatÄ«t par labāku sākuma punktu projektam nekā citas. Vietnes ar jQuery izskatās vislabāk. Vietņu datora versijās tajās ir par 15% vairāk JavaScript nekā visās vietnēs, savukārt mobilajās ierÄ«cēs tās satur par 18% vairāk. (JāatzÄ«st, ka Å”eit ir daži datu bojājumi. Fakts ir tāds, ka jQuery atrodas daudzās vietnēs, tāpēc ir tikai dabiski, ka Ŕādas vietnes ir cieŔāk saistÄ«tas ar kopējo vietņu skaitu nekā citas. Tomēr tas neietekmē to, cik neapstrādāts. dati tiek izvadÄ«ti katram ietvaram.)

Lai gan koda apjoma pieaugums par 15-18% ir ievērojams rādÄ«tājs, salÄ«dzinot to ar citiem ietvariem un bibliotēkām, var secināt, ka jQuery iekasētais "nodoklis" ir ļoti zems. Leņķiskās vietnes, kas atrodas 10. procentilē, nosÅ«ta par 344% vairāk datu uz galddatoru nekā visas vietnes un par 377% vairāk uz mobilajām ierÄ«cēm. React vietnes ir nākamās smagākās, nosÅ«ta par 193% vairāk koda uz darbvirsmu nekā visas vietnes un par 270% vairāk uz mobilajām ierÄ«cēm.

IepriekÅ” minēju, ka, lai gan ietvara izmantoÅ”ana nozÄ«mē, ka projektā tiks iekļauts noteikts koda daudzums, paŔā darba sākumā pie tā ceru, ka ietvars spēj kaut kā ierobežot izstrādātāju. Jo Ä«paÅ”i mēs runājam par maksimālā koda daudzuma ierobežoÅ”anu.

Interesanti, ka jQuery vietnes ievēro Å”o ideju. Lai gan tie ir nedaudz smagāki par visām vietnēm 10. procentiles lÄ«menÄ« (par 15ā€“18%), 90. procentilē tie ir nedaudz vieglāki ā€” aptuveni 3% gan galddatoros, gan mobilajās ierÄ«cēs. Tas nenozÄ«mē, ka tas ir ļoti nozÄ«mÄ«gs ieguvums, taču var teikt, ka vismaz jQuery vietnēm nav milzÄ«gu JavaScript koda izmēru, pat to lielākajās versijās.

Taču to nevar teikt par citiem ietvariem.

Tāpat kā 10. procentiles gadÄ«jumā, 90. procentiles vietās Angular un React atŔķiras no citām vietnēm, taču tās diemžēl atŔķiras uz sliktāko pusi.

Pie 90. procentiles Angular vietnes uz mobilajām ierÄ«cēm sÅ«ta par 141% vairāk datu nekā visas vietnes un par 159% vairāk uz galddatoriem. Reakcijas vietnes uz galddatoriem sÅ«ta par 73% vairāk nekā visas vietnes un par 58% vairāk uz mobilajām ierÄ«cēm. React vietņu koda lielums 90. procentile ir 2197.8 KB. Tas nozÄ«mē, ka Ŕādas vietnes uz mobilajām ierÄ«cēm nosÅ«ta par 322.9 KB vairāk datu nekā to tuvākie konkurenti, pamatojoties uz Vue. Plaisa starp darbvirsmas vietnēm, kuru pamatā ir Angular and React, un citām vietnēm ir vēl lielāka. Piemēram, darbvirsmas React vietnes uz ierÄ«cēm nosÅ«ta par 554.7 KB vairāk JS koda nekā lÄ«dzvērtÄ«gas Vue vietnes.

Laiks, kas nepiecieŔams JavaScript koda apstrādei galvenajā pavedienā

IepriekÅ” minētie dati skaidri norāda, ka vietnēs, kurās tiek izmantoti pētāmie ietvari un bibliotēkas, ir liels JavaScript koda daudzums. Bet, protams, tā ir tikai viena daļa no mÅ«su vienādojuma.

Kad JavaScript kods ir nonācis pārlÅ«kprogrammā, tas ir jāpārnes darba stāvoklÄ«. ÄŖpaÅ”i daudz problēmu rada tās darbÄ«bas, kas jāveic ar kodu galvenajā pārlÅ«kprogrammas pavedienā. Galvenais pavediens ir atbildÄ«gs par lietotāja darbÄ«bu apstrādi, stilu aprēķināŔanu, lapas izkārtojuma veidoÅ”anu un parādÄ«Å”anu. Ja jÅ«s pārslogojat galveno pavedienu ar JavaScript uzdevumiem, tam nebÅ«s iespējas laikus izpildÄ«t pārējos uzdevumus. Tas noved pie kavÄ“Å”anās un "bremzÄ“Å”anas" lapu darbā.

HTTP arhÄ«va datu bāzē ir informācija par to, cik ilgs laiks nepiecieÅ”ams JavaScript koda apstrādei V8 dzinēja galvenajā pavedienā. Tas nozÄ«mē, ka mēs varam apkopot Å”os datus un uzzināt, cik daudz laika galvenajam pavedienam nepiecieÅ”ams, lai apstrādātu dažādu vietņu JavaScript.

Procesora laiks (milisekundēs), kas saistīts ar skripta apstrādi mobilajās ierīcēs

Procentiles
10
25
50
75
90

Visas vietnes
356.4
959.7
2372.1
5367.3
10485.8

jQuery vietnes
575.3
1147.4
2555.9
5511.0
10349.4

Vue vietnes
1130.0
2087.9
4100.4
7676.1
12849.4

Leņķiskās vietas
1471.3
2380.1
4118.6
7450.8
13296.4

Reaģēt vietnes
2700.1
5090.3
9287.6
14509.6
20813.3

JavaScript ietvaru cena
Procesora laiks, kas saistīts ar skriptu apstrādi mobilajās ierīcēs

Procesora laiks (milisekundēs), kas saistīts ar skriptu apstrādi galddatoru ierīcēs

Procentiles
10
25
50
75
90

Visas vietnes
146.0
351.8
831.0
1739.8
3236.8

jQuery vietnes
199.6
399.2
877.5
1779.9
3215.5

Vue vietnes
350.4
650.8
1280.7
2388.5
4010.8

Leņķiskās vietas
482.2
777.9
1365.5
2400.6
4171.8

Reaģēt vietnes
508.0
1045.6
2121.1
4235.1
7444.3

JavaScript ietvaru cena
Procesora laiks, kas saistīts ar skriptu apstrādi galddatoru ierīcēs

Šeit jūs varat redzēt kaut ko ļoti pazīstamu.

Sākumā vietnes ar jQuery tērē ievērojami mazāk par JavaScript apstrādi galvenajā pavedienā nekā citas vietnes. Pie 10. procentiles, salÄ«dzinot ar visām vietnēm, jQuery vietnes mobilajās ierÄ«cēs pavada par 61% vairāk laika, apstrādājot JS kodu galvenajā pavedienā. Darbvirsmas jQuery vietņu gadÄ«jumā apstrādes laiks palielinās par 37%. Pie 90. procentiles jQuery vietņu rezultāts ir ļoti tuvu kopējiem rādÄ«tājiem. Konkrēti, jQuery vietnes mobilajās ierÄ«cēs galvenajā pavedienā pavada par 1.3% mazāk laika nekā visas vietnes un par 0.7% mazāk laika galddatoros.

MÅ«su vērtējuma otrā pusē ir karkasi, kuriem raksturÄ«ga lielākā slodze uz galveno pavedienu. Tas atkal ir Angular and React. VienÄ«gā atŔķirÄ«ba starp abām ir tā, ka, lai gan Angular vietnes pārlÅ«kprogrammām sÅ«ta vairāk koda nekā React vietnes, Angular vietnēm koda apstrādei nepiecieÅ”ams mazāk CPU laika. Daudz mazāk.

Pie 10. procentiles darbvirsmas Angular vietnes galvenajā pavedienā, apstrādājot JS kodu, pavada par 230% vairāk laika nekā visas vietnes. Mobilajām vietnēm Å”is rādÄ«tājs ir 313%. Reakcijas vietnes darbojas vissliktāk. Datoros viņi pavada par 248% vairāk laika, apstrādājot kodu nekā visās vietnēs, un par 658% vairāk laika mobilajās ierÄ«cēs. 658% nav drukas kļūda. Pie 10. procentiles React vietnes sava koda apstrādei pavada 2.7 sekundes no galvenā pavediena laika.

90. procentile, salÄ«dzinot ar Å”iem milzÄ«gajiem skaitļiem, izskatās vismaz nedaudz labāk. SalÄ«dzinot ar visām vietnēm, Angular projekti galvenajā pavedienā pavada par 29% vairāk laika galddatoru ierÄ«cēs un par 27% vairāk laika mobilajās ierÄ«cēs. React vietņu gadÄ«jumā tie paÅ”i skaitļi izskatās attiecÄ«gi 130% un 98%.

Procentuālās novirzes 90. procentilei izskatās labāk nekā lÄ«dzÄ«gas vērtÄ«bas 10. procentilei. Bet Å”eit ir vērts atcerēties, ka skaitļi, kas norāda laiku, Ŕķiet diezgan biedējoÅ”i. Pieņemsim, ka 20.8 sekundes galvenajā mobilajā pavedienā vietnei, kas izveidota ar React. (Es domāju, ka stāsts par to, kas patiesÄ«bā notiek Å”ajā laikā, ir atseviŔķa raksta vērts).

Å eit ir viena iespējamā komplikācija (paldies Džeremijs par to, ka pievērsu manu uzmanÄ«bu Å”ai funkcijai un rÅ«pÄ«gi apsvēru datus no Ŕī viedokļa). Fakts ir tāds, ka daudzas vietnes izmanto vairākus priekÅ”gala rÄ«kus. Jo Ä«paÅ”i esmu redzējis daudzas vietnes, kurās kopā ar React vai Vue tiek izmantots jQuery, jo Ŕīs vietnes migrē no jQuery uz citiem ietvariem vai bibliotēkām. Rezultātā es vēlreiz nokļuvu datubāzē, Å”oreiz atlasot tikai tās saites, kas atbilst vietnēm, kuras izmanto tikai React, jQuery, Angular vai Vue, bet ne jebkuru to kombināciju. LÅ«k, ko es saņēmu.

Procesora laiks (milisekundēs), kas saistīts ar skriptu apstrādi mobilajās ierīcēs situācijā, kad vietnes izmanto tikai vienu ietvaru vai tikai vienu bibliotēku

Procentiles
10
25
50
75
90

Vietnes, kurās tiek izmantots tikai jQuery
542.9
1062.2
2297.4
4769.7
8718.2

Vietnes, kurās tiek izmantots tikai Vue
944.0
1716.3
3194.7
5959.6
9843.8

Vietnes, kurās tiek izmantots tikai Angular
1328.9
2151.9
3695.3
6629.3
11607.7

Vietnes, kas izmanto tikai React
2443.2
4620.5
10061.4
17074.3
24956.3

JavaScript ietvaru cena
Procesora laiks, kas saistīts ar skriptu apstrādi mobilajās ierīcēs situācijā, kad vietnes izmanto tikai vienu ietvaru vai tikai vienu bibliotēku

Pirmkārt, tas nav pārsteidzoÅ”i: ja vietne izmanto tikai vienu sistēmu vai vienu bibliotēku, Ŕādas vietnes veiktspēja biežāk uzlabojas. Katrs instruments darbojas labāk 10. un 25. procentilē. Tam ir jēga. Vietnei, kas izveidota, izmantojot vienu ietvaru, vajadzētu darboties labāk nekā vietnei, kas izveidota, izmantojot divus vai vairākus ietvarus vai bibliotēkas.

Faktiski katra izpētÄ«tā priekÅ”gala rÄ«ka veiktspēja izskatās labāka visos gadÄ«jumos, izņemot vienu dÄ«vainu izņēmumu. Mani pārsteidza tas, ka 50. procentile un augstāk vietņu, kurās tiek izmantota React, darbÄ«ba ir sliktāka, ja React ir vienÄ«gā bibliotēka, ko tās izmanto. Tas, starp citu, bija iemesls, kāpēc es Å”eit sniedzu Å”os datus.

Tas ir nedaudz dÄ«vaini, bet es tomēr mēģināŔu meklēt izskaidrojumu Å”ai dÄ«vainÄ«bai.

Ja projektā tiek izmantots gan React, gan jQuery, iespējams, Å”is projekts ir kaut kur pusceļā, pārejot no jQuery uz React. VarbÅ«t tai ir kodu bāze, kurā Ŕīs bibliotēkas ir sajauktas. Tā kā mēs jau esam redzējuÅ”i, ka jQuery vietnes galvenajā pavedienā pavada mazāk laika nekā React vietnes, tas var norādÄ«t, ka dažu jQuery funkcionalitātes ievieÅ”ana palÄ«dz vietnei darboties nedaudz labāk.

Taču, projektam pārejot no jQuery uz React un vairāk paļaujoties uz React, lietas mainās. Ja vietne ir patieŔām kvalitatÄ«va, un vietnes izstrādātāji rÅ«pÄ«gi izmanto React, tad ar Ŕādu vietni viss bÅ«s kārtÄ«bā. Bet vidējai React vietnei plaÅ”a React izmantoÅ”ana nozÄ«mē, ka galvenais pavediens ir pakļauts lielai slodzei.

Plaisa starp mobilajām ierīcēm un galddatoriem

Vēl viens skatÄ«jums, no kura es aplÅ«koju izpētÄ«tos datus, bija izpētÄ«t, cik liela ir atŔķirÄ«ba starp darbu ar vietnēm mobilajās ierÄ«cēs un galddatoros. Ja runājam par JavaScript koda apjomu salÄ«dzināŔanu, tad Ŕāds salÄ«dzinājums neko briesmÄ«gu neatklāj. Protams, bÅ«tu jauki redzēt mazāku lejupielādējamā koda daudzumu, taču mobilā un galddatora koda daudzumā nav lielas atŔķirÄ«bas.

Bet, ja analizējam laiku, kas nepiecieÅ”ams koda apstrādei, kļūst pamanāma ļoti liela atŔķirÄ«ba starp mobilajām ierÄ«cēm un galddatoriem.

Laika pieaugums (procentos), kas saistīts ar skriptu apstrādi mobilajās ierīcēs, salīdzinot ar datoriem

Procentiles
10
25
50
75
90

Visas vietnes
144.1
172.8
185.5
208.5
224.0

jQuery vietnes
188.2
187.4
191.3
209.6
221.9

Vue vietnes
222.5
220.8
220.2
221.4
220.4

Leņķiskās vietas
205.1
206.0
201.6
210.4
218.7

Reaģēt vietnes
431.5
386.8
337.9
242.6
179.6

Lai gan ir sagaidāma zināma tālruņa un klēpjdatora koda apstrādes ātruma atŔķirÄ«ba, tik lieli skaitļi man liecina, ka mÅ«sdienu sistēmas nav pietiekami mērķētas uz mazjaudas ierÄ«cēm un ka tās cenÅ”as novērst atklāto plaisu. Pat pie 10. procentiles React vietnes mobilajā galvenajā pavedienā pavada par 431.5% vairāk laika nekā darbvirsmas galvenajā pavedienā. jQuery ir vismazākā atstarpe, taču arÄ« Å”eit atbilstoÅ”ais rādÄ«tājs ir 188.2%. Kad vietņu izstrādātāji savus projektus veido tā, ka to apstrāde prasa vairāk procesora laika (un tas notiek, un ar laiku tas tikai pasliktinās), mazjaudas ierīču Ä«paÅ”niekiem par to ir jāmaksā.

Rezultāti

Labiem ietvariem ir jāsniedz izstrādātājiem labs pamats tÄ«mekļa projektu veidoÅ”anai (droŔības, pieejamÄ«bas, veiktspējas ziņā), vai arÄ« tiem ir jābÅ«t iebÅ«vētiem ierobežojumiem, kas apgrÅ«tina tādas lietas izveidi, kas pārkāpj Å”os ierobežojumus.

Šķiet, ka tas neattiecas uz tīmekļa projektu veiktspēju (un, iespējams, ne uz tiem pieejamība).

Ir vērts atzÄ«mēt, ka tas, ka React vai Angular vietnes pavada vairāk CPU laika koda sagatavoÅ”anai nekā citas, nenozÄ«mē, ka React vietnes darbÄ«bas laikā ir vairāk CPU ietilpÄ«gas nekā Vue vietnes. Faktiski mÅ«su pārskatÄ«tie dati ļoti maz stāsta par ietvaru un bibliotēku darbÄ«bas veiktspēju. Viņi vairāk runā par attÄ«stÄ«bas pieejām, kuras, apzināti vai nē, Ŕīs sistēmas var virzÄ«t programmētājus. Mēs runājam par ietvaru dokumentāciju, par to ekosistēmu, par kopÄ«gām izstrādes metodēm.

Ir arÄ« vērts pieminēt kaut ko, ko mēs Å”eit neanalizējām, proti, cik daudz laika ierÄ«ce pavada, izpildot JavaScript kodu, pārvietojoties starp vietnes lapām. Arguments par labu SPA ir tāds, ka pēc vienas lapas aplikācijas ielādÄ“Å”anas pārlÅ«kprogrammā lietotājs teorētiski varēs ātrāk atvērt vietnes lapas. Mana pieredze liecina, ka tas ir tālu no fakta. Bet mums nav datu, lai noskaidrotu Å”o jautājumu.

Skaidrs ir tas, ka, ja tīmekļa vietnes izveidei izmantojat ietvaru vai bibliotēku, jūs veicat kompromisu, sākotnēji ielādējot projektu un sagatavojot to darbam. Tas attiecas pat uz vispozitīvākajiem scenārijiem.

AtbilstoŔās situācijās ir pilnÄ«gi iespējams panākt dažus kompromisus, taču ir svarÄ«gi, lai izstrādātāji Ŕādus kompromisus pieņemtu apzināti.

Taču mums ir arÄ« pamats optimismam. Es priecājos redzēt, cik cieÅ”i Chrome izstrādātāji sadarbojas ar dažu mÅ«su pārskatÄ«to priekÅ”gala rÄ«ku izstrādātājiem, lai palÄ«dzētu uzlabot Å”o rÄ«ku veiktspēju.

Tomēr esmu pragmatisks cilvēks. Jaunas arhitektÅ«ras rada veiktspējas problēmas tik bieži, cik tās tās atrisina. Un ir nepiecieÅ”ams laiks, lai novērstu kļūdas. Tāpat kā mums nevajadzētu gaidÄ«t jaunas tÄ«kla tehnoloÄ£ijas atrisinās visas veiktspējas problēmas, jums nevajadzētu to gaidÄ«t no mÅ«su iecienÄ«tāko sistēmu jaunajām versijām.

Ja vēlaties izmantot kādu no Å”ajā rakstā apskatÄ«tajiem priekÅ”gala rÄ«kiem, tas nozÄ«mē, ka tikmēr jums bÅ«s jāpieliek papildu pÅ«les, lai nekaitētu sava projekta veiktspējai. Å eit ir daži apsvērumi, kas jāņem vērā pirms jaunas sistēmas izveides.

  • Pārbaudi sevi ar veselo saprātu. Vai tieŔām ir jāizmanto izvēlētais ietvars? TÄ«rs JavaScript mÅ«sdienās spēj daudz.
  • Vai ir kāda vieglāka alternatÄ«va izvēlētajam ietvaram (piemēram, Preact, Svelte vai kaut kas cits), kas var sniegt jums 90% no Ŕī ietvara iespējām?
  • Ja jau izmantojat ietvaru, apsveriet, vai ir kaut kas, kas piedāvā labākas, konservatÄ«vākas standarta opcijas (piemēram, Nuxt.js, nevis Vue, Next.js, nevis React, un tā tālāk).
  • Kas bÅ«s jÅ«su budžets JavaScript veiktspēja?
  • Kā tu vari ierobežot izstrādes process, lai projektā bÅ«tu grÅ«tāk ievadÄ«t vairāk JavaScript koda, nekā tas ir absolÅ«ti nepiecieÅ”ams?
  • Ja izmantojat ietvaru, lai atvieglotu attÄ«stÄ«bu, apsveriet to Vai jums ir nepiecieÅ”ams nosÅ«tÄ«t ietvara kodu klientiem. VarbÅ«t varat atrisināt visas problēmas serverÄ«?

Parasti Ŕīs idejas ir vērts aplÅ«kot neatkarÄ«gi no tā, ko tieÅ”i esat izvēlējies priekÅ”gala izstrādei. Taču tie ir Ä«paÅ”i svarÄ«gi, ja strādājat pie projekta, kuram jau no paÅ”a sākuma trÅ«kst veiktspējas.

Cienījamie lasītāji! Kā jūs redzat ideālo JavaScript ietvaru?

JavaScript ietvaru cena

Avots: www.habr.com

Pievieno komentāru