Peningkatan Progresif vs. Aplikasi Satu Halaman

33

Saya baru saja kembali dari sebuah konferensi di Boston bernama An Event Apart .

Tema yang sangat populer di antara pembicara adalah gagasan peningkatan progresif - konten situs harus dalam HTML, dan JavaScript hanya boleh digunakan untuk meningkatkan perilaku.

Argumen yang diberikan pembicara untuk peningkatan progresif sangat menarik. Tidak hanya itu pola yang solid untuk mendukung browser yang lebih lama, dan perangkat di jaringan dengan bandwidth rendah, tetapi HTML gagal jauh lebih anggun dari JavaScript (mis. Markup yang tidak didukung hanya diabaikan, sedangkan jika browser mengeluarkan pengecualian saat mengeksekusi Anda skrip - Anda disemprot).

Jeremy Keith memberikan ceramah khusus tentang hal ini.

Tapi bagaimana dengan aplikasi web satu halaman seperti Backbone dan Angular? Seluruh desain di balik kerangka kerja ini tampaknya mendorong pengembang untuk memindahkan konten dari HTML, dan menjadi sesuatu seperti JSON API.

Saya sepertinya tidak bisa menggunakan dua pola desain ini: peningkatan progresif vs. aplikasi web satu halaman. Apakah ada contoh ketika satu lebih baik dari yang lain? Atau apakah itu bahkan bukan teknologi antagonis, dan saya kehilangan sesuatu di sini dengan model mental saya?

— SeanPlusPlus
sumber

Mereka memiliki dua kasus penggunaan yang berbeda. Ya, ada tumpang tindih ketika server melakukan tugas berat.

— BobDalgleish

5

Saya pikir wajar untuk mengatakan bahwa persyaratan browser untuk Aplikasi Satu Halaman lebih ketat daripada persyaratan untuk aplikasi web "biasa".

— Robert Harvey

3

Anda harus meminta Jeremy Keith untuk memberi Anda contoh dunia nyata di mana peningkatan progresif benar-benar layak untuk menyenangkan 1-10% total orang internet dan meminta data 90% pengguna lain, apakah mereka benar-benar peduli dengan peningkatan progresif atau jika mereka senang jika mereka dapat mengunjungi situs web dengan IE 5.0 atau tanpa javascript

— kirie

1

Jika tipe orang yang menonaktifkan JS / gambar / dll tidak dalam demografi target inti Anda, maka tidak ada alasan bisnis yang valid untuk mengejar Peningkatan Progresif.

— Graham

1

Dukungan untuk 'perangkat di jaringan dengan bandwidth rendah' sebenarnya dan argumen untuk SPA, bukan menentangnya! Di SPA Anda hanya membuat satu permintaan besar, di mana tanpa JS Anda memilikinya setiap waktu!

— Dmitri Zaitsev

21

Sepertinya saya bahwa aplikasi satu halaman menarik garis di pasir peningkatan progresif. Di mana sebelum kita mencoba mengatasi kenyataan bahwa implementasi dan fitur bervariasi di antara peramban yang akan kembali selama beberapa dekade, SPA berasumsi bahwa ada garis dasar tertentu yang dapat kita sepakati secara wajar yang akan dipenuhi oleh sebagian besar pengunjung situs tertentu. Saya tidak berpikir keduanya berselisih. Anda masih dapat terus meningkatkan secara progresif setelah SPA dimulai, seperti memulai dengan sebuah <video>tag, lalu meletakan pemain Anda yang kaya fitur di atasnya.

Lalu ada pengunjung dengan skrip dinonaktifkan, tetapi mereka tahu apa yang mereka hadapi. Saya tidak melihat mengapa pengembang harus membungkuk ke belakang untuk pengunjung tersebut, selain dari catatan "Anda perlu skrip untuk situs ini". Jika kami mengizinkannya, mengapa tidak melayani pengunjung dengan CSS yang dinonaktifkan? Bagaimana dengan gambar yang dinonaktifkan? Ini adalah teknologi web inti. Mereka seharusnya tidak berharap memiliki pengalaman web yang berfungsi penuh ketika mereka memilih dan memilih bagian.

Untuk memastikan saya tidak pergi tanpa analogi mobil, saya seharusnya tidak berharap mobil saya berfungsi jika saya memutuskan saya tidak suka fitur tertentu. Saya bisa memberi tahu insinyur sipil, "Saya menonaktifkan lampu depan saya, jadi tolong pastikan untuk memasang lampu jalan setiap 125 kaki di mana pun saya mungkin mengunjungi." Tanpa lampu depan, mobil saya akan sering bekerja, tetapi beberapa tempat tidak dapat saya kunjungi.

— Collin Allen
sumber

3

I don't see why developers should bend over backwards for those visitors. Jika kontrak Anda menentukan bahwa Anda perlu menyediakan versi situs web yang dapat diakses, mungkin akan lebih sulit untuk menggunakan SPA. Juga bagaimana dengan SEO?

— Simon Bergot

7

@Simon: Anda dapat membuat SPA juga dapat diakses (lihat misalnya stackoverflow.com/questions/15318661/… ). Demikian juga untuk SEO (jika SEO penting, yang akan tergantung pada aplikasi).

— sleske

2

Beberapa analogi Anda sedikit seperti orang yang tidak tahu apa-apa. Menonaktifkan Javascript memiliki tujuan keamanan; akan sulit untuk berargumen bahwa menambahkan lampu ke perawatan membuatnya kurang aman.

— Robert Harvey

1

Benar, menonaktifkan scripting memiliki manfaat keamanan. Tetapi bagi sebagian besar pengunjung, keamanan tambahan yang diberikan dengan membuat pilihan itu tidak sepadan. Tanpa scripting, Facebook menolak untuk bekerja, LinkedIn break, Pinterest break, Instagram memuat halaman kosong, dll. Jika pemain utama membutuhkannya, SPA Anda juga bisa.

— Collin Allen

Hanya mengetahui FB dan LinkedIn, tidak ada alasan bagus bagi situs-situs tersebut untuk istirahat tanpa JS kecuali untuk menenangkan para pengembang yang tidak ingin berupaya membuat situs web yang berfungsi dengan baik (atau untuk memaksa pengguna agar menerima praktik penelusuran yang kurang aman yang dapat menguntungkan garis bawah mereka). Jika mereka adalah aplikasi web lengkap seperti Plunker Anda mungkin ada benarnya, tetapi sebagian besar "aplikasi web" hanya "aplikasi" dalam arti bahwa mereka dibangun di atas semacam kerangka kerja. Dalam hal penggunaan, mereka hanyalah situs web dengan lebih banyak lonceng dan peluit dari yang pernah mereka miliki.

— Dissident Rage

6

SPA paling bermanfaat jika Anda membuat aplikasi yang tidak sesuai dengan model halaman permintaan / respons klasik. Ada tren baru-baru ini di mana situs web biasa ditulis sebagai SPA bahkan ketika mereka cocok dengan baik ke dalam siklus permintaan / respons web, IMHO apa yang mereka lakukan adalah upaya bodoh. Apa yang orang-orang suka dari situs web ini lakukan adalah penerapan kembali yang buruk browser web dengan lebih banyak bug dan lebih sedikit fitur.

Gagasan peningkatan progresif dan SPA tidak saling eksklusif untuk situs web aplikasi satu halaman bodoh ini. Anda hanya perlu javascript untuk melakukan beberapa negosiasi konten (mis. Terima tajuk) sehingga mereka menerima sumber daya JSON sehingga Javascript pada SPA dapat membuat dirinya sendiri alih-alih halaman HTML yang sudah dirender. Masalah dengan jenis situs web ini SPA jelas, Anda harus memiliki duplikat implementasi rendering situs web di kedua server dan pada klien.

Untuk aplikasi web sejati, yaitu yang benar-benar harus menjadi SPA karena tidak cocok dengan pola permintaan / respons standar; peningkatan progresif jauh lebih sulit untuk aplikasi sejati karena mereka benar-benar hanya menggunakan browser sebagai platform teknologi untuk menulis aplikasi dengan mudah. Bahasa scripting adalah bagian penting dari aplikasi web yang sebenarnya, bukan hanya bahasa yang secara opsional dapat dibaut untuk peningkatan. Beberapa teknik peningkatan progresif masih dapat bekerja (misalnya mengganti flash video / audio dengan <video>/ <audio>tag) tetapi aplikasi web sejati akan memerlukan javascript sebagai dasar.

— Lie Ryan
sumber

+1, tetapi tidak selalu mudah untuk memutuskan apakah sesuatu yang "benar-benar" membutuhkan SPA. Misalnya, aplikasi bisnis yang sebagian besar entri data, dengan berbagai kompleksitas dalam formulir. Jika sebagian besar formulir sederhana, SPA tidak "benar-benar" diperlukan, jadi masih ada ketegangan antara solusi SPA dan non-SPA.

— sinelaw

@sinelaw: Sebagian besar aplikasi bisnis umumnya tidak boleh SPA. Ada beberapa pengecualian, misalnya Spreadsheet, Word Processing, tetapi itu adalah yang aneh. Indikator bahwa Anda memerlukan SPA: jika Anda perlu mendorong data dari server ke klien, tidak hanya untuk satu atau dua pemberitahuan, tetapi sebagai elemen penting dari aplikasi, misalnya permainan, pelacakan stok, aplikasi obrolan; jika aplikasi Anda tidak memiliki konsep "Halaman" yang masuk akal atau konsep "Halaman" telah sepenuhnya diputarbalikkan dalam aplikasi, misalnya aplikasi Office. Aplikasi bisnis yang sebagian besar bekerja pada formulir yang lebih baik tetap sebagai non-SPA.

— Lie Ryan

Setuju. Indikator lain untuk SPA: jika mengembangkan SPA lebih murah daripada mengembangkan situs web "klasik". Aplikasi bisnis yang menargetkan pemirsa tertentu terkadang dapat memaksakan persyaratan seperti "menggunakan browser modern", sehingga peningkatan progresif hanya membawa sedikit manfaat.

— sinelaw

@sinelaw: Membangun SPA hampir tidak pernah lebih murah daripada mengembangkan situs multi-halaman; terutama jika Anda tidak menyediakan browser yang lebih lama.

— Lie Ryan

Jika tim Anda terdiri dari para ahli SPA dengan sedikit latar belakang dalam proyek-proyek server-sentris, itu akan lebih murah.

— sinelaw

2

Saya percaya aplikasi web satu halaman dan peningkatan progresif hampir merupakan antagonis. Jika html dihitung pada klien dari data yang diambil dari json api, itu hampir tidak dapat menurunkan anggun. Namun itu dapat menawarkan antarmuka pengguna yang lebih kaya dan lebih menyenangkan.

Anda dapat mengatur bot yang akan merayapi aplikasi Anda dan menyimpan versi statis. Teknik ini dapat digunakan untuk menyajikan HTML ke browser tanpa javascript (digunakan oleh orang buta atau bot mesin pencari). Ini adalah investasi, jadi itu benar-benar sesuai dengan kebutuhan Anda.

Apakah Anda membuat aplikasi web manajemen SDM untuk perusahaan tertentu? Anda tidak perlu degradasi anggun, dan SPA mungkin lebih mudah untuk dibangun. Perusahaan dapat memberlakukan penggunaan browser tertentu, sehingga Anda mungkin memiliki lebih sedikit tes untuk dilakukan.

Apakah Anda membuat situs web publik untuk asosiasi dengan persyaratan aksesibilitas dan kebutuhan visibilitas mesin pencari? Kemudian pertimbangkan untuk membangun HTML di server Anda. Atau membuat SPA dengan versi statis, tergantung pada anggaran Anda.

— Simon Bergot
sumber

1

Saya pikir itu tergantung seberapa jauh Anda ingin pergi dengan Progressive Enhancement - ini adalah paradigma desain daripada seperangkat aturan yang keras dan cepat.

Jika Anda menggunakan kerangka SPA, saya pikir mengizinkan Javascript diberikan. Namun Javascript yang Anda tulis untuk meningkatkan halaman Anda harus cukup pintar untuk berurusan dengan HTML apa pun yang bisa dibuat kerangka kerja.

Anda juga dapat memanfaatkan teknik PE lainnya seperti memanfaatkan fitur CSS terbaru untuk rilis browser terbaru, atau degradasi HTML5 ke HTML4.

— philicomus
sumber

1

Bagian dari peningkatan progresif adalah bahwa konten dasar harus tersedia tanpa javascript. Saya tidak yakin bagaimana menulis SPA tanpa javascript.

— Alan Shutko

@AlanShutko Mungkin dengan iframes. Beberapa halaman, tetapi secara teknis URL tidak berubah ...;)

— Izkata

1

Ya, saya kira saya lebih memikirkan HTML 5 vs HTML 4, dan hal-hal seperti CSS khusus peramban (mis. Anda mungkin ingin menggunakan fitur yang baru saja diterapkan yang hanya tersedia di versi terbaru Chrome tetapi yang lebih terdegradasi ke lebih kontrol primitif di browser lama). Melakukan tanpa javascript akan sulit di SPA, tapi itu hanya salah satu bagian dari konsep peningkatan progresif.

— philicomus

Peningkatan Progresif bisa sesederhana menggunakan CSS3 ketika tersedia untuk sudut pembulatan. Ide dasarnya tidak ada hubungannya dengan JavaScript.

— Daniel Little

1

Peningkatan progresif dan Aplikasi Halaman Tunggal dapat saling mengisi. Dua argumen paling menarik yang saya dengar untuk membuat aplikasi dengan cara ini adalah:

Toleransi kesalahan dalam situasi di mana file HTML mengunduh skrip penuh tetapi direferensikan gagal untuk mengunduh sepenuhnya berkat konektivitas jaringan yang masuk dan keluar (mungkin pada jaringan seluler)
Potensi untuk meningkatkan kinerja yang dirasakan pada pemuatan halaman awal (dengan mengurangi waktu Mulai Render)

Render sisi-server (ini untuk pengguna, bukan hanya alasan SEO) dan cutting-the-mustard adalah dua teknik yang dapat membantu membangun Aplikasi Halaman Tunggal yang ditingkatkan secara progresif dengan kerangka JS sisi klien modern.

Beberapa kerangka kerja JS sisi klien lebih mudah untuk bekerja dengan rendering sisi-server daripada yang lain ( berhati-hatilah beberapa solusi rendering sisi-server dan kombinasi kerangka kerja tidak menghasilkan SPA yang berfungsi karena halaman yang dirender server hanya ditujukan untuk konsumsi mesin pencari, bukan berakhir -pakai ).

Pada saat penulisan, React.js dan Ember (dengan FastBoot yang akan datang) adalah dua yang saya sadari telah atau sedang berusaha membuat rendering sisi server menjadi warga negara kelas satu; halaman yang diberikan sisi server masih berfungsi saat diuraikan pada browser klien.

— Eliot Sykes
sumber

0

Saya berpandangan bahwa pengurangan beban halaman mungkin cukup baik untuk server, dan jaringan. Saya ingin melihat lebih banyak SPA yang digunakan dengan benar.

Saya tidak mengerti bahwa ini membutuhkan dua hal:

1) mengatur semua tautan Anda sebagai tautan permintaan / respons standar pada pemuatan awal, biarkan SPA framework / library Anda lalu ganti dengan versi yang diperbarui (interaktif) setelah browser dimuat dan mesin JS mengidentifikasi bahwa dukungan SPA tersedia. Ini benar-benar peningkatan progresif; JS dimuat di atas situs web html yang ada, dan ini lebih baik untuk mesin pencari, teknologi bantu, dan browser yang lebih lama.

dan

2) Server harus responsif terhadap rute seperti / foo / bar / json dan foo / bar dengan menyajikan format yang benar; realistis jika Anda membungkus semuanya dalam tata letak dan parsial untuk mendapatkan halaman pertama, Anda harus bisa mendapatkan semuanya melalui tata letak dan parsial untuk halaman ke-2 dan selanjutnya juga.

Ada sedikit pekerjaan yang adil di sini; memang diakui, tetapi jika Anda memiliki kontrol atas tumpukan penuh itu tidak menyeimbangkan dua teknologi.

— Crispen Smith
sumber