Tidak ada cara yang lebih pantas untuk memperlahankan tapak web (tiada pun yang dimaksudkan) daripada menjalankan sekumpulan kod JavaScript padanya. Apabila menggunakan JavaScript, anda perlu membayarnya dalam prestasi projek sekurang-kurangnya empat kali. Berikut ialah perkara yang dimuatkan oleh kod JavaScript tapak kepada sistem pengguna:
- Memuat naik fail melalui rangkaian.
- Menghuraikan dan menyusun kod sumber yang tidak dibungkus selepas memuat turun.
- Melaksanakan kod JavaScript.
- Penggunaan ingatan.
Gabungan ini ternyata .
Dan kami menyertakan lebih banyak kod JS dalam projek kami. Apabila organisasi bergerak ke arah tapak yang dikuasakan oleh rangka kerja dan perpustakaan seperti React, Vue dan lain-lain, kami menjadikan fungsi teras tapak sangat bergantung pada JavaScript.
Saya telah melihat banyak laman web yang sangat berat menggunakan rangka kerja JavaScript. Tetapi visi saya tentang isu ini sangat berat sebelah. Hakikatnya ialah syarikat yang bekerja dengan saya datang kepada saya dengan tepat kerana mereka mempunyai masalah prestasi laman web yang kompleks. Akibatnya, saya menjadi ingin tahu untuk mengetahui betapa meluasnya masalah ini, dan apakah "denda" yang kami bayar apabila kami memilih satu atau rangka kerja lain sebagai asas untuk tapak tertentu.
Projek ini membantu saya memikirkan perkara ini. .
Data
Projek Arkib HTTP menjejaki sejumlah 4308655 pautan ke tapak desktop biasa dan 5484239 pautan ke tapak mudah alih. Antara banyak penunjuk yang dikaitkan dengan pautan ini ialah senarai teknologi yang terdapat di tapak yang sepadan. Ini bermakna kami boleh mencuba beribu-ribu tapak yang menggunakan rangka kerja dan pustaka yang berbeza dan mengetahui jumlah kod yang dihantar kepada pelanggan dan jumlah beban yang dikenakan oleh kod itu pada sistem pengguna.
Saya mengumpul data dari Mac 2020, yang merupakan data terbaharu yang boleh saya akses.
Saya memutuskan untuk membandingkan data Arkib HTTP terkumpul untuk semua tapak dengan data untuk tapak yang didapati menggunakan React, Vue dan Angular, walaupun saya mempertimbangkan untuk menggunakan bahan sumber lain juga.
Untuk menjadikannya lebih menarik, saya juga menambah tapak yang menggunakan jQuery pada set data sumber. Perpustakaan ini masih sangat popular. Ia juga memperkenalkan pendekatan kepada pembangunan laman web yang berbeza daripada model Aplikasi Halaman Tunggal (SPA) yang ditawarkan oleh React, Vue dan Angular.
Pautan dalam Arkib HTTP yang mewakili tapak yang didapati menggunakan teknologi yang menarik minat kami
Rangka kerja atau perpustakaan
Pautan ke tapak mudah alih
Pautan ke tapak biasa
jQuery
4615474
3714643
Bertindak
489827
241023
Vue
85649
43691
bersudut
19423
18088
Harapan dan impian
Sebelum kita beralih kepada menganalisis data, saya ingin bercakap tentang apa yang saya ingin harapkan.
Saya percaya bahawa dalam dunia yang ideal, rangka kerja akan melampaui memenuhi keperluan pembangun dan memberikan beberapa faedah konkrit kepada pengguna harian tapak kami. Produktiviti hanyalah salah satu daripada faedah tersebut. Kebolehcapaian dan keselamatan turut diingati di sini. Tetapi ini hanya perkara yang paling penting.
Jadi, dalam dunia yang ideal, beberapa jenis rangka kerja harus memudahkan untuk membuat tapak web berprestasi tinggi. Ini harus dilakukan sama ada disebabkan oleh fakta bahawa rangka kerja memberikan pemaju asas yang baik untuk membina projek, atau disebabkan fakta bahawa ia mengenakan sekatan ke atas pembangunan, mengemukakan keperluan untuknya yang menyukarkan untuk membangunkan sesuatu yang ternyata lambat.
Rangka kerja terbaik harus melakukan kedua-duanya: menyediakan asas yang baik, dan mengenakan sekatan pada kerja yang membolehkan anda mencapai hasil yang baik.
Menganalisis nilai median data tidak akan memberi kami maklumat yang kami perlukan. Dan, sebenarnya, pendekatan ini meninggalkan perhatian kita . Sebaliknya, saya memperoleh skor persentil daripada data yang saya ada. Ini adalah 10, 25, 50 (median), 75, 90 persentil.
Saya amat berminat dengan persentil ke-10 dan ke-90. Persentil ke-10 mewakili prestasi terbaik (atau sekurang-kurangnya lebih kurang hampir dengan yang terbaik) untuk rangka kerja tertentu. Dalam erti kata lain, ini bermakna hanya 10% tapak yang menggunakan rangka kerja tertentu mencapai tahap ini, atau tahap yang lebih tinggi. Persentil ke-90, sebaliknya, adalah bahagian lain dari syiling - ia menunjukkan kepada kita betapa buruknya perkara itu. Persentil ke-90 ialah tapak mengekoriβ10% tapak terakhir yang mempunyai jumlah kod JS terbesar atau masa paling lama yang diperlukan untuk memproses kod mereka pada urutan utama.
Jilid kod JavaScript
Sebagai permulaan, masuk akal untuk menganalisis saiz kod JavaScript yang dihantar oleh tapak yang berbeza melalui rangkaian.
Jumlah kod JavaScript (KB) yang dipindahkan ke peranti mudah alih
Persentil
10
25
50
75
90
Semua tapak
93.4
196.6
413.5
746.8
1201.6
tapak jQuery
110.3
219.8
430.4
748.6
1162.3
laman web Vue
244.7
409.3
692.1
1065.5
1570.7
laman web sudut
445.1
675.6
1066.4
1761.5
2893.2
Tapak web bertindak balas
345.8
441.6
690.3
1238.5
1893.6
Jumlah kod JavaScript yang dihantar ke peranti mudah alih
Jumlah kod JavaScript (KB) yang dipindahkan ke peranti desktop
Persentil
10
25
50
75
90
Semua tapak
105.5
226.6
450.4
808.8
1267.3
tapak jQuery
121.7
242.2
458.3
803.4
1235.3
laman web Vue
248.0
420.1
718.0
1122.5
1643.1
laman web sudut
468.8
716.9
1144.2
1930.0
3283.1
Tapak web bertindak balas
308.6
469.0
841.9
1472.2
2197.8
Jumlah kod JavaScript yang dipindahkan ke peranti desktop
Jika kita hanya bercakap tentang saiz kod JS yang dihantar oleh tapak ke peranti, maka semuanya kelihatan seperti yang anda jangkakan. Iaitu, jika salah satu rangka kerja digunakan, ini bermakna walaupun dalam situasi yang ideal, jumlah kod JavaScript untuk tapak akan meningkat. Ini tidak menghairankan - anda tidak boleh menjadikan rangka kerja JavaScript sebagai asas tapak dan menjangkakan bahawa jumlah kod JS untuk projek itu akan menjadi sangat rendah.
Apa yang menarik tentang data ini ialah sesetengah rangka kerja dan perpustakaan mungkin dianggap sebagai titik permulaan yang lebih baik untuk projek daripada yang lain. Tapak web dengan jQuery kelihatan terbaik. Tapak desktop mereka mengandungi 15% lebih JavaScript daripada semua tapak, dan tapak mudah alih mereka mengandungi 18% lebih JavaScript. (Diakui, terdapat sedikit penyimpangan dalam data di sini. Hakikatnya ialah jQuery terdapat pada banyak tapak, jadi adalah wajar bahawa tapak sedemikian lebih berkait rapat dengan jumlah tapak daripada yang lain. Walau bagaimanapun, ini tidak menjejaskan bagaimana data sumber adalah output untuk setiap rangka kerja.)
Walaupun pertumbuhan kod 15-18% adalah angka yang ketara, jika dibandingkan dengan rangka kerja dan perpustakaan lain, cukai yang dikenakan oleh jQuery adalah sangat rendah. Tapak bersudut dalam persentil ke-10 menghantar 344% lebih banyak data ke peranti desktop daripada semua tapak dan 377% lebih banyak ke peranti mudah alih. Tapak bertindak balas adalah yang paling berat seterusnya, menghantar 193% lebih kod ke peranti desktop daripada semua tapak dan 270% lagi ke peranti mudah alih.
Saya nyatakan sebelum ini bahawa walaupun menggunakan rangka kerja bermakna sejumlah kod akan dimasukkan ke dalam projek pada permulaan kerja padanya, saya berharap rangka kerja itu dapat mengehadkan pembangun. Khususnya, kita bercakap tentang mengehadkan jumlah maksimum kod.
Apa yang menarik ialah tapak jQuery mengikuti idea ini. Walaupun mereka, pada tahap persentil ke-10, lebih berat sedikit daripada semua tapak (sebanyak 15-18%), mereka, pada tahap persentil ke-90, lebih ringan sedikit daripada semua tapak - kira-kira 3% dalam kedua-dua versi desktop dan mudah alih. Ini bukan untuk mengatakan bahawa ini adalah faedah yang sangat ketara, tetapi boleh dikatakan bahawa tapak jQuery sekurang-kurangnya tidak mempunyai saiz kod JavaScript yang besar walaupun dalam versi terbesarnya.
Tetapi perkara yang sama tidak boleh dikatakan mengenai rangka kerja lain.
Sama seperti dalam kes persentil ke-10, di tapak persentil ke-90 pada Angular dan React berbeza daripada tapak lain, tetapi mereka berbeza, malangnya, menjadi lebih teruk.
Pada persentil ke-90, tapak Angular menghantar 141% lebih data ke peranti mudah alih daripada semua tapak dan 159% lebih banyak ke peranti desktop. Tapak React menghantar 73% lebih banyak ke peranti desktop daripada semua tapak dan 58% lebih banyak ke peranti mudah alih. Saiz kod tapak React pada persentil ke-90 ialah 2197.8 KB. Ini bermakna tapak ini menghantar 322.9 KB lebih banyak data ke peranti mudah alih berbanding pesaing berasaskan Vue terdekat mereka. Jurang antara tapak desktop berdasarkan Angular dan React dan tapak lain adalah lebih besar. Sebagai contoh, tapak desktop React menghantar 554.7 KB lebih banyak kod JS kepada peranti berbanding tapak Vue yang serupa.
Masa yang diambil untuk memproses kod JavaScript pada urutan utama
Data di atas jelas menunjukkan bahawa tapak yang menggunakan rangka kerja dan perpustakaan yang dikaji mengandungi sejumlah besar kod JavaScript. Tetapi, sudah tentu, ini hanya satu bahagian daripada persamaan kita.
Selepas kod JavaScript telah tiba dalam penyemak imbas, ia perlu dibawa ke dalam keadaan berfungsi. Terutamanya banyak masalah disebabkan oleh tindakan yang perlu dijalankan dengan kod dalam utas pelayar utama. Urutan utama bertanggungjawab untuk memproses tindakan pengguna, mengira gaya dan membina serta memaparkan reka letak halaman. Jika anda mengatasi utas utama dengan tugasan JavaScript, ia tidak akan mempunyai peluang untuk menyelesaikan tugasan lain tepat pada masanya. Ini membawa kepada kelewatan dan "brek" dalam pengendalian halaman.
Pangkalan data Arkib HTTP mengandungi maklumat tentang tempoh masa yang diperlukan untuk memproses kod JavaScript pada urutan utama enjin V8. Ini bermakna kami boleh mengumpul data ini dan mengetahui berapa banyak masa yang diambil oleh urutan utama untuk memproses JavaScript pelbagai tapak.
Masa CPU (dalam milisaat) yang berkaitan dengan pemprosesan skrip pada peranti mudah alih
Persentil
10
25
50
75
90
Semua tapak
356.4
959.7
2372.1
5367.3
10485.8
tapak jQuery
575.3
1147.4
2555.9
5511.0
10349.4
laman web Vue
1130.0
2087.9
4100.4
7676.1
12849.4
laman web sudut
1471.3
2380.1
4118.6
7450.8
13296.4
Tapak web bertindak balas
2700.1
5090.3
9287.6
14509.6
20813.3
Masa CPU yang berkaitan dengan pemprosesan skrip pada peranti mudah alih
Masa CPU (dalam milisaat) yang berkaitan dengan pemprosesan skrip pada peranti desktop
Persentil
10
25
50
75
90
Semua tapak
146.0
351.8
831.0
1739.8
3236.8
tapak jQuery
199.6
399.2
877.5
1779.9
3215.5
laman web Vue
350.4
650.8
1280.7
2388.5
4010.8
laman web sudut
482.2
777.9
1365.5
2400.6
4171.8
Tapak web bertindak balas
508.0
1045.6
2121.1
4235.1
7444.3
Masa CPU yang berkaitan dengan pemprosesan skrip pada peranti desktop
Di sini anda boleh melihat sesuatu yang sangat biasa.
Sebagai permulaan, tapak dengan jQuery membelanjakan lebih sedikit pemprosesan JavaScript pada utas utama berbanding yang lain. Pada persentil ke-10, berbanding dengan semua tapak, tapak jQuery pada peranti mudah alih menghabiskan 61% lebih masa memproses kod JS pada urutan utama. Dalam kes tapak jQuery desktop, masa pemprosesan meningkat sebanyak 37%. Pada persentil ke-90, markah tapak jQuery adalah sangat hampir dengan markah agregat. Khususnya, tapak jQuery pada peranti mudah alih menghabiskan 1.3% lebih sedikit masa dalam utas utama daripada semua tapak, dan pada peranti desktop mereka menghabiskan 0.7% lebih sedikit masa dalam utas utama.
Di sisi lain penarafan kami ialah rangka kerja yang dicirikan oleh beban terbesar pada utas utama. Ini, sekali lagi, Angular dan React. Satu-satunya perbezaan di antara mereka ialah, walaupun tapak Angular menghantar jumlah kod yang lebih besar kepada penyemak imbas daripada tapak React, ia mengambil masa CPU yang lebih sedikit untuk memproses kod tapak Angular. Jauh lebih rendah.
Pada persentil ke-10, tapak desktop Sudut membelanjakan 230% lebih masa utas utama memproses kod JS daripada semua tapak. Untuk tapak mudah alih angka ini ialah 313%. Tapak bertindak balas mempunyai prestasi yang paling teruk. Pada peranti desktop mereka menghabiskan 248% lebih banyak masa pemprosesan kod daripada semua tapak dan pada peranti mudah alih mereka menghabiskan 658% lebih banyak masa memproses kod. 658% bukan kesilapan menaip. Pada persentil ke-10, tapak React menghabiskan 2.7 saat masa utas utama memproses kod sedia ada mereka.
Nombor persentil ke-90 kelihatan sekurang-kurangnya lebih baik jika dibandingkan dengan nombor besar ini. Projek sudut, berbanding dengan semua tapak, menghabiskan 29% lebih banyak masa dalam urutan utama pada peranti desktop dan 27% lebih banyak masa pada peranti mudah alih. Dalam kes tapak React, penunjuk yang serupa kelihatan seperti 130% dan 98%, masing-masing.
Peratusan sisihan untuk persentil ke-90 kelihatan lebih baik daripada nilai yang sama untuk persentil ke-10. Tetapi di sini perlu diingat bahawa nombor yang menunjukkan masa kelihatan agak menakutkan. Katakan - 20.8 saat dalam urutan utama peranti mudah alih untuk tapak yang dibina pada React. (Saya percaya bahawa kisah tentang apa yang sebenarnya berlaku pada masa ini layak untuk artikel berasingan).
Terdapat satu komplikasi yang berpotensi di sini (terima kasih untuk menarik perhatian saya kepada ciri ini, dan untuk memeriksa data dengan teliti dari sudut pandangan ini). Hakikatnya ialah banyak tapak menggunakan beberapa alat bahagian hadapan. Khususnya, saya telah melihat banyak tapak menggunakan jQuery bersama React atau Vue kerana tapak ini berhijrah dari jQuery ke rangka kerja atau perpustakaan lain. Akibatnya, saya kembali ke pangkalan data, kali ini hanya memilih pautan yang sepadan dengan tapak yang hanya menggunakan React, jQuery, Angular atau Vue, tetapi bukan gabungannya. Inilah yang saya dapat.
Masa pemproses (dalam milisaat) yang berkaitan dengan pemprosesan skrip pada peranti mudah alih dalam situasi di mana tapak menggunakan hanya satu rangka kerja atau hanya satu pustaka
Persentil
10
25
50
75
90
Tapak yang menggunakan jQuery sahaja
542.9
1062.2
2297.4
4769.7
8718.2
Tapak yang hanya menggunakan Vue
944.0
1716.3
3194.7
5959.6
9843.8
Tapak yang hanya menggunakan Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Tapak web yang hanya menggunakan React
2443.2
4620.5
10061.4
17074.3
24956.3
Masa pemproses yang berkaitan dengan pemprosesan skrip pada peranti mudah alih dalam keadaan tapak menggunakan hanya satu rangka kerja atau hanya satu pustaka
Pertama, sesuatu yang tidak menghairankan: apabila tapak menggunakan hanya satu rangka kerja atau satu pustaka, prestasi tapak sedemikian meningkat lebih kerap daripada tidak. Prestasi bagi setiap instrumen kelihatan lebih baik pada persentil ke-10 dan ke-25. Ia masuk akal. Tapak yang dibuat menggunakan satu rangka kerja hendaklah lebih pantas daripada tapak yang dibuat menggunakan dua atau lebih rangka kerja atau perpustakaan.
Malah, markah untuk setiap alat bahagian hadapan yang kami periksa kelihatan lebih baik dalam semua kes, dengan satu pengecualian yang ingin tahu. Apa yang mengejutkan saya ialah pada persentil ke-50 dan ke atas, tapak yang menggunakan React berprestasi lebih teruk apabila React adalah satu-satunya perpustakaan yang mereka gunakan. Ini, dengan cara ini, adalah sebab saya membentangkan data ini di sini.
Ini agak pelik, tetapi saya masih akan cuba mencari penjelasan untuk keanehan ini.
Jika projek menggunakan kedua-dua React dan jQuery, maka projek itu kemungkinan besar berada di tengah-tengah proses pemindahan dari jQuery ke React. Mungkin dia mempunyai pangkalan kod di mana perpustakaan ini bercampur. Memandangkan kami telah melihat bahawa tapak jQuery menghabiskan lebih sedikit masa di utas utama daripada tapak React, ini mungkin memberitahu kami bahawa melaksanakan beberapa fungsi dalam jQuery membantu meningkatkan prestasi tapak sedikit.
Tetapi apabila projek itu bergerak dari jQuery ke React dan lebih bergantung pada React, keadaan berubah. Jika tapak dibuat dengan kualiti yang benar-benar tinggi, dan pembangun tapak menggunakan React dengan berhati-hati, maka semuanya akan baik-baik saja dengan tapak sedemikian. Tetapi untuk tapak React purata, penggunaan React yang meluas bermakna bahawa utas utama tertakluk kepada peningkatan beban.
Jurang antara peranti mudah alih dan desktop
Satu lagi cara saya melihat data adalah untuk meneroka betapa besar jurang antara pengalaman mudah alih dan desktop. Jika kita bercakap tentang membandingkan jumlah kod JavaScript, maka perbandingan sedemikian tidak mendedahkan apa-apa yang mengerikan. Sudah tentu, adalah bagus untuk melihat jumlah kod yang boleh dimuat turun yang lebih kecil, tetapi tidak banyak perbezaan dalam jumlah kod mudah alih dan desktop.
Tetapi jika anda menganalisis masa yang diperlukan untuk memproses kod, jurang yang sangat besar antara peranti mudah alih dan desktop menjadi ketara.
Peningkatan masa (dalam peratusan) yang berkaitan dengan pemprosesan skrip pada peranti mudah alih berbanding dengan desktop
Persentil
10
25
50
75
90
Semua tapak
144.1
172.8
185.5
208.5
224.0
tapak jQuery
188.2
187.4
191.3
209.6
221.9
laman web Vue
222.5
220.8
220.2
221.4
220.4
laman web sudut
205.1
206.0
201.6
210.4
218.7
Tapak web bertindak balas
431.5
386.8
337.9
242.6
179.6
Walaupun beberapa perbezaan dalam kelajuan pemprosesan kod antara telefon dan komputer riba dijangkakan, jumlah yang begitu besar memberitahu saya bahawa rangka kerja moden tidak cukup disasarkan pada peranti berkuasa rendah dan keinginan untuk menutup jurang yang telah dikenal pasti. Walaupun pada persentil ke-10, tapak React menghabiskan 431.5% lebih banyak masa pada urutan utama mudah alih daripada pada urutan utama desktop. jQuery mempunyai jurang terkecil, tetapi di sini angka yang sepadan ialah 188.2%. Apabila pembangun laman web membuat projek mereka sedemikian rupa sehingga mereka memerlukan lebih banyak masa CPU untuk memprosesnya (dan inilah yang berlaku, dan ia hanya menjadi lebih teruk dari semasa ke semasa), pemilik peranti berkuasa rendah perlu membayarnya.
Keputusan
Rangka kerja yang baik harus memberikan pembangun asas yang baik untuk membina projek web (dari segi keselamatan, kebolehcapaian, prestasi) atau sepatutnya mempunyai sekatan terbina dalam yang menyukarkan untuk mencipta sesuatu yang melanggar sekatan tersebut.
Ini nampaknya tidak terpakai pada prestasi projek web (dan nampaknya pada mereka ).
Perlu diingat bahawa hanya kerana tapak React atau Angular menghabiskan lebih banyak masa CPU untuk menyediakan kod berbanding yang lain tidak bermakna tapak React lebih intensif CPU daripada tapak Vue apabila dijalankan. Malah, data yang kami lihat hanya menyatakan sedikit tentang prestasi operasi rangka kerja dan perpustakaan. Mereka lebih banyak bercakap tentang pendekatan pembangunan yang, secara sedar atau tidak, rangka kerja ini boleh mendorong pengaturcara ke arah itu. Kita bercakap tentang dokumentasi untuk rangka kerja, ekosistemnya, dan teknik pembangunan biasa.
Ia juga patut disebut sesuatu yang kami tidak menganalisis di sini, iaitu, berapa banyak masa yang digunakan oleh peranti untuk melaksanakan kod JavaScript semasa beralih antara halaman tapak. Hujah yang memihak kepada SPA ialah apabila aplikasi halaman tunggal dimuatkan ke dalam penyemak imbas, pengguna akan, secara teori, dapat mengakses halaman tapak dengan lebih pantas. Pengalaman saya sendiri memberitahu saya bahawa ini jauh dari fakta. Tetapi kami tidak mempunyai data untuk menjelaskan isu ini.
Apa yang jelas ialah jika anda menggunakan rangka kerja atau perpustakaan untuk membuat tapak web, anda membuat kompromi dari segi memuatkan projek pada mulanya dan menyediakannya untuk digunakan. Ini terpakai walaupun pada senario yang paling positif.
Adalah mungkin untuk membuat beberapa kompromi dalam situasi yang sesuai, tetapi adalah penting bagi pembangun membuat kompromi sedemikian secara sedar.
Tetapi kita juga mempunyai sebab untuk optimis. Saya digalakkan oleh betapa rapatnya pembangun Chrome bekerjasama dengan mereka yang berada di belakang beberapa alat bahagian hadapan yang telah kami bincangkan untuk membantu meningkatkan prestasi alatan tersebut.
Namun, saya seorang yang pragmatik. Seni bina baharu mencipta masalah prestasi sekerap yang menyelesaikannya. Dan ia mengambil masa untuk menghapuskan kekurangan. Sama seperti kita tidak sepatutnya mengharapkan itu akan menyelesaikan semua masalah prestasi, anda tidak sepatutnya mengharapkan ini daripada versi baharu rangka kerja kegemaran kami.
Jika anda ingin menggunakan salah satu alat bahagian hadapan yang dibincangkan dalam bahan ini, ini bermakna anda perlu membuat usaha tambahan untuk memastikan bahawa, secara kebetulan, anda tidak membahayakan prestasi projek anda. Berikut ialah beberapa pertimbangan untuk dipertimbangkan sebelum anda mula menggunakan rangka kerja baharu:
- Semak diri anda dengan akal. Adakah anda benar-benar perlu menggunakan rangka kerja pilihan anda? JavaScript tulen boleh melakukan banyak perkara hari ini.
- Adakah terdapat alternatif yang lebih ringan untuk rangka kerja pilihan anda (seperti Preact, Svelte atau sesuatu yang lain) yang boleh memberi anda 90% daripada keupayaan rangka kerja itu?
- Jika anda sudah menggunakan rangka kerja, fikirkan sama ada terdapat sesuatu yang menawarkan pilihan standard yang lebih baik, lebih konservatif (contohnya, Nuxt.js bukannya Vue, Next.js dan bukannya React, dsb.).
- Apa yang anda akan Prestasi JavaScript?
- Macam mana boleh proses pembangunan untuk menjadikannya lebih sukar untuk memperkenalkan lebih banyak kod JavaScript ke dalam projek daripada yang diperlukan?
- Jika anda menggunakan rangka kerja untuk memudahkan pembangunan, pertimbangkan menghantar kod rangka kerja kepada pelanggan. Mungkin anda boleh menyelesaikan semua isu pada pelayan?
Biasanya, idea ini patut dilihat dengan lebih dekat, tanpa mengira apa sebenarnya yang anda pilih untuk membangunkan bahagian hadapan. Tetapi mereka amat penting apabila anda sedang mengusahakan projek yang tidak mempunyai prestasi sebagai permulaan.
Pembaca yang dihormati! Apakah yang anda lihat sebagai rangka kerja JavaScript yang ideal?
Sumber: www.habr.com