Vaadin フレームワークを使用する必要がありますか [終了]

https://stackoverflow.com/questions/1183801

19-09-2019
|

質問

ちょうど遊んでみました Vaadin フレームワークとても使いやすいと思います。さらに、彼のフレームワークで私が気に入っているのは、それが次のものの上に構築されていることです。 Google ウェブツールキット (GWT).

このフレームワークを使い続けるべきか、それとも GWT を使い続ける方が良いか、どう思いますか?

解決

ねえ。免責事項として、私はVaadinを開発する会社で働いています。

Vaadinは、GWTにプリコンパイルコンポーネントのセットを有するような方法でGWTを使用します。あなたがそうしたい場合は、当然のことながら、さらに独自のコンポーネントを作ることができます。しかし、コンポーネントのセットは非常に完了し、そして多くの場合、あなた自身の必要性のためにカスタマイズすることができます。これは、JavaからJavaScriptにあなたがあなたのアプリケーションを変更するたびに、あなたのコードを再コンパイルする必要がないことを意味します。あなただけ一緒にすでに利用可能なコンポーネントを組み合わせています。

フレームワークは、サーバが駆動されるので、すべてのロジックは、サーバ側で処理されます。コンポーネントは二つの部分、クライアントとサーバのファイルを持っています。クライアント側は、コンポーネントのためだけのダミー「ビュー」です。あなたはそれと対話すると、それはこのまたはそのは/ etc /書き込み押されたサーバーにメッセージを送信します。その後、サーバーは何をすべきかを決定します。わずかなAPIはJavaScriptで利用可能である要求を送信するためのものとして、あなたは、ロジックを「ハック」することはできませんので、これは、セキュリティ強化のためです。これは、いくつかのケースではアプリケーションの速度で少しのトレードオフかもしれないが、私はそれがそんなに悪いとは思いません。最悪のスピードバンプは、通常、UIフレームワークの選択とは何の関係もありませんデシベルクエリラウンドトリップと、このような、あります。あなたは、サーバーから遠く離れているかの瞬間にヒット高いユーザーが存在するため提案として、デモの低迷をすることができます。それが実行する方法も参照してくださいするには、アプリケーションの最終的なアプリケーションを閉じて、自分の環境でそれを試してみてください。あなたはそれをテストするために展開することができ、いくつかの準備ができてアプリケーションがあります。

私は、選択はあなたがやろうとしているものに沸くと思います。あなたは、通常のJavaアプリケーションを構築し、簡単のために、動的なWeb UIを行うことができますようVaadinは、Webアプリケーションに適しています。あなたは、ユーザーがページだけを閲覧し、伝統的なウェブサイトのより多くの何か、やっている場合 - 積極的に相互作用よりも多く、そしてVaadinは行くための最善の方法ではありません。レールのようないくつかの他の無料のフレームワークや、私はあなたがより多くのあなたが今GWTを使用していることを示唆しているように、アプリケーションをやっていると思うのPHPフレームワークなどで移動しますので、Vaadinは良いことがあります。

Vaadinフォーラム上または@freenode #vaadin IRCチャンネルで、ここでは、より多くの質問をし、多分誰かがあなたにVaadinを使用しない理由や、なぜへのより多くの理由を与えることができます。

他のヒント

はほぼ1.5年後、私は私が私の心の底からこれを言うなどMVP、EventBus、Commandパターンのように最後のGoogleのI / Oから学んだすべてのベスト・プラクティスを使用して、とても巨大ではないGWTアプリケーションを開発：後に物事が私のチームとクライアントが技術的にも視覚的に望んでいた道をうまく取得しようと支出の日は、さえUiBinderサンプルメッセージのリリース後、Vaadinは、トンネルの終わりの光のように私のところに来ました。

コマンドパターンでほぼ千定型行動、別の千プレゼンターとビューと別の千件のイベントハンドラなど。これらのクラスのほぼ75％に対処することと、まだ（appfoundationアドオン良好なパターンアプローチを維持していないを書き込んだ後）の上に、小さなネットワークのオーバーヘッドは許容されます。 Vaadinでは、アウト・オブ・ボックス、あなたは良いのウィジェット、ページング、データバインディング、完璧なレイアウト機能を取得します。このすべて何のため？サーバー側でいくつかのより多くのメモリ消費量。

私は次のFacebookや何かを構築していないよので、これは許容可能であると言うことができると思います。私はまだメディアサーバーあたりの同時ユーザーの数千人を扱うことができ、しかも低遅延ラウンドトリップを維持します。

Vaadinで、私はコードの行のほぼ半分で素敵なアプリを構築することができますし、まだアプリケーションは、より完全なようです。： - ）

!! UPDATE 2011年2月23日：私は1つは、各フレームワークの制限に注意する必要があります方法を強調することはできません。 Vaadinは違いはありません。一つは、Vaadinは、HTMLやJavaScriptの任意のフォームを抽象化することを認識する必要があります。また、結果のHTMLは非常に重いですし、履歴状態の世話をする必要があり、自分自身を変更します。プロジェクトをビルドするときに、それらのオーバーヘッドを認識してます。

免責事項:私はこれから言及する図書館のどれにも所属していませんが、たまたまそれらの図書館についての私のやり方をよく知っています。

あなたと同じように、私も新しいプロジェクトにどのスタック/フレームワークを使用するかを考えていたときに、この投稿に出会いました。私は Play! で確かな経験を積んできました。(Scala の場合は問題ありませんが、ここでは関係ありません) しかし、魅力的なウィジェットとサーバー側とのシームレスな統合 + Swing のような開発は、私の興味をそそりました。それは 2010 年の終わりのことでした。その回答を見て Vaadin を試してみようと確信したので、戻ってきて、特にここで読みたかった回答を書くことにしました。なぜなら、この質問は今日でも意味があるからです。一方、Vaadin はバージョン 6 から 7 に移行し、必要ないくつかの注目すべき改善が加えられました。バージョン 1 から 2 に移行し、私 (+ 小規模チーム) は両方のフレームワークを使用して少数のプロジェクトを成功させました。

両方のフレームワークがあるため、比較は興味深いと思います

JVM 上で実行され、その豊富なエコシステムを活用できます
Web アプリケーションに対する彼らのアプローチと、開発者としてあなたが気にかけるべきことに関して、これ以上に対立することはありません。
程度は低いですが、それらが Java EE とどのように関係しているかについても説明します。

賞賛

一言で言えば、基盤となる HTTP リクエスト/レスポンスメカニズムから完全に抽象化されながら、デスクトップアプリケーションをブラウザに移植するというアイデアに魅力を感じるのであれば、おそらく Vaadin が Web アプリケーション作成の候補となるでしょう。プログラミングに対する Swing のようなアプローチは、HTML や JavaScript の低レベルから解放されて満足している人にとっては簡単です。アプリへの新しいリクエストは実際に新しいインスタンスを開始しており、残りのフローはあなたとあなたのロジック次第です。リンクはナビゲーション用の古き良きボタンに戻り、HTML や CSS を微調整することなく、多くの組み込みテンプレートを使用して自由にレイアウトを作成できます。API は一般に非常に一貫性があり、明らかに十分に文書化されています ( ヴァーディンの書は必読です。多くのものが簡単に入手できるので、徹底的に実行してください。Bean をコンポーネントやバリデータにバインドします...)。ウィジェットは全体的に優れたブラウザ間互換性を備えているため、幅広いクライアント上でアプリケーションの一貫した動作が保証されます。

リアリティチェック

Vaadin アプリの開発とテストは楽しい時間を過ごしました。最初のバージョンをリリースしてフィードバックを収集し始めたとき、物事はより明確になり、より微妙なものになりました。私たちはそれに気づきました 私たちは実際、かなり根本的な点で偏見を持っていました, 、つまり:

201x 年、ほとんどのユーザーは長い間 Web を使用しており、デスクトップアプリを実際にほとんど使用していないユーザーはほとんどいませんでした。ここで重要な点は、ブラウザは、ハイパーテキストリンク、「戻る」、「進む」、「リロード」ボタン、ユビキタスなタブ、場合によってはウィンドウを使用した UX インタラクションを標準化し、ほとんどのアクションは HTTP リクエストをトリガーし、応答を待つという基本的な考え方を標準化しました。. 。これは、Web サイトが遵守し、それに基づいて Web サイトが構築される暗黙の契約です。したがって、ユーザーが以前のように「戻る/進む」ボタンを使用できない、またはタブが期待どおりに機能しないという苦情を寄せても、私たちは驚くべきではありませんでした。そして私たちは同意しました。私たちはユーザーとブラウザーを縛る目に見えない契約を破りました。実は私たち自身もそうでした 暗黙的に 他の Web サイトで使用していたように、Vaadin アプリでブラウザを使用するわけではありません。もちろん、前述の本に戻って、URL フラグメントを使用した Web ナビゲーションエクスペリエンスの複製について注意深く読んでみると、実際には予想より複雑であることがわかるでしょう。 Vaadin アプリはステートフルであるため. 。さらに、Play! とは対照的に、MVC または MVP パラダイムは開発者に大まかに課せられるだけです。他に選択肢が実質的にない場合。これを軽く考えないでください。脳は、ページが切り替わった後にほんの数秒間表示される明るい白い画面に慣れています。ユーザーがクリックして新しいページが表示されることを期待すると、ブラウザは砂時計 (またはそのバリエーション) を表示してそれを認識します。AJAX では、リクエストは舞台裏で行われます。現在、小規模でほぼ外科的な AJAX ストライキが標準になっている場所もありますが、大規模な UI アップデートはまだ行われていません。
ステートフルアプリにはいくつかの課題があります...そしてトラブル。1 つの負荷分散 (心配な場合) はさらに複雑です。Vaadin セッションは多くのリクエストにまたがるため、REST ベースのアプローチとは対照的に長くなりますが、UX の観点からは比較的短期間であるため、トランザクションの概念はまったく異なります。実際、ユーザーが最初のフォームに戻ることは珍しくありません。 時間前 自分たちの任務を終えるために。理論的には、これは Vaadin でも機能する可能性がありますが、メモリが常にブロックされた状態でセッションを長時間存続させておく必要があり、これが全体的なスケールでどのように機能するかを慎重に検討する必要があります。同時ユーザー。

ステートフルページは、ユーザーが共有することも難しく、ましてやブックマークすることも困難です (これは、URL フラグメントを扱っていることを前提としています)。
最後に、ロジックがサーバー上にあるため、UI が一般的により遅くなるという印象を共有します。もちろん、クライアント側の JavaScript をロードしたウィジェットをいつでも作成してラウンドトリップ数を削減できますが、必然的にサーバー上で UI の更新を行う必要があります。私の経験からすると、JS は解釈するにはすでにかなり重く、モバイルデバイスでのエクスペリエンスは低くなります (TouchKit については知っていますが、それでも次のとおりです)。モバイルデバイス上の HTML5 アプリは私には向いていません)。また、UI スレッドはリクエストが投稿された後もアクティブになることに注意してください。UI アップデートを取得するのと同様、クライアント側でのユーザーアクション）、さまざまなリスナーを介してアクセスできるようになります。ただし、バックグラウンドスレッドから UI を更新するのはより複雑です (例:アップデートをプッシュします）。ただし、Vaadin 7 では、特にこの点で状況が改善されました。 比較的 軽量な HTML が生成されました。HTTP 圧縮をオンにするだけで、UI の反応性が大幅に向上しました。

結論

そこで私たちは立ち止まって、そもそも Vaadin のアプローチの何がそんなに魅力的だと感じたのか考えてみました。初期の開発は比較的順調に進み、すぐに結果が得られましたが、Web UX の期待に対応するためにいくつかのコンセプトを作り直した結果、流れに逆らって泳いでいたという強い印象を受けました。私たちは、HTTP リクエスト/レスポンスメカニズムから抽象化 (隠蔽?) されるという魅惑的なアイデアは、Web アプリとデスクトップアプリの間の実際のインピーダンスの不一致を明らかにする諸刃の剣であることが判明したと結論付けました。

Web がさらに別のレイヤーであるかのように振る舞うのではなく、Web の仕組みを受け入れる必要があると私たちは強く感じました。 これは URL 中心のアプリケーションを用意することから始まります (Rails/Django/Play によって課されるもの)。「データはアプリケーションよりも長持ちする」という言葉を聞いたことがあるでしょう。現在、データは URL リソースによって参照されるため、URL はデータよりも存続すると言っても過言ではありません。結局のところ、それらは人々がブックマークするものですよね。したがって、基本的な関心事の分離もこのレベルに適用される必要があります。おそらくこれが、そもそもウェブがこれほど普及した理由でしょう。そこで、アプリを再検討して、アクションに応答する中央コントローラーを中心にアプリを構造化しました。 ア・ラ・プレイ 個別のリソースパス上に作成されます。

今のところ、私たちは Vaadin アプリを維持していますが、これらの制約のいくつかと根本的なパラダイムシフトのため、それを使って新しいプロジェクトを開始する予定はありません。しかし、Web 内部の仕組みについてほとんど知識を必要とせず、技術的に一貫性があり、文書化された 360° Java Web フレームワークを構築したチームには脱帽です。良い面として、彼らはコンサルティングサービスを販売する会社によってそのフレームワークを支援していることさえあります。この経験と、それが Web アプリケーションに対する自分の見方を再評価するきっかけになったことに感謝しています。私はその進化を注意深く監視していきますが、より多くの制御と粒度が必要であることは間違いありません。

願わくば、いつか Vaadin が独自の HTTP サーバーに依存しているサーブレットアーキテクチャ全体から解放されることを願っています。さらに良いのは、MVC 設計をフレームワークにもっと深く根付かせることです。しかし、それが予見可能な将来に起こる可能性はやや低く、EE だけを誓う経験豊富な企業 Java ゴリラの間で儲かるニッチを見つけたようです。輝いて。

TL;DR:Vaadin は Web アプリとは何か、そしてさらに重要なことに、Web アプリがどのように動作すべきかという点を見逃していると思います。そろそろプログラマが Web と、ユーザーが Web とどのように対話するかを受け入れる時期が来ています。[戻る] ボタン、[リロード] ボタン、タブ、ブックマーク)。Web アプリが HTTP リクエストとセマンティクス (動詞) に忠実であればあるほど、ユーザーの期待に一致する可能性が高くなります。それが重要です。

編集:Python の経験がある場合は、URL 中心の REST ベースの Web アプリケーションプログラミングを体験するために、Flask も試してみることを強くお勧めします。

編集2:何らかの理由で、フルスタックの Vaadin のようなフレームワークを使用する必要があると感じる場合は、Meteor を試してみてください。これは、Node.js 上で実行される JavaScript ベース (フロントエンドとバックエンドの両方) のフレームワークで、WebSocket を介して非同期通信が行われ (したがって、リクエスト/レスポンスよりも遅延が小さくなります)、デフォルトでリアクティブです。Vaadin で私が嫌いだった多くの点が Meteor で解決されました。たとえば、UI 更新のロジックはクライアント上で実行されるため、Vaadin よりもはるかに応答性が高くなります。JavaScript コミュニティと Java コミュニティの人々はあまり交流がありませんが、初めてこの話を聞いたとき、Vaadin との類似点がすぐに思い浮かびました。Vaadin は現在、コミュニティ内でかなりの勢いを誇っています。その理由は、Vaadin を人気にしたのと同様の理由です。デスクトップのような Web アプリを作成する機能。Java が将来の Web アプリケーションの構想に大きく関与していないことに気付いた場合、または更新を押すだけで済む長いデプロイサイクルにうんざりしている場合は、ぜひ試してみてください。ただし、アプリ全体を 1 つのライブラリだけに結び付ける前に、よく考えてください。

Vaadinについて通常の話では、クライアントとサーバ間の往復通信に関するウィジェットセットや悩みに関するます。

しかし、私の意見では、これはVaadinの最も重要な（おそらく革命）側面を見渡すことができます：それは完全に通常AJAXアプリケーションに要求されるクライアント - サーバ間の通信の設計と実装のタスク（「A」と「X」を排除）AJAXインチ

Vaadinで、あなたは完全にDTOの（データ転送オブジェクト）を忘れて、プロトコルベースのセキュリティ上の問題、遅延ロード例外などを休止することができます。

あなただけのあなただけのスイングとは異なるUIツールキットを使用している、定期的に古いJavaのSwingのデスクトップアプリケーションを書いて、いくつかの意味である。

私の経験から言えば、GWT は多くの定型コードを必要とし、複雑でリッチな UI を構築する場合に時間がかかります。通常、私たちは多くの永続化可能なドメインオブジェクトを保持する非常に複雑なアプリケーションモデルを扱います。このすべてのデータをクライアントに取り込むには、別のクライアントモデルを導入し、データ変換メカニズムを提供する必要があります。この目的で Dozer を使用しましたが、各フィールドをマッピングし、カスタムコンバータを作成し、これらすべてをテストするには時間がかかります。

一方、オーバーエンジニアリングに陥らず、アプリケーションがそれほど複雑でない場合は、クライアントリソースを活用してサーバーへの負荷を軽減できる可能性があります。このようにして、サーバーとの通信を大幅に最小限に抑え、ソフトウェアの応答性を大幅に向上させることができます。

Vadin は非常に開発者にフレンドリーに見えます :) しかし、サーバーに対する「大規模な AJAX 攻撃」が少し怖いです。私には ZK の経験があり、サーバーとの通信が必要なため、UI 上の簡単な操作の動作が遅い場合に、パフォーマンスの問題に直面することがよくありました。

Wicket も優れたフレームワークですが、Web サイトにより適しています。AJAX の有無にかかわらず動作し、検索エンジンによってインデックスを作成できます。そして、最も魅力的な点は、クリーンな HTML コードを扱っていることです。カスタムタグや制御構造はなく、懸念事項が厳密に分離され、コンポーネントには特定のウィケット名のみが使用されます。

それは主にあなたのニーズによって異なります。

超高速でシンプルなアプリケーションが必要な場合 - GWT を使用し、クライアントリソースを活用します
アプリケーションが Vaadin よりも非常に複雑な場合は、より良い選択肢と思われます
アプリケーションがパブリックであり、SEO のためにインデックスを作成する機能が必要な場合は、Wicket を選択してください。

の事はvaadinの..深刻な発展のために、あなたは一人でDTOSが..私は、私はワイヤーで何が起こっているかをより細かく制御をしたいという理由だけで継ぎ目、およびサーバーサイドのUI概念を捨てていましょう、何も忘れることはできません私にとっての問題は、サーバー側で状態を有する、ということを正確です..

Vaadinとサーバ側の処理についての引数に似たコンポーネントの状態とスケーラビリティを管理するためのセッションを使用して自動改札について「懸念」がありました。私は、Javaコミュニティは、（とりわけ）Webフレームワークの電位を測定する方法については通常間違っていると、最後の10年間で学んできました。 GrailsのにJSFから、それは通常、本番アプリケーションの実行を取得するには、重複や非効率的な機能を備えたメモリのカップル百ギガバイトをとり、少なくともダースオープンソースのjarファイル。周りを見て、あなたは、ほとんどのWebホスティング企業がためにJavaテクノロジがWebフレームワークのために取っている不安定なパスの実用的なJavaオプションを提供していませんが表示されます。 GWT 2.1がまだあるため、コンパイル速度を使用するための痛みで、それだけで、最初からそこにあったはずMVPとデータテーブルと深刻になっています。私は、Wicketのが好きしかしVaadinは有望に見える...しかし、Javaフレームワークが行く方法を知って、私は、彼らはいくつかの点で足で自分自身を撮影すると確信しているが、私はそれが原因で重いサーバ側の処理であることはないだろう。

は、格好良いUI年代を構築するために、私はこれが移動するための方法だろうと言うでしょう。プラス、それは非常によく文書化されています。

私は数週間のためにそれを使用してきたと私は今のところそれのように本当にのの。コードは、最終結果が優れている、再良い、非常に論理的な構築をDOCS、固体である。

私は、すべてのデータベースの退屈を整理するためにHibernateとの組み合わせで、それを愛している。

プラス - 導入が容易（Tomcatので、あなただけの簡単なことではありません、ウェブインタフェースを介して、単一の.WARファイルをアップロードすることができます）。

また、コンポーネント指向のJavaのWeb UIフレームワークのためのにApache Wicketののような強い代替を検討する価値があります。 Vaadinは素晴らしいサウンドと、私はこの議論を損なうしたくありませんが、選択は良いことです。そこWicketStuffサイトのホームページ、さらにはオフにリンクされたソースとのいくつかの例だと、マニングからの優れた本は偉大なサードパーティのドキュメントを形成しています。

のMavenでビルドVaadinのデモを見てみましょう： http://asolntsev.blogspot.com/2009/11/vaadin-demo.html の

私はそれが効率的に動作させるためにしようと、うつ病（冗談）を開始するまでのWicketは、進むべき道だと思いました。その後、私は素晴らしく見えたGWTに切り替えますが、そこに書き込むための多くのボイラープレートコードがサイコーで、ドキュメントがその素晴らしいではありません... - >光がVaadinから来た：シンプル、運用、ないバグ今のところ... !!!

主に（とりわけ）大のJava SWの家である当社では新しいウェブベースのproduct.Itを作成する機会が私たちにそこに来た製品の集合であり、この開発3カ国で多くのチームがありました。それが私たちのチームに来たとき、私はexperience.IたちのJava開発を活用するの利益のためにVaadinを使用しての選択は、私の決定で私を助けるためにGoogleを検索していました。また、私はこの記事を読んで。しかし、私は他の多くのチームがVadinを選んだもののVaadinを使用しないことを選択しました。以下は、私は、製品（Vaadin Toまたは未）で開始する前に、その時点での送信メールからの理由があります。これは私の個人的な見解や一般的な枠組みへの不信感から、様々な程度に私の中で常にあります。だから、読者にこの質問に別のテイクを与えたいと思っています。

さて、私たちは学習まくる学習HTML、CSS、CSSセレクタ、素晴らしい言語JavaScriptとJS LIBS、jQueryとYUIに行き、完全なGUIとパフォーマンスのコンプライアンスと時間でWeb製品を作成しました。そして、私は個人的に私は満足しているし、チームはユーザーだけでなく、同様である。

Vaadinの道を行った他のチームも時間に自社製品を作成したと私は同じように満足していると思います。（彼らだけが:)彼らが欠けているのJavaScriptの喜びを知りません）。

誰かが言ったように、すべての抽象化は、漏洩の抽象化であり、彼らはVaadin 7にVaadin 6から移行するために持っていたとき、彼らはかなりの再作業をしなければならなかったし、それは誰もが思ったよりも時間がかかりました。もちろん、彼らはそれを挽くとfinshことに成功しても、それでも遅延の少しは、私はチームがそのために（$$）関連Vaadinチャートアドオンや変更を購入させるVaadin 7をサポートしていませんでしたInvientChartsアドオンといくつかの問題があったと思うによるthis.Alsoにありました....

のののの
Vaadin Toまたはありません
のそれをVaadinで基礎となるのJavaScript、HTMLとCSSを動的にJavaのSwingのタイプのアプリケーションから生成されているようです。ビューのバイアスされ、おそらく愚かな純粋主義者の観点から、例えば、「私はあなたのためのコードを生成します」のキャッチフレーズは、良いデザインの香りを与えるものではありません。あなたはまだ他のフレームワークと提携なぜ抽象化を必要としない限り。任意のコード生成フレームワークと同じように、それはVaadinを念頭に置いていた抽象化のための最善を動作しますが、非常に柔軟ではないはずです。つまり、HTML、CSSおよびJavaScript / JavaScriptライブラリをではなく、抽象化の別のレベルに依存する - - Vaadinフレームワーク私たちは、ウェブテクノロジーをすれば、それは技術が興奮していてそれらのツールや言語で行うのがベストであると感じています。私は、Googleの示すコンパイラは、あなたの手コード化されたものよりも、最も最適化されたJavaScriptを生成すると思いますので、これは専門家GWTやVaadin開発者にナイーブ感じるかもしれ、より優れた複数のチームなど（しかし、ほとんどはかなり大きめのWebアプリケーションを開発する場合）、より良い開発者間でコードを管理することができます生産性、容易なデバッグなどウェブ開発のためのJavaScript（サーバ側で速い勢いを増し - - しかしVaadinのためにJavaでコンポーネントを記述して、JSに変換する自動私たちの開発者の多くには適切ではないと感じていることは非常に重要なプログラミング言語を学ぶことは決してありませんのNode.js ）。 JavaScriptの取得するためにフレームワークに依存する場合には右のように、あなたはその言語に秀でることはありません。私は、製品ベースの会社のためではなく身をもってウェブの言語を習得することが重要であると思います。誰かがコメントしたようJavaはyester年のCOBOLのようになっており、能力のためのJavaScriptのような他の重要な言語を学ぶために構築が不可欠です。 JavaScriptのユニット - - JSTestDriver、およびJSHintを実行し、で動作するようにかなり強力な言語ですが、私が持っている短い時間のためにJSで働いていた、私たちはいくつかの規律（モジュールパターン）でコーディング、テストのすべてのロジック場合ことに気づきましたそれが学習された後、および生産性は、Javaよりも良くなります。また、重要なコンポーネントの例のほとんど - OpenLayersをはJSで書かれている、あなたはこれらまたはWORを延長する必要がある場合JavaScriptを知っている、またはD3.jsのようなそのことの強力なライブラリをする必要が最適でkは利点の多くは、Vaadinやフレームワークを使用してありますが、そう簡単に言えば、長期的には多分JavaScriptを使用して重要なのですか？の

私もVaadinを使用しています。アプリケーションは、私は新しいツールを開発していた一般的によく文書化され、与えられた、私は本当に経験について言っていますが、APIは一貫していたということでした、大規模ではありませんが、私は非常にのためのものをクランクすることができました>私が前に使用したツールと同じ、またはいくつかのケースでは、より良い時間枠でクライアントを要求します。

非常にいくつかの問題。一つだけは今、クライアントがIE 7を使用して主張（聞かない）と愛好家の目キャンデーのいくつかは、アドオンコンポーネントの（チャート）での完全に100％に動作しませんです。

ところで、私はどちらかVaadinのために動作しません： - ）

私は自動改札とVaadinの両方を試してみました、あなたは本当に月にしていくつかの時間のための両方を、試す場合は、Vaadinが行くとないウィケット、期間する方法であることを知っているだろう。 - Dheeraj G

私が働くところ我々はウィケットを見てきましたが、我々は代わりに9000個のファイルを見つけ、我々は30,000人以上持つことができます。当社は、当社のコア金融サービスアプリケーションとの約1,000スクリーンを持っているし、Wicketのは偉大に見えるが、私たちのStruts 1.3のコードが改札に変換することは極めて困難です。私たち建築家は、POCプロジェクトを行なったし、ちょうど3画面は（多くは再利用するためのものである）数百のクラスを追加しました。あなたのhtmlは、Javaコードとその逆と一致する必要がありますので、それはウィケットで画面をprotoypeすることも困難です。

Vaadinは有望に見えるが、それはチームの押し売りになります。

P.S。それは業界で使用されていない場合、どんなにフレームワークがどのように偉大な、誰もがそれを学ぶません。 Wicketのは非常に少数の企業がそれを使用し、まだしばらくの周りされています。私が話をほとんどの開発者は、履歴書に役に立たない新しいフレームワークを学ぶと懸念している。

重要なのは、Vaadinは、スイングのような設計を採用している、それは私がスイングを使用してJavaで始まっていることに役立ちます。

（ないVaadin;）
私は私が働いている会社でgiftadvisorを開発するVaadinを使用しています。

Vaadinあなたは本当のコンポーネント化Swinglike Webアプリケーションを構築することができます。
あなたはすべてのクリックのためのクライアント・サーバ・ラウンドトリップを懸念している場合は、
私が言って、これを持っている：私ははい、マウスオーバーのボタンの外観を変更するマウスオーバーボタンを作成しました。このためのフレームワークは、サーバーとバックに行かなければなりません。そして、それは芋十分に速く動作します。私が何を意味するかチェックするために http://www.cadeau.nl/sophie のを参照してください。

私はそれが私のニーズをスイートとWebプログラミング風になり、Vaadinが好きます。

よろしく、ロブ。

私はわずか2日前にVaadinを始めと、持続性のためのOSGiサービスを結合モジュール性、データとの完全なOSGiの上の小さなCRUDアプリケーションを構築することができました。一つは本当に良いところは、私の完全なUIは、コードの唯一の118行で、単純なJava Beanの構造のための完全なCRUD操作をサポートしていることです。

Vaadinは、OSGiの中で完璧に動作することもいいです。これは、すでにバンドルだと私は、OSGiで使用するvaadinが極めて容易になりニール・バートレットから小さな橋を見つけます。

を参照してください。のrel="nofollow">

私は、サーバー側の状態を使用して、心をいけません。それは、その目的を果たします。クラウドコンピューティングでは今-日間貯蔵および帯域幅が安くなってきています。しかし、ええ、私はあなたのアプリケーションをRESTifyしたい場合は特に優れた設計の観点からあなたのポイントを見ることができます。しかし、私はVaadinなどに関する短所よりも長所があると信じています。あなたは私のようなバックエンドの方に向いている場合は特に - 一つの大きなものは、あなたが特定のブラウザのためのあなたのWebアプリケーションについて多くはJavascript / CSSの複雑さのために、IEそれを呼び出すことができます微調整する必要がいけません。すべてのあなたのWebアプリケーションは何も心配することなく、ブラウザ間の互換性になります。開発者の時間は、ストレージと帯域幅よりも高価であることを忘れないでください。私の意見のthats。 =）

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow