11

「javascriptにコンパイルされるもの」、たとえばGWT、Script＃、WebSharperなどの見方に興味があります。これらは、人々がjavascriptを書かずにjavascriptを書くことを可能にすることを目的としたかなりニッチなコンポーネントのようです。

個人的には、JavaScriptを（JQuery / Protocol / ExtJSまたは他のそのようなライブラリを使用して）書くことに慣れており、GWTのようなものを、開発者が達成する必要のあることを制限する可能性のある不必要な抽象化、または非常に長い時間を提供するベストケースと見なしています回避策。場合によっては、JSNIなどのJavaScriptを記述してしまうこともあります。

さらに悪いことに、隠れて何が起こっているのかわからない場合は、意図しない結果が生じるリスクがあります。たとえば、GWTがクロージャを作成し、名前空間を正しく管理していることをどのように知っていますか？

他人の意見を聞きたいです。これはWebプログラミングが向かっているところですか？

4

5 に答える 5

20

Xを優先してJavaScriptを回避する必要がありますか？ぜひ！

私は免責事項から始めます。私はWebSharper開発者チームに所属しているため、私の答えは非常に偏っています。そもそも私がこのチームに所属している理由は、純粋なJavaScriptの記述に完全に失敗したことに気づき、お気に入りの言語であるF＃からJavaScriptにコンパイラーを作成することを会社に提案したためです。

私にとって、JavaScriptはWebのポータブルなアセンブリであり、 Cが世界の他の地域で行っているのと同じ役割を果たします。持ち運び可能で、広く使用されており、そのまま使用できます。しかし、私はJavaScriptを書きたくありません。それは、アセンブリを書きたいだけです。JavaScriptを言語として使用したくない理由は次のとおりです。

  1. 静的分析はなく、関数が正しい数の引数で呼び出されているかどうかもチェックしません。タイプミスのかみ傷！

  2. ライブラリ、名前空間、モジュール、クラスの概念はないか、非常に限られているため、すべてのフレームワークが独自の概念を発明します（R5RSスキームと同様の状況）。

  3. ツール（コードエディター、デバッガー、プロファイラー）はかなり貧弱であり、そのほとんどは（1）と（2）のためです。JavaScriptは静的分析に適していません。

  4. 標準ライブラリはないか、非常に限られています。

  5. 多くの荒削りな部分があり、突然変異を使用することへの偏見があります。JavaScriptは、型指定されていないファミリでも設計が不十分な言語です（私はSchemeを好みます）。

WebSharperでこれらすべての問題に対処しようとしています。たとえば、Visual StudioのWebSharperは、ExtJsなどのサードパーティのJavaScriptAPIを公開している場合でも、コードを補完します。しかし、私たちが成功するか失敗するかは、実際には重要ではありません。重要なのは、これらの問題に対処することは可能であり、非常に望ましいことです。

さらに悪いことに、隠れて何が起こっているのかわからない場合は、意図しない結果が生じるリスクがあります。たとえば、GWTがクロージャを作成し、名前空間を正しく管理していることをどのように知っていますか？

これは、コンパイラを正しい方法で作成することです。たとえば、WebSharperはF＃ラムダをJavaScriptラムダに1-1の方法でマップします（実際、ラムダを導入することはありません）。たとえば、WebSharperはまだ成熟しておらず、十分にテストされていないため、信頼することを躊躇しているとおっしゃっていれば、おそらくあなたの主張を受け入れるでしょう。しかし、GWTはしばらく前から存在しており、正しいコードを生成するはずです。

結論として、強く型付けされた言語は型なし言語よりも厳密に優れています。必要に応じて型なしコードを簡単に記述できますが、プログラマーのスペルチェッカーである型チェッカーを使用するオプションがあります。どうしてそうしませんか？そうすることを拒否することは、私には少しラッダイトに聞こえます。

于 2010-07-13T06:55:44.830 に答える
8

私は個人的にあるスタイルを別のスタイルよりも好むわけではありませんが、Javascriptからの抽象化が、これらのフレームワークがテーブルにもたらす唯一の利点であるとは思いません。確かに、言​​語全体を抽象化することで、以前は可能であったことが不可能になることもあり、その逆もあります。バニラJavaScriptの記述よりもGWTなどのフレームワークを採用するかどうかの決定は、多くの要因に依存します。

各言語には長所と短所があるため、これをJavaScriptと言語Xの議論にすることは無益です。代わりに、そのようなフレームワークを使用することによって何が得られるか、または失われるかについて客観的な費用便益分析を行います。これは、残念ながらSOコミュニティではなく、あなただけが行うことができます。

内部で何が起こっているのかわからないという問題は、翻訳されたソースと同じようにJavaScriptにも当てはまります。$("p") == $("p")のような比較を試みて結果を取り戻そうとすると、jQueryで何が起こっているのかを正確に知っている人は何人いると思いますかfalse。これは架空の状況ではなく、SOに関していくつかの質問があります。言語やフレームワークを学ぶには時間がかかり、十分な時間があれば、開発者はこれらのフレームワークのコンパイルされたソースを同様に理解することができます。

上記の質問に関連するもう1つの側面は、信頼です。私たちは、低レベルの抽象化に基づいて高レベルの抽象化を継続的に構築し、低レベルのものが期待どおりに機能することになっているという事実に依存しています。正しく動作することを確認するために、C ++またはJavaプログラムのコンパイル済みバイナリを最後に掘り下げたのはいつですか？コンパイラを信頼しているからではありません。

さらに、このようなフレームワークを使用する場合、たとえばJSNIを使用してJavaScriptにフォールバックすることは恥ずべきことではありません。手元にあるツールを使用して、可能な限り最善の方法で問題を解決することがすべてです。JavaScript、Java、C＃、Rubyなどについては何も神聖なものはありません。これらはすべて問題を解決するためのツールであり、あなたにとっては障壁になるかもしれませんが、リアルタイムの節約になり、他の人にとっては有利かもしれません。

Webプログラミングの方向性については、サーバー側のJavaScriptなど、成功すると思う、あるいは期待する興味深いトレンドがたくさんあります。少なくとも、Webアプリケーションでのコードの重複を簡単に回避できるという点で、非常に現実的な問題を解決します。同じ検証、ロジックなどをクライアント側とサーバー側で共有できます。また、単純な（逆）シリアル化メカニズムを記述できるため、RPCまたはRMI通信が非常に簡単になります。つまり、次のように書くことができれば本当に素晴らしいと思います。

account.debit(200);

代わりに、クライアント側で：

$.ajax({
    url: "/account",
    data: { amount: 200 },
    success: function(data) {
        ..
    }
    error: function() {
        ..
    }
});

最後に、次世代のソリューションはそれぞれの失敗から学び、より良い、より速く、より素晴らしいツールを構築するための成功に焦点を当てることができるため、Webアプリケーションを構築するためのフレームワークとソリューションにこのような多様性があることは素晴らしいことです。

于 2010-07-11T02:03:22.263 に答える
5

私は、Javascriptの苦痛を回避すると主張するwebsharperや他のコンパイラーに関して3つの大きな実際的な問題を抱えています。

  • Javascriptをよく知らないと、DOM / ExtJなどを使用したWeb上の例のほとんどを理解できないため、Javascriptを何でも学ぶ必要があります。（何らかの理由で、すべてのF＃プログラマーは少なくともC＃またはVB.NETを読み取ることができなければなりません。そうでない場合、.netフレームワークに関するほとんどの情報にアクセスできません）
  • どのWebプロジェクトでも、DOMとCSSを裏返しに知っているWebエキスパートが数人必要です。そのような人は、JavascriptではなくF＃を使用して喜んで作業しますか？
  • コンパイラーのプロバイダーに縛られているので、彼らは約5年後になります。完全なオープンソースまたはツールがMicrosoftによってサポートされることを望んでいます。

これらのフレームワークで私が目にする4つの大きな利点は次のとおりです。

  • サーバー/クライアント間でコードを共有する
  • プログラマーが知る必要のある言語が少ない（javascriptはJave / C＃のように見えますが、それらのようなものではないため、非常に苦痛です）
  • F＃プログラマーの平均的な品質は、jscriptプログラマーよりもはるかに優れています。
于 2011-04-13T10:41:09.307 に答える
2

価値があると思うのは、すべてのフレームワークには長所と短所があり、プロジェクトチームはユースケースを含める前に評価する必要があるということです。私にとって、フレームワークは問題を解決するために使用される単なるツールであり、その仕事に最適なものを選択する必要があります。

私は純粋なJavaScriptソリューションに固執することを好みますが、そうは言っても、GWTが役立ついくつかのケースを考えることができます。GWTを使用すると、チームはサーバー/クライアント間でコードを共有できるため、同じコードを2回記述する必要がなくなります（JSとJava）。または、誰かがJavaクライアントをWeb UIに移植している場合、GWTに固執する方が簡単だと感じるかもしれません（もちろん、それでも難しくなる可能性があります:-)）。

于 2010-07-10T18:52:35.910 に答える
1

GWTのようなフレームワークが提供するものは他にもたくさんあるので、これは非常に単純化されていることを私は知っていますが、これが私の見方です。JavaScriptが好きなら、JavaScriptを書いてください。そうでない場合は、GWTやカプチーノなどを使用してください。

人々がGWTのようなフレームワークを使用する理由は、必ずしも彼らが提供する抽象化ではなく（ExtJSのようなJavaScriptフレームワークでそれを実現できます）、JavaScript以外の何かでWebアプリケーションを作成できるという事実です。私がWebアプリケーションを作成したいJavaプログラマーの場合、新しい言語を学ぶ必要がないため、GWTを使用します。

本当に、それはすべて好みです。私はJavaScriptを書くのが好きですが、多くの人はそうしません。

于 2010-07-10T19:04:38.020 に答える