Apa kerugian utama dari Java Server Faces 2.0?

Kemarin saya melihat presentasi di Java Server Faces 2.0 yang terlihat sangat mengesankan, meskipun saat ini saya adalah pengembang ASP.NET MVC / jQuery yang bahagia. Yang paling saya sukai tentang JSF adalah sejumlah besar komponen UI AJAX-Enabled yang tampaknya membuat pengembangan lebih cepat daripada dengan ASP.NET MVC, terutama di situs-situs berat AJAX. Pengujian integrasi terlihat sangat bagus juga.

Karena presentasi hanya menekankan keunggulan JSF, saya ingin mendengar tentang pihak lain juga.

Jadi pertanyaan saya adalah:

• Apa kerugian utama dari Java Server Faces 2.0?
• Apa yang membuat pengembang JSF mempertimbangkan untuk menggunakan ASP.NET MVC daripada JSF?

Kerugian JSF 2.0? Jujur, terlepas dari kurva pembelajaran yang relatif curam ketika Anda tidak memiliki latar belakang pengetahuan yang kuat tentang Pengembangan Web dasar (HTML / CSS / JS, sisi server versus sisi klien, dll) dan Java Servlet API dasar (permintaan / respons / sesi , penerusan / pengalihan, dll), tidak ada kerugian serius yang terlintas dalam pikiran. JSF dalam rilisnya saat ini masih perlu menyingkirkan citra negatif yang diperolehnya sejak usia dini, di mana ada beberapa kelemahan serius.

JSF 1.0 (Maret 2004)

Ini adalah rilis awal. Itu berantakan dengan bug di kedua inti dan bidang kinerja yang Anda tidak ingin tahu. Aplikasi web Anda tidak selalu berfungsi seperti yang Anda harapkan secara intuitif. Anda sebagai pengembang akan lari menangis.

JSF 1.1 (Mei 2004)

Ini adalah rilis bugfix. Performa itu masih belum banyak membaik. Ada juga satu kelemahan utama: Anda tidak bisa inline HTML di halaman JSF dengan sempurna. Semua plain vanilla HTML get diberikan sebelum pohon komponen JSF. Anda perlu membungkus semua vanilla polos dalam <f:verbatim>tag sehingga mereka bisa dimasukkan dalam pohon komponen JSF. Meskipun ini sesuai spesifikasi, ini telah menerima banyak kritik. Lihat juga ao JSF / Facelets: mengapa bukan ide yang baik untuk mencampur JSF / Facelets dengan tag HTML?

JSF 1.2 (Mei 2006)

Ini adalah rilis pertama dari tim pengembangan JSF baru yang dipimpin oleh Ryan Lubke. Tim baru melakukan banyak pekerjaan hebat. Ada juga perubahan dalam spesifikasi. Perubahan besar adalah peningkatan penanganan tampilan. Ini tidak hanya sepenuhnya JSF terpisah dari JSP, sehingga orang dapat menggunakan teknologi tampilan yang berbeda dari JSP, tetapi juga memungkinkan pengembang untuk inline plain vanilla HTML di halaman JSF tanpa harus repot dengan <f:verbatim>tag. Fokus utama lain dari tim baru adalah meningkatkan kinerja. Selama masa pakai Implementasi Referensi JSF Sun 1.2 (yang diberi nama kode Mojarra sejak build 1.2_08, sekitar 2008), secara praktis setiap build dikirimkan dengan peningkatan kinerja (utama) di samping perbaikan bug biasa (minor).

Satu-satunya kelemahan serius dari JSF 1.x (termasuk 1.2) adalah tidak adanya ruang lingkup di antara ruang lingkup permintaan dan sesi , yang disebut ruang lingkup percakapan . Hal ini memaksa pengembang untuk repot dengan elemen input tersembunyi, permintaan DB yang tidak perlu dan / atau menyalahgunakan ruang lingkup sesi setiap kali seseorang ingin menyimpan data model awal dalam permintaan berikutnya untuk berhasil memproses validasi, konversi, perubahan model, dan undangan tindakan di lebih banyak aplikasi web yang kompleks. Rasa sakit dapat dilunakkan dengan mengadopsi perpustakaan pihak ke-3 yang menyimpan data yang diperlukan dalam permintaan berikutnya seperti komponen MyFaces Tomahawk <t:saveState> , cakupan percakapan JBoss Seam dan MyFaces Orchestra kerangka percakapan.

Kerugian lain untuk puritan HTML / CSS adalah bahwa JSF menggunakan titik dua :sebagai karakter pemisah ID untuk memastikan keunikan elemen HTML iddalam output HTML yang dihasilkan, terutama ketika suatu komponen digunakan kembali lebih dari satu kali dalam tampilan (templating, iterating komponen, dll) . Karena ini adalah karakter ilegal dalam pengidentifikasi CSS, Anda harus menggunakannya \untuk keluar dari titik dua dalam penyeleksi CSS, menghasilkan penyeleksi yang jelek dan aneh seperti #formId\:fieldId {}atau bahkan #formId\3A fieldId {}. Lihat juga Bagaimana cara menggunakan ID elemen HTML yang dihasilkan JSF dengan titik dua ":" di pemilih CSS? Namun, jika Anda bukan purist, baca juga secara default, JSF menghasilkan id yang tidak dapat digunakan, yang tidak kompatibel dengan css bagian dari standar web .

Juga, JSF 1.x tidak mengirim dengan fasilitas Ajax di luar kotak. Bukan kelemahan teknis, tetapi karena hype Web 2.0 selama periode itu, itu menjadi kelemahan fungsional. Exadel lebih awal memperkenalkan Ajax4jsf, yang dikembangkan secara menyeluruh selama bertahun-tahun dan menjadi bagian inti dari pustaka komponen JBoss RichFaces . Pustaka komponen lain juga dikirimkan dengan kekuatan Ajax, yang terkenal adalah ICEfaces .

Sekitar setengah dari masa pakai JSF 1.2, sebuah teknologi tampilan berbasis XML baru diperkenalkan: Facelets . Ini menawarkan keuntungan besar di atas JSP, terutama di bidang templating.

JSF 2.0 (Juni 2009)

Ini adalah rilis besar kedua, dengan Ajax sebagai kata kunci. Ada banyak perubahan teknis dan fungsional. JSP digantikan oleh Facelet karena teknologi tampilan default dan Facelet diperluas dengan kemampuan untuk membuat komponen khusus menggunakan XML murni ( komponen komposit yang disebut ). Lihat juga Mengapa Facelets lebih disukai daripada JSP sebagai bahasa definisi tampilan dari JSF2.0 dan seterusnya?

Kekuatan Ajax diperkenalkan dalam rasa <f:ajax>komponen yang memiliki banyak kesamaan dengan Ajax4jsf. Anotasi dan peningkatan konvensi-konfigurasi diperkenalkan untuk membunuhfaces-config.xml file verbose sebanyak mungkin. Selain itu, karakter pemisah ID penampung kontainer default :menjadi dapat dikonfigurasi, sehingga pembuat HTML / CSS dapat bernafas lega. Yang perlu Anda lakukan adalah untuk mendefinisikannya sebagai init-paramdi web.xmldengan nama javax.faces.SEPARATOR_CHARdan memastikan bahwa Anda tidak menggunakan karakter diri Anda di mana saja di klien ID, seperti -.

Terakhir tetapi tidak kalah pentingnya, ruang lingkup baru diperkenalkan, ruang lingkup tampilan . Ini menghilangkan kelemahan utama JSF 1.x lainnya seperti yang dijelaskan sebelumnya. Anda cukup mendeklarasikan kacang @ViewScopeduntuk mengaktifkan cakupan percakapan tanpa mengganggu semua cara untuk mempertahankan data dalam permintaan (percakapan) selanjutnya. Sebuah @ViewScopedkacang akan hidup selama Anda kemudian mengirimkan dan navigasi ke pandangan yang sama (independen dari membuka tab browser / jendela!), Baik serentak atau asynchronous (Ajax). Lihat juga Perbedaan antara ruang lingkup Tampilan dan Permintaan dalam kacang yang dikelola dan Bagaimana memilih ruang lingkup kacang yang tepat?

Meskipun praktis semua kelemahan JSF 1.x dihilangkan, ada bug spesifik JSF 2.0 yang mungkin menjadi penghenti. The @ViewScopedgagal dalam penangan tag karena masalah ayam-telur dalam tabungan negara parsial. Ini diperbaiki di JSF 2.2 dan di-backport di Mojarra 2.1.18. Juga melewati atribut khusus seperti HTML5data-xxx tidak didukung. Ini diperbaiki di JSF 2.2 oleh fitur elemen / atribut passthrough baru. Lebih lanjut implementasi JSF, Mojarra memiliki masalah tersendiri . Relatif banyak dari mereka terkait dengan perilaku kadang<ui:repeat> - kadang tidak intuitif , implementasi tabungan negara parsial dan lingkup flash yang diimplementasikan dengan buruk . Sebagian besar dari mereka diperbaiki dalam versi Mojarra 2.2.x.

Sekitar waktu JSF 2.0, PrimeFaces diperkenalkan, berdasarkan jQuery dan jQuery UI. Itu menjadi perpustakaan komponen JSF paling populer.

JSF 2.2 (Mei 2013)

Dengan diperkenalkannya JSF 2.2, HTML5 digunakan sebagai kata kunci walaupun secara teknis ini hanya didukung di semua versi JSF yang lebih lama. Lihat juga dukungan JavaServer Faces 2.2 dan HTML5, mengapa XHTML masih digunakan . Fitur JSF 2.2 baru yang paling penting adalah dukungan untuk atribut komponen kustom, dengan ini membuka dunia kemungkinan, seperti grup tombol radio yang dapat disesuaikan .

Terlepas dari implementasi bug spesifik dan beberapa "hal-hal kecil yang mengganggu" seperti ketidakmampuan untuk menyuntikkan EJB di validator / converter (sudah diperbaiki di JSF 2.3), tidak ada kelemahan utama dalam spesifikasi JSF 2.2.

MVC berbasis komponen vs MVC berbasis permintaan

Beberapa mungkin memilih bahwa kelemahan utama JSF adalah memungkinkan sangat sedikit kendali atas HTML / CSS / JS yang dihasilkan. Itu bukan milik JSF, itu hanya karena itu adalah kerangka kerja MVC berbasis komponen , bukan kerangka kerja MVC berdasarkan permintaan (tindakan) . Jika tingkat tinggi mengendalikan HTML / CSS / JS adalah persyaratan utama Anda ketika mempertimbangkan kerangka kerja MVC, maka Anda seharusnya sudah tidak melihat kerangka kerja MVC berbasis komponen, tetapi pada kerangka kerja MVC berbasis permintaan seperti Spring MVC . Anda hanya perlu mempertimbangkan bahwa Anda harus menulis sendiri semua HTML / CSS / JS boilerplate. Lihat juga Perbedaan antara Permintaan MVC dan Komponen MVC .

Lihat juga:

• Apa perbedaan antara JSF, Servlet dan JSP? (hanya untuk memahami dasar-dasarnya)
• Menggunakan JSF untuk mengembangkan tata letak CSS tanpa tabel (mitos lain tentang JSF)
• JSF vs HTML / CSS / JS / jQuery biasa (ketika JSF adalah pilihan yang salah)
• Pola desain dalam aplikasi web (menggambarkan ideologi di balik MVC)

Setelah 5 tahun bekerja dengan JSF, saya pikir saya dapat menambahkan 2 sen.

Dua kelemahan utama JSF :

1. Kurva belajar besar. JSF itu kompleks, itu benar.
2. Sifat komponennya . Kerangka kerja berbasis komponen mencoba untuk menyembunyikan sifat sebenarnya dari Web, yang datang dengan sejumlah besar komplikasi dan bencana (seperti tidak mendukung GET di JSF dalam hampir 5 tahun).
   IMHO menyembunyikan Permintaan / Tanggapan HTTP dari pengembang adalah kesalahan besar. Dari pengalaman saya, setiap kerangka kerja berbasis komponen menambah abstraksi ke pengembangan Web, dan abstraksi itu menghasilkan overhead yang tidak perlu dan kompleksitas yang lebih tinggi.

Dan kekurangan kecil yang muncul di benak saya:

1. Secara default ID objek terdiri dari id orang tuanya, misalnya form1: button1.
2. Tidak ada cara mudah untuk berkomentar fragmen halaman yang salah. Tag <ui:remove>membutuhkan konten yang benar secara sintaksis yang diuraikan.
3. Komponen pihak ke-3 berkualitas rendah yang misalnya tidak memeriksa metode isRendered()bagian dalam processXxx()sebelum melanjutkan.
4. Menggabungkan KURANG & Sencha itu sulit.
5. Tidak bermain dengan baik dengan REST.
6. Tidak mudah bagi perancang UX, karena komponen yang siap pakai memiliki gaya CSS mereka sendiri, yang perlu ditimpa.

Jangan salah sangka. Sebagai kerangka kerja komponen JSF dalam versi 2 benar-benar bagus, tetapi masih berbasis komponen, dan akan selalu ...

Silakan lihat rendahnya popularitas Tapestry, Wicket dan rendahnya antusiasme para pengembang JSF yang berpengalaman (yang bahkan lebih bermakna). Dan untuk kontrasnya, lihatlah kesuksesan Rails, Grails, Django, Play! Kerangka kerja - mereka semua berbasis tindakan dan tidak mencoba untuk menyembunyikan permintaan / tanggapan sejati programmer dan sifat stateless dari web.

Bagi saya itu adalah kelemahan utama JSF. IMHO JSF dapat cocok dengan beberapa jenis aplikasi (intranet, bentuk-intensif), tetapi untuk aplikasi web kehidupan nyata itu bukan cara yang baik untuk pergi.

Semoga ini membantu seseorang dengan pilihannya yang berkaitan dengan front-end.

Beberapa kekurangan yang muncul di pikiran:

1. JSF adalah kerangka kerja berbasis komponen. Ini memiliki batasan inheren yang harus dilakukan dengan mematuhi model-komponen.
2. AFAIK JSF hanya mendukung POST, jadi jika Anda menginginkan GET di suatu tempat Anda harus melakukan servlet / JSP biasa.
3. Sebagian besar komponen mencoba menyediakan abstraksi atas domain seperti database relasional dan JavaScript front-end, dan sering kali abstraksi ini "bocor" dan sangat sulit untuk di-debug.
4. Abstraksi ini mungkin merupakan titik awal yang baik untuk pengembang junior atau seseorang yang tidak nyaman dengan domain tertentu (misalnya JavaScript front-end), tetapi sangat sulit untuk mengoptimalkan kinerja, karena ada beberapa lapisan yang terlibat, dan kebanyakan orang yang menggunakannya memiliki sedikit pemahaman tentang apa yang terjadi di bawah tenda.
5. Mekanisme templating yang biasanya digunakan dengan JSF tidak ada hubungannya dengan bagaimana web desigers bekerja. Editor WYSIWYG untuk JSF adalah primitif dan dalam hal apa pun, desainer Anda akan memberi Anda HTML / CSS yang harus Anda habiskan untuk berkonversi lama.
6. Hal-hal seperti ekspresi EL tidak dicentang secara statis dan baik kompiler maupun IDE tidak melakukan pekerjaan dengan baik dalam menemukan kesalahan, jadi Anda akan berakhir dengan kesalahan yang harus Anda tangkap saat dijalankan. Ini mungkin baik untuk bahasa yang diketik secara dinamis seperti Ruby atau PHP, tetapi jika saya harus menahan guncangan tipis ekosistem Java, saya minta mengetikkan templat saya.

Singkatnya: Waktu Anda akan menghemat dengan JSF, dari menghindari untuk menulis kode JSP / servlet / beanplate, Anda akan menghabiskannya x10 untuk membuatnya skala dan melakukan apa yang Anda inginkan.

Bagi saya, kelemahan terbesar dari JSF 2.0 adalah kurva belajar tidak hanya dari JSF, tetapi komponen perpustakaan yang harus Anda gunakan untuk membuatnya melakukan pekerjaan yang bermanfaat. Pertimbangkan banyaknya spesifikasi dan standar yang telah Anda tangani untuk benar-benar mahir:

• HTML dalam berbagai inkarnasi. Jangan berpura-pura Anda tidak perlu mengetahuinya.
• HTTP - ketika Anda tidak tahu apa yang sedang terjadi, Anda harus membuka Firebug dan melihatnya. Untuk itu Anda perlu tahu ini.
• CSS - Suka atau tidak. Sebenarnya tidak terlalu buruk dan setidaknya ada beberapa alat yang bagus di sana.
• XML - JSF mungkin akan menjadi tempat pertama Anda menggunakan ruang nama untuk gelar ini.
• Spesifikasi Servlet. Cepat atau lambat Anda akan masuk ke metode panggilan dalam paket ini. Selain itu Anda harus tahu bagaimana Facelet Anda akan berubah menjadi XHTML atau apa pun.
• JSP (sebagian besar agar Anda tahu mengapa Anda tidak membutuhkannya di JSF)
• JSTL (sekali lagi, sebagian besar untuk mengatasi kerangka kerja lama)
• Bahasa Ekspresi (EL) dalam berbagai bentuknya.
• ECMAScript, JavaScript, atau apa pun yang Anda ingin menyebutnya.
• JSON - Anda harus tahu ini bahkan jika Anda tidak menggunakannya.
• AJAX. Saya akan mengatakan JSF 2.0 melakukan pekerjaan yang layak untuk menyembunyikan ini dari Anda tetapi Anda masih perlu tahu apa yang sedang terjadi.
• DOM. Dan bagaimana browser menggunakannya. Lihat ECMAScript.
• Acara DOM - topik dengan sendirinya.
• Java Persistence Architecture (JPA) yaitu jika Anda ingin aplikasi Anda memiliki basis data back-end.
• Jawa itu sendiri.
• JSEE selagi kamu di sana.
• Spesifikasi Injeksi Ketergantungan Konteks (CDI) dan bagaimana bentrok dengan dan digunakan dengan JSF 2.0
• JQuery - Saya ingin melihat Anda rukun tanpanya.

Sekarang, setelah Anda selesai dengan itu Anda bisa melanjutkan dengan spesifikasi kepemilikan, yaitu pustaka komponen dan pustaka penyedia Anda akan mengambil sepanjang jalan:

• PrimeFaces (perpustakaan komponen pilihan saya)
• RichFaces
• MyFaces
• ICEFaces
• EclipseLink (Penyedia JPA saya)
• Hibernasi
• Las

Dan jangan lupa wadahnya! Dan semua file konfigurasi itu:

• GlassFish (2, 3, dll)
• JBoss
• Kucing jantan

Jadi - INI MUDAH MEMBUATNYA? Tentu, JSF 2.0 adalah "mudah" selama yang Anda inginkan adalah halaman web paling dasar dengan interaksi paling sederhana.

Sederhananya, JSF 2.0 adalah mishmash yang paling rumit dan rumit dari teknologi yang direkatkan seperti yang ada di dunia perangkat lunak saat ini. Dan saya tidak bisa memikirkan apa pun yang saya ingin gunakan.

1. Pengembang yang tidak berpengalaman biasanya akan membuat aplikasi yang sangat lambat dan kode akan sangat jelek dan sulit untuk dipelihara. Sangat mudah untuk memulai, tetapi sebenarnya membutuhkan investasi dalam pembelajaran jika Anda ingin menulis program yang bagus.
2. Setidaknya pada awalnya Anda akan sering "terjebak" pada beberapa masalah dan akan menghabiskan lebih banyak waktu membaca posting balusc di internet daripada benar-benar bekerja :) Setelah beberapa saat akan lebih dan kurang dari itu, tetapi masih bisa mengganggu.
3. Bahkan lebih menjengkelkan ketika Anda mengetahui bahwa masalahnya bukan karena Anda kurang pengetahuan / kesalahan tetapi sebenarnya bug. Mojarra cukup buggy, dan lapisan komponen lainnya menambah lebih banyak masalah. Richfaces adalah software omong kosong terbesar yang pernah ditulis :) Tidak tahu bagaimana ini sekarang pada versi 4. Kami memiliki Primefaces yang lebih baik, tetapi Anda masih akan mengalami bug atau kekurangan fitur terutama dengan komponen yang lebih eksotis. Dan sekarang Anda harus membayar untuk pembaruan Primefaces. Jadi saya akan mengatakan buggy tetapi semakin baik terutama setelah versi 2.2 memperbaiki beberapa masalah dengan spec. Kerangka kerja semakin matang tetapi masih jauh dari sempurna (mungkin myfaces lebih baik?).
4. Saya tidak merasa sangat fleksibel. Seringkali jika Anda membutuhkan sesuatu yang sangat khusus dan tidak ada komponen yang melakukan itu - itu akan sedikit menyakitkan. Sekali lagi saya berbicara dari perspektif pengembang rata-rata - yang memiliki tenggat waktu, tutorial membaca cepat, dan mencari stackoverflow ketika terjebak karena tidak ada waktu untuk mempelajari cara kerjanya :) Seringkali beberapa komponen tampaknya memiliki "hampir" apa yang Anda butuhkan, tetapi tidak persis dan kadang-kadang Anda mungkin menghabiskan terlalu banyak waktu untuk membuatnya melakukan sesuatu yang Anda inginkan :) Perlu berhati-hati dalam mengevaluasi apakah lebih baik untuk membuat sendiri atau menyiksa komponen yang ada. Sebenarnya jika Anda membuat sesuatu yang sangat unik saya tidak akan merekomendasikan JSF.

Jadi singkatnya kekurangan saya adalah: Kompleksitas, Kemajuan pembangunan tidak terlalu lancar, buggy, tidak fleksibel.

Tentu ada keuntungan juga, tapi bukan itu yang Anda tanyakan. Pokoknya itu pengalaman saya dengan kerangka kerja orang lain mungkin memiliki pendapat yang berbeda, jadi cara terbaik adalah hanya mencobanya sebentar untuk melihat apakah itu untuk Anda (hanya sesuatu yang lebih kompleks - bukan contoh naif - JSF benar-benar bersinar di sana :) IMHO kasus penggunaan terbaik untuk JSF adalah aplikasi bisnis, seperti CRMs dll ...

"JSF akan menampilkan View-layer HTML dan JavaScript yang tidak dapat Anda kontrol atau ubah tanpa masuk ke kode Controller."

Sebenarnya JSF memberi Anda fleksibilitas, Anda dapat menggunakan komponen standar / pihak ketiga atau membuat sendiri yang Anda miliki kontrol penuh atas apa yang diberikan. Ini hanya satu xhtml yang Anda butuhkan untuk membuat komponen khusus Anda dengan JSF 2.0.

Saya bukan ahli Java Server Faces sama sekali. Tapi IMHO kelemahan utama adalah sisi server. Saya bosan mempelajari dan menggunakan kerangka lapisan presentasi web sisi server seperti Formulir Web ASP.NET, ASP.NET MVC, Java Server Faces, Struts, kerangka kerja php, dan kerangka kerja ruby ​​on rails. Saya mengucapkan selamat tinggal pada mereka semua, dan saya menyapa Angular dan TypeScript. Lapisan presentasi saya berjalan di browser. Saya tidak masalah jika dilayani oleh Windows IIS yang menjalankan php atau ASP.NET, atau jika dilayani oleh server web Apache yang berjalan di Linux. Saya hanya perlu belajar satu kerangka kerja yang berfungsi di mana-mana.

Hanya dua sen saya.

Kami mengembangkan proyek sampel dengan JSF (Itu adalah penelitian tiga minggu sehingga kami mungkin kehilangan beberapa hal!)

Kami mencoba menggunakan jsf inti, jika komponen diperlukan kami menggunakan PrimeFaces.

Proyek itu adalah situs web dengan navigasi. Setiap halaman harus dimuat melalui ajax ketika menu diklik.

Situs ini memiliki dua usecases:

1. Halaman dengan kisi. Grid dimuat melalui ajax dan harus mendukung sort dan paging
2. Halaman panduan tiga langkah. Setiap halaman memiliki validasi sisi klien (untuk validasi sederhana) dan validasi dasar sisi server ajax (untuk validasi kompleks). Setiap pengecualian server (dari lapisan layanan) harus ditampilkan pada halaman panduan yang sama tanpa menavigasi ke halaman berikutnya.

Kami menemukan bahwa:

1. Anda perlu menggunakan beberapa peretasan dari omniFaces untuk membuat status tampilan JSF tetap. Negara JSF akan rusak ketika Anda memasukkan halaman melalui ajax di satu sama lain. Ini tampaknya bug di JSF dan mungkin diperbaiki pada rilis berikutnya (bukan dalam 2.3).
2. JSF Flow tidak bekerja dengan benar dengan ajax (atau kami tidak bisa membuatnya berfungsi!) Kami mencoba menggunakan komponen wizard primeface sebagai gantinya tetapi validasi klien tampaknya tidak didukung dan berarti sementara itu bukan standar aliran JSF standar.
3. Saat menggunakan beberapa komponen jQuery seperti jqGird, dan Anda perlu memuat hasil JSON, maka Anda disarankan untuk menggunakan servlet murni, JSF tidak akan melakukan apa pun untuk Anda. Jadi jika Anda menggunakan komponen semacam ini, desain Anda tidak akan muat di JSF.
4. Kami mencoba melakukan beberapa skrip klien ketika ajax selesai ajaxCompletedan kami menemukan bahwa PF 4 telah mengimplementasikan acara ajax sendiri. Kami memiliki beberapa komponen jQuery dan kami perlu mengubah kode mereka.

Jika Anda mengubah sampel di atas menjadi proyek non Ajax (atau setidaknya lebih sedikit proyek ajax), Anda tidak akan menghadapi banyak masalah di atas.

Kami meringkas penelitian kami sebagai:

JSF tidak berfungsi dengan baik di situs web berbasis ajax sepenuhnya.

Tentu saja kami menemukan banyak fitur bagus di JSF yang mungkin sangat membantu dalam beberapa proyek, jadi pertimbangkan kebutuhan proyek Anda.

Silakan merujuk ke dokumen teknis JSF untuk meninjau keunggulan JSF, dan menurut saya keuntungan terbesar JSF, adalah dukungan SELESAI DAN BESAR dari @BalusC ;-)

Bagi saya kekurangan terbesar JSF adalah dukungan yang buruk untuk halaman yang dihasilkan secara program (dinamis).
Jika Anda ingin membuat halaman Anda (membuat model komponen halaman) secara dinamis dari kode java. Misalnya jika Anda bekerja pada konstruktor halaman web WYSIWYG. Dokumentasi yang memadai dari use case ini tidak tersedia secara umum. Ada banyak titik di mana Anda harus bereksperimen dan pengembangannya berjalan lambat. Banyak hal yang tidak sesuai dengan harapan Anda. Tapi secara umum itu mungkin meretasnya entah bagaimana.
Untung itu bukan masalah dalam filosofi atau arsitektur JSF. Itu tidak cukup diuraikan (sejauh yang saya tahu).

JSF 2 membawa Komponen Komposit yang seharusnya memudahkan pengembangan komponen, tetapi dukungan mereka untuk konstruksi dinamis (terprogram) sangat buruk. Jika Anda mengatasi proses rumit rumit dan hampir tidak berdokumen dari konstruksi Komponen Komposit dinamis, Anda akan menemukan bahwa Jika Anda bersarang beberapa komponen Komposit sedikit lebih dalam, mereka berhenti bekerja, melempar beberapa pengecualian.

Tapi sepertinya komunitas JSF menyadari kekurangan ini. Mereka sedang mengerjakan ini seperti yang Anda lihat dari kedua bug ini
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

Situasi harus lebih baik dengan JSF 2.2 setidaknya jika kita berbicara tentang spesifikasi.

Mengomentari beberapa bulan terakhir pengalaman Primefaces / JSF saya:

• Jika Anda dapat menggunakan komponen "dari rak", saya kira itu tidak buruk.
• Namun, itu tidak berfungsi dengan baik segera setelah Anda keluar dan membutuhkan UI khusus. - Misalnya, kami harus menggunakan bootstrap Twitter untuk proyek kami. (Bukan primitif bootstrap).
  • Sekarang halaman kami berfungsi sebagai berikut:
    • Memuat halaman.
    • Pengguna berinteraksi dengan Primefaces yang memiliki fungsi ajax
    • Binding javascript Bootstrap istirahat
    • Kami menjalankan javascript tambahan untuk mem-rebind semuanya

Janji JSF untuk menghindari penulisan javascript berubah menjadi penulisan javascript lebih banyak daripada yang kita miliki jika tidak menggunakan Primefaces - dan javascript untuk memperbaiki apa yang dipatahkan Primefaces.

Ini adalah time sink - kecuali jika Anda lagi menggunakan barang-barang "dari rak". Juga sangat jelek (Primefaces) ketika harus bekerja dengan Selenium. Itu semua bisa dilakukan - tapi sekali lagi - hanya ada begitu banyak waktu.

Hindari ini jika Anda bekerja dengan tim UX / desain dan perlu untuk beralih dengan cepat di UI - Anda dapat menghemat waktu dengan mempelajari jquery / menulis HTML langsung - atau melihat reaksi / sudut.

JSF memiliki banyak kelebihan, pertanyaan yang tidak menguntungkan biar saya tambahkan beberapa poin.

Pada skenario praktis penerapan proyek web dengan kerangka waktu Anda perlu mengawasi faktor-faktor berikut.

• Apakah Anda memiliki cukup anggota senior dalam tim Anda yang dapat menyarankan kontrol terbaik yang cocok untuk setiap skenario?

• Apakah Anda memiliki bandwidth untuk mengakomodasi kurva pembelajaran awal?

• Apakah Anda memiliki keahlian yang cukup dalam tim Anda yang dapat meninjau
  hal-hal yang dihasilkan oleh JSF oleh pengembang?

Jika jawaban Anda adalah 'Tidak' untuk pertanyaan, Anda mungkin berakhir pada basis kode tidak dapat dipertahankan.

JSF hanya memiliki satu kelemahan: sebelum memulai pengembangan "JSF" Anda harus memahami dengan jelas pengembangan web, inti java dan arsitektur front-end.

Saat ini kerangka kerja JavaScript "baru" hanya mencoba menyalin / menempelkan model berbasis komponen "JSF".

Di antara semua kerangka kerja "arus utama" seperti Spring MVC, Wicket, Tapestry, dll., JSF Java EE dengan komponen kompositnya adalah lapisan presentasi dan teknologi berorientasi komponen yang paling rumit yang disediakan. Ini sedikit rumit dan tidak lengkap dibandingkan dengan solusi yang disediakan oleh HybridJava.