Angular.jsとElmの長所と短所は何ですか？
ブラウザーでリアクティブプログラミングを行い、angular.js（ http://angularjs.org/ ）とElm（ http://Elm-lang.org / ）。
それぞれの相対的な利点/問題は何ですか？
彼らは異なる獣、IMOであると思うが、彼らは可能な限り宣言的であるという目標を共有しており、「ねえ、物事をやろう」という態度を共有している彼らがやるべきこと/ 「。
現在、AngularJSを使用すると、まだ「なじみのある」領域にいます。つまり、ここにマークアップを書き、そこにJSを書き、それを提供します。通常と同じワークフロー。私が知る限り、AngularJSの「革新」とは、 extends HTMLが追加の要素タイプを備えているため、 declare マークアップでのアプリの多くの側面と動作、そしてそのJSライブラリには、テンプレート、ルーティング、データバインディング、フォーム検証、ローカリゼーションなどを提供するために必要な機構が含まれています（...これを書くと、たぶん、AngularJSは少し肥大化しています。）、これは非常に完全なWebアプリ開発フレームワークになります。そして、宣言的なスタイルでコードを書くように促します。
Elmを使用すると、本当に新しい領域（「典型的な」HTML/JSフロントエンド開発の背景がある場合）になります。これは、GUI開発を行う（および考える）ための別の方法です。機能的なリアクティブプログラミング方法でGUIを作成するために特別に作成された完全に新しい言語で記述します。理想的には、従来のDOM APIのいずれにも（少なくとも直接ではなく）対処しないことが理想です。 Elmには一種の「標準ライブラリ」が付属しており、グラフィック/テキスト/などを作成および操作するためのツールを時系列で提供します。
Elm言語コードは、時間の経過やイベント（ユーザー入力など）が発生したときのGUIの外観と動作を完全に宣言的な方法で記述します。次に、ブラウザで実行するためにすべてをHTML/JS/CSSにコンパイルします。
ニレもとても若いです。それが不利かどうかを判断するのはあなたとあなたのニーズです。
AngularJSを選択することは、JSの世界で慣れ親しんだ同じ「古いJS lib/frameworkのことを試してみましょう」というプロセスと同じです。 libファイルを取得してプロジェクトに追加し、そのAPIの使用を開始します。一方、Elmの場合、ワークフローと問題の解決策に異なるアプローチを開始する必要があります。
AngularJSは多くの構造を提供し、たとえばBackbone.jsとは異なりますが、最終的には、高度なGUIとグラフィックビヘイビアを行いたい場合は、AngularJSを使用して、 Elmを使用している場合は記述する必要のない配管の定型的なもの。
一方、大規模なWebアプリを開発してリリースする必要がある場合今、これまでWebで使用していた通常のGUIウィジェットを使用して、 AngularJSの方が安定しているためです。
そうは言っても、エルムは現時点でフロントエンド開発者の世界で起こっている最も興味深く、有望なことだと思います。また、今日グラフィックスを大量に使用するものを開発してリリースする必要がある場合は、非常に複雑なGUIをほんの数行のコードで実行できるため、 /をElmに移行します。しかし、私は最初にその考え方に取り掛かる必要があり、それが非常に若く、既存のJSフロントエンドコードベースと統合することは容易ではないか、可能性さえないという事実に対処する必要があります。
編集：
2015年3月の時点で、Elmははるかに堅牢であり、そのための優れたツールがあります（タイムトラベルデバッガーが思い浮かびます）。
角度は同じままです。 Angularのアプローチは、モデルを変更するたびに起こる（2方向のデータバインディング）ため、ブラウザベースのゲームなどにはまったく不適切です。 Elmは、ゲームと優れたパフォーマンスが必要な高度なGUIに優れています。さらに、Elmには、HTMLで話す必要があるときのために、高速（仮想dom diffingingアプローチを使用）HTMLライブラリがあります。
Elmで選ぶべき骨は、その型システムは、たとえばハスケルの。これは贅沢を求めていると考える人もいるかもしれませんが、逆に、基本的な機能を表現する能力を失うことについてです。特に、経験豊富なJSプログラマーは、表現力に欠ける十分な静的型システムに苦しんでいます。これは、JSで簡単に表現するために使用されているポリモーフィックなコードが、例えば不足のためにElmで型エラーになるためですランク2タイプ。
幸いなことに、エルムに欠けているすべての「ウィッシュリスト」機能は、進行中の議論とそれらの代替案のためにそこにありません。したがって、彼ら（または最良の選択肢）が最終的に言語に到達することは安全な賭けです。
Elmでは、HTML/CSS/JavaScriptフレームワークよりも、複雑で静的なグラフィカルレイアウトとインタラクティブ機能の両方がはるかに単純です。 Elmの場合、偶発的な複雑さはtypesにありますが、それは十分に価値があります それらについて学ぶ -理解、デバッグに役立ちますまた、ソフトウェアをより適切に修正します。関数型プログラミングのバックグラウンドから来たのであれば、すでに慣れ親しんでいるはずです。 HTML/JSにElmを埋め込む も使用できることに注意してください。したがって、理論的には徐々に移行できます。
Elmは、Angularよりもはるかに意見が多く、特に状態管理に関して意見が多くなっています。従来のAngularアプリで状態が問題になる場合は、Reduxスタイルのアプローチを使用して集中化（モノリシック状態）に目を向けたいと思うかもしれません。ngrxはすぐに頭に浮かびます。
Elmは、中心的な不変状態の概念の典型であり、 Reduxのインスピレーション でした。 Elmは、純粋な更新（リデューサー）関数を使用して、単一の不変の状態を強制します。私の考えでは、AngularでOOのようなパターンを使用して発生する可能性がある混乱よりも、非常に反応性の高いWebアプリでの状態の処理がはるかに簡単になります。
Elmはほとんどのアプリに適していますが、外部関数インターフェイス（ポート）が非常に硬いため、外部JSライブラリ（例：googleマップ）で作業する場合、少し複雑になる可能性があります。マテリアルデザインに必要なアニメーションの種類は、エルムアーキテクチャにとっても困難であることがわかりました。つまり、アニメーションが存在しないということではなく、必要以上に配線が必要になるということです。