Няма хутчэйшага спосабу запаволіць сайт (такі вось каламбур), чым выкарыстоўваць на ім кучу JavaScript-кода. Пры выкарыстанні JavaScript даводзіцца расплачвацца за гэта прадукцыйнасцю праектаў не менш за чатыры разы. Вось чым JavaScript-код сайта нагружае сістэмы карыстальнікаў:
- Загрузка файла па сетцы.
- Парсінг і кампіляцыя распакаванага зыходнага кода пасля загрузкі.
- Выкананне JavaScript-кода.
- Спажыванне памяці.
Гэтая камбінацыя аказваецца .
А мы ўключаем у склад сваіх праектаў усё больш і больш JS-кода. Па меры таго, як арганізацыі рухаюцца ў бок сайтаў, якія працуюць на базе фрэймворкаў і бібліятэк накшталт React, Vue і іншых, мы робім асноўны функцыянал сайтаў вельмі моцна якія залежаць ад JavaScript.
Я бачыў мноства вельмі цяжкіх сайтаў, якія выкарыстоўваюць JavaScript-фрэймворкі. Але маё бачанне пытання адрозніваецца моцнай прадузятасцю. Справа ў тым, што кампаніі, з якімі я працую, звяртаюцца да мяне менавіта з-за таго, што яны сустракаюцца са складанымі праблемамі ў вобласці прадукцыйнасці сайтаў. У выніку мне стала цікава даведацца пра тое, наколькі распаўсюджаная гэтая праблема, і пра тое якія «штрафы» мы плацім тады, калі выбіраем той ці іншы фрэймворк у якасці асновы для нейкага сайта.
Высветліць гэта мне дапамог праект .
Дадзеныя
Праект HTTP Archive, у агульнай складанасці, адсочвае 4308655 спасылак на звычайныя сайты, прызначаныя для настольных прылад, і 5484239 спасылак на мабільныя сайты. Сярод шматлікіх паказчыкаў, злучаных з гэтымі спасылкамі, ёсць спіс тэхналогій выяўленых на адпаведных сайтах. Гэта азначае, што мы можам пабудаваць выбарку з тысяч сайтаў, якія выкарыстоўваюць розныя фрэймворкі і бібліятэкі, і пазнаць пра тое, які аб'ём кода яны адпраўляюць кліентам, і пра тое, якую нагрузку на сістэмы карыстачоў стварае гэты код.
Я збіраў дадзеныя за сакавік 2020 гады, гэта былі самыя свежыя дадзеныя, да якіх у мяне быў доступ.
Я вырашыў параўнаць агрэгаваныя HTTP Archive дадзеныя па ўсіх сайтах з дадзенымі па сайтах, на якіх выяўлена выкарыстанне React, Vue і Angular, хоць я разглядаў магчымасць выкарыстання і іншага зыходнага матэрыялу.
Каб было цікавей - я дадаў у набор зыходных дадзеных яшчэ і сайты, на якіх ужываецца jQuery. Гэта бібліятэка ўсё яшчэ карыстаецца вялікай папулярнасцю. Яна, акрамя таго, уяўляе падыход да распрацоўкі вэб-сайтаў, адрозны ад мадэлі аднастаронкавага прыкладання (SPA, Single Page Application), прапанаваны React, Vue і Angular.
Спасылкі ў HTTP Archive, якія прадстаўляюць сайты, на якіх выяўлена выкарыстанне цікавых для нас тэхналогій
Фрэймворк ці бібліятэка
Спасылкі на мабільныя сайты
Спасылкі на звычайныя сайты
JQuery
4615474
3714643
Рэагаваць
489827
241023
Ую
85649
43691
вуглаваты
19423
18088
Надзеі і мары
Перш чым мы пяройдзем да аналізу дадзеных, хачу расказаць пра тое, на што мне хацелася б спадзявацца.
Я мяркую, што ў ідэальным свеце фрэймворкі павінны ісці далей задавальненні патрэб распрацоўнікаў і даваць нейкія пэўныя перавагі звычайным карыстачам, якія працуюць з нашымі сайтамі. Прадукцыйнасць - гэта толькі адна з такіх пераваг. Тут яшчэ прыходзяць у галаву даступнасць і бяспеку. Але гэта - толькі самае важнае.
Такім чынам, у ідэальным свеце нейкі фрэймворк павінен аблягчаць стварэнне высокапрадукцыйнага сайта. Рабіцца гэта павінна альбо за кошт таго, што фрэймворк дае распрацоўніку годную базу, на якой можна пабудаваць праект, альбо за кошт таго, што накладвае на распрацоўку абмежавання, высоўвае да яе патрабаванні, якія ўскладняюць распрацоўку чагосьці такога, што акажацца павольным.
Самыя лепшыя фрэймворкі павінны рабіць і тое і іншае: і даваць добрую базу, і накладваць на працу абмежаванні, якія дазваляюць дамагацца годнага выніку.
Аналіз медыянных значэнняў даных не дасць нам патрэбнай інфармацыі. І, насамрэч, такі падыход пакідае за межамі нашай увагі . Замест гэтага я вывеў з наяўных у мяне дадзеных паказчыкі, выяўленыя ў перцэнтылях. Гэта - 10, 25, 50 (медыяна), 75, 90 перцентили.
Мяне асабліва цікавяць 10 і 90 перцынцілі. 10 перцентиль прадстаўляе самыя лепшыя паказчыкі (ці, прынамсі, больш-менш блізкія да самых лепшых) для канкрэтнага фрэймворка. Іншымі словамі, гэта значыць, што толькі 10% сайтаў, выкарыстоўвалых пэўны фрэймворк даходзяць да гэтага, ці да больш высокага ўзроўню. 90 перцентиль, з іншага боку, гэта - адваротны бок медаля - ён паказвае нам тое, наколькі ўсё можа быць дрэнна. 90 перцентиль - гэта сайты, якія плятуць у хвасце - тыя апошнія 10% сайтаў, якія характарызуюцца самымі вялікімі аб'ёмамі JS-кода або самым вялікім часам, патрабаваным на апрацоўку іх кода ў галоўным струмені.
Аб'ёмы JavaScript-кода
Для пачатку мае сэнс прааналізаваць памер JavaScript-кода, які перадаецца рознымі сайтамі па сетцы.
Аб'ём JavaScript-кода (Кб), перададзенага на мабільныя прылады
Перцынцілі
10
25
50
75
90
Усе сайты
93.4
196.6
413.5
746.8
1201.6
jQuery-сайты
110.3
219.8
430.4
748.6
1162.3
Vue-сайты
244.7
409.3
692.1
1065.5
1570.7
Angular-сайты
445.1
675.6
1066.4
1761.5
2893.2
React-сайты
345.8
441.6
690.3
1238.5
1893.6
Аб'ём JavaScript-кода, які перадаецца на мабільныя прылады
Аб'ём JavaScript-кода (Кб), перададзенага на настольныя прылады
Перцынцілі
10
25
50
75
90
Усе сайты
105.5
226.6
450.4
808.8
1267.3
jQuery-сайты
121.7
242.2
458.3
803.4
1235.3
Vue-сайты
248.0
420.1
718.0
1122.5
1643.1
Angular-сайты
468.8
716.9
1144.2
1930.0
3283.1
React-сайты
308.6
469.0
841.9
1472.2
2197.8
Аб'ём JavaScript-кода, які перадаецца на настольныя прылады
Калі казаць толькі пра памеры JS-кода, які адпраўляецца сайтамі на прылады, тое ўсё выглядае прыкладна так, як можна чакаць. А менавіта, калі выкарыстоўваецца адзін з фрэймворкаў - гэта значыць, што нават у ідэальнай сітуацыі аб'ём JavaScript-кода сайта вырасце. Гэта і нядзіўна - нельга зрабіць JavaScript-фрэймворк асновай сайта і чакаць таго, што аб'ём JS-кода праекта апынецца вельмі нізкім.
Характэрна ў гэтых дадзеных тое, што некаторыя фрэймворкі і бібліятэкі можна злічыць больш удалай стартавай кропкай праекту, чым іншыя. Сайты з jQuery выглядаюць лепш за ўсё. У настольных версіях сайтаў яны ўтрымліваюць на 15% больш JavaScript, чым усе сайты, а ў мабільных - на 18% больш. (Трэба прызнаць, што тут можна назіраць некаторае скажэнне дадзеных. Справа ў тым, што jQuery прысутнічае на мностве сайтаў, таму цалкам натуральна тое, што такія сайты цясней, чым іншыя, злучаны з агульнай колькасцю сайтаў. Аднак гэта не ўплывае на тое, як зыходныя дадзеныя выводзяцца для кожнага фрэймворка.)
Хоць рост аб'ёму кода ў 15-18% - гэта прыкметная лічба, параўнаўшы гэта з іншымі фрэймворкамі і бібліятэкамі, можна прыйсці да высновы аб тым, што «падатак», спаганяемы jQuery, вельмі нізкі. Сайты на Angular з 10 перцентиля адпраўляюць на настольныя прылады на 344% больш дадзеных, чым усе сайты, а на мабільныя - на 377% больш. React-сайты – наступныя па "цяжары", адпраўляюць на настольныя прылады на 193% больш кода, чым усе сайты, а на мабільныя – на 270% больш.
Раней я ўжо згадваў аб тым, што хоць ужыванне фрэймворка і азначае, што ў праект, у самым пачатку працы над ім, будзе ўключаны вызначаны аб'ём кода, я спадзяюся на тое, што фрэймворк здольны неяк абмяжоўваць распрацоўніка. У прыватнасці, гаворка ідзе аб абмежаванні максімальнага аб'ёму кода.
Цікава тое, што jQuery-сайты прытрымліваюцца гэтай ідэі. Хоць яны, на ўзроўні 10 перцентиля, крыху цяжэй за ўсіх сайтаў (на 15-18%), яны, на ўзроўні 90 перцентиля, крыху лягчэй за ўсіх – прыкладна на 3% і ў настольным, і ў мабільным варыянтах. Нельга сказаць, што гэта – вельмі ўжо значная выгада, але можна сказаць, што сайты на jQuery, прынамсі, не адрозніваюцца велізарнымі памерамі JavaScript-кода нават у сваіх самых вялікіх варыянтах.
А вось пра іншыя фрэймворкі таго ж самага сказаць нельга.
Гэтак жа, як і ў выпадку з 10 перцентилем, на 90 перцентиле сайты на Angular і React адрозніваюцца ад іншых сайтаў, але адрозніваюцца яны, нажаль, у горшы бок.
На 90 перцынтыле Angular-сайты адпраўляюць на мабільныя прылады на 141% больш дадзеных, чым усе сайты, а на настольныя – на 159% больш. Сайты на React адпраўляюць на настольныя прылады на 73% больш, чым усе сайты, а на мабільныя - на 58% больш. Памер кода React-сайтаў на 90 перцэнтыле складае 2197.8 Кб. Гэта значыць, што такія сайты адпраўляюць на мабільныя прылады на 322.9 Кб больш дадзеных, чым іх найблізкія канкурэнты, заснаваныя на Vue. Разрыў паміж настольнымі сайтамі, заснаванымі на Angular і React, і паміж іншымі сайтамі, яшчэ большы. Напрыклад, настольныя React-сайты адпраўляюць на прылады на 554.7 Кб больш JS-кода, чым аналагічныя Vue-сайты.
Час, які сыходзіць на апрацоўку JavaScript-кода ў галоўным струмені
Вышэйпрыведзеныя дадзеныя выразна паказваюць на тое, што сайты, якія выкарыстоўваюць доследныя фрэймворкі і бібліятэкі, утрымоўваюць вялікія аб'ёмы JavaScript-кода. Але, вядома, гэта толькі адна з частак нашага ўраўнення.
Пасля таго, як JavaScript-код прыбыў у браўзэр, яго трэба прывесці ў працаздольны стан. Асабліва шмат праблем выклікаюць тыя дзеянні, якія даводзіцца праводзіць з кодам у галоўным струмені браўзэра. Галоўны паток адказны за апрацоўку дзеянняў карыстальніка, за вылічэнне стыляў, за пабудову і вывад макета старонкі. Калі заваліць галоўную плынь JavaScript-справамі, у яго не будзе магчымасці своечасова вырашаць астатнія задачы. Гэта прыводзіць да затрымак і тормазам у працы старонак.
У базе дадзеных HTTP Archive ёсць звесткі аб тым, колькі часу сыходзіць на апрацоўку JavaScript-кода ў галоўным струмені рухавічка V8. Гэта значыць, што мы можам сабраць гэтыя дадзеныя і даведацца аб тым, колькі часу галоўнай плыні патрабуецца на апрацоўку JavaScript розных сайтаў.
Працэсарны час (у мілісекундах), які адносіцца да апрацоўкі скрыптоў на мабільных прыладах.
Перцынцілі
10
25
50
75
90
Усе сайты
356.4
959.7
2372.1
5367.3
10485.8
jQuery-сайты
575.3
1147.4
2555.9
5511.0
10349.4
Vue-сайты
1130.0
2087.9
4100.4
7676.1
12849.4
Angular-сайты
1471.3
2380.1
4118.6
7450.8
13296.4
React-сайты
2700.1
5090.3
9287.6
14509.6
20813.3
Працэсарны час, які адносіцца да апрацоўкі скрыптоў на мабільных прыладах.
Працэсарны час (у мілісекундах), якое адносіцца да апрацоўкі скрыптоў на настольных прыладах.
Перцынцілі
10
25
50
75
90
Усе сайты
146.0
351.8
831.0
1739.8
3236.8
jQuery-сайты
199.6
399.2
877.5
1779.9
3215.5
Vue-сайты
350.4
650.8
1280.7
2388.5
4010.8
Angular-сайты
482.2
777.9
1365.5
2400.6
4171.8
React-сайты
508.0
1045.6
2121.1
4235.1
7444.3
Працэсарны час, які адносіцца да апрацоўкі скрыптоў на настольных прыладах.
Тут можна разгледзець сёе-тое вельмі знаёмае.
Для пачатку - сайты з jQuery марнуюць на апрацоўку JavaScript у галоўным струмені значна менш, чым іншыя. На 10 перцентиле, у параўнанні са ўсімі сайтамі, jQuery-сайты на мабільных прыладах марнуюць на апрацоўку JS-кода ў галоўным струмені на 61% больш часу. У выпадку з настольнымі jQuery сайтамі час апрацоўкі расце на 37%. На ўзроўні 90 перцэнтыляў паказчыкі jQuery-сайтаў вельмі блізкія да агрэгаваных паказчыкаў. У прыватнасці, jQuery-сайты на мабільных прыладах марнуюць на 1.3% менш часу ў галоўнай плыні, чым усе сайты, а на настольных прыладах – на 0.7% менш часу.
З іншага боку нашага рэйтынгу знаходзяцца фрэймворкі, якія характарызуюцца найбольшай нагрузкай на галоўную плынь. Гэта, зноў, Angular і React. Розніца паміж імі складаецца толькі ў тым, што, хоць Angular-сайты адпраўляюць у браўзэры вялікія аб'ёмы кода, чым React-сайты, на апрацоўку кода Angular-сайтаў сыходзіць менш працэсарнага часу. Значна менш.
На 10 перцентиле настольныя Angular-сайты марнуюць на апрацоўку JS-кода на 230% больш часу галоўнай плыні, чым усе сайты. Для мабільных сайтаў гэты паказчык складае 313 працэнтаў. React-сайты характарызуюцца найгоршымі паказчыкамі. На настольных прыладах яны марнуюць на апрацоўку кода на 248% больш часу, чым усе сайты, а на мабільных - на 658% больш. 658% - гэта не памылка друку. На 10 перцентиле React-сайты марнуюць 2.7/XNUMX секунды часу галоўнага патоку на апрацоўку наяўнага ў іх кода.
Паказчыкі 90 перцентиля, калі параўнаць іх з гэтымі вялізнымі лічбамі, выглядаюць, па меншай меры, крыху лепш. Angular-праекты, параўнаныя з усімі сайтамі, марнуюць на настольных прыладах у галоўным струмені на 29% больш часу, а на мабільных прыладах – на 27% больш. У выпадку з React-сайтамі аналагічныя паказчыкі выглядаюць адпаведна як 130% і 98%.
Працэнтныя значэнні адхіленняў для 90 перцентиля выглядаюць лепш, чым падобныя значэнні для 10 перцентиля. Але тут варта памятаць аб тым, што лічбы, якія паказваюць на час, здаюцца даволі страшнымі. Скажам – 20.8 секунд у галоўным струмені мабільнай прылады для сайта, пабудаванага на React. (Мяркую, аповяд пра тое, што, насамрэч, адбываецца за гэты час, варты асобнага артыкула).
Тут ёсць адна патэнцыйная складанасць (дзякую за тое, што ён прыцягнуў маю ўвагу да гэтай асаблівасці, і за тое, што я ўважліва разгледзеў дадзеныя з гэтага пункту гледжання). Справа ў тым, што на шматлікіх сайтах выкарыстоўваецца некалькі фронтэнд-інструментаў. У прыватнасці, я бачыў мноства сайтаў, якія ўжываюць jQuery разам з React ці Vue, бо гэтыя сайты мігруюць з jQuery на іншыя фрэймворкі ці бібліятэкі. У выніку я зноў звярнуўся да базы дадзеных, выбіраючы гэтым разам толькі тыя спасылкі, якія адпавядаюць сайтам, на якіх выкарыстоўваецца толькі React, jQuery, Angular ці Vue, але не нейкая іх камбінацыя. Вось што ў мяне атрымалася.
Працэсарны час (у мілісекундах), які адносіцца да апрацоўкі скрыптоў на мабільных прыладах у сітуацыі, калі на сайтах выкарыстоўваецца толькі адзін фрэймворк ці толькі адна бібліятэка
Перцынцілі
10
25
50
75
90
Сайты, на якіх выкарыстоўваецца толькі jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Сайты, на якіх выкарыстоўваецца толькі Vue
944.0
1716.3
3194.7
5959.6
9843.8
Сайты, на якіх выкарыстоўваецца толькі Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Сайты, на якіх выкарыстоўваецца толькі React
2443.2
4620.5
10061.4
17074.3
24956.3
Працэсарны час, які адносіцца да апрацоўкі скрыптоў на мабільных прыладах у сітуацыі, калі на сайтах выкарыстоўваецца толькі адзін фрэймворк, ці толькі адна бібліятэка
Спачатку - пра тое, што здзіўлення не выклікае: калі на сайце выкарыстоўваецца толькі адзін фрэймворк або адна бібліятэка, прадукцыйнасць такога сайта часцей паляпшаецца, чым не паляпшаецца. Паказчыкі па кожнай прыладзе выглядаюць лепш на 10 і 25 перцентилях. Гэта мае сэнс. Сайт, які зроблены з выкарыстаннем аднаго фрэймворка, павінен быць больш прадукцыйным, чым сайт, які зроблены з выкарыстаннем двух або большай колькасці фрэймворкаў або бібліятэк.
Насамрэч, паказчыкі па кожным доследным фронтэнд-інструменту выглядаюць лепш ва ўсіх выпадках, за вылікам аднаго цікавага выключэння. Мяне здзівіла тое, што на ўзроўні 50 перцентиля і вышэй сайты, якія выкарыстоўваюць React, адрозніваюцца горшай прадукцыйнасці ў тым выпадку, калі React – гэта адзіная выкарыстоўваная на іх бібліятэка. Гэта, дарэчы, стала прычынай таго, што я прыводжу тут гэтыя дадзеныя.
Гэта крыху дзіўна, але я, усё ж паспрабую пашукаць тлумачэнне гэтай дзівацтвы.
Калі ў праекце выкарыстоўваецца і React, і jQuery, то гэты праект, хутчэй за ўсё, знаходзіцца дзесьці на паўдарогі падчас пераходу з jQuery на React. Магчыма, ён мае кодавую базу, у якіх гэтыя бібліятэкі змяшаныя. Так як мы ўжо бачылі, што jQuery-сайты марнуюць у галоўным патоку менш часу, чым React-сайты, гэта можа казаць нам аб тым, што рэалізацыя нейкага функцыяналу на jQuery дапамагае крыху палепшыць паказчыкі сайта.
Але па меры таго, як праект, пераходзячы з jQuery на React, усё больш належыць на React, сітуацыя мяняецца. Калі сайт зроблены па-сапраўднаму якасна, і распрацоўшчыкі сайта выкарыстоўваюць React абачліва, то з такім сайтам усё будзе добра. Але для сярэднестатыстычнага React-сайта шырокае выкарыстанне React азначае, што галоўны струмень падвяргаецца падвышанай нагрузцы.
Разрыў паміж мабільнымі і настольнымі прыладамі
Яшчэ адзін пункт гледжання, з якога я зірнуў на доследныя дадзеныя, складалася ў даследаванні таго, наколькі вялікі парыў паміж працай з сайтамі на мабільных і настольных прыладах. Калі казаць аб супастаўленні аб'ёмаў JavaScript-кода, то нічога страшнага такое супастаўленне не выяўляе. Вядома, прыемна было б бачыць меншыя аб'ёмы загружанага кода, але асаблівай розніцы ў аб'ёмах мабільнага і настольнага кода няма.
А вось калі прааналізаваць час, неабходны на апрацоўку кода, становіцца заўважным вельмі вялікі разрыў паміж мабільнымі і настольнымі прыладамі.
Рост часу (у працэнтах) які адносіцца да апрацоўкі скрыптоў на мабільных прыладах у параўнанні з настольнымі.
Перцынцілі
10
25
50
75
90
Усе сайты
144.1
172.8
185.5
208.5
224.0
jQuery-сайты
188.2
187.4
191.3
209.6
221.9
Vue-сайты
222.5
220.8
220.2
221.4
220.4
Angular-сайты
205.1
206.0
201.6
210.4
218.7
React-сайты
431.5
386.8
337.9
242.6
179.6
Хоць некаторая розніца ў хуткасці апрацоўкі кода паміж тэлефонам і наўтбукам – гэта цалкам чакана, такія вялікія лікі кажуць мне пра тое, што сучасныя фрэймворкі нядосыць нацэленыя на маламагутныя прылады, і на імкненне да зачынення выяўленага парыву. Нават на 10 перцентиле React-сайты марнуюць у галоўнай плыні мабільных прылад на 431.5% больш часу, чым у галоўнай плыні настольных. Найменшы разрыў назіраецца ў jQuery, але нават тут які адпавядае паказчык роўны 188.2%. Калі распрацоўшчыкі сайтаў робяць свае праекты так, што на іх апрацоўку патрабуецца больш працэсарнага часу (а так і адбываецца, і з часам усё толькі горш), плаціць за гэта даводзіцца ўладальнікам маламагутных прылад.
Вынікі
Добрыя фрэймворкі павінны даваць распрацоўнікам якасную базу для стварэння вэб-праектаў (у плане бяспекі, даступнасці, прадукцыйнасці), ці павінны валодаць убудаванымі абмежаваннямі, якія ўскладняюць стварэнне чагосьці такога, што гэтыя абмежаванні парушаюць.
Гэта, як здаецца, не адносіцца да прадукцыйнасці вэб-праектаў (і, відаць, да іх ).
Варта адзначыць, што тое, што React-або Angular-сайты марнуюць больш працэсарнага часу на падрыхтоўку кода, чым іншыя, не абавязкова значыць тое, што React-сайты падчас прац мацней нагружаюць працэсар, чым Vue-сайты. Насамрэч, разгледжаныя намі дадзеныя вельмі мала кажуць аб працоўнай прадукцыйнасці фрэймворкаў і бібліятэк. Яны больш кажуць аб падыходах да распрацоўкі, да якіх, свядома ці не, гэтыя фрэймворкі могуць падштурхоўваць праграмістаў. Гаворка ідзе аб дакументацыі да фрэймворкам, аб іх экасістэме, аб распаўсюджаных прыёмах распрацоўкі.
Яшчэ варта сказаць аб тым, што мы тут не аналізавалі, а менавіта, аб тым, колькі часу прылада марнуе на выкананне JavaScript-кода пры пераходах паміж старонкамі сайта. Довад у карысць SPA складаецца ў тым, што, як толькі аднастаронкавая праграма загружана ў браўзэр, карыстач, тэарэтычна, зможа хутчэй адчыняць старонкі сайта. Мой уласны досвед падказвае мне, што гэта - далёка не факт. Але ў нас няма дадзеных, якія дазваляюць растлумачыць гэтае пытанне.
Цалкам зразумела толькі тое, што калі вы карыстаецеся фрэймворкам або бібліятэкай для стварэння сайта, вы ідзяце на кампраміс у плане першапачатковай загрузкі праекта і падрыхтоўкі яго да працы. Гэта ставіцца нават да самых пазітыўных сцэнароў.
У адпаведных сітуацыях цалкам можна пайсці на некаторыя кампрамісы, але важна тое, каб распрацоўшчыкі ішлі б на такія кампрамісы свядома.
Але ў нас ёсць і нагода для аптымізму. Мяне натхняе тое, як шчыльна распрацоўнікі Chrome узаемадзейнічаюць з тымі, хто займаецца некаторымі з разгледжаных намі фронтэнд-інструментаў у імкненні дапамагчы палепшыць прадукцыйнасць гэтых прылад.
Аднак я - прагматычны чалавек. Новыя архітэктуры таксама часта ствараюць праблемы з прадукцыйнасцю, як і вырашаюць іх. І на тое, каб ухіліць недахопы, патрэбен час. Гэтак жа сама, як нам не варта чакаць таго, што вырашаць усе праблемы прадукцыйнасці, не варта чакаць гэтага і ад новых версій нашых каханых фрэймворкаў.
Калі вы хочаце скарыстацца адным з разгледжаных у гэтым матэрыяле фронтэнд-інструментаў, гэта азначае, што вам давядзецца прыкласці дадатковыя намаганні да таго, каб, між іншым, не нашкодзіць прадукцыйнасці свайго праекта. Вось некаторыя меркаванні, якія варта разгледзець перад пачаткам ужывання новага фрэймворка:
- Праверце сябе з пункта гледжання разумнага сэнсу. Вам праўда трэба выкарыстоўваць абраны фрэймворк? Чысты JavaScript сёння здольны на вельмі шматлікае.
- Ці ёсць лягчэйшая альтэрнатыва абранаму фрэймворку (накшталт Preact, Svelte ці чагосьці яшчэ), здольная даць вам 90% магчымасцяў гэтага фрэймворка?
- Калі вы ўжо карыстаецеся нейкім фрэймворкам - падумайце аб тым, ці ёсць нешта такое, што прапануе лепшыя, больш кансерватыўныя, стандартныя параметры (напрыклад - Nuxt.js замест Vue, Next.js замест React, і гэтак далей).
- Якім будзе ваш JavaScript-прадукцыйнасці?
- Як вы можаце працэс распрацоўкі з мэтай ускладнення ўкаранення ў праект большага аб'ёму JavaScript-кода, чым гэта абсалютна неабходна?
- Калі вы выкарыстоўваеце фрэймворк дзеля выгоды распрацоўкі, падумайце аб тым, адпраўляць код фрэймворка кліентам. Можа быць, вы зможаце вырашыць усе пытанні на сэрвэры?
Звычайна да гэтых ідэй варта дагледзецца па-за залежнасцю ад таго, што менавіта вы абралі для распрацоўкі фронтэнда. Але яны асабліва важныя тады, калі вы працуеце над праектам, якому, з самага пачатку, бракуе прадукцыйнасці.
Паважаныя чытачы! Якім вы бачыце ідэальны JavaScript-фрэймворк?
Крыніца: habr.com