Ember.js atau Backbone.js untuk backend Restful [ditutup]

Saya sudah tahu bahwa ember.js adalah pendekatan yang lebih berat dibandingkan dengan backbone.js. Saya membaca banyak artikel tentang keduanya.

Saya bertanya pada diri sendiri, kerangka mana yang bekerja lebih mudah sebagai frontend untuk backend sandaran rel. Untuk backbone.js saya melihat pendekatan berbeda untuk memanggil backend istirahat. Untuk bara sepertinya saya harus memasukkan beberapa perpustakaan seperti 'data' atau 'sumber daya'. Mengapa ada dua perpustakaan untuk ini?

Jadi, apa pilihan yang lebih baik? Tidak banyak contoh untuk menghubungkan frontend dengan backend juga. Apa contoh kerja yang baik untuk panggilan istirahat backend untuk ini:

URI: ../restapi/topics DAPATKAN kredensial autentikasi: admin / format yang benar: json

— Robin Wieruch
sumber

Harus menyukai pertanyaan yang "tidak konstruktif" namun jawaban yang membantu dan dipikirkan dengan baik masih mendapat 240+ suara positif.

— Andrew

Jawaban:

257

Bertentangan dengan pendapat populer Ember.js bukanlah 'pendekatan yang lebih berat' untuk Backbone.js. Mereka adalah jenis alat berbeda yang menargetkan produk akhir yang sangat berbeda. Sweet spot Ember adalah aplikasi di mana pengguna akan membuat aplikasi tetap terbuka untuk jangka waktu yang lama, mungkin sepanjang hari, dan interaksi dengan tampilan aplikasi atau data yang mendasarinya memicu perubahan mendalam dalam hierarki tampilan. Ember lebih besar dari Backbone, tetapi berkat Expires, Cache-Controlini hanya penting pada beban pertama. Setelah dua hari penggunaan harian, 30k ekstra akan dibayangi oleh transfer data, lebih cepat jika konten Anda melibatkan gambar.

Backbone ideal untuk aplikasi dengan sejumlah kecil status dengan hierarki tampilan tetap relatif datar dan pengguna cenderung jarang mengakses aplikasi atau untuk periode waktu yang lebih singkat. Kode Backbone akan tetap pendek dan manis karena membuat asumsi bahwa data yang mendukung DOM akan dibuang dan kedua item akan dikumpulkan dengan memori: https://github.com/documentcloud/backbone/issues/231#issuecomment-4452400 Ukuran tulang punggung yang lebih kecil juga membuatnya lebih cocok untuk interaksi singkat.

Aplikasi yang ditulis orang di kedua kerangka kerja mencerminkan penggunaan berikut: Aplikasi Ember.js menyertakan dasbor web Square , Zendesk (setidaknya antarmuka agen / tiket), dan penjadwal Groupon : semua aplikasi yang mungkin digunakan pengguna sepanjang hari untuk bekerja.

Aplikasi backbone lebih fokus pada interaksi singkat atau santai, yang seringkali hanya merupakan bagian kecil dari halaman statis yang lebih besar: airbnb , Khan Academy , peta dan daftar Foursquare .

Anda dapat menggunakan Backbone untuk membuat jenis aplikasi yang ditargetkan Ember (misalnya Rdio ) dengan a) meningkatkan jumlah kode aplikasi yang menjadi tanggung jawab Anda untuk menghindari masalah seperti kebocoran memori atau peristiwa zombie (saya pribadi tidak merekomendasikan pendekatan ini) atau b) dengan menambahkan pustaka pihak ketiga seperti backbone.marionette atau Coccyx - ada banyak dari pustaka ini yang semuanya mencoba menyediakan fungsionalitas tumpang tindih yang serupa dan Anda mungkin akhirnya akan merakit kerangka khusus Anda sendiri yang lebih besar dan membutuhkan lebih banyak kode perekat daripada jika Anda baru saja menggunakan Ember.

Pada akhirnya, pertanyaan tentang "yang akan digunakan" memiliki dua jawaban.

Pertama, "Yang harus saya gunakan, secara umum, dalam karier saya": Keduanya, sama seperti Anda pada akhirnya akan mempelajari alat apa pun yang spesifik untuk pekerjaan yang ingin Anda lakukan di masa depan. Anda tidak akan pernah bertanya "Backbone atau D3?"; "Backbone atau Ember" adalah pertanyaan yang sama konyolnya.

Kedua, "Yang harus saya gunakan, khususnya, pada proyek saya berikutnya": Tergantung pada proyeknya. Keduanya akan berkomunikasi dengan server Rails dengan kemudahan yang sama. Jika proyek Anda berikutnya melibatkan campuran halaman yang dihasilkan oleh server dengan apa yang disebut "pulau kekayaan" yang disediakan oleh JavaScript, gunakan Backbone. Jika proyek Anda berikutnya mendorong semua interaksi ke dalam lingkungan browser, gunakan Ember.

— Trek Glowacki
sumber

Tanggapan yang bagus, Trek. Hanya ingin berkomentar di sini Expiresdan Cache-Controlmembantu jauh lebih sedikit daripada yang dipikirkan orang — terutama dalam hal perangkat seluler yang sering mengabaikannya. Saya ingat versi iOS mengabaikan mereka sepenuhnya (tetapi masih mendengarkan manifes cache HTML5). Selain itu, nilai header ini tidak akan membantu selama kunjungan pertama dari pengguna — yang biasanya paling penting dalam memutuskan apakah pengguna akan tetap tinggal dan menggunakan aplikasi Anda. Mengatakan semua perbedaan file 30kb itu sepertinya bukan masalah besar bagi saya. Apakah itu perbedaan 30k mentah atau diperkecil dan di-gzip?

— Mauvis Ledford

Jika Anda melihat aplikasi sebenarnya yang gaya Ember dimaksudkan untuk membantu membuat, Anda akan menemukan tidak ada jalan keluar dari kbs sial itu. Entah berasal dari Ember dan kode aplikasi Anda lebih kecil, atau berasal dari plugin backbone, atau berasal dari kode yang Anda tulis sendiri. Wunderlist , yang menurut Anda akan menjadi "sederhana" dengan kecepatan transfer sekitar 300kb. Saya membayangkan ukurannya akan sama dengan Ember, mungkin lebih kecil - karena tidak pernah menulis salinan persis Wunderlist, saya tidak dapat mengatakannya dengan kepastian 100%.

— Trek Glowacki

Saya setuju, aplikasi tulang punggung saya yang paling populer beroperasi pada 178kb + templat yang dikompresi dan diperkecil. Hanya menunjukkan bagaimana kita seharusnya tidak bergantung pada cache browser.

— Mauvis Ledford

Trek, Anda tepat dengan analisis Anda tentang penggunaan Backbone di aplikasi dengan pola penggunaan yang diperpanjang, dan manajemen status yang kompleks. Saya mengalami pengalaman mengonversi aplikasi lama ke Backbone dan harus melakukan persis seperti yang Anda daftarkan. Kami perlu mengintegrasikan Marionette serta menulis banyak kode perekat untuk hal-hal seperti pemfilteran rute pra / pasca, mitigasi kebocoran memori, dan manajemen acara yang lebih baik.

— Mike Clymer

"Anda tidak akan pernah bertanya pada Backbone atau D3" - tentu saja, tetapi saya dapat dengan mudah membayangkan sebuah proyek di mana saya akan menggunakan D3 bersama dengan Backbone. Mungkin jauh lebih sulit untuk membayangkan proyek di mana Backbone dan Ember digunakan bersama dalam satu halaman. Jadi, menurut saya pertanyaan "Backbone atau Ember" cukup adil. Berikut posting lain yang saya temukan cukup informatif, karena membandingkan dua kerangka kerja lebih dalam: net.tutsplus.com/tutorials/javascript-ajax/…

— Shiprack

Untuk memberikan jawaban yang singkat dan sederhana: untuk backend yang tenang, saat ini, Anda harus menggunakan Backbone.

Untuk memberikan jawaban yang lebih kompleks: Itu sangat tergantung pada apa yang Anda lakukan. Seperti yang dikatakan orang lain, Ember dirancang untuk hal yang berbeda, dan akan menarik bagi orang yang berbeda. Jawaban singkat saya didasarkan pada dimasukkannya persyaratan RESTful Anda.

Saat ini, Ember-Data (yang tampaknya merupakan mekanisme persistensi default dalam Ember) masih jauh dari siap produksi. Artinya, ia memiliki beberapa bug dan, yang terpenting, tidak mendukung URI bersarang (misalnya, / posts / 2 / comments / 4556). Jika REST adalah kebutuhan Anda, maka Anda harus mengatasinya untuk saat ini jika Anda memilih Ember (yaitu Anda harus meretasnya, tunggu, terapkan sesuatu seperti Ember-Data dari awal sendiri, atau gunakan tidak URI yang sangat tenang). Ember-Data tidak sepenuhnya menjadi bagian dari Ember, jadi ini sepenuhnya mungkin.

Perbedaan utama antara keduanya, selain ukuran, pada dasarnya adalah:

Ember mencoba melakukan sebanyak mungkin untuk Anda, sehingga Anda tidak perlu menulis banyak kode. Ini sangat hierarkis dan, jika aplikasi Anda juga sangat hierarkis, kemungkinan besar akan sesuai. Karena begitu banyak manfaatnya bagi Anda, mungkin sulit untuk mengetahui dari mana bug berasal dan alasan mengapa perilaku tak terduga terjadi (ada banyak "keajaiban"). Jika Anda memiliki aplikasi yang secara alami cocok dengan jenis aplikasi yang Ember harapkan untuk Anda buat, ini mungkin tidak akan menjadi masalah.

Backbone mencoba melakukan sesedikit mungkin untuk Anda sehingga Anda dapat bernalar tentang apa yang sedang terjadi dan membangun arsitektur yang sesuai dengan aplikasi Anda (daripada membangun aplikasi yang sesuai dengan arsitektur kerangka yang Anda gunakan). Jauh lebih mudah untuk memulainya tetapi, kecuali Anda berhati-hati, Anda bisa berakhir dengan sangat cepat. Itu tidak melakukan hal-hal seperti properti yang dihitung, acara pelepasan otomatis, dll dan menyerahkannya kepada Anda, jadi Anda perlu menerapkan banyak hal sendiri (atau setidaknya memilih pustaka yang melakukannya untuk Anda), meskipun itu bukan intinya.

Pembaruan : Tampaknya, baru-baru ini, Ember sekarang mendukung URI bersarang, jadi saya kira pertanyaannya adalah seberapa banyak keajaiban yang Anda sukai dan apakah Ember cocok secara arsitektural, untuk aplikasi Anda.

— bengillies
sumber

"yang terpenting, tidak mendukung URI bersarang (/ posts / 2 / comments / 4556 misalnya)" Berikut adalah komit yang relevan dari beberapa minggu yang lalu: github.com/emberjs/data/commit/… . Kami tahu bahwa mungkin sulit untuk mengikuti kerangka kerja pra-rilis yang bergerak cepat, tetapi kita harus selalu menargetkan keakuratan saat berbicara dengan otoritas dan menawarkan saran!

— Trek Glowacki

Keren Terimakasih. Memperbarui jawaban saya. Saya kira yang diperkenalkan dalam penggabungan hubungan besar minggu lalu atau lebih. Saya telah melihat dan membaca perubahan yang terdaftar tetapi tidak dapat menemukan url yang disebutkan dan masalah yang saya lacak masih terbuka ketika saya memeriksanya. Terima kasih telah menunjukkan komit - mungkin sulit ditemukan tanpa mengetahui keberadaannya.

— bengillies

Ini memang dari penggabungan cabang peningkatan hubungan baru-baru ini. Kami perlahan-lahan menindaklanjuti masalah lama dan menutupnya minggu ini.

— Trek Glowacki

Saya pikir pertanyaan Anda akan segera diblokir :) Ada beberapa perselisihan antara kedua kerangka kerja tersebut.

Pada dasarnya Backbone tidak melakukan banyak hal, dan itulah mengapa saya menyukainya: Anda harus banyak membuat kode, tetapi Anda akan membuat kode di tempat yang tepat. Ember melakukan banyak hal, jadi sebaiknya Anda perhatikan apa yang dilakukannya.

Diskusi server adalah salah satu dari sedikit hal yang dilakukan Backbone, dan berfungsi dengan baik. Jadi saya akan mulai dengan Backbone dan kemudian mencoba Ember jika Anda tidak benar-benar puas.

Anda juga dapat mendengarkan podcast ini di mana Jeremy Ashkenas, pencipta Backbone, dan Yehuda Katz, anggota Ember, berdiskusi dengan baik.

— Nicolas Zozol
sumber

Terima kasih. Apa yang dapat Anda katakan tentang ekstensi rets dari ember. Lebih baik gunakan data atau sumber daya? Bisakah Anda memberikan contoh sederhana dari panggilan istirahat api?

— Robin Wieruch

Jawaban singkatnya adalah bahwa perpustakaan bervariasi sepanjang waktu dan saya tidak dapat memberi Anda tanggapan berdasarkan pengalaman saya sebelumnya (saya melakukannya sendiri untuk evaluasi). Saya pikir posting ini akan memberi tahu Anda lebih dari yang saya bisa: stackoverflow.com/questions/8623091/ember-js-rest-api

— Nicolas Zozol

Saya sudah melihat postingan ini. Itu sebabnya saya bertanya :)

— Robin Wieruch

@NicolasZozol podcast yang mana? tautan ?

— deepak

javascriptjabber.com/004-jsj-backbone-js-with-jeremy-ashkenas sejak bulan Februari lalu. Ini sebelum menjadi lebih jelas bahwa kerangka kerja ini tidak benar-benar ada di arena yang tumpang tindih. Anda dapat mendengar Yehuda dan Jeremy berbicara melewati satu sama lain, tidak benar-benar melakukan perbandingan.

— Trek Glowacki