- Dengan hadirnya fitur CSS modern seperti View Transitions API, kini struktur SPA tidak lagi diperlukan untuk mewujudkan transisi halaman yang mulus
- Sebagian besar situs SPA pada praktiknya tidak mampu memberikan performa atau pengalaman mulus sebesar yang diharapkan, dan justru cenderung menurunkan pengalaman pengguna karena kode JavaScript yang berat
- Dengan memanfaatkan transisi halaman native dan Speculation Rules di browser berbasis Chromium, navigasi yang cepat dan alami dapat diwujudkan tanpa JavaScript
- Struktur SPA yang kompleks menghambat optimasi browser, sehingga untuk situs web nyata, struktur MPA yang berpusat pada HTML dan CSS lebih cepat serta lebih mudah dikelola
- Ke depannya, perlu menghindari penerapan SPA yang tidak perlu dan memanfaatkan CSS modern serta fitur native untuk pengembangan situs web yang efisien dan mudah dipelihara
Pendahuluan: berakhirnya era SPA dan munculnya CSS modern
- Dengan diperkenalkannya fitur CSS terbaru seperti View Transitions API, keunggulan utama yang dulu ditawarkan SPA (single-page application) kini tidak lagi dibutuhkan
- Banyak tim pengembang masih memilih framework SPA seperti React dan Vue, tetapi inti keputusan itu sering kali bukan performa, melainkan kesalahpahaman tentang interaksi dan pengalaman navigasi yang mulus
- Keyakinan bahwa SPA wajib untuk menghadirkan navigasi yang mulus pada praktiknya sudah menjadi pola pikir yang usang
Ilusi dan realitas SPA
- SPA pernah menjadi satu-satunya cara untuk mewujudkan transisi halaman yang paling alami, tetapi sekarang tidak lagi demikian
- Banyak SPA mengalami masalah seperti berikut:
- Hanya memiliki efek fade pada status loading, tanpa kelancaran transisi konten yang sesungguhnya
- Masalah pemulihan scroll dan penanganan fokus yang tidak konsisten
- Keterlambatan navigasi akibat penundaan rendering/hydration
- Layout shift dan kemunculan konten mendadak, termasuk skeleton loading
- Kompleksitas yang tidak perlu dan penggunaan JavaScript berlebihan, sementara manfaat performanya minim
- Framework SPA yang representatif (Next.js, Gatsby, Nuxt, dan lain-lain) menambahkan banyak kode JS untuk meniru perilaku browser native yang mendasar
- Akibatnya, kesan alami bawaan platform justru dikorbankan, kecepatan menurun, dan SEO juga terdampak buruk
Perkembangan platform web dan perubahan peran CSS
- Browser modern berbasis Chromium (Chrome, Edge, dan sebagainya) kini mendukung transisi halaman native yang deklaratif
- Melalui View Transitions API, animasi mulus antar dokumen maupun antar halaman penuh dapat diwujudkan tanpa JavaScript
- Kemampuan utamanya meliputi:
- Efek fade antar halaman (bisa dibuat hanya dengan 3–4 baris CSS)
- Animasi elemen bersama seperti transisi alami dari thumbnail ke gambar detail
- Mempertahankan elemen permanen seperti header dan navbar
- Karena menggunakan URL nyata dan perpindahan halaman yang sesungguhnya, kompatibilitas terhadap SEO, berbagi tautan, dan back/forward cache menjadi maksimal
Cara menikmati sinergi CSS dan JS secara memadai
- Jika diperlukan, JS dapat digunakan untuk memanggil View Transition secara manual pada transisi di dalam halaman
- Contoh: pergantian tema, toggle tab, perpindahan dark mode, dan sebagainya, dengan penggunaan JavaScript seminimal mungkin
Speculation Rules dan navigasi instan
- Speculation Rules memungkinkan browser melakukan preload/prerender halaman lebih dulu sambil memprediksi tindakan pengguna (misalnya hover mouse), sehingga navigasi bisa terasa instan
- Dapat dikonfigurasi secara deklaratif melalui
<script type="speculationrules">
- Syaratnya: efek maksimalisasi performa hanya tercapai bila halaman ringan dan teroptimasi; pada halaman yang berat justru ada risiko pemborosan sumber daya
Menghormati fitur bawaan browser dan bfcache
- bfcache (Back/Forward Cache) memungkinkan browser memulihkan seluruh halaman secara instan dalam bentuk snapshot saat pengguna menekan kembali/maju
- Prasyaratnya adalah arsitektur yang bersih, berbasis HTML dan CSS murni; pada struktur yang mencegat routing seperti SPA, fitur ini tidak dapat diterapkan
- Kesimpulannya, browser modern berkembang ke arah memberi penghargaan pada situs web yang sederhana dan tangguh
Perbandingan performa SPA dan MPA
- SPA rata-rata (berdasarkan Next.js):
- Ukuran bundle JS: 1–3MB
- TTI (waktu hingga dapat digunakan): 3,5–5 detik
- Transisi route: palsu/simulatif
- SEO: kompleks, sulit dirawat
- Perilaku scroll/anchor: tidak stabil
- MPA modern (dengan transisi CSS dan Speculation Rules):
- Bundle JS: 0KB (hanya peningkatan opsional)
- TTI: sekitar 1 detik
- Transisi route: perilaku native yang nyata
- SEO: sangat mudah
- Scroll cerdas, fokus, histori: menggunakan perilaku default browser dan didukung secara sempurna
Perbedaan antara situs web dan aplikasi, serta perlunya meninjau ulang kecocokan
- Sebagian besar situs web pada kenyataannya bukanlah “aplikasi”, dan tidak memerlukan state bersama, client-side routing, atau interaksi yang kompleks
- Untuk halaman pemasaran, portal dokumentasi, e-commerce, blog, dan sebagainya, struktur yang berpusat pada HTML, pemuatan cepat, dan kesederhanaan jauh lebih cocok
- Jika stack SPA diterapkan pada semua proyek, hal itu bisa memicu kompleksitas berlebihan dan penurunan performa
- Tuntutan agar “terlihat seperti aplikasi”
- Penerapan framework
- Penambahan client-side routing dan kompleksitas
- Performa menurun dan perlu optimasi tambahan
- Tetap lebih lambat daripada struktur berbasis transisi tautan native + animasi CSS
Kesimpulan dan rekomendasi
- SPA lebih mirip solusi sementara terhadap keterbatasan platform di masa lalu, tetapi kini batasan itu tidak lagi ada
- Sekarang sudah memungkinkan untuk memanfaatkan secara aktif fitur-fitur native berikut:
- Transisi antarpages yang nyata
- Prerendering instan melalui Speculation Rules
- Struktur yang kuat terhadap penurunan fungsi secara bertahap
- Markup yang rapi, pemuatan cepat, dan penggunaan URL nyata
- Struktur yang bisa memaksimalkan bantuan dari platform
- Jika tetap bersikeras memakai SPA hanya demi “kelancaran”, maka harga yang dibayar adalah kompleksitas, performa, dan kemudahan pemeliharaan sekaligus
- Dengan server rendering, halaman nyata, animasi berbasis CSS, preloading yang disengaja, dan JavaScript minimal, kini dimungkinkan membuat situs web yang cepat dan menyenangkan sesuai tuntutan zaman
- Dengan memanfaatkan teknologi yang tersedia pada 2025, kita perlu mengarah pada pengalaman web yang lebih cepat, lebih sederhana, dan ramah bagi semua orang
10 komentar
Sejak awal, kalau situasinya hanya mempertimbangkan SPA karena alasan "kelancaran", saya justru akan memilih mengorbankan sedikit kelancaran dan menulisnya sebagai MPA, jadi saya pribadi tidak terlalu bisa berempati dengan argumen itu...
Hal yang disayangkan dari tulisan tersebut
Menafsirkan tujuan sebenarnya dari SPA secara terlalu sempit
View Transitions API memang sangat keren, tetapi itu saja tidak berarti SPA menjadi tidak diperlukan.
Melihat semua situs web dengan tolok ukur yang sama
Situs pemasaran ≠ dasbor ≠ aplikasi komersial ≠ alat kolaborasi real-time
Semuanya memiliki kebutuhan struktural yang berbeda.
Dalam praktiknya, SPA + SSR + MPA masih hidup berdampingan
Framework hibrida seperti Next.js menunjukkan hal ini dengan baik.
Aset statis memakai SSG, dasbor setelah login memakai CSR/SPA, dan penyesuaian untuk mesin pencari memakai SSR; kombinasi yang fleksibel seperti ini diperlukan.
Saya rasa SPA bukan hanya soal pengalaman pengguna, tetapi lebih dekat pada hasil dari perbaikan struktur.
Untuk halaman yang tidak memerlukan SPA, MPA + CSS modern mungkin bisa menjadi pilihan yang baik, tetapi SPA tetap esensial dari sisi struktur, state, skalabilitas, dan maintainability. Menurut saya, CSS modern bisa “melengkapi” SPA, tetapi tidak bisa “menggantikan”-nya.
Dari contoh yang Anda ajukan, satu-satunya yang tidak bisa digantikan dari SPA dengan view transition dan semacamnya hanyalah alat kolaborasi real-time, dan mayoritas situs web bukanlah alat kolaborasi real-time. Situs marketing, dashboard, dan aplikasi commerce semuanya bisa dibangun sambil menyingkirkan framework SPA serta tetap memenuhi syarat rendering di server, halaman penuh, animasi berbasis CSS, preloading yang disengaja, dan penggunaan JS seminimal mungkin. Ada juga Hotwire dari ekosistem Rails yang mengarah ke pendekatan ini, dan ini punya contoh produksi seperti Basecamp dan Hey. Manajemen state? Selama bukan sesuatu seperti alat kolaborasi real-time, itu cukup ditangani dengan metode sisi server seperti parameter URL dan sesi server, atau dengan local storage. Memang ada kasus yang mengadopsi SPA hanya karena perpindahan halaman (seperti situs resmi AGF, yang sebenarnya Astro pun sudah cukup tetapi tetap mengadopsi React), dan tidak bisa disangkal bahwa perpindahan halaman adalah hal yang sering disebut sebagai keunggulan representatif SPA.
Memang benar bahwa framework SPA saat ini dan tren frontend yang berbasis padanya perlu terus mewaspadai ketidakstandaran, dan juga mudah memicu overengineering serta konsumsi sumber daya yang tidak perlu…
Pandangan terhadap konsep SPA sendiri juga terasa terlalu sempit, tetapi lebih dari itu, saya jadi ragu apakah benar dipahami dampak framework SPA terhadap keseluruhan proses pengembangan.
Mengatakan bahwa dengan satu View Transitions API dan CSS semuanya selesai, jika dibalik artinya semua fungsi yang tidak terkait dengannya, serta paradigma untuk mencapainya, sepenuhnya tidak bermakna; menurut saya itu sudut pandang yang terlalu arogan.
Itu juga persoalan yang berbeda dari overengineering ketika membuat situs setingkat pengganti brosur dengan React.
Saya setuju bahwa kebanyakan proyek kecil tidak benar-benar memerlukan framework SPA, tetapi untuk layanan yang menuntut interaksi kompleks, pengalaman pengguna yang berkelanjutan, serta pemeliharaan dan peningkatan terus-menerus sebagai requirement, menurut saya tetap tidak demikian meskipun CSS sudah berkembang.
Sejujurnya, ini terlihat seperti berkata, tentang Rust atau Haskell yang bahkan belum pernah disentuh, "tanpa itu pun sekarang semuanya bisa dilakukan dengan C++ modern."
Hmm, entahlah. Bukankah tujuan penggunaan framework SPA lebih untuk interaksi yang kompleks dengan pengguna daripada sekadar transisi yang mulus?
Memang ada kasus di mana framework SPA diadopsi hanya demi satu interaksi yang mulus. Sebagian besar situs yang menerapkan SPA sebenarnya tidak memerlukan interaksi yang kompleks.
Sangat setuju
Contoh paling jelas, React sendiri juga semacam Spring-nya frontend
Berat dan rumit, dan walau terasa seperti membuat pekerjaan jadi lebih mudah, kenyataannya justru kita menyiapkan proses yang lebih rumit untuk mengerjakan hal yang sederhana, lalu anehnya merasa nyaman karena proses yang sudah dibuat rumit itu dipermudah
Saya setuju. Jika bukan aplikasi web kompleks seperti Google Docs, menurut saya Howired yang dibuat oleh ekosistem Rails pun sudah cukup, dan untuk halaman statis Astro juga sudah memadai.
Komentar Hacker News
SPA masuk akal ketika pengguna menghabiskan sesi panjang dalam satu aplikasi, yaitu struktur di mana bundle besar dimuat sekali lalu aplikasi bisa dipakai hanya dengan permintaan jaringan kecil setelahnya; efek transisi halus hanyalah bonus, bukan masalah esensial yang diselesaikan SPA; klaim bahwa client-side routing itu untuk perpindahan halaman berarti salah paham terhadap tujuan SPA; jika Anda memakai SPA berdasarkan premis keliru seperti itu, maka artikel ini memang benar, tetapi SPA muncul pada era jQuery untuk aplikasi yang kompleks; sekumpulan kode jQuery raksasa membuat tiap div bertindak seperti mini-app dan disinkronkan lewat banyak permintaan jaringan kecil; pada browser lama dan koneksi internet lambat, ini memungkinkan penggunaan yang efisien tanpa memuat ulang seluruh kode setiap saat; kemudian framework seperti React berkembang dengan memudahkan pengembangan aplikasi yang lebih terstruktur, dan keunggulan inti SPA adalah meng-cache bundle besar sekali untuk pengguna dengan sesi panjang lalu meminimalkan trafik jaringan setelahnya
(Kutipan dari komentar di atas: "...if you shared that misunderstanding of SPAs and used them to solve the wrong problem, this article is 100% correct.") Saya sepenuhnya setuju; penulis artikel ini adalah konsultan SEO dan tampaknya hanya fokus pada situs web pemasaran; aplikasi nyata (bukan situs web pemasaran) bisa mendapat manfaat besar dari SPA; misalnya, bayangkan membuat Google Maps tanpa SPA, bahkan jika Anda menambahkan animasi perpindahan halaman saja, UX-nya akan memburuk secara serius
Ada ungkapan “hanya menumpuk spaghetti jQuery”, tetapi saya sendiri dulu benar-benar menerapkan pola desain JS awal seperti IIFE untuk menata kode, lazy loading modul, obfuscation kode, dan sebagainya; dan dalam pengalaman saya, AngularJS adalah upaya penataan frontend terbesar dan menarik bagi developer Java karena modularitas, DI, dan kemudahan testing; saat awal membuat aplikasi dengan Backbone, saya tidak terlalu memikirkan testing karena mengira sebagian besar fungsinya akan ada di backend, tetapi kemudian saat membangunnya ulang dengan AngularJS, jumlah testing frontend menjadi jauh lebih banyak; tentu sekarang saya jadi kurang suka dengan verbositas, kompleksitas, dan indirection pada kode Angular modern maupun kode Java
Saya rasa koneksi jaringan lambat dan lingkungan caching agresif adalah salah satu alasan kuat mengapa SPA dibutuhkan (lebih relevan untuk application daripada website); ketika ada koneksi yang cukup baik, seluruh frontend bisa diunduh sekali dan di-cache, lalu penggunaan berikutnya bisa berlangsung dengan bandwidth minimum
Jika Anda bekerja di tempat yang memakai pipeline CI/CD modern, bundle JS besar itu kemungkinan dibangun ulang dan cache-nya tidak valid setiap kali deploy, bahkan beberapa kali sehari; HTTP2 sudah menjadi bawaan browser selama 10 tahun, dan berkat multiplexing, alasan untuk menggabungkan JS menjadi bundle besar sudah hilang; pendekatan SPA yang membuat bundle besar gagal memanfaatkan fitur modern browser dan server
Saya penasaran berapa banyak kasus nyata di mana permintaan jaringan benar-benar menjadi sangat kecil setelah loading; sebagian besar SPA yang saya alami tetap punya banyak panggilan besar bahkan setelah dimuat, dan jauh lebih lambat daripada langsung mengirim HTML; klaim bahwa JSON secara magical terkompres lebih baik daripada HTML juga tidak berlaku; HTML juga bisa dikompresi dengan sangat baik; pada praktiknya, argumen bahwa SPA lebih baik karena alasan jaringan hampir seperti propaganda atau takhayul
Menurut saya nilai SPA bukan hanya transisi halus, tetapi juga karena sebagian besar perjalanan pengguna bisa ditangani di sisi klien sehingga server hampir tidak perlu dipikirkan; contohnya, saya masih kesal karena pada 2025 sebagian besar toko online tetap me-reload seluruh halaman dan mengambil data ulang setiap kali filter diubah atau kategori dimasuki; dalam situasi pengguna bolak-balik kategori dan membuat banyak permintaan, UX akan jauh lebih baik jika seluruh katalog diunduh sekali ke klien lalu filter bisa dilakukan tanpa komunikasi lagi dengan server; tentu ada sanggahan bahwa datanya besar, tetapi kebanyakan kategori toko online cukup beberapa KB saja, bahkan lebih kecil daripada satu foto produk; setelah membuat aplikasi seperti ini sejak 2005, saya masih tidak paham kenapa UX seperti ini belum lebih luas dipakai
Menurut saya, hal paling tidak nyaman dari harus full reload halaman bukan ukuran datanya melainkan efisiensi situsnya; data sebenarnya hanya beberapa KB, tetapi halaman itu sendiri mengunduh 100MB dan browser memakai 1GB RAM; misalnya, Hacker News sebagian besar navigasinya berupa reload dan tetap berjalan baik di laptop lama, sedangkan SPA seperti DoorDash di perangkat yang sama butuh 30 detik dan total lebih dari 3 menit sampai benar-benar bisa memesan makanan; saya harus menunggu 2,5 menit sampai antarmukanya muncul, dan hampir semuanya pun bukan full reload
Alat seperti HTMX banyak menyelesaikan masalah ini; menurut saya pendekatan SPA pada akhirnya membuat dua aplikasi terpisah, yaitu frontend dan backend; saya merasa lebih baik menangani sebagian besar hal di server side dan hanya menambahkan efek interaktif sederhana di sisi klien (show/hide, expand/collapse, efek, dan sebagainya); tentu ada tempat di mana SPA memang berguna
Pengalaman serupa, beberapa proyek pribadi saya di-host di web server statis; alih-alih merender puluhan ribu halaman individual, saya memakai satu file JSON dan merendernya di sisi klien dalam SPA; saya juga memakai Github Pages; belakangan ini saya juga bereksperimen dengan build wasm database sqlite untuk mengambil hanya halaman yang diperlukan lewat HTTP Range Requests; Full Text Search sqlite memang berjalan, tetapi untuk pencarian pendek tetap harus mengambil seluruh tabel sehingga agak disayangkan; mungkin lebih baik mengambil seluruh DB lalu membuat tabel FTS secara lokal
Ada juga contoh sanggahan; misalnya saat membuka kategori “sci-fi” di tab baru dengan Shift-click, di MPA itu bisa dilakukan tanpa usaha khusus, tetapi di SPA hal seperti ini harus ditangani terpisah sehingga merepotkan; jika tidak ada tautan kategori dan hanya bisa diakses lewat Select Box, UX-nya buruk
Secara umum, perusahaan tidak ingin seluruh katalog mereka bisa diunduh pengguna, karena pesaing akan mudah menganalisisnya; selain itu, untuk penjualan buku misalnya, jumlahnya bisa ratusan ribu judul, sehingga memindahkan semuanya sekaligus tidak efisien baik dari sisi pengalaman pengguna maupun bandwidth/memori
Tujuan SPA sama sekali bukan perpindahan halaman; hampir tidak ada SPA yang benar-benar mengimplementasikan transisi halaman dengan baik; misalnya di Next.js, karena cara root loading bekerja, implementasi page transition nyaris mustahil; saya pernah benar-benar mencoba menambahkan fitur transisi halaman yang layak ke Next.js, dan itu mimpi buruk; saya melihat dua keunggulan jelas dari SPA; pertama, kebanyakan aplikasi menginginkan tingkat interaktivitas tertentu (HTML/CSS saja tidak cukup), dan mencampur React dengan HTML murni adalah penderitaan besar (terutama saat perlu global state management); kedua, jika seluruh struktur halaman dimuat lebih dulu, pemuatan data berikutnya jadi lebih cepat, dan menampilkan respons instan serta loading screen setelah klik memberi UX yang lebih baik daripada baru bereaksi 500ms kemudian (ceritanya berbeda jika di bawah 100ms); karena tidak perlu menggambar ulang seluruh halaman, performa frontend-nya sulit disaingi HTML saja; memang ada contoh seperti Basecamp yang membangun web app kompleks tanpa SPA, tetapi setelah 30 detik klik sana-sini pun performanya masih tidak menyamai SPA; saya berharap web bisa berjalan lebih sesuai sifat aslinya, tetapi kompleksitas tambahan dari Next.js dan SPA memang membuat aplikasi lebih cepat dan responsif, sekaligus membuat pengembangan lebih merepotkan dan menghasilkan bundle besar; tetap saja, menurut saya HTML saja masih belum bisa menandingi performa SPA
Saya tidak tahu di alam semesta mana konsultan SEO penulis ini hidup; menjadikan Next dan Nuxt sebagai contoh framework representatif yang berlawanan dengan SPA itu benar-benar salah; 1. Next hampir sepenuhnya mendominasi AS/dunia Barat, dan ketika orang membicarakan aplikasi React baru, yang dimaksud biasanya Next; di ekosistem Vue, Nuxt hampir menjadi standar dan Nuxt = versi Next di dunia Vue; artinya orang tanpa sadar justru memilih Next dan strategi MPA; pendulumnya sudah terlalu jauh ke arah MPA, jadi saya malah ingin menganjurkan orang mencoba SPA; 8 tahun terakhir adalah masa demam MPA, dan kini Facebook pun secara resmi merekomendasikan Next alih-alih Create React App di dokumentasinya; 2. Keluhan soal kompleksitas Next adalah tentang tingkat kesulitan strategi MPA modern, sementara kubu SPA hampir seperti berhenti selama 10 tahun; 3. Pengembangan MPA jauh lebih sulit daripada SPA, karena Anda harus jauh lebih ketat menjaga pemisahan antara server dan klien; 4. Jika Anda ingin memuat data ala MPA di SPA, itu pilihan developer, dan kelebihan-kekurangannya harus ditanggung sendiri; Anda juga bisa memuat data lebih dulu agar navigasi SPA terasa instan; 5. Selain frontend utama yang benar-benar penting untuk SEO, ada jauh lebih banyak dashboard internal atau aplikasi, dan developer React biasanya banyak berada di area seperti itu, jadi penting untuk tidak memikul beban yang tidak perlu hanya demi memberi first frame yang sempurna tanpa syarat
Saya rasa nada yang meremehkan SPA itu tidak adil; SPA jelas memerlukan lebih banyak usaha, tetapi juga jelas punya lebih banyak keuntungan; selama ini SPA praktis menjadi satu-satunya cara membuat UX yang terasa seperti aplikasi; penulis menyebut app fatigue, tetapi jika benar-benar ingin memberi pengalaman ‘application’, SPA hampir satu-satunya pilihan; membandingkan SPA berat dengan website ringan (situs statis) itu tidak tepat; kalau seseorang bisa membuat website ringan, ia juga bisa membuat SPA ringan; baik SPA maupun website, jika dibuat secara tidak efisien, sama-sama akan lambat dan berat; sebagai orang yang sudah banyak berinvestasi di SPA, saya sangat tertarik pada cara menghasilkan pengalaman yang sama dengan usaha lebih sedikit, tetapi artikel ini terasa lebih seperti sedikit polesan visual; polishing memang bernilai, tetapi saya rasa tidak cukup berpengaruh untuk menentukan apakah harus memakai SPA atau tidak
Menurut saya, mengatakan “coba buat linear.app tanpa framework SPA” itu tidak realistis, dan proposisi “transisi CSS native membunuh keunggulan terbesar SPA (client routing)” juga tidak masuk akal
Saya rasa Linear adalah kasus yang sangat khusus bahkan di antara SPA; ini bukan argumen untuk melarang SPA atau menghapus JS sepenuhnya dari browser; Linear cepat karena desainnya “offline-first”, tetapi sangat sedikit layanan yang dibangun seperti itu; untuk pemesanan tiket, forum, berita, blog, dan situs informasional, saya rasa pengembangan berbasis SSR jauh lebih baik; gunakan SPA hanya ketika memang dibutuhkan, dan untuk sisanya kembangkan cepat dengan SSR lalu buat terlihat seperti SPA memakai CSS, itu jauh lebih efisien
Bukan berarti SPA tidak punya tempat, tetapi 99% situs lainnya tidak perlu menjadi SPA
SPA bukan tentang view transition (transisi halaman); tulisan asli (TFA) mengisyaratkan bahwa transisi mewah antarhalaman itu penting, padahal itu pemikiran yang salah; alih-alih menyalahkan “CMO” atau “brand manager”, kita seharusnya menyoroti nilai esensial SPA; SPA adalah framework yang sangat baik untuk logika klien, pemisahan concern (logika frontend dan backend dipisah), peningkatan developer experience → kecepatan pengembangan yang lebih tinggi, dan banyak keuntungan lain; tulisan seperti ini sering muncul karena strukturnya memang memancing perdebatan seperti komentar saya, tetapi sebenarnya menurut saya ini bukan jenis tulisan yang layak mendapat perhatian sebesar ini
Dari sudut pandang saya, janji utama SPA bukan transisi halus, melainkan kemampuan membuat data API dan frontend yang sepenuhnya terpisah dari backend, sehingga saya tidak suka mencampur SSR dan client rendering; menurut saya harus jelas, entah itu website atau aplikasi
Saya juga bertanya, “sebenarnya apa kriteria SPA dan MPA?” Situs pribadi saya berbasis Next.js pada praktiknya me-render hampir semuanya di server side; secara teknis itu SPA, tetapi jika JS dinyalakan maka RSC dan client-side navigation berjalan, dan jika JS dimatikan pun komponen khusus klien (misalnya generator QR code) ditampilkan sebagai konten pengganti dan sisanya tetap dirender sepenuhnya dengan SSR sehingga walau agak lebih lambat tetap berfungsi dengan baik; justru komponen yang tidak dirender di server lebih merepotkan; progressive enhancement adalah yang terbaik
Saya juga sangat frustrasi karena industri SEO atau developer web junior yang masuk setelah masa COVID terus salah paham dan meremehkan SPA; dari sudut pandang orang yang sudah mengembangkan sejak 2000-an, asal-usul nyata SPA bukan karena "janji palsu" seperti di tulisan asli, melainkan karena pada akhir 2000-an hingga awal 2010-an strategi mobile-first menyebar dan frontend serta backend harus dipisahkan sepenuhnya; sebelumnya, frontend umumnya hanya sebatas merender HTML dari template server lalu sedikit dibumbui jQuery, tetapi sekarang baik aplikasi mobile maupun desktop harus memakai business logic/DB yang sama, sehingga struktur REST, pembacaan ulang makalah Roy Fielding, arsitektur berorientasi layanan, dan eksposur API ke luar menjadi arus utama; ada juga alasan optimasi biaya; selama periode itu, framework web full-stack seperti Ruby on Rails atau Django sempat mengalami masa lesu; lalu Node.js naik daun, browser dan perangkat mobile makin kuat, dan banyak business logic bisa dipindahkan ke sisi “edge device” (yaitu klien); itulah inti SPA, dan saya tidak melihat CSS bisa menggantikan kebutuhan itu