クライアント側で行われるWebアプリケーションの作業がますます増えています。 UI操作、入力前検証（検証の最後の手段ではない）、ウィジェット、エフェクトなどWebアプリケーション：クライアント側のドメインロジック
ドメインロジックをJavascript/GWT/anythingで書かれたクライアント側に置くことにした場合それ以外は？サーバーはデータベースインフラストラクチャを提供するだけです。
これは実行可能ですか？このアイデアに対する経験、アドバイス、または意見はありますか？
編集： もしあなたが突っ込んだとしても、applicationsの全文をphp/python/java/whateverの行なしで書くことが可能であることが分かります。
これらのことはすべて素晴らしいですが、誰かがJavaScriptを無効にすると、データベースでユーザーが混乱する前に、サーバー上の入力を処理して検証できる必要があることに注意してください。だから、あなたが望むものをクライアント側に置くことができますが、サーバー側でもそれを検証する必要があります。
これは私の意見では実行可能なアイデアではありません。これにはいくつかの理由があります。
すべてのすべてで、クライアント側のコードは、Webサイトのセキュリティとアクセシビリティためには、二つの技術をする必要があり、Webページの感触よりもフィーリングのような複数のアプリケーションをユーザーに提供するために本当にいいですしながら、両方とも実装されている。
少なくとも、あなたが一貫性とスピードを目指しているなら、それは実行可能ではないと思います。多くのロジックをJavascriptと言えば、SLOWクライアントを意味するBrowserの多くの作業が発生します。また、すべてのブラウザが少し癖があることを忘れないでください。
他のポスターとは正反対です。実際には、私はちょうどそのようなscrabble board gameを実装しており、ほぼ完全にクライアント側のロジックを使用しています。実際、クライアント側でさらに集中的にするために、私がしたいことがたくさんあります。 GMailはクライアント側で膨大な作業をしています。
しかし、実用上の理由から、サービス側で管理する必要があるものがいくつかあります。たとえば、サーバーはユーザーにいくつかのタイルを渡す必要があり、ユーザーはサーバーにそのタイルを配置する場所を伝えることができ、サーバーはクライアントを完全に信頼することができないので、サーバーはそれらのスロットが空であることを確認する必要があります（クライアントは常にハイジャック、そうでなければスクリプトを通してHTTPトラフィックを盗聴して変更する）。
ADO.NET Data Servicesのように、RESTfulインターフェイスを使用してDBにCRUD操作を公開する技術や、JavaScriptを使用してデータオブジェクトを直接格納/管理するCouchDBなど、多くの技術があります。また、jQueryやMoo Toolsのようなリッチクライアント側のライブラリは、クライアントがますます多くのことをするように推進しています。
あなたはそれについて考えるならば、クライアント側ですべてのUIと対話の作業を行うことについてフラッシュがたくさんあります。 Adobe Flexアプリケーションの一部は素晴らしいものです。私は最近、グラフをレンダリングするGoogleアナリティクスにピボットを使用し、クライアント側のすべてを使用しました。サーバーはデータを処理します。それでも、Google GearsとFirefox（私は信じていますか？）は、クライアント側のストレージを提供しています。
アプリケーションや使用方法に応じて、コードを再利用します。
クライアントサイドのJavaScriptは、実際にはウェブブラウザに固有のものです。
ドメインオブジェクトとエンティティは、他のアプリケーション（デスクトップ、Webサービスなど）
アプリケーションがますます大きくなっている場合、ダウンロード時間が長く、長くなりますときには言及しないで再利用することができます。
もちろん、誰でもあなたのコードをコピーしてコピーして、すぐにあなたのアプリをクローンすることができます。
公開されている（公開されていない）Webアプリケーションの場合、誰かがあなたの防御をチェックしようとするまでには時間がかかります。 JavaScriptの検証は、最初に行くでしょう。ブラウザーで無効にすることもできますし、アプリケーションで作業中に無効にして有効にすることもできます。
実際には3段階の検証が必要です。
UI検証（オプション）：ユーザー入力の初回チェック。サーバの往復なしのクイックレスポンス - >ユーザは満足しています+あなたのサーバは何らかの無効なリクエストから既に解放されていることを嬉しく思っています。
サーバー側の検証（必須）。ここでは、すべての検証が再びビジネスロジックルールになります。必要なものをチェック/検証/実行するために、標準ライブラリやサードパーティのライブラリにアクセスする必要があります。 BLレベルでデータの整合性を実現します。
データベースレベルの検証（非常に望ましい）。防衛の最後の境界。外部キー/ユニークキー/等の使用によるデータの完全性の保証。制約+複数の並列要求からのトランザクションレベルの保護により、BLレベルの整合性が突然破棄されます。
これを正しく実行するには、その方法が必要です。パフォーマンスの改善に100msのための短い、最新のWebアプリケーションの闘争でhttp://www.websiteoptimization.com/speed/tweak/psychology-web-performance/
：
現在のWebアプリケーションのパフォーマンス分析上の素敵な要約を見つけることができます。このような短時間では、http待ち時間に依存するのはすでに問題です。だから、多くのロジックが、クライアントとのやり取りの際にHTTPコールの数を減らすためにクライアント側に移動しています。
複雑なクライアントサイドコードを構築するのに役立つフレームワークがいくつかあります。初めは、jQuery（UI）、Dojo、MooTools、Prototypeなどです。これらは汎用フレームワークであり、あらゆる種類のクライアント側ロジックに適しています。
より正確：
を結合、クライアント側のレンダリングとデータが異なるフレームワークの包括的な概要はhttp://codebrief.com/2012/01/the-top-10-javascript-mvc-frameworks-reviewed/
ここにあります