Sejarah singkat AJAX dan SSR – Beragampengetahuan

Perjalanan pemrograman saya dimulai lebih dari dua puluh tahun yang lalu, ketika JavaScript masih jauh dari kondisi saat ini dan para pengembang terutama berfokus pada Microsoft Internet Explorer. Salah satu pencapaian saya yang paling membanggakan saat itu adalah menulis beberapa baris kode yang memungkinkan pengguna menambah dan menghapus baris tabel sepenuhnya di sisi klien. kami menyebutnya HTML Dinamis. Saat ini, banyak pengembang yang melupakannya atau tidak pernah mengetahuinya.

Beberapa tahun kemudian, Ajax Kemunculan , benar-benar mengubah cara kita melakukan pengembangan web. Kemunculan AJAX menandai perubahan besar dalam pengembangan Web, memindahkan lebih banyak logika dari server ke klien, dan bukan tanpa alasan.

Rendering klien

Pergeseran ini mendapatkan momentumnya karena dua faktor utama: kemajuan dalam bahasa JavaScript dan peningkatan kemampuan browser. Misalnya, modul JavaScript sangat meningkatkan pemisahan perhatian, sehingga menghasilkan kode yang lebih mudah dikelola. Pada saat yang sama, pengenalan API penyimpanan lokal mengubah aturan mainnya.

Render sisi klien membawa banyak manfaat, salah satunya adalah peningkatan responsivitas yang sangat meningkatkan pengalaman pengguna. Menjaga interaksi tetap lokal dan menghindari bolak-balik server membuat pengalaman pengguna menjadi lebih cepat secara signifikan.

Saya menyebutkan API penyimpanan lokal sebelumnya. Bersama dengan Web Workers, ia mendukung kemampuan offline – sesuatu yang tidak dapat ditawarkan oleh browser sebelumnya. Saya ingat mengembangkan dengan Java Web Start (sekarang OpenWebStart), mengunduh aplikasi dengan koneksi server, dan mengagumi cara kerjanya secara offline. Pada saat itu, ini adalah salah satu dari sedikit teknologi yang menawarkan fungsi ini. Sekarang kami memiliki fungsi serupa langsung di browser!

Keuntungan lain dari migrasi logika ke komputer pengguna adalah berkurangnya beban komputasi server. Hal ini tidak hanya meningkatkan kinerja tetapi juga mengurangi biaya cloud.

Beberapa wawasan organisasi

Sejalan dengan kemajuan teknologi ini, perangkat seluler juga semakin mendapat perhatian. Banyak perusahaan beradaptasi dengan membagi aplikasi mereka menjadi aplikasi Web klien dan API server. Dengan munculnya aplikasi asli, pendekatan ini menjadi norma dan sering kali dianggap remeh.

Pemisahan kepentingan ini mempunyai konsekuensi yang luas. Mengingat pesatnya perubahan teknologi klien dan kompleksitasnya yang semakin meningkat, hampir mustahil bagi satu pengembang untuk menangani seluruh kasus penggunaan dari awal hingga akhir. Oleh karena itu, sebagian besar organisasi membagi pengembangnya menjadi tim front-end dan back-end. Setiap tim beroperasi dalam domainnya sendiri dan bergerak cepat dalam ruang tersebut. Namun ketika diperlukan integrasi, terjadilah glitch sehingga perlu adanya penyesuaian alias perbaikan bug. Proses ini bisa jadi rumit karena memerlukan identifikasi masalah dan menugaskannya ke tim yang tepat. Jangan sampai kita terlibat dalam permainan menyalahkan yang terjadi kemudian.

Bagi banyak organisasi kecil dan menengah, pemisahan buatan antara klien dan server ini merupakan hambatan yang tidak perlu. Aplikasi Web sederhana dengan CSS yang disesuaikan biasanya sudah cukup. Itu sebabnya saya penggemar berat kerangka Vaadin. Dengan Vaadin, pengembang Anda hanya perlu mempelajari satu tumpukan teknologi menggunakan satu bahasa pemrograman dan sekumpulan kecil API. Setiap pengembang dapat mengerjakan backend dan UI, menjadikan prosesnya lebih sederhana dan hemat biaya. Namun, sama seperti layanan mikro, mentalitas kelompok juga kuat.

Munculnya rendering sisi server

Seperti halnya teknologi baru lainnya, pengguna awal akan mengetahuinya dan teknologi tersebut akan mendapatkan daya tarik, namun seiring berjalannya waktu, masalah akan muncul. Render sisi klien tidak terkecuali.

Karena semakin banyak kode yang dipindahkan ke klien, beberapa perangkat lunak, meskipun ada perbaikan, mulai mencapai batas kemampuan pemrosesan browser. Sebelum dapat mulai merender halaman, browser harus mengunduh semua sumber daya yang diperlukan—terutama pustaka JavaScript. Untuk mengurangi masalah ini, kami memperkecil perpustakaan dan meningkatkan jumlah unduhan paralel. Pada satu titik, kami bahkan terpaksa membuat subdomain buatan, karena browser sangat membatasi jumlah unduhan paralel untuk satu domain.

Kami mengembangkan teknik canggih untuk mengelabui pengguna agar mengira laman dimuat dengan cepat, meskipun laman belum sepenuhnya dirender. Ini melibatkan pengelolaan hanya bagian halaman yang terlihat pada awalnya dan menunda sisanya hingga diperlukan. Banyak dari teknologi ini juga bergantung pada mesin browser yang sering berubah. Hal ini menyebabkan munculnya program “pemujaan kargo” dan ilmu hitam yang seharusnya menjadi domain teknik.

Pertanyaan penting lainnya adalah optimasi mesin pencari. Robot yang merayapi dan mengindeks halaman dirancang untuk web yang lebih sederhana, di mana halaman dirender di sisi server. Meskipun Google dan lainnya telah membuat kemajuan besar dalam meningkatkan bot yang sadar JavaScript, tidak ada yang lebih baik untuk SEO selain rendering sisi server.

Terakhir, rendering sisi server mengurangi waktu muat awal dan menyederhanakan organisasi pengembangan.

Kita harus menyadari manfaat yang ditawarkan rendering sisi klien, tapi mungkin pendulumnya sudah berayun terlalu jauh. Mungkinkah mendapatkan yang terbaik dari kedua dunia? Di beberapa sudut industri, istilah dan istilah yang lebih keren berlaku relai keadaan padat Kata ini digunakan untuk menggambarkan kembalinya apa yang telah kami lakukan selama bertahun-tahun – meskipun dengan beberapa perbaikan modern. Idenya adalah untuk memanfaatkan AJAX, JavaScript, dan peningkatan browser tanpa pembengkakan yang tidak perlu. Meskipun ada banyak alat yang tersedia, saya sering mendengar tentang Vue. js dan HTML. Pencarian baru-baru ini juga membawa saya ke Alpine.js. Saya sudah lama menjadi pendukung Vaadin.

Saya berencana untuk mengeksplorasi teknologi-teknologi ini dalam seri terfokus ini dengan menerapkan aplikasi kecil yang harus dilakukan untuk setiap teknologi. Ini adalah persyaratan saya:

• Saya akan melakukan pendekatan ini dari sudut pandang pengembang backend.
• Tidak ada langkah pembuatan front-end: tidak ada TypeScript, tidak ada minifikasi, dll.
• Aplikasi backend mengelola semua dependensi yaitu Maven.

melangkah lebih jauh