Veb-saytni sekinlashtirishning unda JavaScript kodlari to'plamini ishlatishdan ko'ra tezroq yo'li yo'q. JavaScript-ni ishlatganda, siz loyihaning ishlashi uchun kamida to'rt marta to'lashingiz kerak. Saytning JavaScript kodi foydalanuvchi tizimlariga nima yuklaydi:
- Faylni tarmoq orqali yuklash.
- Yuklab olingandan so'ng ochilmagan manba kodini tahlil qilish va kompilyatsiya qilish.
- JavaScript kodini bajarish.
- Xotira iste'moli.
Bu kombinatsiya bo'lib chiqadi .
Va biz loyihalarimizga tobora ko'proq JS kodini kiritmoqdamiz. Tashkilotlar React, Vue va boshqalar kabi ramkalar va kutubxonalar bilan ta'minlangan saytlarga o'tayotganda, biz saytlarning asosiy funksiyalarini JavaScript-ga juda bog'liq qilamiz.
Men JavaScript ramkalaridan foydalangan holda juda og'ir veb-saytlarni ko'rdim. Ammo mening bu masala bo'yicha qarashim juda nojo'ya. Gap shundaki, men ishlayotgan kompaniyalar menga veb-sayt ishlashi bilan bog'liq murakkab muammolarga ega bo'lgani uchun kelishadi. Natijada, men bu muammo qanchalik keng tarqalgani va ma'lum bir sayt uchun asos sifatida u yoki bu ramka tanlaganimizda qanday "jarimalar" to'lashimizni bilishga qiziqib qoldim.
Bu loyiha menga buni tushunishga yordam berdi. .
ma'lumotlar
HTTP Arxiv loyihasi oddiy ish stoli saytlariga jami 4308655 5484239 XNUMX havolani va mobil saytlarga XNUMX XNUMX XNUMX havolani kuzatadi. Ushbu havolalar bilan bog'liq ko'plab ko'rsatkichlar orasida tegishli saytlarda topilgan texnologiyalar ro'yxati mavjud. Bu shuni anglatadiki, biz turli xil ramkalar va kutubxonalardan foydalanadigan minglab saytlardan namuna olishimiz va ular mijozlarga qancha kod jo'natishini va bu kod foydalanuvchi tizimlariga qanchalik yuklashini bilib olishimiz mumkin.
Men 2020 yil mart oyidagi maʼlumotlarni toʻpladim, bu men kirish huquqiga ega boʻlgan eng soʻnggi maʼlumotlar edi.
Men barcha saytlar uchun jamlangan HTTP arxiv ma’lumotlarini React, Vue va Angular’dan foydalanayotgan saytlar ma’lumotlari bilan solishtirishga qaror qildim, garchi men boshqa manbalardan ham foydalanishni o‘yladim.
Buni yanada qiziqarli qilish uchun men manba ma'lumotlar to'plamiga jQuery-dan foydalanadigan saytlarni ham qo'shdim. Ushbu kutubxona hali ham juda mashhur. Shuningdek, u React, Vue va Angular tomonidan taqdim etilgan Single Page Application (SPA) modelidan farq qiluvchi veb-saytlarni ishlab chiqishga yondashuvni taqdim etadi.
Bizni qiziqtirgan texnologiyalardan foydalanayotgani aniqlangan saytlarni ifodalovchi HTTP arxividagi havolalar
Ramka yoki kutubxona
Mobil saytlarga havolalar
Oddiy saytlarga havolalar
jQuery
4615474
3714643
munosabat
489827
241023
Vue
85649
43691
burchak
19423
18088
Umidlar va orzular
Ma'lumotlarni tahlil qilishga o'tishdan oldin, men nimaga umid qilishni xohlayotganim haqida gapirmoqchiman.
Ishonamanki, ideal dunyoda ramkalar ishlab chiquvchilarning ehtiyojlarini qondirishdan tashqariga chiqadi va bizning saytlarimizdan kundalik foydalanuvchilarga qandaydir aniq imtiyozlar beradi. Hosildorlik - bu imtiyozlardan biri. Bu erda qulaylik va xavfsizlik ham yodga tushadi. Ammo bu faqat eng muhimi.
Shunday qilib, ideal dunyoda qandaydir ramkalar yuqori samarali veb-sayt yaratishni osonlashtirishi kerak. Buni yoki ramka ishlab chiquvchiga loyihani qurish uchun munosib asos berishi yoki rivojlanishga cheklovlar qo'yganligi, unga biror narsani ishlab chiqishni qiyinlashtiradigan talablarni qo'yganligi sababli amalga oshirilishi kerak. bu sekin bo'lib chiqadi.
Eng yaxshi ramkalar ikkalasini ham bajarishi kerak: yaxshi asosni ta'minlash va munosib natijaga erishishga imkon beradigan ishlarga cheklovlar qo'yish.
Ma'lumotlarning o'rtacha qiymatlarini tahlil qilish bizga kerakli ma'lumotlarni bermaydi. Va, aslida, bu yondashuv bizning e'tiborimizdan chetda qoladi . Buning o'rniga men ega bo'lgan ma'lumotlardan foizli ballarni oldim. Bular 10, 25, 50 (median), 75, 90 foizlardir.
Meni ayniqsa 10 va 90 foizlar qiziqtiradi. 10-persentil ma'lum bir ramka uchun eng yaxshi ishlashni (yoki hech bo'lmaganda eng yaxshisiga ko'proq yoki kamroq yaqin) ifodalaydi. Boshqacha qilib aytganda, bu ma'lum bir ramkadan foydalanadigan saytlarning atigi 10 foizi ushbu darajaga yoki undan yuqori darajaga erishganini anglatadi. Boshqa tomondan, 90-persentil tanganing boshqa tomonidir - bu bizga narsalar qanchalik yomon bo'lishi mumkinligini ko'rsatadi. 90-protsentil keyingi saytlar bo'lib, eng ko'p JS kodiga ega bo'lgan saytlarning oxirgi 10% yoki ularning kodini asosiy mavzuda qayta ishlash uchun eng uzoq vaqt talab etiladi.
JavaScript kodining hajmlari
Boshlash uchun, tarmoq orqali turli saytlar tomonidan uzatiladigan JavaScript kodining hajmini tahlil qilish mantiqan.
Mobil qurilmalarga o'tkazilgan JavaScript kodi (KB) miqdori
Foizlar
10
25
50
75
90
Barcha saytlar
93.4
196.6
413.5
746.8
1201.6
jQuery saytlari
110.3
219.8
430.4
748.6
1162.3
Vue veb-saytlari
244.7
409.3
692.1
1065.5
1570.7
Burchakli veb-saytlar
445.1
675.6
1066.4
1761.5
2893.2
Reaksiya veb-saytlari
345.8
441.6
690.3
1238.5
1893.6
Mobil qurilmalarga yuborilgan JavaScript kodi miqdori
Ish stoli qurilmalariga oʻtkazilgan JavaScript kodi (KB) miqdori
Foizlar
10
25
50
75
90
Barcha saytlar
105.5
226.6
450.4
808.8
1267.3
jQuery saytlari
121.7
242.2
458.3
803.4
1235.3
Vue veb-saytlari
248.0
420.1
718.0
1122.5
1643.1
Burchakli veb-saytlar
468.8
716.9
1144.2
1930.0
3283.1
Reaksiya veb-saytlari
308.6
469.0
841.9
1472.2
2197.8
Ish stoli qurilmalariga oʻtkazilgan JavaScript kodi miqdori
Agar biz faqat saytlar qurilmalarga yuboradigan JS kodining hajmi haqida gapiradigan bo'lsak, unda hamma narsa siz kutgandek ko'rinadi. Ya'ni, agar ramkalardan biri ishlatilsa, bu ideal vaziyatda ham sayt uchun JavaScript kodining hajmi oshishini anglatadi. Buning ajablanarli joyi yo'q - siz JavaScript ramkasini sayt asosiga aylantira olmaysiz va loyiha uchun JS kodining miqdori juda past bo'lishini kutmaysiz.
Ushbu ma'lumotlarning qiziq tomoni shundaki, ba'zi ramkalar va kutubxonalar boshqalarga qaraganda loyiha uchun yaxshiroq boshlang'ich nuqta deb hisoblanishi mumkin. JQuery-ga ega veb-saytlar eng yaxshi ko'rinadi. Ularning ish stoli saytlari barcha saytlarga qaraganda 15% koʻproq JavaScript-ni oʻz ichiga oladi, mobil saytlarida esa 18% koʻproq JavaScript mavjud. (Toʻgʻri, bu yerda maʼlumotlarda biroz chalkashlik bor. Gap shundaki, jQuery koʻp saytlarda mavjud, shuning uchun bunday saytlar boshqalarga qaraganda saytlarning umumiy soni bilan yaqinroq bogʻliq boʻlishi tabiiy. Biroq, bu qanday boʻlishiga taʼsir qilmaydi. manba ma'lumotlari har bir ramka uchun chiqariladi.)
15-18% kod o'sishi muhim ko'rsatkich bo'lsa-da, boshqa ramkalar va kutubxonalar bilan solishtirganda, jQuery tomonidan qo'llaniladigan soliq juda past. 10-persentildagi burchakli saytlar ish stoli qurilmalariga barcha saytlarga qaraganda 344%, mobil qurilmalarga esa 377% koʻproq maʼlumot yuboradi. Reaktsiya saytlari keyingi eng og'ir bo'lib, ish stoli qurilmalariga barcha saytlarga qaraganda 193%, mobil qurilmalarga esa 270% ko'proq kod yuboradi.
Yuqorida aytib o'tgan edimki, ramkadan foydalanish loyihaga ish boshidanoq ma'lum miqdordagi kod kiritilishini bildirsa-da, umid qilamanki, ramka ishlab chiquvchini qandaydir tarzda cheklay oladi. Xususan, biz kodning maksimal miqdorini cheklash haqida gapiramiz.
Qizig'i shundaki, jQuery saytlari bu fikrga amal qiladi. Garchi ular 10-persentil darajasida barcha saytlardan bir oz og'irroq (15-18%) bo'lsa-da, ular 90-persentil darajasida barcha saytlarga qaraganda bir oz engilroq - ish stoli va mobil versiyalarida taxminan 3% ga. Bu juda muhim foyda degani emas, lekin shuni aytish mumkinki, jQuery saytlari hech bo'lmaganda ularning eng katta versiyalarida ham JavaScript-ning katta hajmlariga ega emas.
Ammo boshqa ramkalar haqida ham shunday deyish mumkin emas.
Xuddi 10-persentilda bo'lgani kabi, Angular va React-dagi 90-persentilda saytlar boshqa saytlardan farq qiladi, lekin afsuski, ular yomon tomoni bilan farq qiladi.
Angular saytlari 90-persentilda barcha saytlarga qaraganda mobil qurilmalarga 141%, ish stoli qurilmalariga esa 159% koʻproq maʼlumot yuboradi. Reaksiya saytlari ish stoli qurilmalariga barcha saytlarga qaraganda 73%, mobil qurilmalarga esa 58% ko‘proq jo‘natadi. React saytlarining 90-persentildagi kod hajmi 2197.8 KB. Bu shuni anglatadiki, ushbu saytlar Vue-ga asoslangan eng yaqin raqobatchilarga qaraganda mobil qurilmalarga 322.9 KB ko'proq ma'lumot yuboradi. Angular va React asosidagi ish stoli saytlari va boshqa saytlar orasidagi tafovut yanada kattaroq. Masalan, React ish stoli saytlari shunga o'xshash Vue saytlariga qaraganda qurilmalarga 554.7 KB ko'proq JS kodini yuboradi.
Asosiy mavzudagi JavaScript kodini qayta ishlash uchun vaqt sarflandi
Yuqoridagi ma'lumotlar o'rganilgan ramkalar va kutubxonalardan foydalanadigan saytlarda katta hajmdagi JavaScript kodlari mavjudligini aniq ko'rsatib turibdi. Lekin, albatta, bu bizning tenglamamizning faqat bir qismi.
JavaScript kodi brauzerga kirgandan so'ng uni ish holatiga keltirish kerak. Ayniqsa, ko'p muammolar asosiy brauzer oqimidagi kod bilan bajarilishi kerak bo'lgan harakatlar tufayli yuzaga keladi. Asosiy tarmoq foydalanuvchi harakatlarini qayta ishlash, uslublarni hisoblash va sahifa tartibini yaratish va ko'rsatish uchun javobgardir. Agar siz asosiy mavzuni JavaScript vazifalari bilan to'ldirib qo'ysangiz, u boshqa vazifalarni o'z vaqtida bajarish imkoniyatiga ega bo'lmaydi. Bu sahifalarning ishlashida kechikishlar va "tormoz" ga olib keladi.
HTTP Arxiv ma'lumotlar bazasi V8 dvigatelining asosiy oqimida JavaScript kodini qayta ishlash uchun qancha vaqt ketishi haqida ma'lumotni o'z ichiga oladi. Bu shuni anglatadiki, biz ushbu ma'lumotlarni to'plashimiz va turli saytlarning JavaScript-ni qayta ishlash uchun asosiy mavzu qancha vaqt ketishini bilib olishimiz mumkin.
Mobil qurilmalarda skriptni qayta ishlash bilan bog'liq CPU vaqti (millisekundlarda).
Foizlar
10
25
50
75
90
Barcha saytlar
356.4
959.7
2372.1
5367.3
10485.8
jQuery saytlari
575.3
1147.4
2555.9
5511.0
10349.4
Vue veb-saytlari
1130.0
2087.9
4100.4
7676.1
12849.4
Burchakli veb-saytlar
1471.3
2380.1
4118.6
7450.8
13296.4
Reaksiya veb-saytlari
2700.1
5090.3
9287.6
14509.6
20813.3
Mobil qurilmalarda skriptni qayta ishlash bilan bog'liq CPU vaqti
Ish stoli qurilmalarida skriptni qayta ishlash bilan bog'liq CPU vaqti (millisekundlarda).
Foizlar
10
25
50
75
90
Barcha saytlar
146.0
351.8
831.0
1739.8
3236.8
jQuery saytlari
199.6
399.2
877.5
1779.9
3215.5
Vue veb-saytlari
350.4
650.8
1280.7
2388.5
4010.8
Burchakli veb-saytlar
482.2
777.9
1365.5
2400.6
4171.8
Reaksiya veb-saytlari
508.0
1045.6
2121.1
4235.1
7444.3
Ish stoli qurilmalarida skriptni qayta ishlash bilan bog'liq CPU vaqti
Bu erda siz juda tanish narsani ko'rishingiz mumkin.
Yangi boshlanuvchilar uchun jQuery-ga ega saytlar JavaScript-ni asosiy mavzuda boshqalarga qaraganda ancha kamroq qayta ishlashga sarflaydi. 10-persentilda, barcha saytlar bilan solishtirganda, mobil qurilmalardagi jQuery saytlari asosiy mavzudagi JS kodini qayta ishlashga 61% ko'proq vaqt sarflaydi. Ish stoli jQuery saytlarida ishlov berish vaqti 37% ga oshadi. 90-persentilda jQuery saytlari ballari umumiy ballarga juda yaqin. Xususan, mobil qurilmalardagi jQuery saytlari asosiy tarmoqda barcha saytlarga qaraganda 1.3%, ish stoli qurilmalarida esa asosiy tarmoqda 0.7% kamroq vaqt sarflaydi.
Bizning reytingimizning boshqa tomonida asosiy ipga eng katta yuk bilan tavsiflangan ramkalar mavjud. Bu yana burchakli va reaktsiya. Ularning orasidagi yagona farq shundaki, Angular saytlari React saytlariga qaraganda brauzerlarga katta hajmdagi kodlar yuborsa ham, Angular saytlari kodini qayta ishlash uchun CPU kamroq vaqt talab etiladi. Juda kamroq.
10-persentilda burchakli ish stoli saytlari JS kodini qayta ishlash uchun barcha saytlarga qaraganda 230% ko'proq asosiy ish vaqtini sarflaydi. Mobil saytlar uchun bu ko'rsatkich 313% ni tashkil qiladi. Reaksiya saytlari eng yomon ishlashga ega. Ish stoli qurilmalarida ular kodni qayta ishlash uchun barcha saytlarga qaraganda 248%, mobil qurilmalarda esa kodni qayta ishlash uchun 658% ko'proq vaqt sarflashadi. 658% xato emas. 10-persentilda React saytlari mavjud kodlarini qayta ishlash uchun asosiy ish vaqtining 2.7 soniyasini sarflaydi.
90 foizli raqamlar bu ulkan raqamlar bilan solishtirganda, hech bo'lmaganda biroz yaxshiroq ko'rinadi. Burchakli loyihalar, barcha saytlar bilan solishtirganda, ish stoli qurilmalarida asosiy mavzuda 29%, mobil qurilmalarda esa 27% ko'proq vaqt sarflaydi. React saytlarida shunga o'xshash ko'rsatkichlar mos ravishda 130% va 98% ga o'xshaydi.
90-persentil uchun og'ish foizlari 10-persentil uchun o'xshash qiymatlardan yaxshiroq ko'rinadi. Ammo bu erda vaqtni ko'rsatadigan raqamlar juda qo'rqinchli ko'rinishini esga olish kerak. Aytaylik - React-da qurilgan sayt uchun mobil qurilmaning asosiy oqimida 20.8 soniya. (Menimcha, bu vaqt ichida sodir bo'lgan voqealar alohida maqolaga loyiqdir).
Bu erda bitta potentsial asorat bor (rahmat e'tiborimni ushbu xususiyatga qaratganim va ma'lumotlarni shu nuqtai nazardan sinchkovlik bilan o'rganganim uchun). Gap shundaki, ko'plab saytlar bir nechta front-end vositalaridan foydalanadi. Xususan, men koʻp saytlar jQuery’ni React yoki Vue bilan bir qatorda ishlatayotganini koʻrganman, chunki bu saytlar jQuery’dan boshqa ramkalar yoki kutubxonalarga oʻtadi. Natijada, men ma'lumotlar bazasiga qaytdim, bu safar faqat React, jQuery, Angular yoki Vue ishlatadigan saytlarga mos keladigan havolalarni tanladim, lekin ularning har qanday kombinatsiyasini emas. Mana menda nima bor.
Saytlar faqat bitta ramka yoki faqat bitta kutubxonadan foydalanadigan holatlarda mobil qurilmalarda skriptni qayta ishlash bilan bog'liq protsessor vaqti (millisekundlarda)
Foizlar
10
25
50
75
90
Faqat jQuery-dan foydalanadigan saytlar
542.9
1062.2
2297.4
4769.7
8718.2
Faqat Vue ishlatadigan saytlar
944.0
1716.3
3194.7
5959.6
9843.8
Faqat Angular ishlatadigan saytlar
1328.9
2151.9
3695.3
6629.3
11607.7
Faqat React ishlatadigan veb-saytlar
2443.2
4620.5
10061.4
17074.3
24956.3
Saytlar faqat bitta ramka yoki faqat bitta kutubxonadan foydalanadigan vaziyatda mobil qurilmalarda skriptlarni qayta ishlash bilan bog'liq protsessor vaqti
Birinchidan, bu ajablanarli emas: sayt faqat bitta ramka yoki bitta kutubxonadan foydalansa, bunday saytning ishlashi tez-tez yaxshilanadi. Har bir asbobning ishlashi 10 va 25 foizlarda yaxshiroq ko'rinadi. Bu mantiqiy. Bitta ramka yordamida yaratilgan sayt ikki yoki undan ortiq ramkalar yoki kutubxonalar yordamida yaratilgan saytdan tezroq bo'lishi kerak.
Darhaqiqat, biz ko'rib chiqqan har bir front-end vositasi uchun ballar barcha holatlarda yaxshiroq ko'rindi, bitta qiziq istisno bundan mustasno. Meni hayratga solgan narsa shu ediki, 50-persentil va undan yuqorida, React-dan foydalanadigan saytlar React foydalanadigan yagona kutubxona bo'lsa, yomonroq ishlaydi. Aytgancha, bu ma'lumotlarni bu erda taqdim etishimga sabab bo'ldi.
Bu biroz g'alati, lekin men hali ham bu g'alatilikning izohini izlashga harakat qilaman.
Agar loyiha React va jQuery-dan foydalansa, u holda bu loyiha jQuery-dan React-ga o'tish jarayonining yarmida bo'lishi mumkin. Ehtimol, u ushbu kutubxonalar aralashgan kod bazasiga ega. Biz allaqachon jQuery saytlari React saytlariga qaraganda asosiy mavzuda kamroq vaqt sarflashini ko'rganimiz sababli, bu jQuery-da ba'zi funksiyalarni amalga oshirish sayt ish faoliyatini biroz yaxshilashga yordam berishini ko'rsatishi mumkin.
Ammo loyiha jQuery'dan Reactga o'tishi va Reactga ko'proq tayanishi bilan vaziyat o'zgaradi. Agar sayt haqiqatan ham yuqori sifatda yaratilgan bo'lsa va sayt ishlab chiquvchilari React-dan ehtiyotkorlik bilan foydalansalar, bunday sayt bilan hammasi yaxshi bo'ladi. Ammo o'rtacha React sayti uchun React-dan keng foydalanish asosiy ipning ortib borayotgan yuklanishini anglatadi.
Mobil va ish stoli qurilmalari orasidagi bo'shliq
Ma'lumotlarga qarashimning yana bir usuli bu mobil va ish stoli tajribasi o'rtasidagi farq qanchalik katta ekanligini o'rganish edi. Agar biz JavaScript kodining hajmlarini taqqoslash haqida gapiradigan bo'lsak, unda bunday taqqoslash hech qanday dahshatli narsani ko'rsatmaydi. Albatta, yuklab olinadigan kodning kichikroq hajmini ko'rish yaxshi bo'lar edi, lekin mobil va ish stoli kodlari miqdorida unchalik katta farq yo'q.
Ammo kodni qayta ishlash uchun zarur bo'lgan vaqtni tahlil qilsangiz, mobil va ish stoli qurilmalari o'rtasidagi juda katta bo'shliq sezilarli bo'ladi.
Ish stoli qurilmalariga nisbatan mobil qurilmalarda skriptni qayta ishlash bilan bog'liq vaqtni (foizda) oshirish
Foizlar
10
25
50
75
90
Barcha saytlar
144.1
172.8
185.5
208.5
224.0
jQuery saytlari
188.2
187.4
191.3
209.6
221.9
Vue veb-saytlari
222.5
220.8
220.2
221.4
220.4
Burchakli veb-saytlar
205.1
206.0
201.6
210.4
218.7
Reaksiya veb-saytlari
431.5
386.8
337.9
242.6
179.6
Telefon va noutbuk o'rtasidagi kodni qayta ishlash tezligida ba'zi farqlarni kutish kerak bo'lsa-da, bunday katta raqamlar menga zamonaviy ramkalar kam quvvatli qurilmalarga etarlicha yo'naltirilmaganligini va aniqlangan bo'shliqni yopish istagini bildiradi. Hatto 10-persentilda ham React saytlari ish stolidagi asosiy mavzuga qaraganda mobil asosiy tarmoqda 431.5% ko'proq vaqt sarflaydi. jQuery eng kichik bo'shliqqa ega, ammo bu erda ham mos keladigan ko'rsatkich 188.2% ni tashkil qiladi. Veb-sayt ishlab chiquvchilari o'z loyihalarini ularni qayta ishlash uchun ko'proq CPU vaqtini talab qiladigan tarzda yaratganda (va bu sodir bo'ladi va vaqt o'tishi bilan bu faqat yomonlashadi), kam quvvatli qurilmalar egalari buning uchun to'lashlari kerak.
natijalar
Yaxshi ramkalar ishlab chiquvchilarga veb-loyihalarni yaratish uchun yaxshi asos berishi kerak (xavfsizlik, foydalanish imkoniyati, ishlash nuqtai nazaridan) yoki ushbu cheklovlarni buzadigan narsalarni yaratishni qiyinlashtiradigan o'rnatilgan cheklovlarga ega bo'lishi kerak.
Bu veb-loyihalarning ishlashiga taalluqli emasga o'xshaydi (va, ehtimol, ularning ).
Shuni ta'kidlash kerakki, React yoki Angular saytlari kodni tayyorlash uchun boshqalarga qaraganda ko'proq CPU vaqtini sarflashi React saytlari ishlayotgan paytda Vue saytlariga qaraganda ko'proq protsessor talab qiladi degani emas. Aslida, biz ko'rib chiqqan ma'lumotlar ramkalar va kutubxonalarning operatsion ishlashi haqida juda kam gapiradi. Ular ongli ravishda yoki yo'q, bu ramkalar dasturchilarni undashi mumkin bo'lgan rivojlanish yondashuvlari haqida ko'proq gapirishadi. Biz ramkalar, ularning ekotizimlari va umumiy rivojlanish usullari uchun hujjatlar haqida gapiramiz.
Shuningdek, biz bu erda tahlil qilmagan narsani, ya'ni sayt sahifalari o'rtasida o'tishda qurilma JavaScript kodini bajarish uchun qancha vaqt sarflashini ham eslatib o'tish kerak. SPA foydasiga argument shundan iboratki, bitta sahifali ilova brauzerga yuklangach, foydalanuvchi nazariy jihatdan sayt sahifalariga tezroq kira oladi. Mening shaxsiy tajribam shuni ko'rsatadiki, bu haqiqatdan uzoqdir. Ammo bizda bu masalaga oydinlik kiritish uchun ma'lumotlar yo'q.
Shunisi aniqki, agar siz veb-sayt yaratish uchun ramka yoki kutubxonadan foydalansangiz, siz loyihani dastlab yuklash va uni ishga tushirish bo'yicha murosaga erishasiz. Bu hatto eng ijobiy stsenariylarga ham tegishli.
Tegishli vaziyatlarda ba'zi murosaga kelish mumkin, ammo ishlab chiquvchilar bunday murosaga ongli ravishda erishishlari muhimdir.
Ammo bizda optimizm uchun ham asos bor. Chrome ishlab chiquvchilari ushbu vositalarning ishlashini yaxshilashga yordam berish uchun biz ko‘rib chiqqan ba’zi bir front-end vositalari ortidagilar bilan qanchalik yaqin ishlayotgani meni ruhlantirdi.
Biroq, men pragmatik odamman. Yangi arxitekturalar ularni hal qilganda ishlash muammolarini yuzaga keltiradi. Va kamchiliklarni bartaraf etish uchun vaqt kerak. Xuddi biz buni kutmasligimiz kerak barcha ishlash muammolarini hal qiladi, buni sevimli ramkalarimizning yangi versiyalaridan kutmasligingiz kerak.
Agar siz ushbu materialda muhokama qilingan oldingi vositalardan birini ishlatmoqchi bo'lsangiz, bu sizning loyihangizning ishlashiga zarar etkazmaslik uchun qo'shimcha harakatlar qilishingiz kerakligini anglatadi. Yangi ramkadan foydalanishni boshlashdan oldin e'tiborga olish kerak bo'lgan ba'zi fikrlar:
- O'zingizni aql bilan tekshiring. Haqiqatan ham siz tanlagan ramkadan foydalanishingiz kerakmi? Sof JavaScript bugungi kunda juda ko'p ish qila oladi.
- Siz tanlagan ramkaga (masalan, Preact, Svelte yoki boshqa biror narsa) ushbu ramkaning 90% imkoniyatlarini beradigan engilroq alternativ bormi?
- Agar siz allaqachon ramkadan foydalanayotgan bo'lsangiz, yaxshiroq, konservativ, standart variantlarni taklif qiladigan biror narsa bor yoki yo'qligini o'ylab ko'ring (masalan, Vue o'rniga Nuxt.js, React o'rniga Next.js va boshqalar).
- Sizning JavaScript unumdorligi?
- Qanday qila olasiz loyihaga juda zarur bo'lganidan ko'ra ko'proq JavaScript kodini kiritishni qiyinlashtirish uchun ishlab chiqish jarayoni?
- Rivojlanish qulayligi uchun ramkadan foydalanayotgan bo'lsangiz, o'ylab ko'ring mijozlarga ramka kodini yuborish. Ehtimol, siz serverdagi barcha muammolarni hal qila olasizmi?
Odatda, bu g'oyalar old tomonni ishlab chiqish uchun nimani tanlaganingizdan qat'i nazar, batafsilroq ko'rib chiqishga arziydi. Lekin ular, ayniqsa, unumdorligi kam bo'lgan loyiha ustida ishlayotganingizda juda muhimdir.
Hurmatli o'quvchilar! Siz ideal JavaScript ramkasi sifatida nimani ko'rasiz?
Manba: www.habr.com