Keluar dari Rabbit Hole SPA dengan Modern Rails

TL; DR: Jejak SPA gelap dan penuh kengerian. Anda dapat melawan mereka tanpa rasa takut ... atau memilih jalan lain yang akan membawa Anda ke tempat yang tepat: Rails modern.



Saya ingat berpikir bahwa Rails berfokus pada tujuan yang salah ketika DHH mengumumkan Turbolinks pada 2012. Kemudian saya yakin bahwa waktu respons instan selama interaksi pengguna adalah kunci menuju UX yang unggul. Karena keterlambatan jaringan, interaktivitas ini hanya dimungkinkan jika Anda meminimalkan ketergantungan jaringan dan, alih-alih panggilan jaringan, mempertahankan sebagian besar status klien.

Saya pikir itu perlu untuk aplikasi yang sedang saya kerjakan. Dan dengan pendapat itu, saya mencoba banyak pendekatan dan kerangka kerja untuk mengimplementasikan template yang sama: Aplikasi satu halaman (SPA). Saya percaya bahwa SPA adalah masa depan. Beberapa tahun kemudian, saya tidak yakin apa masa depan itu, tetapi saya pasti ingin mencari alternatif.

SPA lubang kelinci

Aplikasi satu halaman adalah aplikasi JavaScript yang, setelah diunduh, mendapat kontrol penuh tanpa harus memuat ulang halaman: rendering, menerima data dari server, memproses interaksi pengguna, memperbarui layar ...

Aplikasi tersebut terlihat lebih asli daripada halaman web tradisional, di mana aplikasi tergantung pada server. Misalnya, jika Anda menggunakan Trello, Anda mungkin memperhatikan seberapa cepat kartu dibuat.

Tentu saja, tanggung jawab besar datang dengan kekuatan besar. Dalam aplikasi web tradisional, aplikasi server Anda mencakup model domain dan aturan bisnis, teknologi akses data untuk bekerja dengan database, dan lapisan pengontrol untuk mengontrol bagaimana halaman-halaman HTML disusun sebagai tanggapan terhadap permintaan HTTP.

C SPA sedikit lebih rumit. Anda masih memerlukan aplikasi server yang mencakup model dan aturan domain Anda, server web, database, dan beberapa jenis teknologi akses data ... dan banyak hal tambahan di atas:

Untuk server:

• API yang memenuhi kebutuhan data pelanggan Anda
• Sistem serialisasi JSON untuk bertukar data dengan klien dan sistem caching yang mendukung ini

Untuk klien JavaScript baru:

• Sistem template untuk mengonversi data ke HTML
• Presentasi model dan aturan domain Anda
• Lapisan akses data dalam aplikasi klien untuk mentransfer data ke server
• Sistem untuk memperbarui tampilan ketika data berubah
• Sistem untuk menautkan URL dan layar (saya harap Anda tidak akan menggunakan satu alamat untuk semuanya, itu tidak terlihat seperti aplikasi web)
• Sistem untuk menempelkan semua komponen yang diperlukan untuk menampilkan layar dan mendapatkan data untuk ini
• Templat dan arsitektur baru untuk mengatur semuanya saat
• Sistem untuk penanganan kesalahan, pencatatan, pelacakan pengecualian, dll.
• Sistem untuk menghasilkan JSON untuk permintaan server
• Kerangka Pengujian Otomatis yang Mendukung SPA Anda
• Satu set tes tambahan untuk menulis dan mendukung
• Seperangkat alat tambahan untuk merakit, mengemas, dan menggunakan aplikasi baru

Singkatnya, dengan SPA Anda akan memiliki aplikasi lain untuk dukungan. Dan satu set masalah baru untuk dipecahkan. Dan perhatikan, Anda tidak dapat mengganti satu aplikasi dengan yang lain. Anda masih memerlukan aplikasi server (sekarang ini akan membuat JSON alih-alih HTML).

Jika Anda belum pernah bekerja dengan SPA, Anda dapat meremehkan kesulitan yang akan Anda hadapi. Saya tahu ini karena saya membuat kesalahan yang sama di masa lalu. Render JSON? Saya bisa mengatasinya. Model objek domain kaya dalam JavaScript? Kedengarannya lucu. Dan, Anda tahu, kerangka kerja ini akan menyelesaikan semua masalah ini. Kue yang luar biasa!

Salah

API dan pertukaran data.

Komunikasi antara aplikasi baru Anda dan server adalah masalah yang kompleks.

Ada dua kekuatan yang berlawanan:

• Anda akan ingin membuat permintaan server sesedikit mungkin untuk meningkatkan kinerja.
• Mengonversi catatan tunggal ke JSON itu sederhana. Tetapi mencampur model besar dari berbagai catatan untuk meminimalkan jumlah pertanyaan tidak sama sekali. Anda harus hati-hati mengembangkan logika serialisasi untuk mengoptimalkan jumlah kueri basis data dan mempertahankan kinerja di level tersebut.

Selain itu, Anda perlu memikirkan apa yang harus diunduh, dan kapan melakukannya untuk setiap layar mereka. Maksud saya, Anda memerlukan keseimbangan antara bootstrap, apa yang Anda butuhkan segera dan apa yang dapat dimuat dengan malas, dan kembangkan API yang memungkinkan Anda melakukan ini.

Beberapa standar dapat membantu di sini. API JSON untuk membakukan format JSON; atau GraphQL, untuk memilih hanya data yang diperlukan, serumit yang diperlukan, dalam satu permintaan. Tetapi tidak satu pun dari mereka yang akan menyelamatkan Anda dari:

• Elaborasi dari masing-masing pertukaran data
• Menerapkan kueri untuk memilih data secara efisien di server

Dan kedua aspek ini mewakili jumlah pekerjaan tambahan yang cukup.

Waktu boot

Orang-orang terbiasa mengasosiasikan SPA dengan kecepatan, tetapi kenyataannya adalah membuat mereka memuat dengan cepat tidaklah mudah. Ada banyak alasan untuk ini:

• Aplikasi membutuhkan data sebelum merender sesuatu, dan perlu waktu untuk menguraikan JavaScript dalam jumlah yang cukup besar.
• Di luar permintaan HTTP awal untuk mengunduh aplikasi, Anda biasanya perlu membuat satu atau lebih permintaan untuk mendapatkan data JSON yang diperlukan untuk membuat layar.
• Klien harus mengonversi JSON ke HTML untuk menunjukkan setidaknya sesuatu. Bergantung pada perangkat dan jumlah JSON yang akan dikonversi, ini dapat menyebabkan penundaan yang nyata.

Ini tidak berarti bahwa SPA tidak mungkin dapat dimuat dengan cepat. Saya hanya mengatakan bahwa itu sulit dan Anda harus mengatasinya, karena itu tidak akan sejalan dengan arsitektur SPA.

Misalnya, Discourse, SPA berbasis Ember, memiliki waktu muat yang fantastis, tetapi di antaranya, mereka memuat sejumlah besar data JSON sebagai bagian dari HTML awal sehingga tidak membuat permintaan tambahan. Dan saya perhatikan bahwa tim Wacana gila dalam kecepatan yang baik dan keterampilan mereka jauh di atas rata-rata. Pikirkan sebelum Anda dapat dengan mudah mereproduksi yang sama di SPA Anda.

Solusi ambisius untuk masalah ini adalah isomorfik JavaScript: merender halaman awal Anda di server dan dengan cepat memberikannya kepada klien, sementara di latar belakang SPA memuat dan mendapat kontrol penuh saat siap.

Pendekatan ini membutuhkan menjalankan runtime JavaScript di server, dan juga bukan tanpa masalah teknis. Misalnya, pengembang harus mempertimbangkan acara pemuatan SPA karena perubahan proses pemuatan.

Saya suka kesempatan untuk menggunakan kembali kode dalam ide ini, tetapi saya belum melihat implementasi yang akan memungkinkan saya untuk pergi ke arah yang berlawanan. Selain itu, proses rendering halaman ini terasa sangat lucu bagi saya:

- Server: permintaan ke server API
- Server: permintaan basis data
- Server: menghasilkan JSON
- Server: konversi JSON ke HTML
- Klien: tampilkan HTML awal
- Klien: unduh SPA
- Klien: parsing HTML awal dan berlangganan acara DOM

Bisakah Anda meminta data dari database, menghasilkan HTML dan mulai bekerja?

Ini tidak sepenuhnya adil, karena Anda tidak akan menjadi SPA dan karena sebagian besar sihir ini tersembunyi di balik kerangka kerja, tetapi menurut saya masih salah.

Arsitektur

Mengembangkan aplikasi dengan antarmuka pengguna yang kaya sulit. Ini semua karena ini adalah salah satu masalah yang mengilhami munculnya pendekatan berorientasi objek dan banyak pola desain.

Mengelola status klien sulit. Situs web tradisional biasanya fokus pada layar tanggung jawab tunggal yang kehilangan status ketika mereka reboot. Di SPA, aplikasi bertanggung jawab untuk memastikan bahwa semua pembaruan status dan layar selama penggunaan konsisten dan berjalan lancar.

Dalam praktiknya, jika Anda mulai menulis JavaScript dalam porsi kecil untuk meningkatkan interaksi, maka di SPA Anda harus menulis banyak kode JavaScript tambahan. Di sini Anda harus memastikan bahwa Anda melakukan semuanya dengan benar.

Ada banyak arsitektur berbeda seperti halnya kerangka SPA:

• Sebagian besar kerangka kerja berbeda dari template MVC tradisional. Ember awalnya terinspirasi oleh Cocoa MVC, tetapi mengubah model pemrogramannya cukup banyak di versi terbaru.
• Ada kecenderungan bahwa pengembang lebih suka komponen daripada pemisahan tradisional controller dan presentasi (beberapa kerangka kerja, seperti Ember dan Angular, telah pindah ke pendekatan ini dalam versi terbaru). Semua kerangka kerja menerapkan semacam pengikatan data satu arah. Ikatan dua sisi tidak disarankan karena efek samping yang mungkin ditimbulkannya.
• Sebagian besar kerangka kerja mencakup sistem perutean yang memungkinkan Anda memetakan URL dan layar, dan menentukan cara membuat instance komponen untuk dirender. Ini adalah pendekatan web unik yang tidak ada pada antarmuka desktop tradisional.
• Sebagian besar kerangka kerja memisahkan templat HTML dari kode JavaScript, tetapi React mencampur generasi HTML dan JavaScript dan melakukannya dengan cukup sukses, mengingat penggunaannya yang luas. Ada juga hype sekitar menanamkan CSS dalam JavaScript. Facebook, dengan arsitektur Flux-nya, telah cukup banyak memengaruhi industri, dan wadah seperti Redux, vuex, dll. Sangat dipengaruhi olehnya.

Dari semua kerangka yang saya lihat, Ember adalah favorit saya. Saya suka konsistensinya dan fakta bahwa dia agak keras kepala. Saya juga suka model pemrogramannya dalam versi terbaru, menggabungkan MVC tradisional, komponen, dan routing.

Di sisi lain, saya sangat menentang kamp Flux / Redux. Saya melihat begitu banyak orang pintar menggunakannya sehingga saya berusaha keras untuk belajar dan memahaminya, dan tidak sekali pun. Aku hanya bisa menggelengkan kepalaku frustrasi ketika aku melihat kode. Saya tidak melihat diri saya senang saat menulis kode seperti itu.

Akhirnya, saya tidak bisa tahan dengan campuran HTML dan CSS dalam komponen yang penuh dengan logika JavaScript. Saya mengerti masalah apa yang dipecahkan ini, tetapi masalah yang dibawa pendekatan ini tidak membuatnya sepadan.

Mari kita tinggalkan preferensi pribadi, intinya adalah jika Anda memilih jalur SPA, Anda akan memiliki masalah yang sangat sulit: untuk membuat arsitektur aplikasi baru Anda dengan benar. Dan industrinya cukup jauh dari menyetujui cara melakukan ini. Setiap tahun, kerangka kerja baru, templat, dan versi kerangka kerja muncul, yang sedikit mengubah model pemrograman. Anda perlu menulis dan memelihara satu ton kode berdasarkan pilihan arsitektur Anda, jadi pikirkan dengan benar.

Duplikasi kode

Saat bekerja dengan SPA, Anda mungkin akan mengalami duplikasi kode.

Untuk logika SPA Anda, Anda ingin membuat model kaya objek yang mewakili area domain dan logika bisnis Anda. Dan Anda masih membutuhkan hal yang sama untuk logika server. Dan ini masalah waktu sebelum Anda mulai menyalin kode.

Misalnya, Anda bekerja dengan faktur. Anda mungkin memiliki kelas Faktur dalam JavaScript yang berisi metode total yang merangkum harga semua elemen sehingga Anda dapat merender nilainya. Di server, Anda juga akan memerlukan kelas Faktur dengan metode total untuk menghitung biaya ini untuk mengirimnya melalui email. Kamu lihat? Klien Faktur dan kelas server menerapkan logika yang sama. Duplikasi kode.

Seperti yang dikatakan di atas, JavaScript isomorfik dapat mengurangi masalah ini, membuatnya lebih mudah untuk menggunakan kembali kode. Dan saya katakan ke level, karena korespondensi antara klien dan server tidak selalu 1-ke-1. Anda akan ingin memastikan bahwa beberapa kode tidak pernah meninggalkan server. Sejumlah besar kode masuk akal hanya untuk klien. Dan juga, beberapa aspek sangat berbeda (misalnya, elemen server dapat menyimpan data dalam database, dan klien dapat menggunakan API jarak jauh). Menggunakan kembali kode, bahkan jika mungkin, adalah masalah yang kompleks.

Anda dapat bertaruh bahwa Anda tidak memerlukan model kaya di SPA Anda dan bahwa Anda akan bekerja dengan objek JSON / JavaScript secara langsung, mendistribusikan logika di seluruh komponen UI. Sekarang Anda memiliki duplikasi kode yang sama dicampur dengan kode UI Anda, semoga berhasil.

Dan hal yang sama terjadi jika Anda ingin template untuk rendering HTML antara server dan klien. Misalnya, untuk SEO, bagaimana dengan menghasilkan halaman di server untuk mesin pencari? Anda harus menulis ulang template Anda di server dan memastikan bahwa mereka disinkronkan dengan klien. Sekali lagi duplikasi kode.

Kebutuhan untuk mereproduksi logika pola pada server dan klien, dalam pengalaman saya, adalah sumber kemalangan yang tumbuh dari programmer. Untuk melakukan ini sekali adalah normal. Ketika Anda melakukan ini untuk yang ke-20 kalinya, Anda akan memegangi kepala Anda. Setelah melakukan ini untuk yang ke-50 kalinya, Anda akan memikirkan apakah semua SPA ini diperlukan.

Kerapuhan

Dalam pengalaman saya, mengembangkan SPA yang baik adalah tugas yang jauh lebih rumit daripada menulis aplikasi web dengan generasi server.

Pertama, tidak peduli seberapa hati Anda Anda, tidak peduli berapa banyak tes yang Anda tulis. Semakin banyak kode yang Anda tulis, semakin banyak bug yang Anda miliki. Dan SPA mewakili (maaf, jika saya mendorong keras) setumpuk besar kode untuk menulis dan mendukung.

Kedua, seperti yang disebutkan di atas, mengembangkan GUI yang kaya adalah rumit dan diterjemahkan ke dalam sistem yang kompleks yang terdiri dari banyak elemen yang saling berinteraksi. Semakin kompleks sistem yang Anda buat, semakin banyak bug yang Anda miliki. Dan dibandingkan dengan aplikasi web tradisional menggunakan MVC, kompleksitas SPA hanya gila.

Misalnya, untuk menjaga konsistensi pada server, Anda dapat menggunakan batasan dalam database, validasi model, dan transaksi. Jika terjadi kesalahan, Anda merespons dengan pesan kesalahan. Di klien, semuanya sedikit lebih rumit. Begitu banyak yang bisa salah karena terlalu banyak yang terjadi. Mungkin sebagian catatan berhasil disimpan, dan sebagian lainnya tidak. Mungkin Anda offline di tengah semacam operasi. Anda harus memastikan bahwa UI tetap konsisten dan aplikasi pulih dari kesalahan. Semua ini mungkin, tentu saja, hanya jauh lebih rumit.

Tantangan Organisasi

Kedengarannya konyol, tetapi untuk mengembangkan SPA, Anda membutuhkan pengembang yang tahu apa yang harus dilakukan dengannya. Pada saat yang sama, Anda tidak boleh meremehkan kompleksitas SPA, Anda tidak boleh berpikir bahwa setiap pengembang web berpengalaman dengan motivasi dan pemahaman yang tepat dapat menulis SPA yang bagus dari awal. Anda membutuhkan keterampilan dan pengalaman yang tepat, atau mengharapkan kesalahan penting dibuat. Saya tahu ini karena ini adalah kasus saya.

Ini mungkin tantangan yang lebih penting bagi perusahaan Anda daripada yang Anda kira. Pendekatan SPA mendorong tim yang sangat terspesialisasi daripada tim dari generalis:

• Kerangka kerja SPA adalah perangkat lunak yang kompleks yang membutuhkan banyak jam pengalaman untuk menjadi produktif. Hanya orang-orang di perusahaan Anda yang menghabiskan waktu berjam-jam pada kode ini yang dapat mendukung aplikasi ini.
• Kerangka SPA membutuhkan API yang dipikirkan secara matang dan produktif. Memenuhi persyaratan ini membutuhkan serangkaian keterampilan yang sama sekali berbeda dari yang membutuhkan kerja dengan SPA.

Kemungkinannya adalah Anda akan menemukan diri Anda dengan orang-orang yang tidak dapat bekerja dengan SPA, dan yang tidak dapat bekerja di sisi server, hanya karena mereka tidak tahu caranya.

Spesialisasi ini mungkin ideal untuk Facebook atau Google dan tim mereka yang terdiri dari beberapa lapis pasukan teknik. Tetapi apakah itu baik untuk tim Anda yang terdiri dari 6 orang?

Rel modern

Ada 3 hal yang masuk ke Rails modern yang dapat mengubah pikiran Anda tentang pengembangan aplikasi web modern:

• salah satunya adalah Turbolinks dan ini adalah ledakan otak
• yang lain adalah teman lama yang diabaikan hari ini: tanggapan SJR dan permintaan rendering AJAX sederhana
• dan yang terakhir ditambahkan baru-baru ini: Stimulus

Sulit untuk memahami apa itu untuk menerapkan pendekatan apa pun tanpa bermain dengannya. Oleh karena itu, saya akan membuat beberapa referensi ke Basecamp di bagian berikut. Saya tidak ada hubungannya dengan Basecamp, kecuali sebagai pengguna yang bahagia. Adapun artikel ini, ini hanyalah contoh langsung dari Rails modern yang dapat Anda coba secara gratis.

Turbolinks

Gagasan di balik Turbolinks sederhana: percepat aplikasi Anda dengan sepenuhnya mengganti halaman yang memuat ulang dengan permintaan AJAX yang menggantikan elemen ``. Sihir batin yang melakukan pekerjaan ini tersembunyi. Sebagai pengembang, Anda dapat fokus pada pemrograman sisi server tradisional.

Turbolinks terinspirasi oleh pjax dan melalui beberapa revisi.

Dulu saya khawatir tentang kinerjanya. Saya salah. Akselerasinya sangat besar. Yang meyakinkan saya adalah bagaimana saya menggunakannya dalam proyek, tetapi Anda bisa mencoba versi percobaan di Basecamp dan bermain dengannya. Coba buat proyek dengan beberapa elemen, lalu navigasikan dengan mengklik bagian. Ini akan memberi Anda ide yang baik tentang seperti apa Turbolinks.

Saya tidak berpikir bahwa Turbolinks sangat luar biasa dengan kebaruannya (pjax - 8 tahun). Atau kecanggihan teknisnya. Ini mengherankan saya bagaimana ide sederhana dapat meningkatkan produktivitas Anda dengan urutan besar dibandingkan dengan alternatif untuk SPA.

Izinkan saya menyoroti beberapa masalah yang diperbaiki:

• Pertukaran data. Anda tidak memilikinya. Tidak perlu membuat serial JSON, membuat API, atau memikirkan permintaan data yang memuaskan kebutuhan pelanggan dalam hal kinerja.
• Beban awal. Tidak seperti SPA, pendekatan ini merangsang waktu pemuatan cepat (sesuai desain). Untuk merender layar, Anda bisa mendapatkan data yang Anda butuhkan langsung dari database. HTML — .
• : JavaScript-. , SPA.

MVC di server, dalam versi yang digunakan oleh Rails dan banyak kerangka kerja lainnya, jauh lebih sederhana daripada templat yang digunakan untuk arsitektur GUI yang kaya: dapatkan permintaan, bekerja dengan database untuk memuaskannya, dan tampilkan halaman HTML sebagai jawaban.

Akhirnya, batasan yang selalu diganti memiliki efek yang luar biasa: Anda dapat fokus pada rendering awal halaman alih-alih memperbarui bagian tertentu (atau memperbarui beberapa kondisi di dunia SPA). Dalam kasus umum, dia hanya melakukan segalanya.

• Duplikasi kode. Hanya ada satu tampilan aplikasi Anda yang hidup di server. Model domain Anda, aturannya, layar aplikasi, dll. Tidak perlu menduplikasi konsep dalam klien.
• . SPA, JavaScript , . , , , .

Perhatikan bahwa saya tidak berbicara tentang masalah penamaan, tetapi tentang memperbaikinya. Sebagai contoh, GraphQL atau SPA rehydration adalah solusi super pintar untuk masalah yang sangat kompleks. Tetapi bagaimana jika, alih-alih mencoba mencari solusi, Anda menempatkan diri Anda dalam situasi di mana masalah ini tidak ada? Ini adalah perubahan dalam pendekatan untuk masalah tersebut. Dan saya butuh bertahun-tahun untuk sepenuhnya menghargai kemampuan pendekatan ini untuk menyelesaikan masalah.

Tentu saja, Turbolinks bukanlah peluru perak yang bebas gangguan. Masalah terbesar adalah ia dapat merusak kode JavaScript yang ada:

• Turbolinks dikirimkan dengan acara "pemuatan halaman" khusus, dan plugin yang ada yang mengandalkan pemuatan halaman biasa tidak akan berfungsi. Saat ini ada cara yang lebih baik untuk menambahkan perilaku ke DOM, tetapi widget lawas tidak akan berfungsi jika tidak diadaptasi.
• Kode JavaScript yang memodifikasi DOM harus idempoten karena dapat dijalankan beberapa kali. Sekali lagi, ini membatalkan banyak JavaScript yang ada.
• Kecepatannya luar biasa, tetapi tidak seperti di SPA, yang dapat menangani beberapa interaksi tanpa memuat server. Saya akan berbicara lebih banyak tentang kompromi nanti.

Render AJAX dan jawaban SJR

Ingat ketika merender HTML melalui Ajax menjadi tren 15 tahun yang lalu? Coba tebak? Ini masih merupakan alat yang hebat di gudang senjata Anda:

• HTML DOM, ( 100 ).
• HTML , .

Anda dapat melihat bagaimana pendekatan ini dirasakan di Basecamp dengan membuka menu profil Anda dengan mengklik tombol kanan atas:



Membuka secara instan. Dari sisi pengembangan, Anda tidak perlu khawatir tentang serialisasi JSON dan sisi klien. Anda cukup menampilkan fragmen ini di server, menggunakan semua fitur Rails.

Alat serupa yang Rails sertakan selama bertahun-tahun adalah tanggapan JavaScript sisi-server (SJR). Mereka memungkinkan Anda untuk menanggapi permintaan Ajax (biasanya formulir pengiriman) dengan JavaScript yang dijalankan oleh klien. Ini memberikan keuntungan yang sama seperti rendering AJAX dari potongan HTML: ini berjalan sangat cepat, Anda dapat menggunakan kembali kode di sisi server, dan Anda dapat langsung mengakses database untuk membuat respons.

Anda dapat melihat bagaimana ini terjadi jika Anda masuk ke Basecamp dan mencoba membuat todo baru. Setelah Anda mengklik "Tambahkan todo", server akan menyimpan todo dan merespons dengan fragmen JavaScript yang menambahkan todo baru ke DOM.

Saya pikir banyak pengembang hari ini melihat rendering AJAX dan tanggapan SJR dengan jijik. Saya juga ingat itu. Mereka adalah alat dan, dengan demikian, dapat disalahgunakan. Tetapi ketika digunakan dengan benar, ini adalah solusi hebat. Memungkinkan Anda menawarkan UX yang hebat dan interaktivitas dengan harga yang sangat rendah. Sayangnya, seperti Turbolinks, mereka sulit untuk dievaluasi jika Anda belum melawan SPA.

Stimulus

Stimulus adalah kerangka kerja JavaScript yang diterbitkan beberapa bulan lalu. Itu tidak peduli tentang rendering atau manajemen negara berbasis JavaScript. Alih-alih, itu hanya cara modern yang bagus untuk mengatur JavaScript, yang Anda gunakan untuk menambahkan HTML:

• Ini menggunakan MutationObserver untuk mengikat perilaku ke DOM, yang berarti tidak peduli bagaimana HTML muncul di halaman. Tentu saja, ini sangat bagus untuk Turbolinks.
• Ini akan menghemat satu ton kode boilerplate untuk melampirkan perilaku ke DOM, untuk melampirkan penangan acara ke acara, dan untuk menempatkan elemen dalam wadah yang ditentukan.
• Ini bertujuan untuk membuat kode HTML Anda mudah dibaca dan dimengerti, yang bagus jika Anda pernah menemui masalah dalam mencari tahu bagian mana dari JavaScript yang bekerja pada elemen sialan ini.
• Ini mendorong kegigihan dalam DOM. Sekali lagi, ini berarti bahwa dia tidak peduli bagaimana HTML dihasilkan, yang cocok untuk banyak skenario, termasuk Turbolinks.

Jika Anda menerima jalur Rails, JavaScript Anda akan fokus pada memodifikasi kode HTML sisi-server dan meningkatkan interaksi (dengan sedikit JavaScript). Stimulus dirancang untuk mengatur kode tersebut. Ini bukan sistem SPA dan tidak berpura-pura menjadi satu.

Saya menggunakan Stimulus di beberapa proyek, dan saya sangat menyukainya. Ini menghilangkan banyak kode boilerplate, itu dibangun di atas standar web terbaru dan membaca dengan sangat indah. Dan sesuatu yang sangat saya sukai: sekarang ini adalah cara standar untuk melakukan sesuatu yang masih harus diselesaikan di setiap aplikasi.

Game kompromi

Turbolinks biasanya dijual sebagai "Dapatkan semua manfaat SPA tanpa ketidaknyamanan." Saya tidak berpikir ini sepenuhnya benar:

• Aplikasi yang dibangun menggunakan Rails modern terlihat cepat, tetapi SPA masih akan merespon lebih cepat untuk interaksi yang tidak tergantung server.
• Ada beberapa skenario di mana SPA lebih masuk akal. Jika Anda perlu menawarkan tingkat interaktivitas yang tinggi, Anda perlu mengelola sejumlah besar negara, menjalankan logika kompleks di sisi klien, dll. Kerangka SPA akan membuat hidup Anda lebih mudah.

Sekarang pengembangan adalah permainan kompromi. Dan dalam game ini:

• Modern Rails memungkinkan Anda membuat aplikasi yang cukup cepat dan tampak hebat.
• Untuk berbagai macam aplikasi, Rails memungkinkan Anda untuk mengimplementasikan fungsi yang sama dengan kode yang lebih sedikit dan kompleksitas yang lebih sedikit.

Saya percaya bahwa dengan Rails Anda bisa mendapatkan 90% dari penawaran SPA dengan usaha 10%. Dalam hal kinerja, Rails membunuh SPA. Adapun UX, saya pikir banyak pengembang membuat kesalahan yang sama seperti saya, dengan asumsi bahwa SPA UX tidak tertandingi. Ini tidak benar. Bahkan, seperti dibahas di atas, Anda lebih tahu apa yang Anda lakukan saat membuat SPA Anda, atau UX sebenarnya akan lebih buruk.

Kesimpulan

Saya menonton perusahaan secara besar-besaran menerima kerangka SPA dan melihat banyak artikel tentang cara melakukan hal-hal mewah bergaya SPA. Saya pikir ada banyak "penggunaan alat yang salah untuk pekerjaan itu," karena saya sangat percaya bahwa jenis aplikasi yang membenarkan penggunaan SPA terbatas.

Dan saya katakan mereka membenarkannya karena SPA itu kompleks. Bagaimanapun, saya harap saya meyakinkan Anda tentang ini. Saya tidak mengatakan bahwa tidak mungkin untuk membuat aplikasi SPA yang hebat, atau bahwa aplikasi Rails modern sangat bagus secara definisi, hanya satu pendekatan yang sangat rumit dan yang lainnya jauh lebih sederhana.

Saat mempersiapkan artikel ini, saya menemukan tweet ini:



Itu membuat saya tertawa karena saya akan memilih opsi pertama jika alternatifnya tidak dibenarkan. Dia juga merupakan perwakilan dari jenis pemikiran pengembang yang menyukai kompleksitas dan berkembang pesat, bahkan sampai berpikir bahwa orang lain dengan kriteria berbeda gila.

Setelah bertahun-tahun, saya menyadari bahwa kompleksitas sering menjadi pilihan. Tetapi dalam dunia pemrograman, sangat sulit untuk memilih kesederhanaan. Kami sangat menghargai kompleksitas sehingga menerima kesederhanaan sering membuat kami berpikir secara berbeda, yang menurut definisi sulit.

Ingatlah bahwa Anda dapat menyingkirkan masalah. Jika Anda memilih jalur SPA, pastikan itu dibenarkan dan Anda memahami masalahnya. Jika Anda tidak yakin, bereksperimenlah dengan berbagai pendekatan dan lihat sendiri. Mungkin Facebook atau Google, dalam skala mereka, tidak memiliki kemewahan membuat keputusan seperti itu, tetapi Anda mungkin bisa.

Dan jika Anda adalah pengembang Rails yang meninggalkan Rails bertahun-tahun yang lalu, saya sarankan Anda kembali ke sana. Saya pikir Anda akan senang.