- Sebagian pengembang menganggap framework SPA (React, AngularJS, dll.) wajib untuk mengembangkan aplikasi berkualitas tinggi
- Namun, bahkan sebelum SPA, aplikasi berbasis MPA sudah lama memberikan pengalaman pengguna yang sangat baik
- Saya mencoba membangun platform observabilitas berbasis MPA yang berfokus pada data dengan memanfaatkan HTMX, dan dengan optimasi yang tepat, MPA yang dirender di server juga dapat memberikan performa serta pengalaman pengguna yang unggul
Kesalahpahaman dan fakta terkait MPA
Kesalahpahaman 1: MPA lambat saat perpindahan halaman
- Masalah: karena browser secara default mengunduh ulang JavaScript dan CSS setiap kali berpindah halaman
- Solusi:
- Gunakan library seperti PJAX, Turbolinks, atau HTMX Boost untuk hanya mengganti HTML body
- Service worker dapat dimanfaatkan untuk caching halaman dan meningkatkan penanganan request
- Contoh: setelah menerapkan service worker, waktu DOMContentLoaded berkurang dari 2,9 detik menjadi 500ms
Cara mengimplementasikan service worker
- Buat file
sw.js: tulis skrip untuk mengelola caching dan request jaringan
- Definisikan daftar file yang di-cache: tentukan aset utama seperti HTML, CSS, dan JS
- Atur strategi caching: cache aset statis secara permanen atau perbarui secara berkala
Kesalahpahaman 2: MPA tidak bisa berjalan offline dan tidak bisa menyimpan request untuk dipulihkan saat jaringan kembali
- Dengan service worker, aplikasi dapat tetap berjalan bahkan dalam keadaan offline
- Memanfaatkan Workbox:
- Saat jaringan gagal, request di-cache dan dicoba ulang dalam waktu maksimal 24 jam
- Atur handler offline untuk menyediakan konten pengganti saat ada request
Kesalahpahaman 3: MPA menimbulkan kedipan layar saat perpindahan halaman
- Solusi:
- Dengan service worker dan API preload, rendering layar bisa ditunda sampai aset siap
- Sejak 2019, browser menangani perpindahan dalam domain yang sama tanpa kedipan
Kesalahpahaman 4: MPA tidak bisa membuat efek perpindahan halaman yang mewah
- SPA memang terkenal dengan animasi perpindahan halaman, tetapi browser kini juga mulai mendukungnya
- Di Chrome 126, animasi transisi antar-dokumen dapat dibuat hanya dengan CSS
- Tautan demo
Kesalahpahaman 5: Di HTMX atau MPA, semua aksi pengguna diproses di server
- HTMX dirancang agar hanya sebagian aksi yang diproses di server
- Jika diperlukan, fitur interaktif sisi klien dapat ditambahkan dengan WebComponents atau framework JavaScript
- Pendekatan ala SPA juga bisa diterapkan hanya pada komponen tertentu
Kesalahpahaman 6: Manipulasi DOM itu lambat, jadi perlu React/Virtual DOM
- Virtual DOM hanya menunjukkan perbedaan performa pada aplikasi yang sangat kompleks
- Untuk sebagian besar aplikasi umum, manipulasi DOM langsung sudah cukup cepat
- Referensi: "Virtual DOM is pure Overhead"
Kesalahpahaman 7: Fitur interaktif kecil pun memerlukan JavaScript
- Dengan teknologi browser modern, berbagai fitur bisa dibuat tanpa JavaScript
- Fitur toggle dapat dibuat dengan checkbox HTML dan CSS
- Dipadukan dengan HTMX, data dapat dimuat secara asinkron saat diklik
Kesalahpahaman terakhir: Tanpa SPA, kode sisi klien akan berubah menjadi spaghetti code
- Bahkan pada era spaghetti code, banyak perangkat lunak produktif berhasil dikembangkan
- Pada tahap MVP awal, struktur yang sederhana justru bisa lebih menguntungkan
Kesimpulan
- Pada 2024, browser telah banyak berkembang dengan mengintegrasikan pelajaran dari revolusi SPA
- Hanya dengan alat bawaan browser (HTML, CSS, JavaScript), aplikasi yang interaktif dan dapat berjalan offline pun bisa dibuat
- Disarankan untuk kembali memanfaatkan potensi browser dan mempercayainya sekali lagi
8 komentar
Kalau pernah mencoba mengembangkan dengan para developer yang kemampuan rata-ratanya mirip-mirip, Anda akan langsung tahu betapa muluknya cerita seperti ini. Sepertinya yang menulis ini entah dikelilingi para jenius atau bekerja sendirian... (melihat dia masih menyebut AngularJS yang sudah lewat masanya saja sudah kelihatan) Dan pengembangan itu bukan cuma dilakukan oleh para jenius.
Mungkin ada yang akan meremehkannya dengan bilang "yang begitu ya cuma ngumpul sesama mereka", tapi perubahan selalu terjadi berkat orang-orang biasa.
Melihat yang begini, pikiran pertama saya justru jadi merasa htmx sama sekali tidak boleh diterima.
Ini memang topik yang terus terus muncul belakangan ini,
ada video beberapa tahun lalu di mana Rich Harris menyampaikan pendapatnya tentang topik tersebut.
https://www.youtube.com/watch?v=860d8usGC0o&t=635s
Kalau tidak salah ingat, ringkasnya adalah bahwa cara pembaruan berbasis partial HTML berpotensi menimbulkan ketidakkonsistenan antara tampilan dan data.
Apakah Anda masih percaya pada spesifikasi browser...?
Kalau mau dibilang, saya menganggap SPA sebagai metode pengembangan aplikasi yang ketergantungannya pada perilaku browser relatif lebih kecil.
Memang benar browser sudah cukup banyak mengejar berbagai kemungkinan keren dari SPA, dan itu terlihat lebih cocok dengan cara komunikasi HTTP yang memang dirancang sejak awal, tetapi mungkin itu terjadi karena Chrome pada dasarnya memegang posisi yang nyaris monopolistik di dunia browser sehingga punya kelonggaran... entah ini akan bertahan lama atau tidak. Baik kelonggarannya maupun pangsa pasarnya...
Kalau yang seperti
phoenix liveview, yakni memanipulasi DOM dari server berbasis websocket, paradigmenya berbeda.Saat mencoba
htmx, saya merasa kurang menyenangkan karena server harus mengirimkan potongan-potongan HTML.Terutama di bagian CSS, kalau class ditentukan dari server, dari sudut pandang server tidak mungkin tahu CSS apa yang sedang dipakai di layar, jadi rasanya seperti memaksa penggunaan CSS bersama.
Beberapa tahun lalu saya pernah mencoba membuat UI yang agak kompleks dengan Phoenix LiveView, tetapi menerapkan interaksi sederhana terasa terlalu rumit, dan karena satu LiveView diproses sebagai satu proses Elixir, interaksi dengan komponen di sebelahnya menjadi sangat sulit. Pada akhirnya saya menyerah dan kembali ke React.
Menurut saya, liveview terasa seperti masa depan…
Karena
liveviewjuga sangat bergantung pada jaringan, saat server berada di lokasi jauh sehingga ping tinggi, atau di wilayah seperti negara dunia ketiga yang infrastruktur internetnya kurang baik, kelemahannya terasa cukup besar.Komentar Hacker News
Ada yang mempertanyakan mengapa artikel itu tidak menyinggung cara memanfaatkan cache browser untuk mengelola aset CSS dan JS statis. Saat dulu membangun situs belanja dengan pendekatan MPA, perpindahan halamannya hampir tidak terasa
Ada juga yang berpendapat bahwa pengembangan web pada era PHP dan jQuery adalah yang paling produktif. Muncul opini yang mempertanyakan apakah paradigma lama justru lebih produktif daripada teknologi modern seperti React. Situs besar seperti Amazon atau Steam juga masih dibangun dengan pendekatan merender HTML di server lalu menambahkan JS
Ada komentar yang meminta penjelasan tentang apa yang membuat strategi service worker lebih baik dibanding header cache HTTP yang sudah ada. Memang bisa mengurangi network round-trip, tetapi terasa seperti menemukan ulang semuanya demi optimasi kecil
Judul "You Can't Build Interactive Web Apps Except as Single Page Applications... And Other Myths" terasa seperti clickbait karena bagian maknanya yang terpotong
Hal paling berbahaya dalam pemrograman adalah kebosanan pengembang dan ketidaktahuan terhadap masa lalu
Ada yang mengatakan tidak paham mengapa dikotomi antara sisi server dan sisi klien (SPA) masih ada di era web server Node.js. Muncul pertanyaan apakah sebagian besar pekerjaan tidak bisa diinisialisasi di server, lalu diserialisasikan ke klien agar berjalan sebagai SPA
Ada kecenderungan melihat SPA dan MPA sebagai dua kubu yang saling berlawanan, padahal ini bisa dibedakan sebagai cara menggunakan web stack secara alami versus dengan cara "hack". SPA saat ini adalah pendekatan hack itu, dan di masa lalu pernah ada CGI, applet Java, dan Flash. Pendekatan hack berperan memperluas batas metode yang alami
Sebelum memutuskan technology stack, para pengembang sering kali salah memahami apa yang sebenarnya mereka tulis. Jika tidak membutuhkan tingkat interaktivitas yang tinggi, kebanyakan framework sisi server mungkin sudah cukup
Ada bantahan terhadap mitos bahwa "Anda tidak bisa membuat aplikasi web interaktif jika bukan single-page app". SPA memberikan kontrol yang lebih besar dan mengurangi kemungkinan harus mengerjakan ulang sebagian kode
Headline HN terasa lebih agresif daripada judul aslinya. Ini adalah esai yang dipresentasikan Tony Alaribe di BigSkyDevCon, yang membahas teknik untuk membuat aplikasi web non-SPA terasa cepat dan mulus. Esai itu memperkenalkan teknik baru, dan ada yang menganggapnya sebagai presentasi terbaik di konferensi tersebut