Wala nang mas mabilis na paraan para pabagalin ang isang website (no pun intended) kaysa magpatakbo ng isang grupo ng JavaScript code dito. Kapag gumagamit ng JavaScript, kailangan mong bayaran ito sa pagganap ng proyekto nang hindi bababa sa apat na beses. Narito kung ano ang nilo-load ng JavaScript code ng site sa mga system ng mga user:
- Pag-upload ng file sa network.
- Pag-parse at pag-compile ng hindi naka-pack na source code pagkatapos mag-download.
- Pagpapatupad ng JavaScript code.
- Pagkonsumo ng memorya.
Ang kumbinasyong ito ay lumabas na .
At isinasama namin ang mas maraming JS code sa aming mga proyekto. Habang lumilipat ang mga organisasyon patungo sa mga site na pinapagana ng mga framework at library tulad ng React, Vue at iba pa, ginagawa naming lubos na nakadepende sa JavaScript ang pangunahing functionality ng mga site.
Nakakita na ako ng maraming napakabigat na website na gumagamit ng JavaScript frameworks. Ngunit ang aking pananaw sa isyu ay malakas na kinikilingan. Ang katotohanan ay ang mga kumpanyang pinagtatrabahuhan ko ay eksaktong lumapit sa akin dahil mayroon silang mga kumplikadong problema sa pagganap ng website. Bilang resulta, naging interesado akong malaman kung gaano kalawak ang problemang ito, at kung anong "multa" ang binabayaran namin kapag pumili kami ng isa o ibang balangkas bilang batayan para sa isang partikular na site.
Ang proyektong ito ay nakatulong sa akin na malaman ito. .
Data
Sinusubaybayan ng proyekto ng HTTP Archive ang kabuuang 4308655 na link sa mga regular na desktop site at 5484239 na link sa mga mobile site. Kabilang sa maraming tagapagpahiwatig na nauugnay sa mga link na ito ay isang listahan ng mga teknolohiyang matatagpuan sa mga kaukulang site. Nangangahulugan ito na makakasampol tayo ng libu-libong site na gumagamit ng iba't ibang mga framework at library at matutunan kung gaano karaming code ang ipinapadala nila sa mga kliyente at kung gaano karaming load ang inilalagay ng code na iyon sa mga system ng mga user.
Nangolekta ako ng data mula Marso 2020, na siyang pinakakamakailang data na nagkaroon ako ng access.
Nagpasya akong ihambing ang pinagsama-samang HTTP Archive data para sa lahat ng mga site na may data para sa mga site na natagpuang gumagamit ng React, Vue, at Angular, bagama't napag-isipan kong gumamit din ng iba pang mapagkukunang materyal.
Upang gawin itong mas kawili-wili, nagdagdag din ako ng mga site na gumagamit ng jQuery sa source data set. Sikat pa rin ang library na ito. Ipinakilala rin nito ang isang diskarte sa pagbuo ng website na naiiba sa modelo ng Single Page Application (SPA) na inaalok ng React, Vue at Angular.
Mga link sa HTTP Archive na kumakatawan sa mga site na natagpuang gumagamit ng mga teknolohiyang interesado sa amin
Framework o library
Mga link sa mga mobile site
Mga link sa mga regular na site
jQuery
4615474
3714643
Gantihin
489827
241023
Vue
85649
43691
Anggular
19423
18088
Pag-asa at pangarap
Bago tayo magpatuloy sa pagsusuri ng data, gusto kong pag-usapan kung ano ang gusto kong asahan.
Naniniwala ako na sa isang perpektong mundo, ang mga frameworks ay lalampas sa pagtugon sa mga pangangailangan ng mga developer at magbibigay ng ilang kongkretong benepisyo sa mga pang-araw-araw na gumagamit ng aming mga site. Ang pagiging produktibo ay isa lamang sa mga benepisyong iyon. Naiisip din dito ang accessibility at kaligtasan. Ngunit ito lamang ang pinakamahalagang bagay.
Kaya, sa perpektong mundo, dapat gawing mas madali ng ilang uri ng framework ang paggawa ng website na may mataas na pagganap. Ito ay dapat gawin alinman dahil sa ang katunayan na ang balangkas ay nagbibigay sa developer ng isang disenteng batayan kung saan bubuo ng isang proyekto, o dahil sa ang katunayan na ito ay nagpapataw ng mga paghihigpit sa pag-unlad, na naglalagay ng mga kinakailangan para dito na nagpapahirap sa pagbuo ng isang bagay. mabagal pala yun.
Ang pinakamahusay na mga balangkas ay dapat gawin pareho: magbigay ng isang mahusay na batayan, at magpataw ng mga paghihigpit sa trabaho na nagbibigay-daan sa iyo upang makamit ang isang disenteng resulta.
Ang pagsusuri sa mga median na halaga ng data ay hindi magbibigay sa amin ng impormasyong kailangan namin. At, sa katunayan, ang diskarteng ito ay hindi natin napapansin . Sa halip, nakuha ko ang mga percentile na marka mula sa data na mayroon ako. Ito ang 10, 25, 50 (median), 75, 90 percentiles.
Ako ay partikular na interesado sa ika-10 at ika-90 na porsyento. Ang 10th percentile ay kumakatawan sa pinakamahusay na pagganap (o hindi bababa sa higit pa o mas malapit sa pinakamahusay) para sa isang partikular na framework. Sa madaling salita, nangangahulugan ito na 10% lang ng mga site na gumagamit ng partikular na framework ang nakakaabot sa antas na ito, o sa mas mataas na antas. Ang 90th percentile, sa kabilang banda, ay ang kabilang panig ng barya - ipinapakita nito sa atin kung gaano kasama ang mga bagay. Ang 90th percentile ay ang mga sumusunod na siteβang huling 10% ng mga site na may pinakamalaking halaga ng JS code o ang pinakamahabang oras na kinakailangan upang maproseso ang kanilang code sa pangunahing thread.
Dami ng JavaScript code
Upang magsimula, makatuwirang suriin ang laki ng JavaScript code na ipinadala ng iba't ibang mga site sa network.
Dami ng JavaScript code (KB) na inilipat sa mga mobile device
Percentiles
10
25
50
75
90
Lahat ng mga site
93.4
196.6
413.5
746.8
1201.6
mga site ng jQuery
110.3
219.8
430.4
748.6
1162.3
Mga website ng Vue
244.7
409.3
692.1
1065.5
1570.7
Angular na mga website
445.1
675.6
1066.4
1761.5
2893.2
Mag-react sa mga website
345.8
441.6
690.3
1238.5
1893.6
Dami ng JavaScript code na ipinadala sa mga mobile device
Dami ng JavaScript code (KB) na inilipat sa mga desktop device
Percentiles
10
25
50
75
90
Lahat ng mga site
105.5
226.6
450.4
808.8
1267.3
mga site ng jQuery
121.7
242.2
458.3
803.4
1235.3
Mga website ng Vue
248.0
420.1
718.0
1122.5
1643.1
Angular na mga website
468.8
716.9
1144.2
1930.0
3283.1
Mag-react sa mga website
308.6
469.0
841.9
1472.2
2197.8
Dami ng JavaScript code na inilipat sa mga desktop device
Kung pag-uusapan lang natin ang tungkol sa laki ng JS code na ipinapadala ng mga site sa mga device, magiging hitsura ang lahat gaya ng inaasahan mo. Ibig sabihin, kung ang isa sa mga balangkas ay ginamit, nangangahulugan ito na kahit na sa isang perpektong sitwasyon, ang dami ng JavaScript code para sa site ay tataas. Hindi ito nakakagulat - hindi mo maaaring gawing batayan ng isang site ang isang JavaScript framework at inaasahan na ang halaga ng JS code para sa proyekto ay magiging napakababa.
Ang kawili-wili sa data na ito ay ang ilang mga frameworks at library ay maaaring ituring na mas mahusay na mga panimulang punto para sa isang proyekto kaysa sa iba. Pinakamaganda ang hitsura ng mga website na may jQuery. Ang kanilang mga desktop site ay naglalaman ng 15% na higit pang JavaScript kaysa sa lahat ng mga site, at ang kanilang mga mobile site ay naglalaman ng 18% na higit pang JavaScript. (Tanggapin, mayroong ilang skew sa data dito. Ang katotohanan ay ang jQuery ay naroroon sa maraming mga site, kaya natural na ang mga naturang site ay mas malapit na nauugnay sa kabuuang bilang ng mga site kaysa sa iba. Gayunpaman, hindi ito nakakaapekto kung paano ang source data ay output para sa bawat framework.)
Habang ang 15-18% na paglago ng code ay isang makabuluhang bilang, kung ihahambing sa iba pang mga balangkas at aklatan, ang buwis na ipinataw ng jQuery ay napakababa. Ang mga angular na site sa 10th percentile ay nagpapadala ng 344% na mas maraming data sa mga desktop device kaysa sa lahat ng mga site, at 377% higit pa sa mga mobile device. Ang mga react site ay ang susunod na pinakamabigat, nagpapadala ng 193% mas maraming code sa mga desktop device kaysa sa lahat ng site, at 270% higit pa sa mga mobile device.
Nabanggit ko kanina na kahit na ang paggamit ng isang framework ay nangangahulugan na ang isang tiyak na halaga ng code ay isasama sa proyekto sa pinakadulo simula ng trabaho dito, umaasa ako na ang balangkas ay magagawang kahit papaano ay limitahan ang developer. Sa partikular, pinag-uusapan natin ang tungkol sa paglilimita sa maximum na halaga ng code.
Ang kawili-wili ay sinusunod ng mga site ng jQuery ang ideyang ito. Bagama't ang mga ito, sa antas ng ika-10 porsyento, ay bahagyang mas mabigat kaysa sa lahat ng mga site (sa pamamagitan ng 15-18%), sila, sa antas ng ika-90 porsyento, ay bahagyang mas magaan kaysa sa lahat ng mga site - sa pamamagitan ng humigit-kumulang 3% sa parehong mga bersyon ng desktop at mobile. Hindi ito nangangahulugan na ito ay isang napakalaking benepisyo, ngunit masasabi na ang mga site ng jQuery ay hindi bababa sa walang malalaking sukat ng JavaScript code kahit na sa kanilang pinakamalaking mga bersyon.
Ngunit ang parehong ay hindi masasabi tungkol sa iba pang mga balangkas.
Tulad ng sa kaso ng 10th percentile, sa 90th percentile na mga site sa Angular at React ay naiiba mula sa iba pang mga site, ngunit sila ay naiiba, sa kasamaang-palad, para sa mas masahol pa.
Sa 90th percentile, ang mga Angular na site ay nagpapadala ng 141% mas maraming data sa mga mobile device kaysa sa lahat ng mga site, at 159% higit pa sa mga desktop device. Ang mga react site ay nagpapadala ng 73% higit pa sa mga desktop device kaysa sa lahat ng site, at 58% pa sa mga mobile device. Ang laki ng code ng mga site ng React sa 90th percentile ay 2197.8 KB. Nangangahulugan ito na ang mga site na ito ay nagpapadala ng 322.9 KB na higit pang data sa mga mobile device kaysa sa kanilang pinakamalapit na mga kakumpitensyang nakabase sa Vue. Ang agwat sa pagitan ng mga desktop site batay sa Angular at React at iba pang mga site ay mas malaki. Halimbawa, ang mga desktop site ng React ay nagpapadala ng 554.7 KB na mas maraming JS code sa mga device kaysa sa mga katulad na site ng Vue.
Oras na kinuha upang iproseso ang JavaScript code sa pangunahing thread
Ang data sa itaas ay malinaw na nagpapahiwatig na ang mga site na gumagamit ng mga framework at library na pinag-aralan ay naglalaman ng malaking halaga ng JavaScript code. Ngunit, siyempre, ito ay isang bahagi lamang ng aming equation.
Pagkatapos na dumating ang JavaScript code sa browser, kailangan itong dalhin sa isang gumaganang estado. Lalo na maraming problema ang sanhi ng mga pagkilos na iyon na kailangang isagawa gamit ang code sa pangunahing thread ng browser. Ang pangunahing thread ay responsable para sa pagproseso ng mga aksyon ng user, pagkalkula ng mga estilo, at pagbuo at pagpapakita ng layout ng pahina. Kung mapupuno mo ang pangunahing thread ng mga gawain sa JavaScript, hindi ito magkakaroon ng pagkakataong kumpletuhin ang iba pang mga gawain sa napapanahong paraan. Ito ay humahantong sa mga pagkaantala at "preno" sa pagpapatakbo ng mga pahina.
Ang database ng HTTP Archive ay naglalaman ng impormasyon tungkol sa kung gaano katagal bago maproseso ang JavaScript code sa pangunahing thread ng V8 engine. Nangangahulugan ito na maaari naming kolektahin ang data na ito at matutunan kung gaano katagal ang pangunahing thread upang maproseso ang JavaScript ng iba't ibang mga site.
Oras ng CPU (sa millisecond) na nauugnay sa pagpoproseso ng script sa mga mobile device
Percentiles
10
25
50
75
90
Lahat ng mga site
356.4
959.7
2372.1
5367.3
10485.8
mga site ng jQuery
575.3
1147.4
2555.9
5511.0
10349.4
Mga website ng Vue
1130.0
2087.9
4100.4
7676.1
12849.4
Angular na mga website
1471.3
2380.1
4118.6
7450.8
13296.4
Mag-react sa mga website
2700.1
5090.3
9287.6
14509.6
20813.3
Oras ng CPU na nauugnay sa pagpoproseso ng script sa mga mobile device
Oras ng CPU (sa millisecond) na nauugnay sa pagpoproseso ng script sa mga desktop device
Percentiles
10
25
50
75
90
Lahat ng mga site
146.0
351.8
831.0
1739.8
3236.8
mga site ng jQuery
199.6
399.2
877.5
1779.9
3215.5
Mga website ng Vue
350.4
650.8
1280.7
2388.5
4010.8
Angular na mga website
482.2
777.9
1365.5
2400.6
4171.8
Mag-react sa mga website
508.0
1045.6
2121.1
4235.1
7444.3
Oras ng CPU na nauugnay sa pagpoproseso ng script sa mga desktop device
Dito makikita mo ang isang bagay na pamilyar.
Para sa mga panimula, ang mga site na may jQuery ay gumagastos ng mas kaunting pagpoproseso ng JavaScript sa pangunahing thread kaysa sa iba. Sa ika-10 percentile, kumpara sa lahat ng site, ang mga site ng jQuery sa mga mobile device ay gumugugol ng 61% na mas maraming oras sa pagproseso ng JS code sa pangunahing thread. Sa kaso ng mga desktop jQuery site, ang oras ng pagproseso ay tumataas ng 37%. Sa 90th percentile, ang mga marka ng jQuery sites ay napakalapit sa mga pinagsama-samang marka. Sa partikular, ang mga site ng jQuery sa mga mobile device ay gumugugol ng 1.3% mas kaunting oras sa pangunahing thread kaysa sa lahat ng mga site, at sa mga desktop device ay gumugugol sila ng 0.7% mas kaunting oras sa pangunahing thread.
Sa kabilang panig ng aming rating ay mga balangkas na nailalarawan sa pamamagitan ng pinakamalaking pagkarga sa pangunahing thread. Ito ay, muli, Angular at React. Ang pagkakaiba lang ng mga ito ay, bagama't ang mga Angular na site ay nagpapadala ng mas malaking halaga ng code sa mga browser kaysa sa mga site ng React, mas kaunting oras ng CPU ang kailangan upang maproseso ang code ng mga Angular na site. Malayong mas mababa.
Sa ika-10 percentile, ang mga Angular na desktop site ay gumugugol ng 230% na mas maraming oras sa pagpoproseso ng JS code kaysa sa lahat ng mga site. Para sa mga mobile site ang bilang na ito ay 313%. Ang mga react site ang may pinakamasamang performance. Sa mga desktop device, gumugugol sila ng 248% na mas maraming oras sa pagpoproseso ng code kaysa sa lahat ng mga site, at sa mga mobile device ay gumugugol sila ng 658% na mas maraming oras sa pagpoproseso ng code. 658% ay hindi isang typo. Sa 10th percentile, ang mga React site ay gumugugol ng 2.7 segundo ng pangunahing oras ng thread sa pagpoproseso ng kanilang kasalukuyang code.
Ang 90th percentile na mga numero ay mukhang mas maganda nang kaunti kung ihahambing sa malalaking numerong ito. Ang mga angular na proyekto, kumpara sa lahat ng site, ay gumugugol ng 29% na mas maraming oras sa pangunahing thread sa mga desktop device, at 27% na mas maraming oras sa mga mobile device. Sa kaso ng mga site ng React, ang mga katulad na tagapagpahiwatig ay mukhang 130% at 98%, ayon sa pagkakabanggit.
Ang mga porsyento ng paglihis para sa ika-90 na porsyento ay mukhang mas mahusay kaysa sa mga katulad na halaga para sa ika-10 na porsyento. Ngunit narito ito ay nagkakahalaga ng pag-alala na ang mga numero na nagpapahiwatig ng oras ay tila nakakatakot. Sabihin nating - 20.8 segundo sa pangunahing thread ng isang mobile device para sa isang site na binuo sa React. (Naniniwala ako na ang kuwento ng kung ano ang aktwal na nangyayari sa panahong ito ay karapat-dapat sa isang hiwalay na artikulo).
Mayroong isang potensyal na komplikasyon dito (salamat para sa pagguhit ng aking pansin sa tampok na ito, at para sa maingat na pagsusuri sa data mula sa puntong ito ng view). Ang katotohanan ay maraming mga site ang gumagamit ng ilang mga front-end na tool. Sa partikular, nakakita ako ng maraming site na gumagamit ng jQuery kasama ng React o Vue habang lumilipat ang mga site na ito mula sa jQuery patungo sa ibang mga framework o library. Bilang resulta, bumalik ako sa database, sa pagkakataong ito ay pinipili lamang ang mga link na nauugnay sa mga site na gumamit lamang ng React, jQuery, Angular o Vue, ngunit hindi ang anumang kumbinasyon ng mga ito. Narito ang nakuha ko.
Oras ng processor (sa millisecond) na nauugnay sa pagpoproseso ng script sa mga mobile device sa mga sitwasyon kung saan ang mga site ay gumagamit lamang ng isang framework o isang library lamang
Percentiles
10
25
50
75
90
Mga site na gumagamit lamang ng jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Mga site na gumagamit lamang ng Vue
944.0
1716.3
3194.7
5959.6
9843.8
Mga site na gumagamit lang ng Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Mga website na gumagamit lang ng React
2443.2
4620.5
10061.4
17074.3
24956.3
Oras ng processor na nauugnay sa pagproseso ng mga script sa mga mobile device sa isang sitwasyon kung saan ang mga site ay gumagamit lamang ng isang framework, o isang library lamang
Una, isang bagay na hindi nakakagulat: kapag ang isang site ay gumagamit lamang ng isang framework o isang library, ang pagganap ng naturang site ay mas madalas na bumubuti kaysa sa hindi. Ang pagganap para sa bawat instrumento ay mukhang mas mahusay sa ika-10 at ika-25 na porsyento. Ito ay may katuturan. Ang isang site na ginawa gamit ang isang framework ay dapat na mas mabilis kaysa sa isang site na ginawa gamit ang dalawa o higit pang mga frameworks o library.
Sa katunayan, ang mga marka para sa bawat front-end na tool na sinuri namin ay mas maganda sa lahat ng kaso, na may isang kakaibang pagbubukod. Ang ikinagulat ko ay na sa 50th percentile at mas mataas, ang mga site na gumagamit ng React ay gumaganap nang mas malala kapag ang React ay ang tanging library na ginagamit nila. Ito, sa pamamagitan ng paraan, ang dahilan kung bakit ipinakita ko ang data na ito dito.
Ito ay medyo kakaiba, ngunit susubukan ko pa ring maghanap ng paliwanag para sa kakaibang ito.
Kung ang isang proyekto ay gumagamit ng parehong React at jQuery, malamang na ang proyektong iyon ay nasa kalagitnaan ng proseso ng paglipat mula sa jQuery patungo sa React. Marahil ay mayroon siyang codebase kung saan pinaghalo ang mga aklatang ito. Dahil nakita na namin na ang mga site ng jQuery ay gumugugol ng mas kaunting oras sa pangunahing thread kaysa sa mga site ng React, maaaring sabihin nito sa amin na ang pagpapatupad ng ilang functionality sa jQuery ay nakakatulong na mapabuti ang pagganap ng site nang kaunti.
Ngunit habang lumilipat ang proyekto mula sa jQuery patungo sa React at higit na umaasa sa React, nagbabago ang sitwasyon. Kung ginawa ang site na may tunay na mataas na kalidad, at maingat na ginagamit ng mga developer ng site ang React, magiging maayos ang lahat sa naturang site. Ngunit para sa karaniwang site ng React, ang malawakang paggamit ng React ay nangangahulugan na ang pangunahing thread ay napapailalim sa tumaas na pagkarga.
Ang agwat sa pagitan ng mga mobile at desktop device
Ang isa pang paraan ng pagtingin ko sa data ay upang tuklasin kung gaano kalaki ang agwat sa pagitan ng mga karanasan sa mobile at desktop. Kung pinag-uusapan natin ang paghahambing ng mga volume ng JavaScript code, kung gayon ang gayong paghahambing ay hindi nagpapakita ng anumang kahila-hilakbot. Siyempre, masarap makakita ng mas maliliit na halaga ng nada-download na code, ngunit walang gaanong pagkakaiba sa dami ng mobile at desktop code.
Ngunit kung susuriin mo ang oras na kinakailangan upang maproseso ang code, magiging kapansin-pansin ang napakalaking agwat sa pagitan ng mga mobile at desktop device.
Pagtaas ng oras (sa porsyento) na nauugnay sa pagpoproseso ng script sa mga mobile device kumpara sa mga desktop
Percentiles
10
25
50
75
90
Lahat ng mga site
144.1
172.8
185.5
208.5
224.0
mga site ng jQuery
188.2
187.4
191.3
209.6
221.9
Mga website ng Vue
222.5
220.8
220.2
221.4
220.4
Angular na mga website
205.1
206.0
201.6
210.4
218.7
Mag-react sa mga website
431.5
386.8
337.9
242.6
179.6
Bagama't inaasahan ang ilang pagkakaiba sa bilis ng pagpoproseso ng code sa pagitan ng isang telepono at isang laptop, ang mga malalaking numero ay nagsasabi sa akin na ang mga modernong balangkas ay hindi sapat na naka-target sa mga aparatong mababa ang kapangyarihan at ang pagnanais na isara ang puwang na natukoy. Kahit na sa ika-10 porsyento, ang mga site ng React ay gumugugol ng 431.5% na mas maraming oras sa pangunahing thread ng mobile kaysa sa pangunahing thread sa desktop. Ang jQuery ay may pinakamaliit na puwang, ngunit kahit dito ang katumbas na figure ay 188.2%. Kapag ginawa ng mga developer ng website ang kanilang mga proyekto sa paraang nangangailangan sila ng mas maraming oras ng CPU para iproseso ang mga ito (at ito ang nangyayari, at lumalala lamang ito sa paglipas ng panahon), kailangang bayaran ito ng mga may-ari ng mga device na mababa ang kapangyarihan.
Mga resulta ng
Ang magagandang frameworks ay dapat magbigay sa mga developer ng magandang pundasyon para sa pagbuo ng mga web project (sa mga tuntunin ng seguridad, accessibility, performance), o dapat ay may built-in na mga paghihigpit na nagpapahirap sa paggawa ng isang bagay na lumalabag sa mga paghihigpit na iyon.
Mukhang hindi ito naaangkop sa pagganap ng mga proyekto sa web (at tila sa kanilang ).
Kapansin-pansin na dahil lang sa ang React o Angular na mga site ay gumugugol ng mas maraming oras ng CPU sa paghahanda ng code kaysa sa iba ay hindi nangangahulugan na ang mga site ng React ay mas masinsinang CPU kaysa sa mga site ng Vue kapag tumatakbo. Sa katunayan, kakaunti ang sinasabi ng data na aming tiningnan tungkol sa pagganap ng pagpapatakbo ng mga frameworks at library. Mas marami silang pinag-uusapan tungkol sa mga diskarte sa pag-unlad na, sinasadya o hindi, ang mga balangkas na ito ay maaaring itulak ang mga programmer patungo. Pinag-uusapan natin ang tungkol sa dokumentasyon para sa mga balangkas, kanilang ecosystem, at karaniwang mga diskarte sa pag-unlad.
Ito rin ay nagkakahalaga ng pagbanggit ng isang bagay na hindi namin nasuri dito, ibig sabihin, kung gaano katagal ginugugol ng device ang pagpapatupad ng JavaScript code kapag lumilipat sa pagitan ng mga pahina ng site. Ang argumento na pabor sa SPA ay na kapag na-load ang solong page na application sa browser, ang user ay, sa teorya, ay mas mabilis na ma-access ang mga page ng site. Sinasabi sa akin ng aking sariling karanasan na ito ay malayo sa katotohanan. Ngunit wala kaming data upang linawin ang isyung ito.
Ang malinaw ay kung gagamit ka ng isang framework o library upang lumikha ng isang website, nagsasagawa ka ng isang kompromiso sa mga tuntunin ng paunang paglo-load ng proyekto at inihanda ito upang pumunta. Nalalapat ito kahit sa mga pinakapositibong sitwasyon.
Posibleng gumawa ng ilang kompromiso sa mga naaangkop na sitwasyon, ngunit mahalaga na sinasadya ng mga developer ang mga naturang kompromiso.
Ngunit mayroon din tayong dahilan para sa optimismo. Hinihikayat ako sa kung gaano kalapit ang pakikipagtulungan ng mga developer ng Chrome sa mga nasa likod ng ilan sa mga front-end na tool na aming nasaklaw upang makatulong na mapabuti ang pagganap ng mga tool na iyon.
Gayunpaman, ako ay isang pragmatic na tao. Ang mga bagong arkitektura ay lumilikha ng mga problema sa pagganap nang kasingdalas ng paglutas ng mga ito. At nangangailangan ng oras upang maalis ang mga pagkukulang. Tulad ng hindi natin dapat asahan ay malulutas ang lahat ng mga problema sa pagganap, hindi mo dapat asahan ito mula sa mga bagong bersyon ng aming mga paboritong framework.
Kung gusto mong gumamit ng isa sa mga front-end na tool na tinalakay sa materyal na ito, nangangahulugan ito na kailangan mong gumawa ng karagdagang mga pagsisikap upang matiyak na, hindi sinasadya, hindi mo mapipinsala ang pagganap ng iyong proyekto. Narito ang ilang mga pagsasaalang-alang na dapat isaalang-alang bago ka magsimulang gumamit ng bagong balangkas:
- Suriin ang iyong sarili gamit ang sentido komun. Kailangan mo ba talagang gamitin ang iyong napiling balangkas? Malaki ang magagawa ng purong JavaScript ngayon.
- Mayroon bang mas magaan na alternatibo sa balangkas na iyong pinili (tulad ng Preact, Svelte o iba pa) na maaaring magbigay sa iyo ng 90% ng mga kakayahan ng balangkas na iyon?
- Kung gumagamit ka na ng framework, isipin kung may nag-aalok ng mas mahusay, mas konserbatibo, karaniwang mga opsyon (halimbawa, Nuxt.js sa halip na Vue, Next.js sa halip na React, atbp.).
- Ano ang iyong Pagganap ng JavaScript?
- Paano mo proseso ng pag-unlad upang gawing mas mahirap ang pagpasok ng higit pang JavaScript code sa isang proyekto kaysa sa talagang kinakailangan?
- Kung gumagamit ka ng isang balangkas para sa kadalian ng pag-unlad, isaalang-alang magpadala ng framework code sa mga kliyente. Siguro maaari mong malutas ang lahat ng mga isyu sa server?
Karaniwan, ang mga ideyang ito ay sulit na tingnang mabuti, anuman ang eksaktong pipiliin mong bumuo ng front end. Ngunit ang mga ito ay lalong mahalaga kapag gumagawa ka ng isang proyekto na kulang sa pagganap sa simula.
Minamahal na mambabasa! Ano ang nakikita mo bilang perpektong balangkas ng JavaScript?
Pinagmulan: www.habr.com