GWTのキラキラと貧困（またはダーツを信じない理由パート2）

Habréで最も議論されたトピックの1つは、Javascriptを完全に置き換えると主張する新しいDart言語の作成に関するGoogleの発表でした。

Googleにとって、これはこの種の最初のプロジェクトではありません。 2006年以降、完全にJavaでWebアプリケーションを作成できるGoogle Web Toolkitがあります。 たとえば、AdwordsとGoogle Waveが機能します。

しかし、特に2006年の基準、機会によって、美しい約束と非常に深刻なにもかかわらず、GWTは決して「離陸」しませんでした。 はい、プロジェクトはサポートおよび開発されていますが、開発者のコ​​ミュニティはうまくいきませんでした。 サードパーティのコンポーネントはほとんどなく、サポートされていません。プログラマのシステムに精通するのは困難です。

Googleが現在宣伝しているDart言語のほぼすべての「バン」は、すでにWebtoolkitに実装されています。 この記事では、GWTの長所と短所を分析して、将来のDartの泥だらけの形を調べようとします。

目標と目的

プログラマーの観点から見ると、最新のWebアプリケーションを作成するには、クライアント側のHTML、CSS、およびJavascriptのすべての技術を使用する必要があります。 SQL、PHP、および多くの場合、サーバー用のSmartyなどのテンプレートエンジン。 データは、XML、JSON、またはある種の自転車を使用してネットワークを通過します。



これは古典的なUnixの方法です。作業の各領域に対して異なるツールが使用されます。 このアプローチは、非常に柔軟です。 特定のツールが気に入らない場合は、別のツールに置き換えることができます。Python用のPHP、NoSQL用のSQL、Flash用のHTMLです。



コインの裏側は、これらのツールはすべて非常に異なるということです。 構文が異なるだけでなく、根本的に異なるパラダイムがあります。 プログラマーはそれぞれをうまくマスターするのに何年も必要です。 Webの場合、これは長すぎます。



2番目の問題は、避けられないコードの重複です。 たとえば、ユーザーに日付（出発など）を尋ねる必要がある場合は、プレーンテキスト入力フィールドを使用して、入力した値を確認する必要があります。 まず、これがDROP TABLEではなく日付であることを確認する必要があり、次に、近い将来にあることを確認する必要があります。 これらのチェックは、クライアント部分（使いやすさ）、サーバー（セキュリティ）、およびデータベース（整合性）の3回実行する必要があります。 そして、ほとんどの場合、データベースがすべてを自動的にチェックする場合、サーバーとクライアントの部分のチェックは独立して記述し、ロケールを指定する必要がありますが、これは最も簡単なタスクではありません。 その結果、同じことを行う2つの関数を取得できますが、どちらか一方を使用することも、単にコピーすることもできません。



GWTは、Dartと同様に、これらの問題を解決することを目的としています。 GWTの場合、動物園に残っているのはJavaと小さなCSSのみであり、フォントと色のみを担当します（ただし、要素のレイアウトは担当しません）。 それ以外のすべては、ライブラリの深部に隠されているか、標準のスタブレベルで使用されます（単一のdivを持つHTML。インターフェース全体が後でプログラムで挿入されます）。



技術動物園に加えて、IEが主導するブラウザ動物園もあります。 現在でも、キーを押すという通常のイベント（onkeypress）を処理​​するには、javascriptでブラウザーのバージョンを確認する必要があります。ブラウザーごとに異なる方法でこの関数を呼び出すためです。 その後、2006年には、ページをほぼ同じに見せるために、膨大な数の松葉杖を使用する必要がありました。 GWTはこの問題を美しく解決しました。

仕組み

GWTプロジェクト全体は、MVCとパターンを備えたウォームチューブJavaという1つの環境と1つの言語で記述されています。 ほとんどすべての標準ライブラリがエミュレートされるという意味では、ほぼ完全なJavaでしたが、もちろんデスクトップアプリケーションからすべてのコードを単純に転送することは不可能でした。 GoogleはEclipseエディターの特別なビルドをリリースしました。このビルドでは、デバッグを含むすべてがすぐに使用できました。



サーバー側では、すべてがGWTライブラリが接続された通常のJava Server Pagesのようでした。 しかし、JSPホスティングを見つける必要があるため、この経済全体の設定を何らかの方法で把握する必要がありました。 ただし、サーバー部分は何でも作成できますが、単一言語の利点はすべて失われました。



クライアント部分はJavaからJavascriptにコンパイルされ、ファイルはブラウザごとにコンパイルされて動的にロードされました。 これにより、ブラウザのバージョンに関する多数のチェックが回避され、通常は非常にうまく機能しました。



HTML自体は使用されませんでした。 理論的には、HTMLページを作成し、適切な場所にプログラムでコントロールを挿入できますが、それでも主流は完全に動的なインターフェイスを完全にJavaで作成することでした。 .NetフォームエディタやDelphiのように、マウスでインターフェイスを描画できる半機能のグラフィックエディタもありました。 要素の位置とサイズはプログラムで設定され、CSSにはフォント、色、丸い角のような小さなフリルのみが残りました。



一般的に、理論的には、すべてが非常にクールに見えました。

練習する

実際には、すべてがそれほどバラ色ではありませんでした。



テリーテーブルレイアウトを使用して、自動的に作成されたインターフェイス要素。 長方形のブロックはすべて、単一のセルを持つテーブルを生成しました。 パネル（複数のブロックを組み合わせた）は、1行または1列の表で表されました。 ダイアログボックスは、ネストされたパネルの山でした。 出力は、かなり高度にネストされたテーブルからの混乱であり、ほとんど把握することができませんでした。 ブラウザは、結果として得られる巨大なDOMを大した喜びなく噛み砕いた。



私は完全にセマンティックレイアウトのファンではありません。古典的なOOPの観点からプログラムによるHTML生成を実装することは可能であり、IEのすべてのバージョンで同じように動作すること、そして2006年でさえテーブルでのみ可能であったことを理解しています。 しかし、GWTで何が起こったのか-ただ遅くなりました。 Chromeでも、最新のプロセッサでも、ウィジェットが数百しかないページでも、速度は低下します。



独自のHTMLを作成してGWTにフィードすることも、実際にはそれほど簡単ではありませんでした。 これはjQueryではなく、DOMを簡単に操作し、適切と思われるHTMLを生成できます。 理論的には、テーブルの上位レベルをいくつか保存することはできますが、それらを完全に放棄することはできません。 最悪なのは、GWTとネイティブJavascriptの相互作用でした。



理論的には、GWTはJSNIをサポートしています。これは、アセンブラーとしてJavascriptのみを使用したC言語のアセンブリ言語です。 しかし、それは一方向にしか機能しません。 つまり、GWTから外部jsライブラリを問題なく呼び出すことができます。 しかしそれどころか... javascriptとは、html要素のonclickを切断してGWTでインターセプトします。このようなシャーマニズムはマニュアルには記載されておらず、開発者によってまったく提供されていないようです。 これを行うことは可能でしたが、GWTではなくJavascriptトリックの助けを借りました。



Googleはブラウザー間のすべての違いを完全にブロックしようとしましたが、最後までこれを行うことができませんでした。 （少なくともバージョン2.2では、これ以上作業しませんでした）ぼやけたマウスクリックでテキストを強調表示することの禁止など、javascriptでも「シャーマニズム」に属するいくつかの微妙な点が残っていました。 しかし、これは非常に重要です。

概念的な問題

確かに、GWT全体が機能しました。 ゆっくりと、多分いくつかの場所では不器用で完全にではないかもしれませんが、うまくいきました。 彼の主な問題は、GWTで大規模なアプリケーションを開発する悪名高い速度が、標準技術の動物園よりもはるかに遅いことです。 そして、Dartが前のセクションの問題を解決すれば、開発速度に問題はありません。



すべてのプログラミングパラダイム（古典的なOOP、プロトタイプ、手続き型、リレーショナル、関数型）はすべてチューリング完全であり、同じクラスの問題を解決できます。 OOPが最良のパラダイムであると言うことは、「私はレーマーです」と言うようなものです。 全体の質問は、どのパラダイムによって特定の問題を迅速に解決できるかということです。



Java、およびそれを使用した従来のOOP全体は、クラスをオブジェクト自体（クラスのインスタンス）から分離するという考えに基づいています。 これは、数百万行の請求書、支払い、在庫残高などを処理する必要があるビジネスアプリケーションに適しています。 クラスは比較的少ないですが、多くのオブジェクトがあります。



ウェブ上ではそうではありません。 1つのページには、ログインフォームが1つ、バスケットが1つ、現在のユーザーが1つ、「戦利品を支払う」ボタンが1つだけあります。 これらの要素ごとに個別のクラスを作成してから、各クラスのコピーを1つ作成するのはなぜですか？ 実際には、ほとんどの場合、Web上のクラスとオブジェクトを分離する必要はないことが示されています。



わかりました、フォーギャングのフォロワーは言うでしょう、しかし、あなたがセカンドボタン「loot」を必要とするとき、しかしパールボタンで何が起こるでしょうか？ Javascriptでは、これがまさに次のとおりです。2番目のボタンは、最初のボタンのプロトタイプによって作成されますが、ボタンがあります。 古典的なOOPでは、別個のクラスがありますが、これはそれほど悪くありません。 主なことは、インターフェイスを強調表示してリファクタリングし、まったく何もしないが、クラスの構造を維持するだけのコードを書くことです。 そしてすべて静的なタイピングのため、「ボタンだけ」ではなく「真珠のボタン」を使用することはできません。



私はGWTで4年間執筆しましたが、自信を持って、ダックタイピングはWebの静的よりも優れていると言えます。 また、コンパイル速度のみに影響し、コード実行の速度には影響しません。



GWTは、古典的なOOPの真のファンによって作られました。彼は聖なるパターンからの逸脱を許しませんでした。 誰かがインラインスタイルの要素を使用できないと判断した場合、やめられません。 このような機能はありません。スタイルを変更するために、CSSクラスですべてを実行します。 もちろん、一般的に、ほとんどの場合、インラインスタイルは実際には使用すべきではありませんが、たとえば、アニメーションを実装するにはどうすればよいですか？ .opacity03 {opacity：0.3}という形式のクラスを20個作成しますか？



くそー、GWTには、グリッドタイプのコンポーネント（セルを編集できるテーブルのようなコントロール）があり、独自のMVCが完全に実装されています。 ビジュアルコントロールで... 2x3のプレートを作成する必要がある場合は、モデル、コンテナ、およびリストを記述する必要があります。 200コードの場合の行:)



同じチームがダートをやったら...ええと、わかりません。 2006年ではありませんが、Javascriptは成長し、落ち着き、jQueryレベルのライブラリで大きくなりすぎています。 Dartが「撮影」する理由は1つもわかりません。 Googleのすべての力にもかかわらず。