DartにはWebプログラマーに役立つ機能はありますか？
私は非常に簡単にサイトをチェックアウトし、興味を持ちました。 Dartを使用する利点はありますか？ JavaScriptの単なる置き換えですか？
単純なJavaのように見えます。仕事でかなりの数のC＃を書くと、言語は私が慣れているものと非常によく似ているので、構文を学ぶことは学ぶのに簡単に見えます。言語についての意見や経験はありますか？
（CoffeeScriptと比較して（=私はやっていないRuby構文）構文は私にはより身近に見えます）。
ご質問ありがとうございます！完全な免責事項、私はダートチームで働いています。
おそらく、Dartの今日の最も優れた利点は、C＃、Java、C++、およびほとんどのJavaScript開発者が使い慣れていることです。多くの開発者は、言語（クラスベースのオブジェクト指向、字句スコープ、使い慣れた構文）とツール（コード補完、リファクタリング、コードナビゲーション、デバッグ）に関して、Dartがこれを超えることを目指している一連の期待を抱いています。
言語について私が気に入っている点をいくつか紹介します。
オプションの静的型。プロトタイプを作成しているとき、または単純に小さなスクリプトを記述しているときは、大量の静的型を使用しません。私はちょうどそれらを必要としません、そして私は式典に行き詰まりたくありません。ただし、これらのスクリプトのいくつかは、より大きなプログラムに進化します。スクリプトがスケーリングするにつれて、私はクラスと静的な型注釈が必要になる傾向があります。
有罪になるまで無罪。 Dartは、コンパイル時エラーが発生する状況を最小限に抑えるように努めています。 Dartの多くの状態は警告であり、プログラムの実行を停止しません。どうして？ Web開発の方法に合わせて、開発者が少しのコードを試し、リロードをヒットして、何が起こるかを確認できるようにすることが不可欠です。開発者は、コードの隅をテストする前に、プログラム全体が正しいことを最初に証明する必要はありません。
レキシカルスコープ。慣れていないのなら、これは素晴らしいことです。簡単に言えば、変数の可視性、さらにthisはプログラム構造によって定義されます。これにより、従来のWebプログラミングにおける一群の不可解な問題が排除されます。 thisをあなたが考えたり期待したりするために関数を再バインドする必要はありません。
言語に組み込まれた実際のクラス。ほとんどのWeb開発フレームワークがソリューションを提供しているので、ほとんどの開発者がクラスで作業したいことは明らかです。ただし、フレームワークAの「クラス」は、従来のWeb開発ではフレームワークBと互換性がありません。 Dartは自然にクラスを使用します。
トップレベルの関数。 Javaの苦痛な部分の1つは、すべてをクラスに入れる必要があることです。これは、特に、いくつかのユーティリティ関数。Dartでは、どのクラスの外でもトップレベルで関数を定義できます。これにより、ライブラリの構成がより自然に感じられます。
クラスには暗黙のインターフェースがあります。明示的なインターフェースを排除することで、言語が簡素化されます。 IDuckをどこにでも定義する必要はありません。必要なのはクラスDuckだけです。すべてのクラスには暗黙のインターフェースがあるため、_
MockDuck implements Duck_を作成できます名前付きコンストラクター。コンストラクターに名前を付けることができます。これにより、読みやすくなります。例：
var duck = new Duck.fromJson(someJsonString)ファクトリコンストラクタ。ファクトリパターンは非常に一般的であり、これが言語に組み込まれているのを見るのは素晴らしいことです。ファクトリコンストラクタは、シングルトン、キャッシュからのオブジェクト、またはサブタイプのオブジェクトを返すことができます。
Isolates。スレッド間で変更可能な状態を共有する時代は終わりました（エラーが発生しやすい手法）。 Dartアイソレートは、独立したメモリヒープであり、別のプロセスまたはスレッドで実行できます。アイソレートは、ポートを介してメッセージを送信することにより通信します。 Dart VM=で動作し、HTML5アプリでWebワーカーにコンパイルできます。
DartはJavaScriptにコンパイルされます。 JavaScriptはWebの共通語であるため、これは非常に重要です。 Dartアプリは最新のWebで実行する必要があります。
Strong tooling。 Dartプロジェクトにはエディターも付属しています。コード補完、リファクタリング、クイックフィックス、コードナビゲーション、デバッグなどがあります。また、IntelliJにはDartプラグインがあります。
Libraries。 Dartコードをライブラリに編成して、名前空間と再利用を容易にすることができます。コードはライブラリをインポートでき、ライブラリは再エクスポートできます。
文字列補間。これは、Nice機能であり、文字列を簡単に作成できます：_
var msg = "Hello $friend!";_noSuchMethod Dartは動的言語であり、
noSuchMethod()を使用して任意のメソッド呼び出しを処理できます。Generics。「これはりんごのリストです」と言えることで、ツールがより多くの情報を提供し、潜在的なエラーを早期に発見できます。幸いなことに、Dartのジェネリックは、おそらく慣れているものよりもシンプルです。
Operator overloading。 Dartクラスは、_
+_または_-_などの演算子の動作を定義できます。たとえば、new Point(1,1) + new Point(2,2)のようなコードを記述できます。
そうは言っても、JavaScriptライブラリは他にもたくさんあります。
個人的には、ウェブ上には多くの言語の余地があると思います。アプリが素晴らしく、ほとんどの最新ブラウザーで実行されている場合、私はそれが書かれている言語をそれほど気にしません。開発者であるあなたが幸せで生産的であり、Web上で起動している限り、それは重要なこと！ :)
仕事でかなりの数のC＃を書くと、言語は私が慣れているものと非常に似ています
それがダートのポイントです。 JavaScriptは、一般的なイディオムがほとんどない扱いにくい言語と見なされています。 Javaのような言語では、問題にアプローチする自然な方法がよくあります。たとえば、テーブルのインベントリを保持している場合、JavaまたはC＃でクラステーブルを作成します。
Javascriptにはクラスがありません。プロトタイプを使用することもできますが、プロトタイプは扱いにくく、そのような強力な構造とカプセル化ツールを提供していません。 （少なくともスタントを作成することなしではありません。）継承、構成などは、Javascriptプロトタイプでは扱いにくいものです。これが、ほとんどの人がプレーンハッシュマップを使用してデータを格納する理由です。または、プロトタイプのようなサードパーティのライブラリを使用して、クラスのような体験を提供します。
つまり、利便性と構造化の両方が必要です。大規模なアプリを構築する標準的な方法がないため、Javascriptはうまくスケーリングできません。しかし現在、そのようなサードパーティのライブラリは非常に人気が高まっています。 （backbone.jsのように）
ダートはそれを解決するものです。これは、Javaの構造上の利便性を提供するためにあり、さらに、これらの厄介なJS機能のすべてを備えているわけではありません（そのほとんどは弱い型付けに関連しています）。
したがって、答えは「はい」です：クラス、継承、...：「従来のOOP」。 （ほとんどの現実のJS Webアプリケーションは、メイン構造としてjQueryのコールバックベースのアプローチを使用しています。）また、静的型付けのルーズな形式がありますが、それが主なセールスポイントではありません。
ところで：2010年付けのこの「内部」Googleメーリングを読むことをお勧めします： Javascriptの将来
JavaScriptには、言語を進化させるだけでは修正できない根本的な欠陥があります。私たちは、Javascriptの将来に向けて2つの方向からの戦略を採用します... Javascriptの動的な性質を維持することを目的とする新しい言語（Dashと呼ばれます）を開発します。 。
私にとっては、スコープとクラスを使用してJavaScriptよりもコードを構造化する機会が得られます。
これは、JavaとJavaScriptに似ており、Dartエディターを使用していたので、ほぼゼロの適応でした。すぐにコーディングを開始しました。
var ws = new [Moz]WebSocketさまざまなブラウザに対応する必要があるのは面倒です。 Dartは、一般的なブラウザと互換性のあるJavaScriptコードにコンパイルされます。
私の課題は主にJavaScriptコードとのインターフェースです。私はどういうわけかそれを回避する方法を見つけますが、それがダートの一部であるならばそれはより良いでしょう。
Java 2.0の初めから、Java/C＃アプローチはJSをノックすることに明らかに偏っています。これは、クライアント側の言語とサーバー側の言語が人為的に（または非常に現実的かつ必要に）区別されているためです。これは、サーバー側言語がWebアプリのコア問題ドメインの「制御」を維持し、それほど深刻ではないコード（UIコード）をビジネスコード（サーバー側）から区別できるようにするためだと思います。また、Java主にFlashとHTML 5のせいでアプレットとのGUI戦争に負けたので、サーバーサイドカーネルのままにしておくのが大好きだと思います。統一されたフロントとバックエンドのパラダイムの多元的な混合未来。