👩🏾‍⚕️ 🛌 🕰️ Harga kerangka kerja JavaScript 🐒 🤷🏼 🎅🏾

Tidak ada cara yang lebih cepat untuk memperlambat situs (pelesetan itu) daripada menggunakan banyak kode JavaScript di dalamnya. Saat menggunakan JavaScript, Anda harus membayar untuk ini dengan kinerja proyek setidaknya empat kali. Ini adalah cara kode JavaScript situs memuat sistem pengguna:

Unduh file melalui jaringan.
Parsing dan kompilasi kode sumber yang tidak dibongkar setelah memuat.
Eksekusi kode JavaScript.
Konsumsi memori.

Kombinasi ini sangat mahal . Dan kami memasukkan semakin banyak kode JS dalam proyek kami. Saat organisasi bergerak menuju situs berdasarkan kerangka dan pustaka seperti React, Vue, dan lainnya, kami membuat fungsi utama situs sangat bergantung pada JavaScript.

Saya melihat banyak situs yang sangat berat menggunakan kerangka kerja JavaScript. Tetapi visi saya tentang masalah ini sangat berat sebelah. Faktanya adalah bahwa perusahaan tempat saya bekerja menghubungi saya justru karena mereka menghadapi masalah kompleks di bidang kinerja situs web. Akibatnya, saya menjadi penasaran untuk mengetahui seberapa luas masalah ini dan “denda” macam apa yang kita bayarkan ketika kita memilih satu atau beberapa kerangka kerja lain sebagai dasar untuk situs tertentu.

Proyek Arsip HTTP membantu saya mengetahui hal ini .

Data

Proyek Arsip HTTP, secara total, melacak 4.308.655 tautan ke situs reguler yang didedikasikan untuk perangkat desktop, dan 5.484.239 tautan ke situs seluler. Di antara banyak indikator yang terkait dengan tautan ini, ada daftar teknologi yang ditemukan di situs masing-masing. Ini berarti bahwa kami dapat membuat sampel dari ribuan situs yang menggunakan berbagai kerangka kerja dan perpustakaan, dan mencari tahu berapa banyak kode yang mereka kirim ke pelanggan, dan berapa banyak beban yang dibuat sistem pengguna membuat kode ini.

Saya mengumpulkan data untuk Maret 2020, ini adalah data terbaru yang dapat saya akses.

Saya memutuskan untuk membandingkan data Arsip HTTP agregat untuk semua situs dengan data untuk situs di mana React, Vue, dan Angular terdeteksi, meskipun saya sedang mempertimbangkan untuk menggunakan bahan sumber lainnya.

Untuk membuatnya lebih menarik - saya juga menambahkan situs yang menggunakan jQuery ke dataset sumber. Perpustakaan ini masih sangat populer. Ini juga menyediakan pendekatan pengembangan situs web yang berbeda dari model Aplikasi Halaman Tunggal (SPA) yang diusulkan oleh React, Vue, dan Angular.

Tautan di Arsip HTTP mewakili situs yang telah menemukan penggunaan teknologi yang menarik bagi kami

Kerangka kerja atau perpustakaan	Tautan ke situs seluler	Tautan ke situs reguler
jQuery	4615474	3714643
Reaksi	489827	241023
Vue	85649	43691
Sudut	19423	18088

Harapan dan impian

Sebelum kita melanjutkan ke analisis data, saya ingin berbicara tentang apa yang ingin saya harapkan.

Saya percaya bahwa di dunia yang ideal, kerangka kerja harus melampaui memuaskan kebutuhan pengembang dan memberikan keuntungan konkret tertentu untuk pengguna biasa yang bekerja dengan situs kami. Kinerja hanyalah salah satu dari manfaat ini. Di sini, aksesibilitas dan keamanan masih muncul di pikiran. Tapi ini hanya yang paling penting.

Jadi, di dunia yang ideal, kerangka kerja tertentu harus memfasilitasi pembuatan situs berkinerja tinggi. Ini harus dilakukan baik karena fakta bahwa kerangka kerja memberikan pengembang dasar yang layak untuk membangun proyek, atau karena fakta bahwa ia memberlakukan pembatasan pada pengembangan, mengedepankan persyaratan untuk itu yang mempersulit pengembangan sesuatu yang ternyata lambat.

Kerangka kerja terbaik harus melakukan keduanya: memberi dasar yang baik, dan memaksakan pembatasan pada pekerjaan, memungkinkan untuk mencapai hasil yang layak.

Analisis nilai data median tidak akan memberi kita informasi yang diperlukan. Dan, pada kenyataannya, pendekatan semacam itu meninggalkan banyak hal penting di luar perhatian kita . Sebaliknya, saya menyimpulkan dari indikator data saya yang dinyatakan dalam persentil. Ini adalah 10, 25, 50 (median), 75, 90 persentil.

Saya khususnya tertarik pada persentil ke 10 dan ke 90. Persentil ke-10 mewakili kinerja terbaik (atau setidaknya mendekati atau kurang mendekati yang terbaik) untuk kerangka kerja tertentu. Dengan kata lain, ini berarti bahwa hanya 10% dari situs yang menggunakan kerangka kerja tertentu mencapai ini, atau ke tingkat yang lebih tinggi. Persentil ke-90, di sisi lain, adalah sisi lain dari koin - ini menunjukkan kepada kita seberapa buruknya hal itu. Persentil ke-90 adalah situs tenun - 10% terakhir dari situs yang ditandai oleh volume terbesar kode JS atau waktu terlama yang diperlukan untuk memproses kode mereka di arus utama.

Volume kode JavaScript

Untuk mulai dengan, masuk akal untuk menganalisis ukuran kode JavaScript yang dikirimkan oleh berbagai situs melalui jaringan.

Jumlah kode JavaScript (Kb) yang ditransfer ke perangkat seluler

	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

Jumlah kode JavaScript yang dikirimkan ke perangkat desktop

Jika kita hanya berbicara tentang ukuran kode JS yang dikirim oleh situs ke perangkat, maka semuanya tampak seperti yang Anda harapkan. Yaitu, jika salah satu kerangka kerja digunakan, ini berarti bahwa bahkan dalam situasi yang ideal, volume kode JavaScript situs akan meningkat. Ini tidak mengejutkan - Anda tidak dapat membuat kerangka kerja JavaScript sebagai dasar dari situs ini dan berharap bahwa volume kode JS proyek akan sangat rendah.

Perlu dicatat dalam data ini bahwa beberapa kerangka kerja dan perpustakaan dapat dianggap sebagai titik awal proyek yang lebih sukses daripada yang lain. Situs JQuery terlihat terbaik. Pada versi desktop situs mengandung 15% lebih banyak JavaScript daripada semua situs, dan pada versi seluler - 18% lebih banyak. (Saya harus mengakui bahwa di sini Anda dapat mengamati beberapa distorsi data. Faktanya adalah bahwa jQuery hadir di banyak situs, jadi wajar jika situs tersebut lebih dekat daripada yang lain dengan jumlah total situs. Namun, ini tidak mempengaruhi cara sumber data ditampilkan untuk setiap kerangka kerja.)

Meskipun peningkatan 15-18% dalam volume kode adalah angka yang penting, membandingkannya dengan kerangka kerja dan pustaka lainnya, kita dapat menyimpulkan bahwa "pajak" yang dibebankan oleh jQuery sangat rendah. Situs di Angular dari persentil ke-10 mengirim 344% lebih banyak data ke perangkat desktop daripada semua situs, dan ke ponsel - 377% lebih banyak. Bereaksi situs, yang berikutnya dalam hal keparahan, mengirim 193% lebih banyak kode ke perangkat desktop daripada semua situs, dan 270% lebih banyak ke perangkat seluler.

Saya telah menyebutkan bahwa meskipun penggunaan kerangka kerja berarti sejumlah kode akan dimasukkan dalam proyek, pada awal pekerjaan di dalamnya, saya berharap bahwa kerangka kerja itu entah bagaimana dapat membatasi pengembang. Secara khusus, kita berbicara tentang membatasi jumlah maksimum kode.

Menariknya, situs jQuery mengikuti ide ini. Meskipun mereka, pada tingkat persentil ke-10, sedikit lebih berat dari semua situs (15-18%), mereka, pada tingkat persentil ke-90, sedikit lebih ringan dari semua - sekitar 3% dalam versi desktop dan seluler. Ini tidak dapat dikatakan sebagai manfaat yang sangat signifikan, tetapi dapat dikatakan bahwa situs jQuery setidaknya tidak berbeda dalam ukuran besar kode JavaScript, bahkan dalam versi terbesarnya.

Tetapi hal yang sama tidak dapat dikatakan tentang kerangka kerja lain.

Seperti dengan persentil ke-10, situs persentil ke-90 di Angular dan React berbeda dari situs lain, tetapi sayangnya mereka berbeda menjadi lebih buruk.

Pada persentil ke-90, situs Angular mengirim 141% lebih banyak data ke perangkat seluler daripada semua situs, dan 159% lebih banyak ke desktop. Bereaksi situs mengirim 73% lebih banyak ke perangkat desktop daripada semua situs, dan 58% lebih ke ponsel. Ukuran kode situs Bereaksi pada persentil ke-90 adalah 2197,8 Kb. Ini berarti bahwa situs-situs tersebut mengirim 322,9 Kb lebih banyak data ke perangkat seluler daripada pesaing terdekat mereka berdasarkan Vue. Kesenjangan antara situs desktop berdasarkan Angular dan React, dan antara situs lain, bahkan lebih besar. Misalnya, desktop Bereaksi situs mengirim 554,7 KB lebih banyak kode JS ke perangkat daripada situs Vue serupa.

Waktu yang dihabiskan untuk memproses kode JavaScript di utas utama

Data di atas dengan jelas menunjukkan bahwa situs yang menggunakan kerangka kerja yang dipelajari dan pustaka berisi sejumlah besar kode JavaScript. Tapi, tentu saja, ini hanya satu bagian dari persamaan kami.

Setelah kode JavaScript tiba di peramban, kode tersebut harus dibawa ke kondisi kerja. Terutama banyak masalah yang disebabkan oleh tindakan-tindakan yang harus dilakukan dengan kode di arus utama browser. Utas utama bertanggung jawab untuk memproses tindakan pengguna, untuk menghitung gaya, untuk membangun dan menampilkan tata letak halaman. Jika Anda mengisi arus utama dengan urusan-Urusan JavaScript, itu tidak akan dapat menyelesaikan tugas lain tepat waktu. Ini menyebabkan keterlambatan dan "rem" dalam pekerjaan halaman.

Basis data HTTP Archive berisi informasi tentang berapa banyak waktu yang diperlukan untuk memproses kode JavaScript di utas utama mesin V8. Ini berarti bahwa kami dapat mengumpulkan data ini dan mencari tahu berapa banyak waktu utas utama diperlukan untuk memproses JavaScript dari berbagai situs.

Waktu CPU (dalam milidetik) terkait dengan pemrosesan skrip pada perangkat seluler

Persentil	10	25	lima puluh	75	90
Semua situs	356.4	959.7	2372.1	5367.3	10485.8
situs jQuery	575.3	1147.4	2555.9	5511.0	10349.4
Situs Vue	1130.0	2087.9	4100.4	7676.1	12849.4
Situs sudut	1471.3	2380.1	4118.6	7450.8	13296.4
Bereaksi Situs	2700.1	5090.3	9287.6	14509.6	20813.3

Waktu CPU terkait dengan pemrosesan skrip pada perangkat seluler

Waktu CPU (dalam milidetik) terkait dengan pemrosesan skrip pada perangkat desktop

Persentil	10	25	lima puluh	75	90
Semua situs	146.0	351.8	831.0	1739.8	3236.8
situs 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

Waktu CPU terkait dengan pemrosesan skrip pada perangkat desktop

Di sini Anda dapat melihat sesuatu yang sangat familiar.

Sebagai permulaan, situs dengan jQuery menghabiskan lebih sedikit untuk pemrosesan JavaScript di utas utama daripada yang lain. Pada persentil ke-10, dibandingkan dengan semua situs, situs jQuery di perangkat seluler menghabiskan 61% lebih banyak waktu memproses kode JS di utas utama. Dalam kasus situs desktop jQuery, waktu pemrosesan meningkat sebesar 37%. Pada tingkat persentil ke-90, metrik situs jQuery sangat dekat dengan metrik gabungan. Yaitu, situs jQuery di perangkat seluler menghabiskan waktu 1,3% lebih sedikit di arus utama daripada semua situs, dan di perangkat desktop - 0,7% lebih sedikit waktu.

Di sisi lain dari peringkat kami, ada kerangka kerja yang ditandai dengan beban terbesar pada utas utama. Ini, sekali lagi, adalah Sudut dan Bereaksi. Satu-satunya perbedaan di antara mereka adalah bahwa meskipun situs Angular mengirim kode dalam jumlah lebih besar ke browser daripada Situs Bereaksi, dibutuhkan waktu prosesor lebih sedikit untuk memproses kode situs Angular. Jauh lebih sedikit.

Pada persentil ke-10, situs Angular desktop menghabiskan 230% lebih banyak waktu pemrosesan utas utama kode JS daripada semua situs. Untuk situs seluler, angka ini 313%. Bereaksi situs memiliki kinerja terburuk. Pada perangkat desktop, mereka menghabiskan 248% lebih banyak waktu pada pemrosesan kode dibandingkan semua situs, dan pada perangkat seluler - 658% lebih banyak. 658% bukan kesalahan ketik. Pada persentil ke 10, Bereaksi situs menghabiskan 2,7 detik dari waktu utas utama untuk memproses kode yang mereka miliki.

Persentil ke-90, jika dibandingkan dengan angka-angka besar ini, terlihat setidaknya sedikit lebih baik. Proyek sudut, dibandingkan dengan semua situs, menghabiskan 29% lebih banyak waktu di perangkat desktop di utas utama, dan 27% lebih banyak di perangkat seluler. Dalam kasus situs Bereaksi, indikator yang sama terlihat, masing-masing, sebesar 130% dan 98%.

Penyimpangan persentase untuk persentil ke-90 terlihat lebih baik daripada nilai yang sama untuk persentil ke-10. Tetapi di sini perlu diingat bahwa angka-angka yang menunjukkan waktu tampak cukup menakutkan. Katakanlah - 20,8 detik dalam arus utama perangkat seluler untuk situs yang dibangun di Bereaksi. (Saya percaya bahwa kisah tentang apa yang sebenarnya terjadi selama masa ini layak mendapat artikel terpisah).

Ada satu potensi kesulitan (terima kasihJeremy untuk menarik perhatian saya ke fitur ini, dan untuk mempertimbangkan data dari sudut pandang ini dengan cermat). Faktanya adalah bahwa banyak situs menggunakan beberapa alat front-end. Secara khusus, saya melihat banyak situs yang menggunakan jQuery bersama dengan React atau Vue, karena situs-situs ini bermigrasi dari jQuery ke kerangka kerja atau pustaka lainnya. Akibatnya, saya kembali beralih ke basis data, memilih kali ini hanya tautan yang sesuai dengan situs yang hanya menggunakan Bereaksi, jQuery, Sudut atau Vue, tetapi bukan kombinasi keduanya. Itu yang saya lakukan.

Waktu CPU (dalam milidetik) terkait dengan pemrosesan skrip pada perangkat seluler dalam situasi di mana situs hanya menggunakan satu kerangka kerja atau hanya satu perpustakaan

Persentil	10	25	lima puluh	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

Waktu CPU terkait dengan pemrosesan skrip pada perangkat seluler dalam situasi di mana hanya satu kerangka kerja digunakan di situs, atau hanya satu perpustakaan

Pada awalnya, tidak mengherankan: ketika hanya satu kerangka kerja atau satu perpustakaan yang digunakan di suatu situs, kinerja situs semacam itu lebih sering terjadi. membaik daripada tidak membaik. Indikator untuk setiap instrumen terlihat lebih baik pada 10 dan 25 persen. Masuk akal. Situs yang dibuat menggunakan satu kerangka kerja harus lebih produktif daripada situs yang dibuat menggunakan dua kerangka kerja atau lebih.

Bahkan, indikator untuk setiap instrumen front-end yang diteliti terlihat lebih baik di semua kasus, minus satu pengecualian yang aneh. Saya terkejut bahwa pada tingkat persentil ke-50 dan lebih tinggi, situs yang menggunakan React memiliki kinerja lebih buruk jika React adalah satu-satunya perpustakaan yang digunakan pada mereka. Ngomong-ngomong, ini adalah alasan mengapa saya membawa data ini ke sini.

Ini agak aneh, tetapi saya masih mencoba mencari penjelasan tentang keanehan ini.

Jika sebuah proyek menggunakan React dan jQuery, maka proyek ini kemungkinan besar setengah transisi dari jQuery ke React. Mungkin memiliki basis kode di mana perpustakaan ini dicampur. Karena kita telah melihat bahwa situs jQuery menghabiskan lebih sedikit waktu di utas utama daripada Bereaksi situs, ini mungkin memberitahu kita bahwa menerapkan beberapa fungsionalitas pada jQuery membantu sedikit meningkatkan kinerja situs.

Tetapi ketika proyek, bergerak dari jQuery ke React, lebih mengandalkan React, situasinya berubah. Jika situs dibuat sangat berkualitas tinggi, dan pengembang situs menggunakan Bereaksi dengan hati-hati, maka dengan situs ini semuanya akan baik-baik saja. Tetapi untuk rata-rata situs Bereaksi, penggunaan Bereaksi luas berarti bahwa utas utama sedang mengalami peningkatan beban.

Kesenjangan antara perangkat seluler dan desktop

Sudut pandang lain dari mana saya melihat data yang diteliti adalah mempelajari seberapa lebar jarak antara bekerja dengan situs di perangkat seluler dan desktop. Jika kita berbicara tentang membandingkan volume kode JavaScript, maka perbandingan seperti itu tidak mengungkapkan sesuatu yang mengerikan. Tentu saja, akan menyenangkan untuk melihat jumlah kode unduhan yang lebih kecil, tetapi tidak ada banyak perbedaan dalam volume kode seluler dan desktop.

Tetapi jika Anda menganalisis waktu yang diperlukan untuk memproses kode, Anda akan melihat celah yang sangat besar antara perangkat seluler dan desktop.

Peningkatan waktu (dalam persen) terkait dengan pemrosesan skrip pada perangkat seluler dibandingkan dengan desktop

Persentil	10	25	lima puluh	75	90
Semua situs	144.1	172.8	185.5	208.5	224.0
situs jQuery	188.2	187.4	191.3	209.6	221.9
Situs Vue	222.5	220.8	220.2	221.4	220.4
Situs sudut	205.1	206.0	201.6	210.4	218.7
Bereaksi Situs	431.5	386.8	337.9	242.6	179.6

Meskipun beberapa perbedaan dalam kecepatan pemrosesan kode antara ponsel dan laptop cukup diharapkan, sejumlah besar mengatakan bahwa kerangka kerja modern tidak cukup fokus pada perangkat berdaya rendah, dan pada keinginan untuk menutup celah. Bahkan pada persentil ke-10, situs Bereaksi menghabiskan 431,5% lebih banyak waktu di aliran utama perangkat seluler daripada di aliran utama perangkat desktop. Kesenjangan terkecil diamati dalam jQuery, tetapi bahkan di sini indikator yang sesuai adalah 188,2%. Ketika pengembang situs web membuat proyek mereka sehingga membutuhkan lebih banyak waktu prosesor untuk memprosesnya (dan ini terjadi, dan seiring waktu semuanya menjadi lebih buruk), pemilik perangkat berdaya rendah harus membayar untuk itu.

Ringkasan

Kerangka kerja yang baik harus menyediakan pengembang dengan basis kualitas untuk membuat proyek web (dalam hal keamanan, ketersediaan, kinerja), atau harus memiliki batasan bawaan yang menyulitkan untuk membuat sesuatu yang melanggar batasan ini.

Ini tampaknya tidak berlaku untuk kinerja proyek web (dan, tampaknya, ketersediaannya ).

Perlu dicatat bahwa fakta bahwa React- atau Angular-sites menghabiskan lebih banyak waktu CPU pada persiapan kode daripada yang lain tidak berarti bahwa React-sites dalam proses kerja memuat prosesor lebih dari pada Vue-sites. Faktanya, data yang kami ulas mengatakan sangat sedikit tentang kinerja kerangka kerja dan perpustakaan. Mereka berbicara lebih banyak tentang pendekatan pengembangan yang, secara sadar atau tidak, kerangka kerja ini dapat mendorong programmer. Kita berbicara tentang dokumentasi untuk kerangka kerja, tentang ekosistemnya, tentang teknik pengembangan umum.

Layak disebutkan bahwa kami tidak menganalisisnya di sini, yaitu, berapa banyak waktu yang dihabiskan perangkat untuk mengeksekusi kode JavaScript saat bernavigasi antar halaman situs. Argumen yang mendukung SPA adalah bahwa begitu aplikasi satu halaman dimuat ke browser, pengguna, secara teoritis, akan dapat membuka halaman situs lebih cepat. Pengalaman saya sendiri mengatakan bahwa ini jauh dari kenyataan. Tetapi kami tidak memiliki data untuk mengklarifikasi masalah ini.

Hanya jelas bahwa jika Anda menggunakan kerangka kerja atau pustaka untuk membuat situs, Anda berkompromi dalam hal pemuatan awal proyek dan mempersiapkannya untuk pekerjaan. Ini berlaku bahkan untuk skenario paling positif.

Dalam situasi yang tepat, sangat mungkin untuk membuat beberapa kompromi, tetapi penting bahwa pengembang membuat kompromi secara sadar.

Tapi kami punya alasan untuk optimis. Saya terdorong oleh seberapa dekat pengembang Chrome berinteraksi dengan beberapa alat front-end yang telah kami ulas dalam upaya membantu meningkatkan kinerja alat-alat ini.

Namun, saya adalah orang yang pragmatis. Arsitektur baru seringkali menciptakan masalah kinerja ketika mereka menyelesaikannya. Dan butuh waktu untuk memperbaiki kekurangannya. Sama seperti kita seharusnya tidak mengharapkan teknologi jaringan baru untuk menyelesaikan semua masalah kinerja, kita tidak seharusnya mengharapkan ini dari versi baru kerangka kerja favorit kita.

Jika Anda ingin menggunakan salah satu alat front-end yang dibahas dalam materi ini, ini berarti Anda harus melakukan upaya tambahan untuk memastikan bahwa, sementara itu, tidak membahayakan produktivitas proyek Anda. Berikut adalah beberapa pertimbangan untuk dipertimbangkan sebelum mulai menggunakan kerangka kerja baru:

Uji diri Anda dalam hal akal sehat. Apakah Anda benar-benar perlu menggunakan kerangka kerja yang dipilih? JavaScript murni mampu melakukan banyak hal saat ini.
Apakah ada alternatif yang lebih mudah untuk kerangka kerja yang dipilih (seperti Preact, Svelte, atau yang lain) yang dapat memberi Anda 90% kemampuan kerangka kerja ini?
Jika Anda sudah menggunakan semacam kerangka kerja, pikirkan apakah ada sesuatu yang menawarkan parameter standar yang lebih baik, lebih konservatif (misalnya, Nuxt.js bukannya Vue, Next.js alih-alih Bereaksi, dan sebagainya).
Apa yang akan menjadi anggaran kinerja JavaScript Anda ?
Bagaimana Anda dapat membatasi proses pengembangan untuk mempersulit pelaksanaan kode JavaScript dalam jumlah yang lebih besar ke dalam proyek daripada yang mutlak diperlukan?
Jika Anda menggunakan kerangka kerja untuk kenyamanan pengembangan, pertimbangkan apakah Anda perlu mengirim kode kerangka kerja ke klien Anda. Mungkin Anda bisa menyelesaikan semua masalah di server?

Biasanya, ide-ide ini layak untuk dilihat terlepas dari apa yang sebenarnya telah Anda pilih untuk mengembangkan frontend. Tetapi mereka sangat penting ketika Anda mengerjakan proyek yang, sejak awal, kurang produktivitas.

Pembaca yang budiman! Bagaimana Anda melihat kerangka JavaScript yang sempurna?