Aplikasi Halaman Tunggal: kelebihan dan kekurangan [ditutup]

Saya sudah membaca tentang SPA dan itu keuntungan. Saya menemukan sebagian besar dari mereka tidak meyakinkan. Ada 3 keuntungan yang membangkitkan keraguan saya.

Pertanyaan: Bisakah Anda bertindak sebagai pembela SPA dan membuktikan bahwa saya salah tentang tiga pernyataan pertama?

                              === ADVANTAGES ===

1. SPA sangat baik untuk situs yang sangat responsif:

Render sisi server sulit diterapkan untuk semua status perantara - status tampilan kecil tidak memetakan dengan baik ke URL.

Aplikasi satu halaman dibedakan oleh kemampuannya untuk menggambar ulang bagian mana pun dari UI tanpa memerlukan bolak-balik server untuk mengambil HTML. Ini dicapai dengan memisahkan data dari penyajian data dengan memiliki lapisan model yang menangani data dan lapisan tampilan yang dibaca dari model.

Apa yang salah dengan memegang lapisan model untuk non-SPA? Apakah SPA satu-satunya arsitektur yang kompatibel dengan MVC di sisi klien?

2. Dengan SPA kita tidak perlu menggunakan permintaan tambahan ke server untuk mengunduh halaman.

Hah, dan berapa banyak halaman yang dapat diunduh pengguna selama mengunjungi situs Anda? Dua tiga? Sebaliknya muncul masalah keamanan lain dan Anda perlu memisahkan halaman login Anda, halaman admin dll menjadi halaman terpisah. Pada gilirannya itu bertentangan dengan arsitektur SPA.

3.Mungkin ada keuntungan lain? Jangan dengar hal lain ..

                            === DISADVANTAGES ===

1. Klien harus mengaktifkan javascript.
2. Hanya satu titik masuk ke situs.
3. Keamanan.

PS Saya sudah bekerja di proyek SPA dan non-SPA. Dan saya mengajukan pertanyaan-pertanyaan itu karena saya perlu memperdalam pemahaman saya. Tidak bermaksud membahayakan pendukung SPA. Jangan tanya saya untuk membaca sedikit tentang SPA. Saya hanya ingin mendengar pertimbangan Anda tentang itu.

Mari kita lihat salah satu situs SPA paling populer, GMail.

1. SPA sangat baik untuk situs yang sangat responsif:

Render sisi server tidak sesulit dulu dengan teknik sederhana seperti menyimpan # hash di URL, atau yang terbaru HTML5pushState . Dengan pendekatan ini, keadaan sebenarnya dari aplikasi web tertanam dalam URL halaman. Seperti di GMail setiap kali Anda membuka email, tag hash khusus ditambahkan ke URL. Jika disalin dan ditempelkan ke jendela browser lain dapat membuka email yang sama persis (asalkan mereka dapat mengotentikasi). Pendekatan ini memetakan langsung ke string kueri yang lebih tradisional, perbedaannya hanya pada eksekusi. Dengan HTML5 pushState () Anda dapat menghilangkan #hashdan menggunakan URL yang benar-benar klasik yang dapat diselesaikan pada server pada permintaan pertama dan kemudian memuat melalui ajax pada permintaan berikutnya.

2. Dengan SPA kita tidak perlu menggunakan permintaan tambahan ke server untuk mengunduh halaman.

Jumlah halaman yang diunduh pengguna selama kunjungan ke situs web saya ?? benar-benar berapa banyak surat yang dibaca ketika dia membuka akun suratnya. Saya membaca> 50 sekaligus. sekarang struktur surat hampir sama. jika Anda akan menggunakan skema rendering sisi server maka server akan merendernya pada setiap permintaan (kasus umum). - masalah keamanan - Anda harus / tidak boleh menyimpan halaman terpisah untuk admin / login yang sepenuhnya tergantung pada struktur situs Anda, ambil paytm.com misalnya juga membuat situs web SPA tidak berarti Anda membuka semua titik akhir untuk semua pengguna yang saya maksud, saya menggunakan formulir auth dengan situs web spa saya. - dalam kerangka SPA yang mungkin paling sering digunakan Angular JS, dev dapat memuat seluruh kuil html dari situs web sehingga dapat dilakukan tergantung pada tingkat otentikasi pengguna. pre loading html untuk semua jenis auth isn '

3. Mungkin ada keuntungan lain? Jangan dengar hal lain ..

• hari ini Anda dapat dengan aman menganggap klien akan memiliki browser yang mengaktifkan javascript.
• hanya satu titik masuk situs. Seperti yang saya sebutkan sebelumnya, pemeliharaan status dimungkinkan, Anda dapat memiliki sejumlah titik masuk seperti yang Anda inginkan, tetapi Anda harus memilikinya.
• bahkan dalam pengguna SPA hanya melihat apa yang ia miliki hak yang tepat. Anda tidak harus menyuntikkan semuanya sekaligus. memuat template html berbeda dan javascript async juga merupakan bagian yang valid dari SPA.

Keuntungan yang bisa saya pikirkan adalah:

1. rendering html jelas membutuhkan beberapa sumber daya sekarang setiap pengguna yang mengunjungi situs Anda melakukan ini. juga tidak hanya merender logika utama sekarang dilakukan sisi klien, bukan sisi server.
2. masalah waktu tanggal - Saya hanya memberi waktu UTC klien adalah format yang ditetapkan sebelumnya dan bahkan tidak peduli dengan zona waktu yang saya biarkan javascript menanganinya. ini adalah keuntungan besar di mana saya harus menebak zona waktu berdasarkan lokasi yang berasal dari pengguna IP.
3. bagi saya menyatakan lebih baik dikelola di SPA karena setelah Anda menetapkan variabel Anda tahu itu akan ada di sana. ini memberi kesan mengembangkan aplikasi daripada halaman web. ini sangat membantu dalam membuat situs seperti foodpanda, flipkart, amazon. karena jika Anda tidak menggunakan keadaan sisi klien Anda menggunakan sesi mahal.
4. situs web pasti sangat responsif - Saya akan mengambil contoh ekstrim untuk ini mencoba membuat kalkulator di situs web non SPA (Saya tahu ini aneh).

Pembaruan dari Komentar

Sepertinya tidak ada yang menyebutkan tentang soket dan polling panjang. Jika Anda keluar dari klien lain mengatakan aplikasi seluler, maka browser Anda juga harus keluar. Jika Anda tidak menggunakan SPA, Anda harus membuat kembali koneksi soket setiap kali ada pengalihan. Ini juga harus bekerja dengan setiap pembaruan dalam data seperti pemberitahuan, pembaruan profil dll

Perspektif alternatif: Selain dari situs web Anda, apakah proyek Anda akan melibatkan aplikasi seluler asli? Jika ya, Anda kemungkinan besar akan memberi makan data mentah ke aplikasi asli dari server (yaitu JSON) dan melakukan pemrosesan sisi klien untuk merendernya, benar? Jadi dengan pernyataan ini, Anda SUDAH melakukan model rendering sisi klien. Sekarang pertanyaannya menjadi, mengapa Anda tidak harus menggunakan model yang sama untuk versi situs web proyek Anda? Agak no-brainer. Kemudian pertanyaannya adalah apakah Anda ingin membuat halaman sisi server hanya untuk manfaat SEO dan kenyamanan URL yang dapat dibagikan / bookmark

Saya seorang pragmatis, jadi saya akan mencoba melihat ini dari segi biaya dan manfaat.

Perhatikan bahwa untuk setiap kerugian yang saya berikan, saya menyadari bahwa mereka dapat dipecahkan. Itu sebabnya saya tidak melihat apa pun sebagai hitam dan putih, melainkan biaya dan manfaat.

Keuntungan

• Pelacakan status yang lebih mudah - tidak perlu menggunakan cookie, pengiriman formulir, penyimpanan lokal, penyimpanan sesi, dll. Untuk mengingat status di antara 2 pemuatan halaman.
• Konten pelat ketel yang ada di setiap halaman (header, footer, logo, spanduk hak cipta, dll.) Hanya dimuat sekali per sesi browser tipikal.
• Tidak ada latensi overhead saat pengalihan "halaman".

Kekurangan

• Pemantauan kinerja - terikat tangan: Sebagian besar solusi pemantauan kinerja tingkat browser Saya telah melihat fokus secara eksklusif pada waktu pemuatan halaman saja, seperti waktu untuk byte pertama, waktu untuk membangun DOM, round-trip jaringan untuk HTML, acara yang memuat, dll. Memperbarui halaman post-load via AJAX tidak akan diukur. Ada solusi yang memungkinkan Anda instrumen kode Anda untuk merekam tindakan eksplisit, seperti ketika mengklik tautan, memulai penghitung waktu, lalu mengakhiri penghitung waktu setelah memberikan hasil AJAX, dan mengirimkan umpan balik itu. Relik Baru, misalnya, mendukung fungsi ini. Dengan menggunakan SPA, Anda telah mengikat diri Anda hanya dengan beberapa alat yang mungkin.
• Pengujian keamanan / penetrasi - terikat tangan: Pemindaian keamanan otomatis dapat mengalami kesulitan menemukan tautan ketika seluruh halaman Anda dibangun secara dinamis oleh kerangka SPA. Mungkin ada solusi untuk ini, tetapi sekali lagi, Anda membatasi diri.
• Bundling: Sangat mudah untuk masuk ke situasi ketika Anda mengunduh semua kode yang diperlukan untuk seluruh situs web pada pemuatan halaman awal, yang dapat melakukan sangat untuk koneksi bandwidth rendah. Anda dapat menggabungkan file JavaScript dan CSS Anda untuk mencoba memuat dalam potongan yang lebih alami saat Anda pergi, tetapi sekarang Anda perlu mempertahankan pemetaan itu dan menonton file yang tidak diinginkan untuk ditarik melalui dependensi yang tidak direalisasi (kebetulan saja pada saya). Sekali lagi, dipecahkan, tetapi dengan biaya.
• Refactoring Big Bang: Jika Anda ingin membuat perubahan arsitektur besar, seperti katakanlah, beralih dari satu kerangka kerja ke kerangka kerja lainnya, untuk meminimalkan risiko, diinginkan untuk membuat perubahan tambahan. Yaitu, mulailah menggunakan yang baru, bermigrasi atas dasar tertentu, seperti per-halaman, per-fitur, dll., Lalu lepaskan yang lama setelahnya. Dengan aplikasi multi-halaman tradisional, Anda dapat beralih satu halaman dari Angular ke React, lalu beralih halaman lain di sprint berikutnya. Dengan SPA, semuanya atau tidak sama sekali. Jika Anda ingin mengubah, Anda harus mengubah seluruh aplikasi sekaligus.
• Kompleksitas navigasi: Tooling ada untuk membantu mempertahankan konteks navigasi di SPA, seperti history.js, Angular 2, yang sebagian besar bergantung pada kerangka URL (#) atau API riwayat yang lebih baru. Jika setiap halaman adalah halaman terpisah, Anda tidak memerlukan semua itu.
• Kompleksitas mencari tahu kode: Secara alami kami menganggap situs web sebagai halaman. Aplikasi multi-halaman biasanya mem-partisi kode per halaman, yang membantu pemeliharaan.

Sekali lagi, saya menyadari bahwa setiap masalah ini dapat dipecahkan, dengan biaya tertentu. Tapi ada titik di mana Anda menghabiskan semua waktu Anda memecahkan masalah yang Anda bisa hindari di tempat pertama. Itu kembali ke manfaat dan betapa pentingnya bagi Anda.

Kekurangan

1. Klien harus mengaktifkan javascript. Ya, ini jelas kerugian SPA. Dalam kasus saya, saya tahu bahwa saya dapat mengharapkan pengguna saya mengaktifkan JavaScript. Jika Anda tidak bisa maka Anda tidak bisa melakukan SPA, titik. Itu seperti mencoba untuk menyebarkan aplikasi .NET ke mesin tanpa .NET Framework diinstal.

2. Hanya satu titik masuk ke situs. Saya mengatasi masalah ini menggunakan SammyJS . 2-3 hari kerja untuk mendapatkan pengaturan rute Anda dengan benar, dan orang-orang akan dapat membuat bookmark tautan-dalam ke aplikasi Anda yang bekerja dengan benar. Server Anda hanya perlu mengekspos satu titik akhir - titik akhir "beri saya HTML + CSS + JS untuk aplikasi ini" (anggap sebagai lokasi unduhan / perbarui untuk aplikasi yang dikompilasi) - dan JavaScript sisi klien yang Anda tulis akan menangani entri aktual ke dalam aplikasi.

3. Keamanan.Masalah ini tidak unik untuk SPA, Anda harus berurusan dengan keamanan dengan cara yang persis sama ketika Anda memiliki aplikasi server klien "sekolah lama" (model HATEOAS menggunakan Hypertext untuk menghubungkan antar halaman). Hanya saja pengguna membuat permintaan alih-alih JavaScript Anda, dan bahwa hasilnya dalam HTML daripada JSON atau beberapa format data. Di aplikasi non-SPA Anda harus mengamankan halaman individual di server, sedangkan di aplikasi SPA Anda harus mengamankan titik akhir data. (Dan, jika Anda tidak ingin klien Anda memiliki akses ke semua kode, maka Anda harus memecah JavaScript yang dapat diunduh menjadi area terpisah juga. Saya hanya mengikatnya ke dalam sistem perutean berbasis SammyJS saya sehingga browser hanya meminta hal-hal yang klien tahu harus memiliki akses, berdasarkan beban awal peran pengguna,

Keuntungan

1. Keuntungan arsitektur utama dari SPA (yang jarang disebutkan) dalam banyak kasus adalah pengurangan besar dalam "chattiness" aplikasi Anda. Jika Anda mendesainnya dengan benar untuk menangani sebagian besar pemrosesan pada klien (intinya, bagaimanapun juga), maka jumlah permintaan ke server (baca "kemungkinan untuk 503 kesalahan yang merusak pengalaman pengguna Anda") berkurang secara dramatis. Bahkan, SPA memungkinkan untuk melakukan pemrosesan offline sepenuhnya, yang sangat besar dalam beberapa situasi.

2. Kinerja tentu saja lebih baik dengan rendering sisi klien jika Anda melakukannya dengan benar, tetapi ini bukan alasan yang paling meyakinkan untuk membangun SPA. (Bagaimanapun juga, kecepatan jaringan meningkat.) Jangan membuat SPA hanya untuk kasus ini.

3. Fleksibilitas dalam desain UI Anda mungkin merupakan keunggulan utama lain yang saya temukan. Setelah saya mendefinisikan API saya (dengan SDK dalam JavaScript), saya dapat sepenuhnya menulis ulang front-end saya dengan nol dampak pada server selain dari beberapa file sumber daya statis. Coba lakukan itu dengan aplikasi MVC tradisional! :) (Ini menjadi berharga ketika Anda memiliki penyebaran langsung dan konsistensi versi API Anda untuk dikhawatirkan.)

Jadi, intinya: Jika Anda memerlukan pemrosesan offline (atau setidaknya ingin klien Anda dapat bertahan hidup dari pemadaman server sesekali) - secara dramatis mengurangi biaya perangkat keras Anda sendiri - dan Anda dapat mengasumsikan JavaScript & browser modern, maka Anda memerlukan SPA. Dalam kasus lain, ini lebih merupakan tradeoff.

Salah satu kelemahan utama dari SPA - SEO. Hanya baru-baru ini Google dan Bing mulai mengindeks halaman berbasis Ajax dengan mengeksekusi JavaScript selama perayapan, dan masih dalam banyak kasus halaman diindeks dengan tidak benar.

Saat mengembangkan SPA, Anda akan dipaksa untuk menangani masalah SEO, mungkin dengan post-rendering semua situs Anda dan membuat snapshot html statis untuk penggunaan crawler. Ini akan membutuhkan investasi yang kuat dalam infrastruktur yang tepat.

Pembaruan 19.06.16:

Sejak menulis jawaban ini beberapa waktu yang lalu, saya mendapatkan lebih banyak pengalaman dengan Aplikasi Halaman Tunggal (yaitu, AngularJS 1.x) - jadi saya memiliki lebih banyak info untuk dibagikan.

Menurut pendapat saya, kelemahan utama dari aplikasi SPA adalah SEO, membuat mereka terbatas pada jenis aplikasi "dashboard" saja. Selain itu, Anda akan mengalami masa yang lebih sulit dengan caching, dibandingkan dengan solusi klasik. Sebagai contoh, dalam caching ASP.NET sangat mudah - cukup aktifkan OutputCaching dan Anda baik: seluruh halaman HTML akan di-cache sesuai dengan URL (atau parameter lainnya). Namun, di SPA Anda perlu menangani caching sendiri (dengan menggunakan beberapa solusi seperti cache level kedua, caching template, dll.).

Saya ingin menjadikan SPA yang terbaik untuk Aplikasi Berbasis Data. gmail, tentu saja semua tentang data dan dengan demikian kandidat yang baik untuk SPA.

Tetapi jika halaman Anda sebagian besar untuk tampilan, misalnya, halaman persyaratan layanan, maka SPA benar-benar berlebihan.

Saya pikir sweet spot memiliki situs dengan campuran halaman gaya SPA dan statis / MVC, tergantung pada halaman tertentu.

Misalnya, di satu situs yang saya bangun, pengguna mendarat di halaman indeks MVC standar. Tetapi kemudian ketika mereka pergi ke aplikasi yang sebenarnya, maka itu memanggil SPA. Keuntungan lain dari hal ini adalah bahwa waktu buka SPA tidak pada halaman beranda, tetapi pada halaman aplikasi. Waktu buka berada di beranda dapat menjadi gangguan bagi pengguna situs pertama kali.

Skenario ini sedikit seperti menggunakan Flash. Setelah beberapa tahun pengalaman, jumlah situs Flash saja turun mendekati nol karena faktor beban. Tetapi sebagai komponen halaman, masih digunakan.

Untuk perusahaan seperti google, amazon dll, yang servernya berjalan pada kapasitas maksimal dalam mode 24/7, mengurangi lalu lintas berarti uang nyata - lebih sedikit perangkat keras, lebih sedikit energi, lebih sedikit pemeliharaan. Menggeser penggunaan CPU dari server ke klien terbayar, dan SPA bersinar. Keuntungannya kelebihan berat badan sejauh ini. Jadi, SPA atau tidak SPA sangat tergantung pada use case.

Hanya untuk menyebutkan kasus penggunaan lain, mungkin tidak begitu jelas (untuk pengembang web) untuk SPA: Saat ini saya sedang mencari cara untuk mengimplementasikan GUI dalam sistem tertanam dan arsitektur berbasis browser tampaknya menarik bagi saya. Secara tradisional tidak ada banyak kemungkinan untuk UI dalam sistem embedded - Java, Qt, wx, dll atau kerangka kerja komersial yang wajar. Beberapa tahun yang lalu Adobe mencoba memasuki pasar dengan flash tetapi tampaknya tidak begitu berhasil.

Saat ini, karena "embedded system" sekuat mainframe beberapa tahun yang lalu, UI berbasis browser yang terhubung ke unit kontrol melalui REST adalah solusi yang memungkinkan. Keuntungannya adalah, palet besar alat untuk UI tanpa biaya. (mis. Qt membutuhkan $ 20-30 per unit terjual dengan biaya royalti ditambah $ 3000-4000 per pengembang)

Untuk arsitektur seperti itu SPA menawarkan banyak keuntungan - mis. Pendekatan pengembangan yang lebih akrab bagi pengembang aplikasi desktop, berkurangnya akses server (seringkali dalam industri mobil UI dan sistem muddle adalah perangkat keras yang terpisah, di mana bagian sistem memiliki RT OS).

Karena satu-satunya klien adalah browser bawaan, kerugian yang disebutkan seperti ketersediaan JS, logging sisi server, keamanan tidak dihitung lagi.

2. Dengan SPA kita tidak perlu menggunakan permintaan tambahan ke server untuk mengunduh halaman.

Saya masih harus belajar banyak tetapi sejak saya mulai belajar tentang SPA, saya mencintai mereka.

Poin khusus ini dapat membuat perbedaan besar.

Di banyak aplikasi web yang bukan SPA, Anda akan melihat bahwa mereka masih akan mengambil dan menambahkan konten ke halaman yang membuat permintaan ajax. Jadi saya pikir SPA melampaui dengan mempertimbangkan: bagaimana jika konten yang akan diambil dan ditampilkan menggunakan ajax adalah seluruh halaman? dan bukan hanya sebagian kecil halaman?

Biarkan saya menyajikan skenario. Pertimbangkan bahwa Anda memiliki 2 halaman:

1. halaman dengan daftar produk
2. halaman untuk melihat detail produk tertentu

Pertimbangkan bahwa Anda berada di halaman daftar. Kemudian Anda mengklik suatu produk untuk melihat detailnya. Aplikasi sisi klien akan memicu 2 permintaan ajax:

1. permintaan untuk mendapatkan objek json dengan detail produk
2. permintaan untuk mendapatkan templat html tempat detail produk akan dimasukkan

Kemudian, aplikasi sisi klien akan memasukkan data ke templat html dan menampilkannya.

Kemudian Anda kembali ke daftar (tidak ada permintaan untuk ini!) Dan Anda membuka produk lain. Kali ini, hanya akan ada permintaan ajax untuk mendapatkan detail produk. Template html akan sama sehingga Anda tidak perlu mengunduh lagi.

Anda dapat mengatakan bahwa di SPA non, ketika Anda membuka detail produk, Anda hanya membuat 1 permintaan dan dalam skenario ini kami lakukan 2. Ya. Tetapi Anda mendapatkan keuntungan dari perspektif keseluruhan, ketika Anda menavigasi banyak halaman, jumlah permintaan akan lebih rendah. Dan data yang ditransfer antara sisi klien dan server akan lebih rendah juga karena template html akan digunakan kembali. Selain itu, Anda tidak perlu mengunduh semua permintaan css, gambar, file javascript di semua halaman dalam semua permintaan.

Juga, mari kita pertimbangkan bahwa bahasa sisi server Anda adalah Java. Jika Anda menganalisis 2 permintaan yang saya sebutkan, 1 unduhan data (Anda tidak perlu memuat file tampilan dan memanggil mesin rendering tampilan) dan unduhan lain serta templat html statis sehingga Anda dapat memiliki server web HTTP yang dapat mengambil secara langsung tanpa harus memanggil server aplikasi Java, tidak ada perhitungan yang dilakukan!

Akhirnya, perusahaan besar menggunakan SPA: Facebook, GMail, Amazon. Mereka tidak bermain, mereka memiliki insinyur terbaik yang mempelajari semua ini. Jadi, jika Anda tidak melihat kelebihannya, Anda bisa memercayai mereka pada awalnya dan berharap menemukan mereka di ujung jalan.

Tetapi penting untuk menggunakan pola desain SPA yang baik. Anda dapat menggunakan kerangka kerja seperti AngularJS. Jangan mencoba menerapkan SPA tanpa menggunakan pola desain yang bagus karena Anda mungkin akan mengalami kekacauan.

Kekurangan : Secara teknis, desain dan pengembangan awal SPA adalah kompleks dan dapat dihindari. Alasan lain untuk tidak menggunakan SPA ini adalah:

• a) Keamanan: Aplikasi Halaman Tunggal kurang aman dibandingkan dengan halaman tradisional karena skrip lintas situs (XSS).
• b) Memory Leak: Kebocoran memori dalam JavaScript bahkan dapat menyebabkan Komputer yang kuat melambat. Sebagai situs web tradisional mendorong untuk bernavigasi di antara halaman, sehingga setiap kebocoran memori yang disebabkan oleh halaman sebelumnya hampir dibersihkan meninggalkan residu lebih sedikit.
• c) Klien harus mengaktifkan JavaScript untuk menjalankan SPA, tetapi dalam aplikasi multi-halaman JavaScript dapat sepenuhnya dihindari.
• d) SPA tumbuh ke ukuran optimal, menyebabkan waktu tunggu yang lama. Misalnya: Bekerja di Gmail dengan koneksi yang lebih lambat.

Selain di atas, batasan arsitektur lainnya adalah hilangnya Data Navigasi, Tidak ada log Riwayat Navigasi di browser dan kesulitan dalam Pengujian Fungsional Otomatis dengan selenium.

Tautan ini menjelaskan Kelebihan dan Kekurangan Aplikasi Satu Halaman.

Dalam perkembangan saya, saya menemukan dua keuntungan berbeda untuk menggunakan SPA. Itu bukan untuk mengatakan bahwa hal berikut ini tidak dapat dicapai dalam aplikasi web tradisional hanya karena saya melihat manfaat tambahan tanpa memperkenalkan kerugian tambahan.

• Potensi untuk lebih sedikit permintaan server karena rendering konten baru tidak selalu atau bahkan permintaan server http untuk halaman html baru. Tapi saya katakan potensial karena konten baru bisa dengan mudah membutuhkan panggilan Ajax untuk menarik data tetapi data itu bisa lebih ringan daripada itu sendiri ditambah markup memberikan keuntungan bersih.

• Kemampuan untuk mempertahankan "Negara". Dalam istilah yang paling sederhana, atur variabel saat masuk ke aplikasi dan itu akan tersedia untuk komponen lain di seluruh pengalaman pengguna tanpa meneruskannya atau mengaturnya ke pola penyimpanan lokal. Namun mengelola kemampuan ini secara cerdas adalah kunci untuk menjaga ruang lingkup tingkat atas tidak berantakan.

Selain meminta JS (yang bukan hal gila untuk memerlukan aplikasi web) Kerugian lain yang tercatat menurut saya adalah tidak spesifik untuk SPA atau dapat dikurangi melalui kebiasaan dan pola pengembangan yang baik.

Cobalah untuk tidak mempertimbangkan menggunakan SPA tanpa terlebih dahulu menentukan bagaimana Anda akan mengatasi keamanan dan stabilitas API di sisi server. Maka Anda akan melihat beberapa manfaat sebenarnya dari menggunakan SPA. Khususnya, jika Anda menggunakan server RESTful yang mengimplementasikan OAUTH 2.0 untuk keamanan, Anda akan mencapai dua pemisahan mendasar yang dapat menurunkan biaya pengembangan dan pemeliharaan Anda.

1. Ini akan memindahkan sesi (dan ini keamanan) ke SPA dan membebaskan server Anda dari semua overhead itu.
2. API Anda menjadi stabil dan mudah diperluas.

Diberitahu sebelumnya, tetapi tidak dibuat eksplisit; Jika tujuan Anda adalah menggunakan aplikasi Android & Apple, menulis JavaScript SPA yang dibungkus dengan panggilan asli untuk meng-host layar di browser (Android atau Apple) menghilangkan kebutuhan untuk mempertahankan basis kode Apple dan basis kode Android.

Saya mengerti ini adalah pertanyaan yang lebih lama, tetapi saya ingin menambahkan kelemahan lain dari Aplikasi Halaman Tunggal:

Jika Anda membuat API yang mengembalikan hasil dalam bahasa data (seperti XML atau JSON) alih-alih bahasa pemformatan (seperti HTML), Anda mengaktifkan interoperabilitas aplikasi yang lebih besar, misalnya, dalam aplikasi bisnis-ke-bisnis (B2B). Interoperabilitas semacam itu memiliki manfaat besar tetapi memungkinkan orang untuk menulis perangkat lunak untuk "menambang" (atau mencuri) data Anda. Kerugian khusus ini umum untuk semua API yang menggunakan bahasa data, dan tidak untuk SPA secara umum (memang, SPA yang meminta server untuk HTML yang telah diterjemahkan sebelumnya menghindari hal ini, tetapi dengan mengorbankan pemisahan model / tampilan yang buruk). Risiko ini terkena kerugian ini dapat dikurangi dengan berbagai cara, seperti pembatasan permintaan dan pemblokiran koneksi, dll.