Vaadin Frameworkを使用する必要がありますか
Vaadin Framework で遊んでみましたが、とても使いやすいようです。さらに、私が彼のフレームワークで気に入っているのは、 Google Web Toolkit（GWT） の上に構築されていることです。
このフレームワークを使い続けるべきですか、それともGWTに固執する方が良いと思いますか？
ねえ。免責事項として、私はVaadinを開発している会社で働いています。
Vaadinは、GWTでプリコンパイルされた一連のコンポーネントを持つ方法でGWTを使用します。もちろん、必要に応じて独自のコンポーネントを追加で作成することもできます。ただし、コンポーネントのセットは非常に完全であり、多くの場合、独自のニーズに合わせてカスタマイズできます。これは、アプリケーションを変更するたびにJavaからJavaScriptにコードを再コンパイルする必要がないことを意味します。すでに利用可能なコンポーネントを組み合わせるだけです。
フレームワークはサーバー駆動型であるため、すべてのロジックはサーバー側で処理されます。コンポーネントには、クライアントファイルとサーバーファイルの2つの部分があります。クライアント側は、コンポーネントの単なる「ビュー」です。一度対話すると、サーバーにメッセージが送信され、これが押された/書き込まれたなどのメッセージが送信されます。その後、サーバーは何をすべきかを決定します。これは、セキュリティを強化するためです。リクエストを送信するための小さなAPIのみがjavascriptで利用可能であるため、ロジックを「ハッキング」できません。これは場合によってはアプリケーションの速度と少しトレードオフになるかもしれませんが、それほど悪いことではないと思います。最悪のスピードバンプは通常、dbクエリの往復などであり、UIフレームワークの選択とは何の関係もありません。提案されたデモの動きが遅いのは、サーバーから遠く離れているか、現時点でユーザーのヒットが多いためです。独自の環境で試して、アプリケーションの最終アプリケーションを閉じて、パフォーマンスを確認してください。テストするためにデプロイできる、すぐに使えるアプリケーションがいくつかあります。
その選択は、あなたがやろうとしていることに要約されると思います。 VaadinはWebアプリケーションに適しています。通常のJavaアプリケーションを構築して、そのための動的なWeb UIを簡単に実行できるためです。ユーザーがページを表示するだけである従来のWebサイトのように、積極的にやり取りする以上のことを行う場合、Vaadinは最善の方法ではありません。 Railsやphpフレームワークなど、他の無料のフレームワークを使用してください。GWTを使用していることを示唆しているので、Vaadinが良いはずです。
ここで、Vaadinフォーラムまたはircチャンネル#vaadin @freenodeで質問をしてください。Vaadinを使用する理由または使用しない理由について、さらに多くの理由を教えてくれるかもしれません。
MVP、EventBus、CommandPatternなど、最後のGoogle I/Oで学んだベストプラクティスを使用して、ほぼ1.5年ほどそれほど大きくないGWTアプリケーションを開発した後、心の底からこう言います。 UiBinderのリリース後も、チームとクライアントが技術的および視覚的に望んでいた方法で物事を解決するために、Vaadinはトンネルの終わりの光のように私に来ました。
コマンドパターン、1,000のプレゼンターとビュー、1,000のイベントハンドラーなど、ほぼ1,000の定型的なアクションを記述した後、これらのクラスの75％近くを処理する必要はなく、優れたパターンアプローチを維持します（appfoundationアドオン）。わずかなネットワークオーバーヘッドが許容されます。すぐに使えるVaadinを使用すると、優れたウィジェット、ページング、データバインディング、完璧なレイアウトが得られます。何のためにこれのすべて？サーバー側のメモリ消費量がいくらか増えました。
私は次のFacebookなどを構築していないので、これは受け入れられると言えると思います。中型サーバーごとに数千の同時ユーザーを処理できますが、低遅延の往復を維持できます。
Vaadinを使用すると、ほぼ半行のコードでNiceアプリを構築できますが、それでもアプリケーションはより完全に見えます。 :-)
!!更新2011年2月23日：各フレームワークの制限をどのように認識すべきかを強調することはできません。 Vaadinも同様です。 Vaadinはあらゆる形式のHTMLまたはJavaScriptを抽象化することに注意してください。また、結果のHTMLは非常に重いため、履歴状態の変更は自分で処理する必要があります。したがって、プロジェクトをビルドするときは、これらのオーバーヘッドに注意してください。
免責事項：私はこれから言及するライブラリのどれとも提携していませんが、たまたまそれらの周りの私のやり方をよく知っています。
あなたと同じように、新しいプロジェクトにどのスタック/フレームワークを使用するかを考えると、この投稿に出くわしました。 Playで確かな経験がありました！ （わかりました、Scalaでは、それはここでは関係ありません）が、魅力的なウィジェットと、サーバー側+ Swingのような開発とのシームレスな統合は、私の興味をそそりました。それは2010年後半であり、答えが私にVaadinを試してみるように確信させたので、私は戻って来て、ここで読みたいと思う答えを書くことに決めました。質問は今日でも関連しているので。一方、Vaadinはバージョン6から7に移行し、いくつかの注目すべき改善が必要でした。Play！バージョン1から2になり、私（+小さなチーム）は両方のフレームワークで少数の成功したプロジェクトを完了しました。
比較は興味深いと思います。なぜなら、両方のフレームワーク
- jVM上で実行し、豊富なエコシステムを活用できます
- webアプリケーションへのアプローチと、開発者が気にする必要のあるものについて、これ以上対立することはありませんでした。
- それほどではありませんが、Java EEとの関連性。
賞賛
ある文で、基盤となるHTTPリクエスト/レスポンスメカニズムから完全に抽象化されながら、デスクトップアプリケーションをブラウザに移植するというアイデアを見つけた場合、VaadinはおそらくWebアプリケーションを作成する候補です。プログラミングに対するSwingのようなアプローチは、低レベルのHTMLおよびJavaScriptから最も離れている人にとっては簡単です。アプリへの新しいリクエストは実際に新しいインスタンスを開始し、フローの残りはあなたとあなたのロジック次第です。リンクはナビゲーション用の古き良きボタンに戻り、HTMLやCSSを微調整する必要なく、多くの組み込みテンプレートを使用してレイアウトを自由に作成できます。 APIは一般的に非常に一貫しており、明らかに文書化されています（ Book of Vaadin は必須の読み取りです。たとえば、Beanをコンポーネントやバリデーターにバインドするなど、多くのものがすぐに利用できるので徹底的に実行してください。 ）。ウィジェットは、ブラウザ間の互換性が全体的に優れているため、幅広いクライアントでアプリケーションの一貫した動作を保証します。
リアリティチェック
Vaadinアプリの開発とテストには良い時間を過ごしました。最初のバージョンをリリースし、フィードバックを収集し始めたとき、物事はより明確で微妙になりました。 実際にはかなり基本的な方法でバイアスがかかっていたことがわかりました、つまり：
201xでは、ほとんどのユーザーがWebを使用してきた長い歴史があり、実際にはデスクトップアプリをほとんど使用しないユーザーはほとんどいません。ここで重要なのは、ブラウザは、ハイパーテキストリンク、戻る、進む、リロードボタン、ユビキタスタブ、場合によってはウィンドウ、およびほとんどのアクションがHTTPリクエストをトリガーし、応答。これは、Webサイトがその周辺に構築される暗黙の契約です。そのため、ユーザーが以前のように戻る/進むボタンを使用できない、またはタブが期待どおりに機能しないと苦情を言ったとしても驚かないでください。そして同意しました。ユーザーとブラウザをバインドする目に見えない契約を破りました。実際、私たち自身は暗黙的に Vaadinアプリで他のWebサイトで使用したようにブラウザーを使用していませんでした。もちろん、前述の本に戻って、URLフラグメントを使用してWebナビゲーションエクスペリエンスを複製することを注意深く読んでみると、実際には予想よりも複雑であることがわかりますVaadinアプリはステートフルですさらに、Play！とは対照的に、MVCまたはMVPパラダイムは開発者に緩く課せられているだけです。他のオプションはほとんどありません。これを軽んじてはいけませんが、ページの変更後、ほんの一瞬、脳は明るい白い画面に慣れています。ユーザーがクリックして新しいページが表示されると、ブラウザは砂時計（またはそのバリエーション）を表示して確認します。 AJAXでは、リクエストはバックグラウンドで行われます。今日、小規模でほとんど外科的なAJAXストライキが標準になっている場所がありますが、主要なUIの更新はまだありません。
ステートフルアプリは、課題とトラブルを共有します。負荷分散（懸念がある場合）は、より複雑です。 Vaadinセッションは多くのリクエストにまたがるため、トランザクションの概念はまったく異なり、したがってRESTベースのアプローチとは対照的に長くなりますが、UXに関しては比較的短命です。実際、ユーザーが時間前に開始したフォームに戻ってタスクを完了することは珍しくありません。これは、理論的にはVaadinでも機能しますが、メモリが常にブロックされた状態で長時間セッションを維持する必要があり、これがw.r.tをスケーリングすることについて慎重に検討する必要があります。同時ユーザー。
ブックマークは言うまでもなく、ステートフルページはユーザーが共有するのも難しくなります（URLフラグメントを扱ったと仮定します）。
最後に、サーバー上にあるロジックではUIが一般的に遅くなるという印象を共有します。もちろん、ラウンドトリップの回数を減らすためにクライアント側のJavaScriptをロードしたウィジェットを常に作成できますが、必然的にサーバー上でUIを更新する必要があります。 JSは私の経験では解釈するのが既に非常に重く、モバイルデバイスでのエクスペリエンスは低下します（TouchKitには気づいていますが、それでもモバイルデバイスのHTML5アプリはそれをカットしません）。また、UIスレッドはリクエストがポストされた後（つまり、UI更新のプルに似たクライアント側でのユーザーアクション）にアクティブになり、さまざまなリスナーからアクセスできることに注意してください。ただし、バックグラウンドスレッドからUIを更新するのはより複雑です（更新のプッシュなど）。 Vaadin 7はこの点で状況を改善しましたが、特にが比較的/軽いHTMLを生成しました。 HTTP圧縮をオンにするだけで、UIの反応性が大幅に改善されました。
結論
だから私たちは立ち止まって、最初にVaadinアプローチで何がそれほど魅力的であるかを考えました。最初の開発は比較的スムーズな乗り心地で、結果は速かったが、Web UXの期待に対応するためにいくつかの概念を作り直し、潮に逆らって泳ぐという強い印象を与えた。 HTTPリクエスト/レスポンスメカニズムから抽象化（あいまいに？）される誘惑的なアイデアは、ウェブアプリとデスクトップアプリの間の実際のインピーダンスミスマッチを明らかにする両刃の剣を証明したと結論付けました。
Webがさらに別のレイヤーであるように振る舞うのではなく、その動作方法を受け入れるべきだと強く感じましたそしてこれはURL中心のアプリケーションを持つことから始まります（Rails/Django/Playによって課されるように）。おそらく、データがアプリケーションよりも寿命が長いという誰かの声を聞いたことがあるでしょう。今日では、データはURLリソースによって参照されるため、URLはデータよりも有効であると安全に言えます。結局のところ、それらは人々がブックマークするものですよね？したがって、懸念の基本的な分離もこのレベルで適用する必要があります。これがおそらくウェブがそもそもとても人気を博した理由です。そこで、異なるリソースパス上で行われたPlay àla Play のアクションに応答する中央コントローラーを中心にアプリを再構築しました。
今のところ、Vaadinアプリをメンテナンスしていますが、これらの制約のいくつかと基本的なパラダイムシフトのため、新しいプロジェクトを開始することはありません。ただし、技術的に一貫性があり、まとまりがあり、十分に文書化された360°Java Webフレームワークを構築したチームには敬意を払います。利点として、彼らはコンサルティングサービスを販売している会社で彼らの枠組みさえ支持しています。この経験と、それがWebアプリケーションに対する私の見方を再評価してくれたことに感謝しています。その進化を注意深く監視しますが、より多くの制御と粒度が必要です。
いつかVaadinが、独自のHTTPサーバーを必要とするサーブレットアーキテクチャ全体から解放されることを願っています。フレームワークにより深く根ざしたMVC設計がさらに良いでしょう。しかし、EEだけを誓うベテランの企業Javaゴリラの間で有利なニッチを見つけたように見えるので、それは予見可能な未来ではいくぶんありそうもない。輝いて。
TL; DR：Vaadinは、webappが何であるか、さらに重要なこととして、それらがどのように振る舞うべきかという点を見逃していると思います。プログラマーがWebを採用し、ユーザーがWebを操作する方法（つまり、戻るボタン、再読み込みボタン、タブ、ブックマーク）についてです。 WebアプリがHTTPリクエストとセマンティクス（動詞）に近いほど、ユーザーの期待に一致する可能性が高くなります。それが鍵です。
EDIT：Pythonの経験がある場合は、Flaskも試して、URL中心のRESTベースのWebアプリケーションプログラミングのフレーバーを取得することを強くお勧めします。 。
編集2：何らかの理由で、フルスタックのVaadinライクなフレームワークを使用する必要があると思われる場合は、Meteorを試してください。これは、WebSocketを介して非同期通信が発生するNode.jsで実行されるJavaScriptベース（フロントエンドとバックエンドの両方）のフレームワークであり（したがって、要求/応答よりも待機時間が短い）、デフォルトでリアクティブです。 Vaadinで嫌いなものの多くは、Meteorで対処されています。たとえば、UI更新のロジックはクライアント上で実行されるため、Vaadinよりも応答性が大幅に向上します。 JavaScriptコミュニティとJavaコミュニティの人々はあまり交差していませんが、私が最初にそれを聞いたとき、Vaadinとの類似点がすぐに私を襲いました。現在、コミュニティ内でかなりの勢いを享受しているのは、Vaadinを人気にした理由と同様の理由です。デスクトップのようなWebアプリを作成する機能。 Javaが将来のWebアプリの写真にあまり含まれていないことに気付いた場合や、更新を行うのに必要な長い展開サイクルに疲れている場合は、試してみてください。ただし、アプリ全体を1つのライブラリに結び付ける前によく考えてください。
Vaadinについての通常の話は、ウィジェットセットに関するもので、クライアントとサーバー間の往復通信に関する心配です。
しかし、私の意見では、これはVaadinの最も重要な（おそらく革命的な）側面を見落としています。通常、AJAXアプリケーション（ "A"およびAJAXの「X」）。
Vaadinを使用すると、DTO（データ転送オブジェクト）、プロトコルベースのセキュリティ問題、Hibernate遅延読み込み例外などを完全に忘れることができます。
ある意味では、通常の古いJava Swingデスクトップアプリケーションを書いているだけで、Swingとは異なるUIツールキットを使用しているだけです。
私の経験から、GWTには多くの定型コードが必要であり、複雑でリッチなUIの構築には時間がかかります。通常、多くの永続可能なドメインオブジェクトを保持する非常に複雑なアプリケーションモデルを扱います。このすべてのデータをクライアントに提供するには、個別のクライアントモデルを導入し、データ変換メカニズムを提供する必要があります。この目的のためにDozerを使用しましたが、各フィールドのマッピング、カスタムコンバーターの作成、およびこれらすべてのテストに時間がかかります。
一方、オーバーエンジニアリングに陥らず、アプリケーションがそれほど複雑でない場合は、クライアントリソースを利用してサーバーへの負荷を軽減することができます。このようにして、サーバーとの通信を劇的に最小化し、応答性の高いソフトウェアを取得できます。
Vadinは非常に開発者のように見えます:)しかし、私はサーバーへの「大規模AJAX攻撃」を少し恐れています。私はZKの経験があり、サーバーとの通信が必要なためUIの些細な操作が遅くなるとパフォーマンスの問題に直面することがよくありました。
Wicketは別の優れたフレームワークですが、Webサイトにより適しています。 AJAXの有無にかかわらず動作し、検索エンジンでインデックスを作成できます。そして、最も魅力的なのは、きれいなHTMLコードを処理することです。カスタムタグ、制御構造、懸念事項の厳密な分離、およびコンポーネントの特定のwicketidナグだけです。
それは主にあなたのニーズに依存します：
- 超高速でシンプルなアプリケーションが必要な場合-GWTを使用し、クライアントリソースを利用する
- あなたのアプリケーションがVaadinよりも非常に複雑な場合は、より良いオプションになります
- アプリケーションがパブリックであり、Wicketを選択するよりも、SEO用にインデックスを作成する機能が必要な場合。
問題は、深刻な開発のために、dtosはもちろん、何も忘れることができないということです。.まさにそれであり、サーバー側に状態を持っています。
セッションを使用してコンポーネントの状態とスケーラビリティを管理するWicketには、Vaadinおよびサーバー側の処理に関する議論と同様の「懸念」がありました。私は過去10年間、Javaコミュニティが（特に）Webフレームワークの可能性を測定する方法について通常間違っていることを学びました。 JSFからGrailsに至るまで、通常は数百GBのメモリと、オーバーダクションで非効率的な機能を備えた少なくとも12個のオープンソースjarファイルを使用して、本番アプリケーションを実行します。周りを見てみると、ほとんどのWebホスティング会社は、WebフレームワークでJavaテクノロジーが採用している不安定なパスのため、実用的なJavaオプションを提供していません。 GWT 2.1は、コンパイル速度のために使用するのがいまだに苦痛であり、最初から存在していたはずのMVPとデータテーブルで深刻になっています。私はWicketが好きですが、Vaadinは有望に見えます...しかし、Javaフレームワークがどのように動くかを知っているので、ある時点で足元で自分自身を撃つと確信していますが、サーバー側の処理が重いためだとは思いません。
見栄えの良いUIを構築するには、これが最善の方法だと思います。さらに、非常によく文書化されています。
Apache Wicket をコンポーネント指向のJava Web UIフレームワークの強力な代替手段として検討することも価値があります。 Vaadinの音は素晴らしく、この議論を邪魔したくありませんが、選択は良いことです。ホームページからリンクされたソースを含むいくつかの例があり、WicketStuffサイトにはさらに多くの例があります。また、Manningの素晴らしい本は素晴らしいサードパーティのドキュメントを形成しています。
私は数週間それを使用してきましたが、私は本当にこれまでのところ気に入っています。コードはしっかりしており、ドキュメントは非常に論理的で非常に論理的な構造であり、最終結果は優れています。
Hibernateと組み合わせて、すべてのデータベースの面倒を整理するのが大好きです。
プラス-簡単にデプロイできます（Tomcatを使用すると、Webインターフェースを介して単一の.WARファイルをアップロードできます。これ以上簡単ではありません）
主に大きなJava SWハウスである当社では（特に）、新しいWebベースの製品を作成する機会がありました。製品のセットであり、3か国に多くのチームがありました。これを開発しています。私たちのチームに来たとき、Java開発経験を活用するためにVaadinを使用することを選択しました。私もこの投稿を読みました。しかし、他の多くのチームがVadinを選択したにもかかわらず、私はVaadinの使用に反対しました。以下は、製品を開始する前にその時点で送信したメールの理由です（Vaadinかどうか）。これは私の個人的な見解であり、フレームワークへの不信感は常にさまざまな程度で私にあります。そのため、読者にこの質問について別の意見を述べたかっただけです。
さて、HTML、CSS、CSSセレクター、すばらしい言語のJavaScriptとJSライブラリ、JQueryとYUIを学習し、GUIとパフォーマンスに完全に準拠したWeb製品を作成しました。個人的には嬉しいですし、チームもユーザーも満足しています。
Vaadin方式を採用した他のチームも時間内に製品を作成し、同様に満足していると思います（JavAScriptの喜びを知らないのは彼らだけです:)）。
誰かが言ったように、すべての抽象化は漏れやすい抽象化であり、Vaadin 6からVaadin 7に移行する必要がある場合、かなりの再作業を行わなければならず、誰もが思っていたよりも時間がかかりました。もちろん、彼らは何とか粉砕して仕上げました。それでもこれには少し遅れがあり、また、InvientChartsアドオンに問題があり、Vaadin 7をサポートしていないため、チームが関連するVaadin Chartsアドオンを購入（$$）して変更することになったと思います...
VaadinまたはNot
Vaadinでは、基礎となるJavaScript、HTML、およびCSSはJava Swingタイプのアプリケーションから動的に生成されるようです。偏った、おそらくばかげた純粋主義の観点からすると、このような「私はあなたのためにコードを生成します」というキャッチフレーズは良いデザインの匂いを与えません。抽象化が必要でない限り、なぜ別のフレームワークと提携するのか。他のコード生成フレームワークと同様に、Vaadinが念頭に置いた抽象化には最適ですが、柔軟性はあまりありません。 Webテクノロジーを使用する場合、別の抽象化レベルであるVaadinフレームワークに依存するのではなく、テクノロジーが喚起したツールや言語（HTML、CSS、JavaScript/JavaScriptライブラリ）で行うのが最適だと思います。グーグルのコンパイラーはあなたのコードよりも最適化されたJavaScriptを生成するので、GWTやVaadinのエキスパート開発者にはナイーブな気がするかもしれません。しかし、VaadinのJavaでコンポーネントを記述してからJSに自動変換することは、開発者の多くがWeb開発用のJavaScript（JavaScriptそして、サーバー側で急速に牽引力を得ています– Node.js）。フレームワークに依存してJavaScriptを正しく使用する場合、その言語でExcelを実行することはありません。製品ベースの会社では、代わりにウェブの言語を直接学ぶことが重要だと思います。誰かがコメントしたように、Javaは昨年のCOBOLのようになっており、JavaScriptのような他の重要な言語を習得する能力の構築が不可欠です。しかし、JSで少しの間働いていたので、何らかの規律（モジュールパターン）でコーディングし、すべてのロジック（JavaScriptユニット-JSTestDriver）をテストし、JSHintを実行すると、かなり強力な言語であることに気付きました、そして学習されると生産性はJavaよりも良くなります。また、ほとんどの重要なコンポーネントの例– OpenLayersはJSで記述されており、これらを拡張するか、最適に動作する必要がある場合はJavaScriptを知る必要があります。D3.jsのような強力なライブラリVaadinとフレームワークを使用する場合、長期的にはJavaScriptを使用することが重要ですか？
Wicketが効率的に機能するようになり、うつ病（ジョーク）が始まるまでは、Wicketが前進すると考えていました。それから、私はGWTに切り替えましたが、見栄えはよかったのですが、ボイラープレートのコードを書くのは非常に多く、ドキュメンテーションはそれほど素晴らしいものではありません... !!!
mavenを使用したVaadinデモビルドをご覧ください。 http://asolntsev.blogspot.com/2009/11/vaadin-demo.html
私もVaadinを使用しています。アプリケーションは大きくありませんが、この経験で本当に気に入ったのは、APIが一貫しており、一般的によく文書化されており、新しいツールで開発していることを考えると、非常に =以前に使用したツールと同じ、または場合によってはより良い時間枠でクライアントを要求します。
問題はほとんどありません。ただ一つは、クライアントがIE 7（質問しない）を使用することを主張しているだけで、一部の手の込んだアイキャンディは完全に100％動作しませんアドオンコンポーネントで （チャート）。
ちなみに私はヴァーディンでも働いていません:-)
私はWicketとVaadinの両方を試しましたが、実際に両方を試してみると、1か月後にはVaadinがWicket期間ではなく行く方法であることがわかります。 -ディーラージG
私はわずか2日前にVaadinで始め、モジュール化、データバインディング、永続化のためのOSGiサービスを備えたOSGi上に小さなCRUDアプリケーションを構築することができました。本当に素晴らしいことの1つは、完全なUIがコードの118行のみであり、単純なJava Bean構造の完全なCRUD操作をサポートしていることです。
VaadinがOSGiで完全に動作することも素晴らしいことです。それはすでにバンドルであり、OSGiでvaadinを非常に使いやすくするNeil Bartletからの小さな橋を見つけました。
タスクリストVaadinの例 を参照してください
私が働いているWicketを見てきましたが、9,000個のファイルの代わりに30,000個以上のファイルを見つけることができました。コアの金融サービスアプリケーションには1,000近くの画面があり、Wicketの見栄えは良くなりますが、Struts 1.3コードをWicketに変換することは非常に困難です。私たちのアーキテクトはPOCプロジェクトを行い、わずか3つの画面で数百のクラスを追加しました（多くは再利用用です）。 HTMLがJavaコードと一致する必要があり、その逆も同じであるため、Wicketで画面をプロトタイプすることも困難です。
Vaadinは有望に見えますが、チームにとっては難しい販売になるでしょう。
追伸フレームワークがどれほど優れていても、それが業界で使用されていなければ、誰も学習しません。 Wicketはしばらく前から使用されていますが、Wicketを使用している企業はほとんどありません。私が話すほとんどの開発者は、履歴書では役に立たない新しいフレームワークの学習に関心があります。
重要な点は、VaadinがSwingに似たデザインを使用していることです。これは、Swingを使用してJavaで始めたことに役立ちます。
私は、Vaadinを使用して、Vaadinではなく、勤務先の会社でGiftAdvisorを開発しました。
Vaadinを使用すると、実際のコンポーネント化されたSwinglike Webアプリケーションを構築できます。
あなたがクリックごとにクライアントとサーバーの往復を心配している場合、私はこれを言います：はい、マウスオーバーでボタンの外観を変更するマウスオーバーボタンを作成しました。このため、フレームワークはサーバーに戻って戻る必要があります。そして、それは十分に速く動します。 http://www.cadeau.nl/sophie を参照して、意味を確認してください。
私はVaadinが好きです。それは私のニーズに合っており、ウェブ開発を簡単にします。
よろしく、ロブ。
サーバー側で状態を使用しても構いません。それはその目的を果たします。現在のクラウドコンピューティングでは、ストレージと帯域幅が安くなっています。しかし、特にアプリケーションをREST化する場合は、良いデザインの観点からあなたのポイントを見ることができます。しかし、私はヴァーディンなどに関して短所よりも長所があると信じています。一つ重要なことは、特定のブラウザ向けにウェブアプリを細かく調整する必要がないことです。特に、私のようなバックエンドを志向している場合、Javascript/CSSの複雑さのためにIEを呼び出すことができます。すべてのWebアプリは、何も心配することなく、ブラウザ間で互換性があります。開発者の時間は、ストレージと帯域幅よりも高価です。それが私の意見です。 =）