Pendekatan Dev untuk UI JavaScript kompleks [ditutup]

Saya mencoba memahami lanskap berbagai pendekatan, dan praktik terbaik, seputar pengembangan JavaScript sisi-klien yang kompleks.

Saya tidak yakin apa yang memberi label pada kelas aplikasi ini, mungkin AJAX atau RIA yang berat (tetapi bukan plugin seperti Flash / Silverlight). Saya merujuk ke aplikasi web dengan karakteristik ini:

• Meniru UX desktop kaya / asli dalam JavaScript
• Berisi sebagian besar / semua perilaku di JS sisi klien, menggunakan server sebagai data-API (JSON / Html-Templates).

Ini berbeda dengan menggunakan server web untuk rendering UI, menghasilkan semua HTML dalam model refresh halaman.

Beberapa contoh adalah:

• Google Documents / Gmail
• Mindmeister
• Pelacak Penting

Saat kami bergerak maju ke HTML5, saya bisa melihat gaya pengembangan RIA ini, dengan JavaScript yang berat, menjadi semakin umum dan perlu untuk bersaing.

PERTANYAAN: Jadi apa pendekatan umum yang muncul di sekitar mengelola jenis pengembangan JS berat ini?

Kode sisi klien, ketika aplikasi tumbuh dalam fitur, sangat rumit. Ada masalah penskalaan upaya pengembangan lintas beberapa tim dengan JS mentah (atau begitulah yang saya dengar, dan bisa dipercaya).

Google telah mendekati masalah dengan membangun GWT yang mengkompilasi dari bahasa tingkat yang lebih tinggi (Jawa) ke JS, bersandar pada infrastruktur pembangunan yang ada yang dimiliki oleh bahasa tingkat yang lebih tinggi (Eclipse, pengetikan yang kuat, alat refactoring), bersama dengan mengabstraksi kompatibilitas browser dan masalah lain yang jauh dari pengembang.

Ada alat lain, seperti Skrip # untuk C # yang melakukan hal serupa. Semua ini menempatkan JS lebih banyak dalam peran IL (Bahasa Antara). yaitu. "Kamu tidak pernah benar-benar menulis dalam 'bahasa tingkat rendah' ​​itu lagi."

Tapi ini 'kompilasi ke JS' bukan satu-satunya pendekatan. Tidak jelas bahwa GWT adalah pendekatan yang dominan ... atau memang akan menjadi seperti itu.

Apa yang dilakukan orang dengan JavaScript klien kaya? Beberapa pertanyaan yang berorientasi:

• Apakah sebagian besar toko membuat JS secara manual (di atas lib seperti jQuery et al)?
• Atau ada banyak pendekatan berbeda, tanpa praktik terbaik yang jelas muncul?
• Apakah sebagian besar toko menghindari pengembangan skala RIA yang mendukung model server-side / redraw page yang lebih sederhana untuk dikembangkan? Jika demikian, apakah ini akan bertahan?
• Apakah mengkompilasi ke JS mungkin merupakan tren masa depan yang muncul? Atau apakah ini salah arah?
• Bagaimana mereka mengelola kompleksitas dan refactoring JS klien?
• Modularisasi dan distribusi pekerjaan lintas tim?
• Aplikasi, penegakan, dan pengujian pola sisi klien seperti MVC / MVP dll.

Jadi, apa tren yang muncul di masa depan JavaScript-berat dan HTML5 kita ini?

Terima kasih!

Sebagian besar aplikasi Web yang saya lihat (dan pengembang Web yang saya ajak bicara) yang bergerak ke arah ini menggunakan jQuery sebagai basisnya.

Seluruh alasan di balik GWT (dan bahasa multi-level yang serupa) adalah bahwa JavaScript terlalu flakey / terlalu rapuh / terlalu dapat diubah untuk digunakan oleh "programmer nyata". Tetapi jika Anda memiliki kerangka kerja yang menangani bit flakey / rapuh / dapat diubah untuk Anda, maka tidak ada alasan untuk menambahkan lapisan kompleksitas tambahan.

Hanya pendapat saya ...

Saya akan mengatakan GWT berisiko. Setelah Anda memutuskan untuk menggunakannya, Anda terjebak dengannya. Pada dasarnya itu berarti Anda memperlakukan markup Anda, DOM dan beberapa aspek CSS sebagai lingkungan eksekusi. Semakin sulit untuk mencampur JavaScript yang ditulis secara manual dengan GWT karena kode klien Anda menjadi semakin canggih. GWT memiliki metode asli tetapi cukup terbatas dalam hal kemungkinan penerapan. Itu adalah trade off besar dan ini taruhan besar.

Google mencoba menjual GWT sebagai lingkungan eksekusi platform-X yang sangat cepat dengan integrasi sisi server yang layak. Tapi seperti yang sudah ditunjukkan orang lain, masalahnya tidak lagi - JQuery dan YUI sama cepatnya jika tidak lebih cepat. Dan jauh lebih mudah untuk membuat profil dan mengoptimalkan halaman Anda ketika mereka dirakit secara manual sehingga Anda memiliki kontrol penuh atas CSS, markup dan JavaScript.

GWT mencoba menyembunyikan platform yang mendasarinya dari Anda yang mungkin sebenarnya merupakan cara yang salah untuk melakukan sesuatu. Banyak kerangka kerja komponen web melakukan hal yang sama. Anda seharusnya menulis kode turunan XML yang ambigu dengan EL dan tag khusus yang dimasukkan. Hasilnya akan menjadi kekacauan HTML yang buruk bentuknya dengan potongan-potongan kecil JavaScript jelek yang ditaburkan di semua tempat. Halaman-halamannya lambat, bermasalah, dan sama sekali tidak dapat dipelihara.

Dalam proyek kami saat ini, kami menggunakan Stripes - kerangka kerja berbasis aksi tingkat rendah, - dan JQuery di sisi klien. Sangat mudah untuk melakukan Ajax setelah Anda melihat dengan jelas semua bagian teka-teki: inilah kode sisi-Server Anda yang beroperasi pada data. Inilah kode sisi klien Anda - untuk pengambilan data dan untuk membuat segala sesuatu terjadi pada suatu halaman. Inilah CSS Anda, inilah markup Anda, inilah templating Anda - semuanya bersih dan terpisah. Mudah diperluas, dapat diretas, dapat disetel, dan dapat disangkal. Aku menyukainya.

Saya suka JQuery dengan sikapnya terhadap kecepatan dan kesederhanaan. Saya suka YUI3 untuk modularitas dan widget komprehensif. Saya suka YUI CSS karena memberi saya konsistensi di seluruh browser. Saya suka JavaScript untuk Bagian Bagus. Saya suka Java karena membiarkan saya Selesaikan Pekerjaan.

KISS saja, dan kamu akan baik-baik saja!

Saya telah mendengar ini disebut "Aplikasi satu halaman".

Ini adalah lingkungan baru, dan aturannya belum sepenuhnya ditulis. Saya bekerja pada aplikasi satu halaman yang relatif besar tahun lalu (2010), dan ini adalah alat yang kami gunakan.

Bagian belakangnya adalah Java, menggunakan servlets untuk menyediakan layanan JSON, yang digunakan pada akhirnya untuk mengirimkan pesanan yang sudah disiapkan. Layanan ini juga digunakan untuk beberapa langkah validasi, dan penetapan harga.

Kode front-end adalah javascript. Kami menggunakan jQuery untuk melakukan manipulasi elemen halaman, Murni untuk templating, dan RequireJs untuk memecah kode menjadi modul. (Tool build RequireJs digunakan untuk memberikan unduhan yang lebih optimal.)

Kami menulis tes kami menggunakan qUnit , dan memiliki tes jUnit yang menggunakan htmlunit untuk menjalankan setiap tes qUnit, lalu mengikis output untuk hasil, dan lulus atau gagal berdasarkan status lulus / gagal qUnit. Itu ditambahkan ke tes jUnit kami untuk bagian belakang, dan digulung ke ci kami, menggunakan Hudson / Jenkins .

Saya bekerja pada aplikasi seperti itu, dibangun di atas Ext JS. Aplikasi ini diatur secara modular. Modul yang berbeda diimplementasikan sebagai komponen mandiri yang membersihkan setelah mereka sendiri ketika mereka dihapus dari hierarki komponen Ext. On-demand loader memuat komponen tambahan tepat sebelum dibutuhkan (satu file js = satu komponen).

Saya menemukan bahwa pendekatan ini tidak terlalu sulit untuk diukur. Satu-satunya batasan nyata yang saya temui terkait dengan memiliki terlalu banyak elemen DOM di pohon pada saat yang sama di IE. Solusinya ada untuk secara strategis membongkar bagian-bagian tersembunyi dari aplikasi. Karena semua manipulasi DOM terjadi melalui hierarki komponen Ext, DOM hampir sepenuhnya diabstraksi, dan pengembangannya tetap mudah.

Secara pribadi saya pikir kerangka kerja seperti jQuery sangat penting tidak hanya untuk berurusan dengan variasi di berbagai browser tetapi juga untuk menghilangkan perbedaan-perbedaan itu sehingga mereka tidak menambahkan suara ke kode. Alat-alat seperti GWT, Websharper , dan lainnya mengambil langkah lebih jauh dan pasti memiliki tempat tetapi saya bertanya-tanya apakah itu hanya lapisan tambahan tipuan dalam banyak kasus.

Sesuatu yang saya terkejut bahwa tidak ada yang disebutkan adalah pengujian unit. Sekarang diterima secara umum bahwa aplikasi sisi server yang kompleks harus memiliki tes unit otomatis dan saya pikir sudah saatnya JS di aplikasi RIA cukup kompleks untuk memerlukan pengujian unit - bersama dengan arsitektur / kode yang memungkinkan.

Namun, tidak seperti dengan aplikasi sisi server yang kompleks, firasat saya berdasarkan pada apa yang saya lihat dan dengar adalah bahwa sebagian besar aplikasi sisi klien yang kompleks sama sekali tidak memiliki pengujian unit (Saya tidak berbicara tentang pengujian selenium di sini, pengujian unit nyata).

Saya pikir tren yang akan muncul berikutnya adalah pengenalan unit testing (dan kode yang bisa diuji unit). Baru saja menyelesaikan proyek dengan jumlah moderat JavaScript non-unit yang diuji, saya berharap ini akan menjadi yang terakhir.