Apakah ide yang baik untuk melakukan UI 100% dalam Javascript dan menyediakan data melalui API?

19

Pekerjaan utama saya hari ini adalah membuat aplikasi HTML. Maksud saya secara internal menggunakan aplikasi tipe CRUD dengan banyak tampilan kotak yang dapat diedit, kotak teks, dropdown, dll. Kami saat ini menggunakan formulir web ASP.NET, yang menyelesaikan pekerjaan, tetapi kinerjanya sebagian besar suram, dan cukup sering Anda harus melompat melalui lingkaran untuk mendapatkan apa yang Anda butuhkan. Lingkaran yang digantung di langit-langit dan menyala.

Jadi saya bertanya-tanya apakah itu mungkin ide yang baik untuk memindahkan semua UI ke sisi JavaScript. Kembangkan serangkaian kontrol yang dapat digunakan kembali yang kuat yang dirancang khusus untuk kebutuhan kita, dan hanya pertukaran data dengan server. Ya, saya suka paradigma "kontrol" (alias "widget"), cukup cocok untuk aplikasi semacam itu. Jadi di sisi server kita masih memiliki tata letak dasar yang mirip dengan markup ASPX kita saat ini, tetapi itu kemudian akan dikirim ke klien hanya sekali, dan bagian Javascript akan mengurus semua pembaruan UI berikutnya.

Masalahnya adalah saya belum pernah melakukan ini sebelumnya, dan saya belum pernah melihat orang melakukan hal ini, jadi saya tidak tahu apa masalahnya. Secara khusus, saya khawatir tentang:

Kinerja masih. Benchmarking menunjukkan bahwa saat ini penundaan utama ada di sisi klien, ketika browser mencoba merender ulang sebagian besar halaman setelah pembaruan AJAX. Bentuk web yang dihasilkan ASP.NET markup memberikan arti baru pada kata "web", dan kontrol Devexpress yang kaya menambahkan lapisan kompleksitas Javascript mereka sendiri di atas itu. Tetapi apakah akan lebih cepat untuk menghitung ulang semua perubahan yang diperlukan di sisi Javascript dan kemudian memperbarui hanya apa yang perlu diperbarui? Perhatikan bahwa saya sedang berbicara tentang formulir yang memiliki beberapa tampilan kotak yang dapat diedit, banyak kotak teks, banyak dropdown masing-masing dengan setengah juta item yang dapat disaring di dalamnya, dll.
Kemudahan pengembangan . Akan ada lebih banyak Javascript sekarang, dan mungkin akan bercampur dengan markup HTML halaman. Itu atau semacam mesin pandangan baru harus diproduksi. Intellisense untuk Javascript juga jauh lebih buruk daripada kode C #, dan karena sifat dinamis Javascript tidak dapat diharapkan untuk mendapatkan jauh lebih baik. Praktik pengkodean dapat memperbaikinya sedikit, tetapi tidak banyak. Selain itu, sebagian besar pengembang kami terutama pengembang C # sehingga akan ada beberapa kurva pembelajaran dan kesalahan awal.
Keamanan . Banyak pemeriksaan keamanan harus dilakukan dua kali (sisi server dan sisi UI), dan sisi server pemrosesan data harus memasukkan lebih banyak lagi. Saat ini, jika Anda mengatur kotak teks agar hanya-baca di sisi server, Anda dapat bergantung pada nilainya yang tidak berubah melalui pulang-pergi klien. Kerangka kerja ini sudah memiliki cukup kode untuk memastikannya (melalui enkripsi kondisi tampilan). Dengan pendekatan hanya data, semakin sulit, karena Anda harus memeriksa semuanya secara manual. Di sisi lain, mungkin lubang keamanan akan lebih mudah dikenali, karena Anda hanya akan memiliki data yang perlu dikhawatirkan.

Secara keseluruhan, apakah ini akan menyelesaikan masalah kita, atau memperburuknya? Adakah yang pernah mencoba ini, dan apa hasilnya? Apakah ada kerangka kerja di luar sana yang membantu dalam upaya semacam ini (selain jQuery dan persamaan moral)?

— Vilx-
sumber

So on the server side we would still have a basic layout simliar to our current ASPX markup, but that then would get sent to the client only once, and the Javascript part would take care of all the subsequent UI updates.

Anda gambarkan persis apa ASP.NET adalah, yang memberitahu saya bahwa Anda mungkin tidak menggunakannya dengan benar. :) Dalam aplikasi ASP.NET Anda jika Anda menempatkan komponen di dalam panel pembaruan maka perpustakaan javascript ASP.NET akan melakukan postback asinkron ke sisi server dan hanya merender ulang komponen yang Anda tentukan.

— maple_shaft

@maple_shaft - Saya tahu, tapi entah bagaimana ini berfungsi lambat sekali. Juga, grid sudah melakukan panggilan balik. Untuk yang lainnya, jika ada postback, dalam sebagian besar kasus Anda harus menyegarkan sebagian besar halaman, karena kontrol mengubah visibilitas / kemampuan menulis / dll. Dan itu lambat.

— Vilx-

3

Setiap kali saya melihat aplikasi ASP.NET di mana seseorang meletakkan segala sesuatu di halaman dalam panel Pembaruan, saya merasa seperti melempar monitor saya ke dinding>. <! Ini mengalahkan hampir seluruh tujuan ASP.NET. Untuk mempertahankan siklus hidup sisi server dan acara aplikasi, penting baginya untuk berkomunikasi bolak-balik dengan seluruh kondisi tampilan halaman. Jika Anda memiliki 200 kontrol dan kisi data maka Joel Spolsky tidak akan dapat memprediksi bahwa Anda akan memiliki masalah kinerja yang sangat besar. Ed Woodcock dan AmmoQ meringkas semuanya dengan sempurna sehingga saya tidak perlu memberikan jawaban tambahan.

— maple_shaft

1

@maple_shaft - Maaf, tapi saya benar-benar membuat profil tentang hal ini. Itu lambat pada komputer pengembang lokal juga, dan Fiddler dengan jelas menunjukkan bahwa koneksi HTTP dibuka kurang dari sedetik, sementara halaman hanya muncul beberapa detik kemudian, dan sementara itu browser menggunakan CPU sebanyak mungkin dapatkan dan pada dasarnya beku. Itu bukan kondisi tampilan yang kembung, itu HTML / Javascript yang kembung.

— Vilx-

1

@ Vilx- tidak ada yang salah dengan C # /. NET (Terlepas dari windows saja / biaya). Ada masalah besar dengan mengasapi yang menempatkan kerangka ASP.NET WebForms di atasnya. Seperti yang disebutkan coba Nancy jika Anda suka .NET. Tapi ini benar-benar di luar topik, itu hanya komentar bahwa Anda akan lebih baik jika Anda berhenti menggunakan

— formulir web

10

Linkedin melakukan ini untuk situs seluler mereka (lihat http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-10-performance-tips-linkedin-mobile bagian 4), dan tampaknya sangat bermanfaat bagi mereka dari sudut pandang kinerja.

Namun, saya sarankan Anda menghindari melakukan hal yang sama, karena berbagai alasan.

Yang pertama adalah perawatan: C # / ASP.net adalah, karena itu menjadi kerangka sisi server, klien-independen, sedangkan Javascript tidak (bahkan dengan kerangka kerja seperti jQuery Anda tidak akan mendapatkan kompatibilitas lintas-browser 100% (bukan pembuktian di masa depan). Saya akan mengatakan itu juga lebih mudah untuk memverifikasi fungsionalitas aplikasi yang diketik secara statis daripada yang dinamis, yang merupakan sesuatu yang Anda harus benar-benar pertimbangkan jika Anda sedang membangun situs skala besar.

Yang kedua adalah Anda akan kesulitan menemukan orang lain yang mampu (dan mau) membangun aplikasi javascript murni dari jenis kompleksitas yang diperlukan untuk menjalankan seluruh situs web Anda (dibandingkan dengan relatif mudahnya menemukan. Programmer NET). Ini mungkin bukan urusan Anda secara langsung, tetapi tentu saja itu adalah sesuatu untuk dipikirkan dari perspektif jangka panjang.

Masalah ketiga adalah kompatibilitas klien; jika Anda membuat situs web yang menghadap publik, maka ingatlah bahwa sebagian dari jaringan masih belum mengaktifkan JS (karena berbagai alasan), jadi Anda harus benar-benar yakin bahwa Anda tidak akan mengecualikan sebagian besar basis pengguna Anda dengan beralih ke situs web berbasis JS.

Adapun kekhawatiran Anda:

Saya tidak akan terlalu khawatir tentang aspek keamanan, tidak ada alasan mengapa Anda tidak dapat mencampuradukkan paradigma dan melakukan beberapa pemrosesan sisi server ketika Anda membutuhkan keamanan (Anda akan memiliki beberapa kode rendering tampilan di sana di suatu tempat yang mengembalikan HTML , tidak ada alasan Anda tidak dapat mematikan panggilan AJAX saja, jika diperlukan).
Kemudahan pengembangan tidak terlalu menjadi perhatian juga, menurut saya, ada alat yang sangat bagus untuk pengembangan JS, jangan hanya memasukkan diri Anda ke dalam VisualStudio karena Anda sudah terbiasa! (coba JetBrains WebStorm, misalnya).
Performa mesin tampilan JS benar-benar baik dalam kebanyakan kasus (sekali lagi, dalam pengalaman saya), saya sangat menggunakannya setiap hari. Apa yang saya sarankan adalah menghindari kerangka kerja kelas berat seperti knockout.js dll., Dan pergi untuk sesuatu seperti mesin template mikro Jon Resig. Dengan cara ini Anda dapat mencolokkan kode pendukung dengan cara yang Anda yakini cepat dan andal.

Apa yang akan saya lakukan, jika saya adalah Anda, adalah benar-benar memeriksa alasan di balik peralihan ini; Mungkin saja Anda tidak memanfaatkan .NET secara efektif dan perlu meningkatkan permainan Anda, WebForms bukanlah kerangka kerja yang lambat, jadi mungkin beberapa perpustakaan pihak ke-3 yang Anda gunakan memperlambat rendering Anda.

Coba lakukan profil kinerja aplikasi menggunakan uji beban dan alat profiling, dan lihat di mana kemacetan Anda sebelum Anda tenggelam dalam jumlah besar waktu dan upaya menjadi solusi yang lebih radikal, Anda mungkin akan terkejut dengan apa yang Anda temukan sebagai pelakunya karena kelambatanmu!

— Ed James
sumber

Tidak, karena saya sudah mengomentari jawaban Darknights, ini adalah aplikasi internal, dengan tidak ada (well, little) bagian yang menghadap publik, jadi ketergantungan JavaScript adalah OK. Dan saya sudah melakukan profiling. Sisi servernya bagus. Sisi klienlah yang berada di bawah HTML yang dihasilkan secara besar-besaran (seperti yang saya katakan, markup yang dihasilkan ASP.NET suram) dan Devexpress Javascript.

— Vilx-

1

@EdWoodcock situs web ASP.NET pada dasarnya didorong oleh Javascript. Ini adalah cara menangani komunikasi asinkron dari kondisi tampilan dan rendering halaman.

— maple_shaft

@ Vilx- Ini mungkin mengejutkan, tetapi kontrol seperti Data Grid sangat rumit. Mungkin Anda hanya memiliki terlalu banyak elemen dalam satu halaman?

— maple_shaft

@ Vilx- Mungkin sekarang saatnya untuk melihat penggunaan kontrol Anda, jika mereka menghasilkan markup gila (kontrol asp.net default tidak dalam kebanyakan kasus jika Anda menggunakan hal-hal seperti Repeater alih-alih DataGrids dll.) Maka mungkin Anda harus memutar kontrol Anda sendiri (atau pindah ke HTML tulisan tangan di UserControls sebagai gantinya).

— Ed James

1

@maple_shaft - Atau, lebih spesifik lagi Flex, yang (seperti yang saya mengerti) dibangun di atas Flash untuk tujuan yang persis seperti itu. Itu ide lain yang sudah saya mainkan selama beberapa waktu. Tapi ... sebanyak yang saya coba sebutkan ini kepada orang lain, saya hanya menerima tanggapan negatif, jadi saya tidak bisa membayangkan menyelesaikan ini. Kita semua juga harus mempelajari sesuatu yang sama sekali baru.

— Vilx-

8

Gunakan ExtJS jika Anda ingin pergi ke sana, jangan menemukan kembali kemudi. Tetapi bersiaplah, ini berarti perubahan paradigma yang lengkap. Keterampilan HTML Anda hampir usang. AJAX di mana-mana, server sebagian besar menyediakan API AJAX. Anda akan menulis lebih banyak javascript dari sebelumnya, jadi lebih baik pastikan Anda benar-benar cocok dengan javascript.

— pengguna281377
sumber

1

Saya sangat nyaman dengan Javascript. Saya tahu beberapa orang lain tidak.

— Vilx-

2

Saya melakukan itu selama beberapa tahun di pekerjaan sebelumnya. ExtJS sangat bagus dan Anda dapat melakukan banyak hal dengannya.

— Zachary K

@ZacharyK - Bagaimana kinerjanya pada formulir yang sangat rumit? Yang seperti saya tulis di sana, dengan beberapa tampilan grid, panel, dll?

— Vilx-

2

Cukup baik. Anda perlu memikirkan model data Anda tentu saja. Sejujurnya saya mencoba menghindari bentuk besar, dan menyusun beberapa elemen yang lebih kecil. Tapi itu tidak ada hubungannya dengan batas-batas ExtJS maka desain yang baik, dll

— Zachary K

@ ZakaryK - Terlalu malas untuk mengulangi diri saya sendiri. Baca komentar saya pada jawaban Ed Woodcock. Saya tidak bisa membuatnya lebih sederhana. :(

— Vilx-

8

Tim saya memutuskan untuk bermigrasi ke ExtJS akhir 2008. Kami pada saat itu memiliki aplikasi PHP 200.000 baris yang menderita masalah front-end. Situasi kami jauh lebih buruk daripada Anda, karena kami memiliki kerangka kontrol bentuk formulir handrolled yang benar-benar buruk, dan kami menggunakan banyak iframe untuk memuat bagian halaman (arsitektur visual tanggal kembali ke 2005, dan tim tidak sadar dari ajax sejak awal). Kami tetap harus memperbaiki kode, jadi ini membuatnya lebih mudah untuk memutuskan untuk menyusun ulang basis kode menjadi terutama sisi klien.

Saat ini aplikasinya adalah 300.000 baris, di mana 60.000 baris adalah kode extjs, dan sekitar 3/4 dari fungsinya telah dimigrasikan ke ExtJS. Kode extjs adalah semua aplikasi satu halaman, tetapi masih menyematkan beberapa bentuk lama di dalam iframe. Kami porting di atas wadah navigasi terlebih dahulu, dan kemudian memigrasi sebagian area fitur sedikit demi sedikit. Dengan pendekatan ini kami berhasil menyelaraskan migrasi extjs ke proses dev fitur reguler, tanpa memperlambat kami terlalu banyak.

Performa

Kode ExtJS terbukti jauh lebih cepat daripada kode sebelumnya. Kode lama itu tentu saja sangat buruk dari segi kinerja, tetapi meskipun demikian kami senang dengan hasilnya. Kode UI adalah semua javascript statis, jadi cache dengan sangat baik (kita sedang dalam tahap perencanaan melemparkannya ke CDN). Server tidak terlibat dalam rendering front-end, yang mengurangi beban kerja di sana. Ini juga membantu bahwa ExtJS menyediakan banyak kontrol atas siklus hidup UI (rendering malas, bongkar mudah elemen UI yang tidak terlihat). Biasanya sekali kode di-bootstrap (arsitektur pemuatan berdasarkan permintaan), sebagian besar waktu pemuatan layar dihabiskan dalam panggilan layanan web untuk mengambil data. Kotak ExtJS sangat cepat, terutama ketika menggunakan tampilan buffered untuk merender baris yang terlihat pada gulir.
Kemudahan pengembangan

Sejujurnya, ini adalah tas campuran. ExtJS adalah DSL, sebenarnya bukan pengembangan web dalam arti tradisional. Butuh waktu lama bagi pengembang kami untuk benar-benar mempelajari API framework, dan saya tidak melihat kurva ini kurang curam pada framework sisi klien lainnya. Semua orang di tim harus menjadi pengembang javascript "senior" (sebagai aturan praktis, buku crockford tidak boleh menyimpan rahasia). Kami menderita masalah bootstrap dengan pengembang baru, karena keahlian sisi klien tidak seluas yang Anda pikirkan, dan keahlian tenaga kerja hampir nihil (di Belgia, tempat kami berada).

Di sisi lain, begitu kecepatan Anda meningkat, pengalaman dev sangat menyenangkan. ExtJS sangat kuat, jadi jika Anda berada di groove Anda dapat menyiapkan layar yang luar biasa dengan sangat cepat. Dari segi IDE kami menggunakan PHPStorm, yang menurut saya cukup kompeten dengan kode ExtJS.
Keamanan

Keamanan adalah salah satu alasan utama untuk melakukan UI sisi klien. Alasannya sederhana: serangan pengurangan permukaan. API layanan web yang digunakan oleh kode ExtJS kami adalah permukaan serangan yang jauh lebih kecil daripada lapisan UI sisi-server. ASVS OWASP menentukan bahwa Anda harus memvalidasi semua input pada server untuk kebenaran sebelum menggunakannya. Dalam arsitektur layanan web, jelas dan mudah kapan dan bagaimana melakukan validasi input. Saya juga merasa lebih mudah untuk alasan tentang keamanan dalam arsitektur UI sisi klien. Kami masih berjuang dengan masalah XSS, karena Anda tidak dibebaskan dari penyandian ke HTML, tetapi secara keseluruhan kami jauh lebih baik tentang keamanan daripada kami berada di basis kode lama. ExtJS memudahkan untuk melakukan validasi sisi-server dari bidang formulir, jadi kami tidak banyak menderita karena harus menulis kode dua kali.

— Joeri Sebrechts
sumber

Saya berharap bisa melakukan lebih dari sekedar +1 karena pengalaman Anda yang sebenarnya!

— Vilx-

4

Jika Anda mampu untuk tidak mendukung pengguna tanpa naskah, dan mesin pencari tidak mempedulikan Anda, maka ya, itu adalah pendekatan yang sangat layak. Berikut ini ikhtisar singkat pro dan kontra:

Pro:

semuanya di satu tempat (javascript)
Anda dapat memuat data dari server, bukan markup, yang dapat menghemat banyak bandwidth jika dilakukan dengan benar
lebih mudah untuk mendapatkan aplikasi yang responsif (latensi jaringan masih ada, tetapi respons awal terhadap input pengguna lebih cepat)
server web tidak perlu membuat HTML apa pun atau memperluas templat apa pun (mis., upaya pemrosesan dipindahkan dari server ke klien)

Cons:

semuanya harus dalam javascript (mungkin atau mungkin tidak menjadi masalah)
logika kritis perlu diduplikasi di server
negara perlu dipertahankan pada klien dan server, dan disinkronkan antara keduanya
keamanan bisa lebih sulit untuk diperbaiki (mengingat bagaimana segala sesuatu dalam kode sisi klien dapat dimanipulasi oleh pengguna jahat)
Anda mengekspos sebagian besar basis kode Anda (kode yang berjalan di server tidak dapat dilihat dari luar)

Secara pribadi, saya pikir jika Anda memilih rute ini, ASP.NET UpdatePanels bukan jalan yang benar. Mereka bagus untuk sebagian aplikasi web yang ada, tetapi mereka masih mengirim HTML melalui AJAX, dan mengelola keadaan dengan cara ini bisa sangat berbulu. Lebih baik Anda melakukannya, hanya menyajikan dokumen HTML statis, dan kemudian menggunakan perpustakaan template javascript untuk melakukan rendering HTML; server tidak melayani HTML dinamis sama sekali, sebaliknya, klien membuat panggilan tingkat logika bisnis ke server dan menerima data mentah.

— tammmer
sumber

1

Ya, Anda bisa tetapi ..

Anda perlu memastikan Anda memiliki "degradasi" yang anggun sehingga bagian-bagian penting dari aplikasi Anda akan tetap berfungsi tanpa Javascript.

Ini adalah cara saya membangun sebagian besar aplikasi "HIJAX" style.

— Malam gelap
sumber

Aplikasi sudah javascript-berat dan tidak berfungsi tanpanya. Klien kami baik-baik saja dengan itu dan tidak pernah mengeluh. Dan, jujur saja, saya belum menemukan pengguna yang menonaktifkan Javascript hari ini dan usia. Perhatikan juga bahwa aplikasi ini TIDAK memerlukan SEO apa pun (itu akan menjadi bencana jika mesin pencari dapat mengakses semua informasi sensitif itu), dan TIDAK dimaksudkan untuk digunakan dari perangkat seluler. Kami juga berpikir untuk membuat sesuatu yang serupa untuk perangkat seluler, tapi itu baru dalam tahap konsep untuk saat ini, dan kami bahkan tidak tahu apakah akan ada permintaan.

— Vilx-

2

"Dan, jujur saja, aku belum menemukan pengguna yang menonaktifkan Javascript hari ini dan usia." Baiklah halo. Saya telah menginstal noscript sehingga default untuk saya adalah menonaktifkan javascript saat mendarat di situs web baru. Dan jika tidak ada yang berhasil saya biasanya hanya menutup tab situs web.

— Arkh

3

@Arkh Anda berpikir seperti seorang programmer bukan pengguna, kami memperhitungkan minoritas kecil dalam skema besar. Tidak bisakah mengubah ini menjadi "ke js atau tidak ke js?" karena sudah dilakukan sampai mati di sekitar bagian ini :)

— Darknight

1

Orang-orang yang menonaktifkan JS biasanya sangat menyadari bahwa dengan melakukan hal itu mereka dapat menemukan situs yang mengandalkannya dan dengan demikian tidak akan berfungsi. Apakah mereka ingin mengaktifkannya untuk situs tertentu adalah pilihan mereka, tetapi jika mereka sengaja menonaktifkan teknologi standar saya tidak keberatan jika mereka tidak dapat menelusuri situs. Di sisi lain, saya tidak tahu tentang dukungan JS untuk pembaca layar. Itu mungkin masalah yang lebih besar. Dan tentu saja ada masalah pengindeksan. Tetapi ketika seseorang ingin membuat aplikasi yang tidak memerlukan pengindeksan dan tidak akan dapat digunakan oleh orang buta, masuk akal untuk mengandalkan JS.

— Andrea

1

maple_shaft Aku menyukaimu, jadi aku akan mengatakannya dengan baik, jangan lari ke jalan itu :) terima kasih!

— Darknight

1

Situs saya masih dalam masa pertumbuhan tetapi sejauh ini 100% js ui baik-baik saja bagi saya. Satu-satunya logika server yang ada di ujung depan adalah pemetaan model dan url ajax. Server tidak memiliki pengetahuan tentang ui sama sekali, yang bagi saya sangat mudah untuk dipelihara. Jika Anda tertarik, Anda dapat checkout situs saya yang ditulis dalam ExtJS http://coffeedig.com/coffee/ . Situs saya tidak benar-benar memiliki masalah keamanan tetapi klien membantu pengguna normal dengan validasi sederhana. Saya tahu bahwa pengguna jahat dapat benar-benar mengirim ajax ke server sehingga semua logika "keamanan" dilakukan di server.

Saya pikir masalah terbesar bagi Anda adalah bahwa Anda akan melakukan pembalikan lengkap dari apa yang digunakan tim Anda, akan ada kurva pembelajaran yang curam. Saya pikir pendekatan terbaik adalah dengan bereksperimen dengan beberapa kerangka kerja js dan mencoba untuk merasakannya dengan menulis beberapa layar sederhana.

— pamit
sumber