私は大規模な Java ベースの Web アプリケーションに取り組んでいます。これは過去 5 年ほどかけて構築されたものです。UI にはオーバーホールが必要であり、大幅に書き直す必要があります。使用可能な UI ツール/ライブラリ/フレームワークを調査しており、テンプレートのオプションとしてDust.jsを見つけました。
質問: Dust.jsの ユーザーがどう思うか興味があります。
- それは成功しましたか?
- 使いやすいですか?
- 十分に文書化されていますか?
- コミュニティサポートは良いですか?( 「dust.js」とタグ付けされた STに関する 6 つの質問のみ!)
- Underscoreのテンプレート、Google Closure Templates、Handlebars、Mustacheなどの他のテンプレート ツールと比較した場合の長所と短所は何ですか。
- Backbone.js (オンライン ブック)などの MV* 構造フレームワークで使用する際に問題はありますか?
背景:
Dust.js に関心を持っている理由:以下のLinkedInブログ投稿が最初に私たちの注意を引きました。
- JSP を置き去りにする: LinkedIn を Dust.js クライアント側テンプレートに移行する
クライアント側テンプレートのスローダウン: mustache、handlebars、dust.js など
2 つの投稿の 2 つ目は質問 5 に非常にうまく答えていますが、LinkedIn を除けば、Google からの結果で、テンプレート システムについて詳しく説明したり、テンプレート システムが人気のある選択肢であることを示唆したりするものはほとんどありません。さらに、この投稿では、機能を拡張し、いつの日か元のプロジェクトに貢献したいと考えていると述べています。彼らがそうするまで、私たちも機能を拡張する必要があるのではないかと心配しています。
そうは言っても、LinkedIn のテンプレート システムに対する最初の要件は私たちのものに非常に近く (以下を参照)、選択する前に非常に徹底的な調査を行ったことは明らかです。
私たちの要件:
- DRY : 理想的には、サーバー (Java ベース) とクライアント側でテンプレート システムを使用するか、LinkedIn の完全なアプローチを選択した場合はクライアント側でのみ使用したいと考えています。
Instead of using a JSP, GSP, or ERB to assemble a page server side and send back HTML, we have the server send back just the dynamic data as JSON and have the page assembled in the browser using a static client-side template served from a CDN"
- 完全に国際化
- 優れたコミュニティ サポート
- 十分に使いやすく、手に取りやすい
- jQueryとBackbone.jsで問題なく動作します
- 十分に文書化されています
- DRY : 理想的には、サーバー (Java ベース) とクライアント側でテンプレート システムを使用するか、LinkedIn の完全なアプローチを選択した場合はクライアント側でのみ使用したいと考えています。