Sekitar setahun yang lalu, artikel nyata Nikita Prokopov tentang kekecewaan dalam perangkat lunak dirilis. Dilihat oleh umpan balik positif, pengembang tidak peduli dengan kualitas produk mereka. Mungkin sudah waktunya untuk mulai berakting?
Dalam artikel ini saya ingin berbicara tentang perkembangan saya, yang, menurut pendapat saya, dapat menyembuhkan masalah kinerja utama dari web modern dan membuat pengguna sedikit lebih bahagia. Masalahnya adalah: kode JS berat, waktu tinggi untuk mulai bekerja dengan halaman (TTI) , memori tinggi dan konsumsi prosesor.
Sebelum membaca lebih lanjut, ikuti tautannya . Coba mainkan beberapa permainan. Mainkan lebih disukai dari desktop.
Sedikit sejarah
Sejak awal, browser web dikandung sebagai klien tipis untuk server web. Browser menampilkan halaman hypertext yang diterima dari server. Sederhana dan elegan. Seperti yang sering terjadi, ide yang indah dihadapkan dengan kenyataan, dan setelah beberapa tahun, produsen browser telah menambahkan dukungan untuk bahasa scripting. Pada awalnya, itu berfungsi hanya sebagai hiasan, dan sampai pertengahan 2000-an, itu dianggap bentuk yang baik untuk membuat halaman web berfungsi tanpa dukungan JS.
Pendekatan modern untuk pengembangan situs web adalah hasil dari pengembangan persyaratan interaktivitas antarmuka pengguna. Tugas untuk meningkatkan interaktivitas berada di pundak para pembuat kode. Mereka sering tidak memiliki kompetensi dan wewenang untuk mengembangkan solusi "lintas sektoral". Desainer tata letak belajar menulis JS dan menjadi front-end. Logika secara bertahap mulai mengalir dari server ke klien. Adalah nyaman bagi pelari terdepan untuk menulis untuk browser, dan back-end nyaman untuk tidak memikirkan pengguna (berikan JSON saya kepada Anda, dan setidaknya rumput tidak tumbuh). Hanya dua tahun yang lalu, ada lonjakan minat dalam arsitektur serverless, di mana disarankan bahwa aplikasi JS akan bekerja secara langsung dengan database dan bus acara.
Saat ini, "situs web bola dalam ruang hampa" adalah aplikasi JS yang kompleks dan server API sederhana yang digunakan untuk berkomunikasi. Logika utama berjalan pada klien yang tebal, sisi server berubah menjadi lapisan sederhana ke database.
Kebutuhan untuk menjaga logika pada klien menciptakan masalah. Jika layanan "lepas landas" dan mulai menghasilkan uang, maka lebih lanjut, dalam hal produktivitas, itu hanya akan bertambah buruk. Persyaratan akan berubah. Tim pengembangan akan berubah. Akan ada semakin banyak kode baru, dan kode lama tidak akan dibersihkan. Halaman akan membengkak dari dependensi, itu akan memuat JSON tentang tujuan yang tidak ada yang ingat, tapi itu menakutkan untuk dihapus, tiba-tiba ada yang rusak. Tugas latar belakang SetInterval akan muncul, masing-masing dilakukan selama beberapa milidetik setiap detik, yang setelah beberapa waktu akan menyebabkan rem dan menghangatkan iPad pengguna yang malang hingga ia dapat menggoreng telur goreng di atasnya. Itu berakhir dengan fakta bahwa front-end yang terbakar akan datang ke manajer dengan proposal untuk menulis ulang semuanya dari awal pada kerangka kerja baru. Manajer akan menolak, dan front-end akan mulai menggunakan dua kerangka kerja bersama.
Cara kerja Korolev
Jadi, bagaimana jika kita kembali ke pokok laporan? Saat ketika seseorang datang dengan ide memperbarui konten tanpa memuat ulang halaman, dan keniscayaan historis memunculkan AJAX? Bagaimana jika Anda meninggalkan semuanya di server dan membuat klien kurus? Situs terbaik melakukan pra-rendering halaman server (SSR) sehingga pengguna melihat antarmuka sebelum JS dimuat dan dimulai. Anda dapat melangkah lebih jauh dan meninggalkan klien hanya kode yang bertanggung jawab untuk memproses I / O, mengingat persyaratan saat ini untuk interaktivitas. Pikiran tentang ini tumpah ke proyek Korolev .
Bagaimana cara kerjanya di sisi klien? Pengguna datang ke halaman. Server memberikan HTML yang dihasilkan dan skrip kecil (~ 6 Kbytes tanpa kompresi) yang terhubung ke server melalui soket web. Ketika seorang pengguna menjalankan suatu peristiwa (misalnya, klik), skrip mengirimkannya ke server. Setelah memproses acara tersebut, server membuat daftar perintah dari bentuk "tambah <div> sana", "tambahkan kelas ke elemen seperti itu", "hapus elemen ini dan itu". Klien menerapkan daftar perintah ke DOM. Dengan demikian, bekerja dengan HTML tidak terjadi - skrip bekerja langsung dengan DOM, jadi jangan khawatir bahwa isi formulir atau posisi gulir akan diatur ulang.
Apa yang terjadi di server? Ketika permintaan untuk sebuah halaman berasal dari browser, Korolev membuat sesi baru. Untuk sesi, keadaan awal dibuat, yang disimpan dalam cache. HTML dihasilkan dari keadaan ini, yang diberikan kepada klien sebagai respons terhadap permintaan. Selain itu, server menyimpan "DOM virtual" di sesi. Setelah meminta halaman, server menerima permintaan untuk membuka soket web. Korolev mengaitkan soket web terbuka dengan sesi. Setiap acara yang berasal dari klien dapat mengubah status yang terkait dengan sesi. Setiap perubahan status mengarah ke panggilan ke fungsi render , yang membentuk "DOM virtual" baru, yang dibandingkan dengan versi lama. Hasil perbandingan dalam daftar perintah untuk dikirim ke klien.
Apa yang terjadi pada kode dan kepala pengembang? Di atas dapat mengingatkan Anda tentang Bereaksi, dengan perbedaan bahwa semuanya berjalan di server. Dalam hal pendekatan pembangunan, kami juga memiliki sesuatu yang serupa. Oleh karena itu, jika Anda bekerja dengan Bereaksi atau "DOM virtual" lainnya, maka pendekatan Ratu akan familier bagi Anda. Jika Anda tidak terbiasa dengan Bereaksi, maka bayangkan Anda memiliki data yang Anda masukkan ke dalam templat. Bayangkan bahwa sesuai dengan templat, pengendali acara tersebar yang dapat mengubah data (tetapi bukan DOM). Anda mengubah data, halaman berubah sendiri. Korolev sendiri datang dengan cara mengubah DOM.
Performa
Ada dua pertanyaan populer tentang Korolev: "bagaimana jika penundaannya tinggi" dan "apakah ini tidak memuat server saya". Kedua pertanyaan itu sangat masuk akal. Programmer front-end digunakan untuk menjalankan programnya pada mesin lokal pengguna. Ini berarti bahwa perubahan yang dibuat untuk itu akan diterapkan segera setelah mesin JS selesai mengeksekusi kode dan browser mulai render. Saya secara khusus menunjukkan contoh menggunakan "pada kecepatan maksimum" di awal. Anda dapat mengamati penundaan hanya jika Anda datang dari sisi lain dunia (server berada di Moskow) atau Anda duduk di Internet melalui GPRS. Yah, atau server virtual saya yang menyedihkan dengan satu inti dan 1 GB RAM tidak tahan dengan efek habr.
Pertanyaan tentang beban server biasanya ditanyakan oleh beckender. Mesin keluaran perubahan bekerja dengan sangat cepat: ~ 10 ribu kesimpulan per detik untuk dua pohon acak dari 500 node pada macbook junior 2013. Render statis juga memberikan hasil yang cukup bagus: hingga 1 juta halaman per detik. Setiap "DOM virtual" disimpan dan diproses dalam bentuk serial khusus dan membutuhkan 128 KB untuk halaman web rata-rata. Proses output dioptimalkan secara khusus dan tidak memiliki overhead untuk memori dan GC.
Adapun kecepatan perkembangannya, di sini Korolev memberikan keuntungan besar. Tidak perlu menulis lapisan tambahan antara database dan server. Tidak perlu menegosiasikan protokol antara klien dan server. Tidak perlu khawatir tentang modularitas front-end - bobot JS pada klien akan selalu tetap sama. Tidak perlu melakukan logika tambahan untuk acara server: cukup terima pesan dari antrian dan ubah status sesi, Korolev akan membuat dan mengirim.
Harga
Anda harus membayar manfaatnya. Beberapa kebiasaan harus ditinggalkan, dan beberapa kebiasaan baru harus diperoleh. Misalnya, Anda harus meninggalkan animasi JS dan puas dengan animasi CSS. Anda harus mempelajari cara membuat infrastruktur yang awalnya didistribusikan secara geografis jika Anda ingin melayani pengguna dari berbagai negara dengan kualitas tinggi. Harus meninggalkan JS dan pergi ke Scala.
Saya sedikit malu (sebenarnya tidak) bahwa saya menyesatkan pembaca dan tidak segera mengatakan bahwa Korolev ditulis dalam Scala. Apakah Anda akan membaca sampai titik ini jika saya segera membicarakan hal ini? Berbicara tentang Ratu, saya harus mengatasi dua stereotip. Yang pertama adalah karena fakta bahwa rendering server dianggap sebagai sesuatu yang lambat, bukan interaktif. Yang kedua terkait dengan fakta bahwa Scala adalah sesuatu yang rumit. Dan stereotip pertama dan kedua tidak ada hubungannya dengan kenyataan. Selain itu, pemrograman dalam gaya Bereaksi pada Scala lebih nyaman daripada pada JS. JS modern condong ke arah pemrograman fungsional, Scala mengeluarkannya dari kotak. Misalnya, objek apa pun di Scala memiliki metode copy() yang memungkinkan Anda untuk menyalin objek dengan mengubah beberapa bidang. Koleksi abadi dibangun ke dalam perpustakaan standar Scala.
Kesimpulan
Korolev telah dikembangkan selama tiga tahun oleh beberapa pengembang dan banyak masalah "anak-anak" diselesaikan di dalamnya. Proyek ini didokumentasikan dengan baik, semua fungsi ditutupi dengan contoh-contoh. Saya mengusulkan untuk memulai implementasi Ratu dengan layanan independen kecil. Saya harap Korolev membantu membuat program kurang mengecewakan.
Tautan ke proyek di github