Hakuna njia ya haraka ya kupunguza kasi ya tovuti (pun iliyokusudiwa) kuliko kutumia rundo la msimbo wa JavaScript juu yake. Unapotumia JavaScript, unapaswa kulipia na utendaji wa miradi sio chini ya mara nne. Hivi ndivyo msimbo wa JavaScript wa tovuti unavyopakia mifumo ya watumiaji:
- Inapakua faili kupitia mtandao.
- Kuchanganua na kukusanya msimbo wa chanzo ambao haujapakiwa baada ya kupakua.
- Utekelezaji wa msimbo wa JavaScript.
- Matumizi ya kumbukumbu.
Mchanganyiko huu unageuka .
Na tunajumuisha nambari zaidi na zaidi za JS katika miradi yetu. Mashirika yanapoelekea kwenye tovuti zinazoendeshwa na mifumo na maktaba kama vile React, Vue na nyinginezo, tunafanya utendakazi wa msingi wa tovuti utegemee sana JavaScript.
Nimeona tovuti nyingi nzito sana kwa kutumia mifumo ya JavaScript. Lakini maono yangu ya suala hilo yana upendeleo mkubwa. Ukweli ni kwamba makampuni ninayofanya kazi nayo yanageuka kwangu kwa sababu yanakabiliwa na matatizo magumu katika uwanja wa utendaji wa tovuti. Kama matokeo, nilitamani kujua jinsi shida hii ni ya kawaida, na ni aina gani ya "adhabu" tunayolipa tunapochagua mfumo mmoja au mwingine kama msingi wa tovuti fulani.
Mradi ulinisaidia kujua hili. .
Data
Mradi wa Kumbukumbu ya HTTP hufuatilia jumla ya viungo 4308655 vya tovuti za kawaida za mezani na viungo 5484239 vya tovuti za simu. Miongoni mwa vipimo vingi vinavyohusishwa na viungo hivi ni orodha ya teknolojia inayopatikana kwenye tovuti husika. Hii ina maana kwamba tunaweza sampuli ya maelfu ya tovuti zinazotumia mifumo na maktaba mbalimbali na kujifunza kuhusu kiasi cha msimbo wanachotuma kwa wateja na ni kiasi gani cha upakiaji wa msimbo huu kwenye mifumo ya watumiaji.
Nilikusanya data ya Machi 2020, ambayo ilikuwa data ya hivi majuzi zaidi niliyoweza kufikia.
Niliamua kulinganisha data iliyojumlishwa ya Kumbukumbu ya HTTP kwenye tovuti zote na data kutoka kwa tovuti zinazopatikana kwa kutumia React, Vue, na Angular, ingawa nilizingatia kutumia nyenzo nyingine chanzo pia.
Ili kuifanya ipendeze zaidi, niliongeza pia tovuti zinazotumia jQuery kwenye seti ya data ya chanzo. Maktaba hii bado ni maarufu sana. Pia inatanguliza mbinu tofauti ya ukuzaji wa wavuti kuliko muundo wa Maombi ya Ukurasa Mmoja (SPA) unaotolewa na React, Vue na Angular.
Viungo kwenye Kumbukumbu ya HTTP vinavyowakilisha tovuti ambazo zimegundulika kuwa zinatumia teknolojia zinazovutia
Mfumo au maktaba
Viungo vya tovuti za simu
Viungo vya tovuti za kawaida
jQuery
4615474
3714643
Tenda
489827
241023
Vue
85649
43691
Angular
19423
18088
Matumaini na ndoto
Kabla ya kuendelea na uchambuzi wa data, nataka kuzungumza juu ya kile ningependa kutumaini.
Ninaamini kuwa katika ulimwengu bora, mifumo inapaswa kwenda zaidi ya kukidhi mahitaji ya wasanidi programu na kutoa manufaa fulani kwa mtumiaji wastani anayefanya kazi na tovuti zetu. Utendaji ni moja tu ya faida hizo. Hapa ndipo ufikivu na usalama hutumika. Lakini hii ndiyo tu muhimu zaidi.
Kwa hivyo, katika ulimwengu bora, aina fulani ya mfumo inapaswa iwe rahisi kuunda tovuti ya utendaji wa juu. Hii inapaswa kufanywa ama kwa sababu ya ukweli kwamba mfumo unampa msanidi msingi msingi mzuri wa kujenga mradi, au kwa sababu ya ukweli kwamba inaweka vizuizi kwa maendeleo, inaweka mahitaji yake ambayo yanachanganya maendeleo ya kitu kinachogeuka. kuwa mwepesi.
Mifumo bora inapaswa kufanya zote mbili: kutoa msingi mzuri, na kuweka vikwazo kwenye kazi, kukuwezesha kufikia matokeo mazuri.
Kuchambua maadili ya wastani ya data haitatupa habari tunayohitaji. Na, kwa kweli, njia hii inaacha mawazo yetu . Badala yake, nilipata asilimia kutoka kwa data niliyokuwa nayo. Hizi ni 10, 25, 50 (wastani), 75, 90 percentiles.
Ninavutiwa sana na asilimia ya 10 na 90. Asilimia ya 10 inawakilisha utendakazi bora zaidi (au angalau karibu zaidi au kidogo na bora zaidi) kwa mfumo mahususi. Kwa maneno mengine, hii ina maana kwamba ni 10% tu ya tovuti zinazotumia mfumo fulani hufikia kiwango hiki, au cha juu zaidi. Asilimia 90, kwa upande mwingine, ni upande mwingine wa sarafu - inatuonyesha jinsi mambo mabaya yanaweza kuwa. Asilimia 90 ni tovuti zinazofuata nyumaβzile 10% za chini za tovuti ambazo zina msimbo mwingi wa JS au muda mrefu zaidi kuchakata misimbo yao kwenye mazungumzo kuu.
Kiasi cha msimbo wa JavaScript
Kuanza, ni mantiki kuchambua saizi ya msimbo wa JavaScript unaopitishwa na tovuti tofauti kwenye mtandao.
Kiasi cha msimbo wa JavaScript (Kb) uliohamishwa kwenye vifaa vya mkononi
Asilimia
10
25
50
75
90
Tovuti zote
93.4
196.6
413.5
746.8
1201.6
tovuti za jQuery
110.3
219.8
430.4
748.6
1162.3
Angalia tovuti
244.7
409.3
692.1
1065.5
1570.7
Maeneo ya angular
445.1
675.6
1066.4
1761.5
2893.2
React Sites
345.8
441.6
690.3
1238.5
1893.6
Kiasi cha msimbo wa JavaScript uliotumwa kwa vifaa vya rununu
Kiasi cha msimbo wa JavaScript (Kb) uliohamishwa kwenye vifaa vya eneo-kazi
Asilimia
10
25
50
75
90
Tovuti zote
105.5
226.6
450.4
808.8
1267.3
tovuti za jQuery
121.7
242.2
458.3
803.4
1235.3
Angalia tovuti
248.0
420.1
718.0
1122.5
1643.1
Maeneo ya angular
468.8
716.9
1144.2
1930.0
3283.1
React Sites
308.6
469.0
841.9
1472.2
2197.8
Kiasi cha msimbo wa JavaScript uliotumwa kwa vifaa vya mezani
Ikiwa tutazungumza tu kuhusu ukubwa wa msimbo wa JS ambao tovuti hutuma kwa vifaa, basi kila kitu kinaonekana kama unavyoweza kutarajia. Yaani, ikiwa moja ya mifumo inatumiwa, hii inamaanisha kuwa hata katika hali nzuri, kiasi cha nambari ya JavaScript ya tovuti itaongezeka. Hii haishangazi - huwezi kufanya mfumo wa JavaScript kuwa msingi wa tovuti na kutarajia kwamba kiasi cha msimbo wa JS wa mradi kitakuwa cha chini sana.
Kinachoshangaza kuhusu data hii ni kwamba baadhi ya mifumo na maktaba zinaweza kuchukuliwa kuwa mahali pazuri pa kuanzia kwa mradi kuliko zingine. Tovuti zilizo na jQuery zinaonekana bora zaidi. Kwenye matoleo ya eneo-kazi la tovuti, yana JavaScript 15% zaidi kuliko tovuti zote, na kwenye simu ya mkononi yana 18% zaidi. (Ni kweli, kuna ufisadi fulani wa data hapa. Ukweli ni kwamba jQuery iko kwenye tovuti nyingi, kwa hivyo ni kawaida kwamba tovuti kama hizo zinahusishwa kwa karibu zaidi kuliko zingine na jumla ya idadi ya tovuti. Hata hivyo, hii haiathiri jinsi ghafi data ni pato kwa kila mfumo.)
Ingawa ongezeko la 15-18% la ujazo wa msimbo ni takwimu inayojulikana, ikilinganishwa na mifumo mingine na maktaba, mtu anaweza kuhitimisha kuwa "kodi" inayotozwa na jQuery ni ya chini sana. Tovuti za pembe katika asilimia ya 10 hutuma data zaidi ya 344% kwenye kompyuta ya mezani kuliko tovuti zote, na 377% zaidi kwa simu ya mkononi. Tovuti za React ndizo zinazofuata kwa uzito zaidi, zinazotuma 193% ya msimbo zaidi kwenye eneo-kazi kuliko tovuti zote, na 270% zaidi kwenye simu ya mkononi.
Hapo awali, nilitaja kwamba ingawa kutumia mfumo inamaanisha kuwa kiasi fulani cha nambari kitajumuishwa katika mradi huo, mwanzoni mwa kazi juu yake, natumai kuwa mfumo huo unaweza kupunguza msanidi programu. Hasa, tunazungumza juu ya kupunguza kiwango cha juu cha nambari.
Inafurahisha, tovuti za jQuery hufuata wazo hili. Ingawa ni nzito kidogo kuliko tovuti zote katika asilimia 10 (kwa 15-18%), ni nyepesi kidogo katika asilimia 90 karibu 3% kwenye kompyuta ya mezani na ya simu. Hii haimaanishi kuwa hii ni faida kubwa sana, lakini inaweza kusemwa kuwa tovuti za jQuery, angalau, hazina saizi kubwa za msimbo wa JavaScript, hata katika matoleo yao makubwa zaidi.
Lakini hiyo haiwezi kusemwa kuhusu mifumo mingine.
Kama ilivyo kwa asilimia 10, tovuti za asilimia 90 kwenye Angular na React hutofautiana na tovuti zingine, lakini zinatofautiana, kwa bahati mbaya, mbaya zaidi.
Katika asilimia 90, tovuti za Angular hutuma data zaidi ya 141% kwa simu kuliko tovuti zote, na 159% zaidi kwenye kompyuta ya mezani. Tovuti za React hutuma 73% zaidi kwenye kompyuta ya mezani kuliko tovuti zote, na 58% zaidi kwenye simu ya mkononi. Ukubwa wa msimbo wa tovuti za React katika asilimia 90 ni 2197.8 KB. Hii inamaanisha kuwa tovuti kama hizo hutuma data zaidi ya KB 322.9 kwa vifaa vya rununu kuliko washindani wao wa karibu kulingana na Vue. Pengo kati ya tovuti za eneo-kazi kulingana na Angular na React na tovuti zingine ni kubwa zaidi. Kwa mfano, tovuti za desktop React hutuma msimbo wa JS wa 554.7 KB zaidi kwa vifaa kuliko tovuti sawa za Vue.
Muda uliochukuliwa kuchakata msimbo wa JavaScript katika mazungumzo kuu
Data iliyo hapo juu inaonyesha wazi kwamba tovuti zinazotumia mifumo na maktaba zinazochunguzwa zina idadi kubwa ya msimbo wa JavaScript. Lakini bila shaka, hiyo ni sehemu moja tu ya mlingano wetu.
Baada ya msimbo wa JavaScript umefika kwenye kivinjari, inahitaji kuletwa katika hali inayoweza kufanya kazi. Hasa shida nyingi husababishwa na vitendo hivyo ambavyo vinapaswa kufanywa na nambari kwenye uzi kuu wa kivinjari. Thread kuu ni wajibu wa usindikaji vitendo vya mtumiaji, kwa mitindo ya kuhesabu, kwa ajili ya kujenga na kuonyesha mpangilio wa ukurasa. Ukizidisha uzi mkuu na kazi za JavaScript, hautapata fursa ya kukamilisha kazi zingine kwa wakati. Hii inasababisha ucheleweshaji na "breki" katika kazi ya kurasa.
Hifadhidata ya Kumbukumbu ya HTTP ina maelezo kuhusu muda ambao inachukua kuchakata msimbo wa JavaScript katika uzi kuu wa injini ya V8. Hii ina maana kwamba tunaweza kukusanya data hii na kujua ni muda gani thread kuu inachukua kuchakata JavaScript ya tovuti mbalimbali.
Muda wa kichakataji (katika milisekunde) unaohusiana na uchakataji wa hati kwenye vifaa vya rununu
Asilimia
10
25
50
75
90
Tovuti zote
356.4
959.7
2372.1
5367.3
10485.8
tovuti za jQuery
575.3
1147.4
2555.9
5511.0
10349.4
Angalia tovuti
1130.0
2087.9
4100.4
7676.1
12849.4
Maeneo ya angular
1471.3
2380.1
4118.6
7450.8
13296.4
React Sites
2700.1
5090.3
9287.6
14509.6
20813.3
Muda wa kichakataji unaohusiana na uchakataji wa hati kwenye vifaa vya rununu
Muda wa kichakataji (katika milisekunde) unaohusiana na uchakataji wa hati kwenye vifaa vya mezani
Asilimia
10
25
50
75
90
Tovuti zote
146.0
351.8
831.0
1739.8
3236.8
tovuti za jQuery
199.6
399.2
877.5
1779.9
3215.5
Angalia tovuti
350.4
650.8
1280.7
2388.5
4010.8
Maeneo ya angular
482.2
777.9
1365.5
2400.6
4171.8
React Sites
508.0
1045.6
2121.1
4235.1
7444.3
Muda wa kichakataji unaohusiana na uchakataji wa hati kwenye vifaa vya mezani
Hapa unaweza kuona kitu kinachojulikana sana.
Kwa kuanzia, tovuti zilizo na jQuery hutumia kidogo sana kuchakata JavaScript kwenye uzi kuu kuliko tovuti zingine. Katika asilimia 10, ikilinganishwa na tovuti zote, tovuti za jQuery kwenye simu ya mkononi hutumia muda wa 61% zaidi kuchakata msimbo wa JS kwenye thread kuu. Katika kesi ya tovuti za jQuery za desktop, wakati wa usindikaji huongezeka kwa 37%. Katika asilimia 90, tovuti za jQuery zinapata alama karibu sana na jumla ya alama. Hasa, tovuti za jQuery kwenye vifaa vya mkononi hutumia muda pungufu kwa 1.3% kwenye mazungumzo kuu kuliko tovuti zote, na muda mfupi wa 0.7% kwenye vifaa vya mezani.
Kwa upande mwingine wa rating yetu ni mifumo ambayo ina sifa ya mzigo wa juu kwenye thread kuu. Hii ni, tena, Angular na React. Tofauti pekee kati ya hizo mbili ni kwamba wakati tovuti za Angular hutuma msimbo zaidi kwa vivinjari kuliko tovuti za React, tovuti za Angular huchukua muda mdogo wa CPU kuchakata msimbo. Mbali kidogo.
Katika asilimia 10, tovuti za Angular za eneo-kazi hutumia 230% zaidi ya muda kwenye kuchakata thread kuu ya msimbo wa JS kuliko tovuti zote. Kwa tovuti za rununu, takwimu hii ni 313%. Tovuti za React ndio watendaji mbaya zaidi. Kwenye kompyuta ya mezani, wanatumia 248% ya muda zaidi kuchakata msimbo kuliko tovuti zote, na 658% zaidi kwenye simu. 658% sio typo. Katika asilimia 10, tovuti za React hutumia sekunde 2.7 za muda wa mazungumzo kuu kuchakata misimbo yao.
Asilimia ya 90, ikilinganishwa na nambari hizi kubwa, inaonekana angalau bora zaidi. Ikilinganishwa na tovuti zote, miradi ya Angular hutumia muda wa 29% zaidi kwenye vifaa vya mezani kwenye thread kuu, na 27% zaidi ya muda kwenye vifaa vya mkononi. Kwa upande wa tovuti za React, takwimu sawa zinaonekana kama 130% na 98%, mtawalia.
Asilimia ya mikengeuko ya asilimia 90 inaonekana bora kuliko thamani zinazofanana za asilimia 10. Lakini hapa inafaa kukumbuka kuwa nambari zinazoonyesha wakati zinaonekana kuwa za kutisha. Hebu tuseme sekunde 20.8 kwenye thread kuu ya simu ya tovuti iliyojengwa na React. (Nadhani hadithi ya kile kinachotokea wakati huu inastahili nakala tofauti).
Kuna shida moja inayowezekana hapa (asante kwa kuteka mawazo yangu kwa kipengele hiki, na kwa kuzingatia kwa makini data kutoka kwa mtazamo huu). Ukweli ni kwamba tovuti nyingi hutumia zana kadhaa za mbele. Hasa, nimeona tovuti nyingi zinazotumia jQuery kando ya React au Vue, kwani tovuti hizo zinahama kutoka jQuery hadi mifumo mingine au maktaba. Kama matokeo, niligonga hifadhidata tena, wakati huu nikichagua tu viungo ambavyo vinalingana na tovuti zinazotumia React, jQuery, Angular, au Vue pekee, lakini sio mchanganyiko wao. Hivi ndivyo nilivyopata.
Muda wa kichakataji (katika milisekunde) unaohusiana na usindikaji hati kwenye vifaa vya rununu katika hali ambapo tovuti hutumia mfumo mmoja tu au maktaba moja tu.
Asilimia
10
25
50
75
90
Tovuti zinazotumia jQuery pekee
542.9
1062.2
2297.4
4769.7
8718.2
Tovuti zinazotumia Vue pekee
944.0
1716.3
3194.7
5959.6
9843.8
Tovuti zinazotumia Angular pekee
1328.9
2151.9
3695.3
6629.3
11607.7
Tovuti zinazotumia React pekee
2443.2
4620.5
10061.4
17074.3
24956.3
Wakati wa processor unaohusiana na usindikaji wa maandishi kwenye vifaa vya rununu katika hali ambapo tovuti hutumia mfumo mmoja tu, au maktaba moja tu
Kwanza, jambo ambalo halishangazi: tovuti inapotumia mfumo mmoja tu au maktaba moja, utendaji wa tovuti kama hiyo huboresha mara nyingi zaidi. Kila chombo hufanya kazi vyema katika asilimia ya 10 na 25. Inaleta maana. Tovuti ambayo imetengenezwa kwa mfumo mmoja inapaswa kufanya vizuri zaidi kuliko tovuti ambayo imetengenezwa kwa mifumo miwili au zaidi au maktaba.
Kwa kweli, utendaji wa kila chombo cha mbele kilichosomwa inaonekana bora katika matukio yote, isipokuwa kwa ubaguzi mmoja wa curious. Kilichonishangaza ni kwamba katika asilimia 50 na zaidi, tovuti zinazotumia React hufanya vibaya zaidi wakati React ndiyo maktaba pekee wanayotumia. Hii, kwa njia, ndiyo sababu ya mimi kuwasilisha data hii hapa.
Hii ni ajabu kidogo, lakini bado nitajaribu kutafuta maelezo ya ajabu hii.
Ikiwa mradi unatumia React na jQuery, basi mradi huo una uwezekano wa kuwa katikati ya mpito kutoka jQuery hadi React. Labda ina codebase ambapo maktaba hizi zimechanganywa. Kwa kuwa tayari tumeona kuwa tovuti za jQuery hutumia muda mchache kwenye thread kuu kuliko tovuti za React, hii inaweza kutuambia kwamba kutekeleza baadhi ya utendaji katika jQuery husaidia tovuti kufanya vizuri zaidi.
Lakini kadri mradi unavyobadilika kutoka jQuery hadi React na kutegemea zaidi React, mambo yanabadilika. Ikiwa tovuti ni ya ubora wa juu, na watengenezaji wa tovuti hutumia React kwa uangalifu, basi kila kitu kitakuwa sawa na tovuti hiyo. Lakini kwa tovuti ya wastani ya React, matumizi makubwa ya React inamaanisha kuwa uzi kuu uko chini ya mzigo mzito.
Pengo kati ya vifaa vya rununu na vya mezani
Mtazamo mwingine ambao niliangalia data iliyotafitiwa ilikuwa kusoma jinsi pengo ni kubwa kati ya kufanya kazi na tovuti kwenye vifaa vya rununu na vya mezani. Ikiwa tunazungumza juu ya kulinganisha idadi ya nambari ya JavaScript, basi ulinganisho kama huo hauonyeshi chochote kibaya. Bila shaka, itakuwa nzuri kuona kiasi kidogo cha msimbo unaoweza kupakuliwa, lakini hakuna tofauti kubwa katika kiasi cha msimbo wa simu na eneo-kazi.
Lakini tukichambua muda unaohitajika kuchakata msimbo, pengo kubwa sana kati ya vifaa vya rununu na vya mezani huonekana.
Ongezeko la muda (asilimia) linalohusiana na kuchakata hati kwenye vifaa vya mkononi ikilinganishwa na eneo-kazi
Asilimia
10
25
50
75
90
Tovuti zote
144.1
172.8
185.5
208.5
224.0
tovuti za jQuery
188.2
187.4
191.3
209.6
221.9
Angalia tovuti
222.5
220.8
220.2
221.4
220.4
Maeneo ya angular
205.1
206.0
201.6
210.4
218.7
React Sites
431.5
386.8
337.9
242.6
179.6
Ingawa tofauti fulani katika kasi ya usindikaji wa msimbo kati ya simu na kompyuta ya mkononi inapaswa kutarajiwa, idadi kubwa kama hiyo huniambia kuwa mifumo ya kisasa haijalengwa vya kutosha kwenye vifaa vyenye nguvu ndogo, na kwamba wanajitahidi kuziba pengo walilogundua. Hata katika asilimia 10, tovuti za React hutumia 431.5% zaidi ya muda kwenye mtandao mkuu wa simu kuliko kwenye thread kuu ya eneo-kazi. jQuery ina pengo ndogo zaidi, lakini hata hapa takwimu inayolingana ni 188.2%. Wakati watengenezaji wa tovuti hufanya miradi yao kwa namna ambayo usindikaji wao unahitaji muda zaidi wa processor (na hutokea, na inakuwa mbaya zaidi kwa muda), wamiliki wa vifaa vya chini vya nguvu wanapaswa kulipa.
Matokeo ya
Mifumo mizuri inapaswa kuwapa wasanidi programu msingi mzuri wa kujenga miradi ya wavuti (kuhusiana na usalama, ufikiaji, utendakazi), au wanapaswa kuwa na vizuizi vilivyojumuishwa ambavyo hufanya iwe ngumu kuunda kitu ambacho kinakiuka vizuizi hivyo.
Hii haionekani kutumika kwa utendakazi wa miradi ya wavuti (na labda sio yao ).
Inafaa kukumbuka kuwa kwa sababu tovuti za React au Angular hutumia muda mwingi wa CPU kuandaa msimbo kuliko zingine haimaanishi kuwa tovuti za React zinatumia CPU nyingi zaidi kuliko tovuti za Vue wakati zinaendesha. Kwa hakika, data ambayo tumepitia inasema machache sana kuhusu utendaji kazi wa mifumo na maktaba. Wanazungumza zaidi juu ya njia za maendeleo ambazo, kwa uangalifu au la, mifumo hii inaweza kusukuma waandaaji wa programu. Tunazungumza juu ya nyaraka za mifumo, kuhusu mfumo wao wa ikolojia, kuhusu mbinu za kawaida za maendeleo.
Inafaa pia kutaja jambo ambalo hatukuchanganua hapa, yaani, muda gani kifaa kinatumia kutekeleza msimbo wa JavaScript wakati wa kuvinjari kati ya kurasa za tovuti. Hoja inayopendelea SPA ni kwamba mara tu programu ya ukurasa mmoja inapopakiwa kwenye kivinjari, mtumiaji ataweza kinadharia kufungua kurasa za tovuti haraka zaidi. Uzoefu wangu mwenyewe unaniambia kuwa hii ni mbali na ukweli. Lakini hatuna data ya kufafanua suala hili.
Jambo lililo wazi ni kwamba ikiwa unatumia mfumo au maktaba kuunda tovuti, unafanya maelewano katika suala la kupakia mradi huo na kuutayarisha. Hii inatumika hata kwa matukio mazuri zaidi.
Inawezekana kabisa kufanya maelewano fulani katika hali zinazofaa, lakini ni muhimu kwamba watengenezaji wafanye maelewano hayo kwa uangalifu.
Lakini pia tuna sababu ya kuwa na matumaini. Ninafurahi kuona jinsi wasanidi wa Chrome wanavyofanya kazi kwa ukaribu na wasanidi wa baadhi ya zana za mbele ambazo tumekagua katika juhudi za kusaidia kuboresha utendakazi wa zana hizo.
Walakini, mimi ni mtu wa vitendo. Usanifu mpya huunda shida za utendaji mara nyingi wanavyotatua. Na inachukua muda kurekebisha makosa. Kama vile hatupaswi kutarajia itasuluhisha shida zote za utendakazi, haupaswi kutarajia hii kutoka kwa matoleo mapya ya mifumo yetu tunayopenda.
Ikiwa unataka kutumia mojawapo ya zana za mwisho zilizojadiliwa katika makala hii, hii ina maana kwamba utalazimika kuweka jitihada za ziada ili usidhuru utendaji wa mradi wako kwa sasa. Hapa kuna mambo ya kuzingatia kabla ya kuanza mfumo mpya:
- Jijaribu kwa akili ya kawaida. Je, unahitaji kweli kutumia mfumo uliochaguliwa? JavaScript safi leo ina uwezo wa mengi.
- Je, kuna njia mbadala nyepesi kwa mfumo uliochaguliwa (kama Preact, Svelte au kitu kingine) ambacho kinaweza kukupa 90% ya uwezo wa mfumo huu?
- Ikiwa tayari unatumia mfumo, zingatia kama kuna kitu ambacho hutoa chaguo bora zaidi, kihafidhina zaidi, cha kawaida (km Nuxt.js badala ya Vue, Next.js badala ya React, na kadhalika).
- Mapenzi yako Utendaji wa JavaScript?
- Unawezaje mchakato wa ukuzaji ili kuifanya iwe ngumu kuingiza nambari zaidi ya JavaScript kwenye mradi kuliko inavyohitajika kabisa?
- Ikiwa unatumia mfumo kwa urahisi wa maendeleo, fikiria tuma nambari ya mfumo kwa wateja. Labda unaweza kutatua masuala yote kwenye seva?
Kawaida mawazo haya yanafaa kutazama, bila kujali ni nini hasa umechagua kwa maendeleo ya mbele. Lakini ni muhimu hasa unapofanya kazi kwenye mradi ambao hauna utendaji tangu mwanzo.
Ndugu wasomaji! Je, unaonaje mfumo bora wa JavaScript?
Chanzo: mapenzi.com