js-framework-markmark - variasi penyelesaian ideal untuk masalah matematik kelajuan atau mengapa ia standard

Hei semua! Saya menghabiskan masa selama 2.5 tahun untuk menyelesaikan masalah kelajuan dalam repositori penanda aras js-framework-mark, dan saya tidak menyesalinya, kerana terdapat pemerhatian yang sangat menarik yang saya perhatikan baru-baru ini.

Pada asasnya, semua rangka kerja dan pembangun perpustakaan menghadapi isu kelajuan pada peringkat awal pembangunan web. Ini adalah perkara utama, kerana lebih cepat orang melihat perubahan data pada UI, lebih sedikit masa yang mereka luangkan. Bayangkan jika tapak berfungsi 10% lebih pantas, maka berbilion-bilion orang boleh menyelamatkan banyak tahun nyawa.

Sesuatu perlu dilakukan, jadi, dan mungkin atas sebab lain, banyak repositori dengan penanda aras rangka kerja dan perpustakaan moden telah dicipta. Salah satu repositori tersebut ialah js-framework-markmark. Ia mengandungi hampir semua rangka kerja dan perpustakaan popular untuk mencipta UI.

Tugas utama ialah melukis jadual yang bergantung pada data. Ia akan kelihatan seperti tugas yang mudah, tetapi sebenarnya, ia sangat, sangat menunjukkan, kerana ia menarik perhatian kepada perkara utama bahawa aplikasi boleh kelihatan seperti apa-apa, tetapi komponen, urutan mereka dalam DOM, berfungsi dengan penyemak imbas dan perkara lain - meniru tingkah laku tapak biasa. Kerana baris dalam jadual, pengepala pada halaman - semuanya secara umum, hanya satu komponen umum.

Memandangkan aplikasi berfungsi seperti biasa dengan kod dan masa sebagai kebergantungan (kami tidak mengambil kira paparan, warna, kerana ia boleh dikatakan 0 dan 1 pada wayar, jadi hanya terdapat 2 kebergantungan sedemikian), maka sekurang-kurangnya 1 komponen, sekurang-kurangnya satu juta komponen yang saling berkaitan - tidak ada makna tertentu, kerana semuanya terletak pada satu enjin. Oleh itu, kesederhanaan di sini juga sesuai, kerana ia adalah kejelasan.

Jadi, kita ada tugas, tetapi kita perlu menyelesaikannya entah bagaimana. Pengaturcaraan adalah baik kerana kita boleh menyelesaikan satu masalah matematik dalam sejuta cara yang berbeza, tetapi kita sampai kepada perkara utama, algoritma ideal asas adalah sama untuk semua orang. Ini adalah teorem, dan apa dan bagaimana dilaksanakan adalah soal citarasa dan keperluan untuk kemudahan.

Mari kita lihat antara muka sekarang, bagaimana rupanya:

Apl ujian:

Beberapa keputusan:
https://krausest.github.io/js-framework-benchmark/2024/table_chrome_130.0.6723.58.html

Kami mempunyai hasil untuk tindakan utama yang berbeza dengan jadual yang boleh berlaku apabila keadaan berubah. Kita boleh mengukur kelajuan kerja dan membandingkan kod yang berfungsi lebih cepat dan yang lebih perlahan. Ini sangat mudah, kerana ia mewujudkan medan permainan yang sama rata untuk semua rangka kerja dan perpustakaan. Tetapi tidak mengapa jika hanya kelajuan yang menjadi masalah, tetapi standard struktur itu sendiri juga ditetapkan, kerana ia mesti betul. Pendekatan komponen, pelaksanaan utama, keadaan dan istilah lain disertakan dalam semua ini. Tanpa piawaian sedemikian, ini bukanlah topik yang berkesan.

Jadi, piawaian itu telah lama ditetapkan oleh pencipta rangka kerja dan perpustakaan - ia jelas dan boleh difahami oleh mereka yang melakukannya. Persoalannya ialah sekarang kita perlu menyesuaikan semua ini untuk kerja pantas, supaya UI dipaparkan dengan cepat.

Jadi, idea yang bagus untuk mengumpulkan semua pencipta rangka kerja dan perpustakaan yang "besar" dan tidak begitu besar, dan hanya peminat yang juga ingin mencuba tangan mereka. Semua ini penting, kerana, seperti dalam sukan, kita mempunyai komuniti, dan terdapat lembaga "pemimpin" di mana penyelesaian yang berbeza untuk masalah diterbitkan. Ini bukan perbandingan yang sangat baik dari segi pengaturcaraan, kerana ia hanya matematik, tetapi idea itu sendiri menarik, kerana ia mendorong orang untuk melakukan dengan cantik dan cepat dan, yang paling penting, ia adalah betul.

Nah, komuniti sedemikian telah menghasilkan banyak penyelesaian hebat dalam beberapa tahun kebelakangan ini yang boleh digunakan hari ini oleh semua pencipta semasa dan akan datang. Anda tidak perlu mencipta semula roda, kerana algoritma asas sudah ditulis. Pemahaman ini boleh menjimatkan banyak tahun.

Ramai pembangun telah pun menulis contoh pelaksanaan kod ideal, agak mudah untuk mendasarkannya, jadi perkara terbaik ialah ini tidak berlaku sebelum ini dan ia berlaku, antara lain, kerana repositori ini. Tidak kira apa yang orang katakan, ia adalah hebat.

Jika kami mempertimbangkan algoritma yang ideal mengikut komponen, kami boleh menyerlahkan - algoritma pelaksanaan utama (menggunakan Urutan yang semakin lama meningkat atau variasi lain daripadanya), pengklonan templat, kereaktifan secara langsung (textContent, addEventListener, classList.add), atau menggunakan VDOM yang tidak berguna hari ini, walaupun dari segi templat adalah perlu, serta bekerja dengan keadaan dan import antara komponen, 2 yang terakhir boleh dibahaskan. Tetapi inilah asasnya, tiada lagi yang boleh dicipta di sini.

Artikel ini tidak akan mengandungi sebarang kod seperti itu, kerana terdapat banyak kod dalam repositori penanda aras.

Apa pun, saya harap orang ramai tidak lama lagi akan memahami bahawa hari ini kami sudah mempunyai kod yang ideal untuk memaparkan data, ia hanya berbaloi untuk mengambil kira dan melakukan sesuatu yang baharu berdasarkannya, tanpa mencipta semula roda. Banyak perpustakaan dan rangka kerja hari ini boleh berfungsi dengan lebih pantas dan lebih cekap, cuma kod warisan tidak membenarkan ini, kerana mungkin terdapat banyak kerja dan bukan hakikat bahawa ia boleh dilakukan tanpa membuat semula segala-galanya.

Atas ialah kandungan terperinci js-framework-markmark - variasi penyelesaian ideal untuk masalah matematik kelajuan atau mengapa ia standard. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!