我认为他们是不同的野兽，IMO，尽管他们确实有尽可能声明性的目标，以及“嘿，让我们做事”的态度我们应该如何做".
现在，与AngularJS你仍然处于“熟悉”的领域。意思是，你在这里写一些标记，在那里写一些 JS，然后你提供它。与平常相同的工作流程。据我所知，AngularJS 的“创新”在于它extendsHTML 具有附加元素类型，以便您可以declare你的应用程序的很多方面和行为都在标记中，然后它的 JS 库包含必要的机制来为你提供模板、路由、数据绑定、表单验证、本地化等（...写这篇文章让我想知道是否也许 AngularJS 有点臃肿。），这使得它成为一个非常完整的 Web 应用程序开发框架。它促使您以声明式风格编写代码。
With Elm你真的进入了新的领域（如果你有“典型的” HTML/JS 前端开发背景）。这是进行（和思考）GUI 开发的不同方式。您将使用一种全新的语言进行编写 - 专门用于以函数响应式编程方式创建 GUI - 理想情况下您永远不会处理（至少不会直接）任何传统的 DOM API。 Elm 附带了一种“标准库”，它为您提供了随时间创建和操作图形/文本/等的工具。
您的 Elm 语言代码将以完全声明性的方式描述您希望 GUI 在时间推移和事件（用户输入等）发生时的外观和行为。然后，它会将其全部编译为 HTML/JS/CSS，以便在浏览器上运行。
榆树也很年轻。这是否是一个缺点取决于您和您的需求。
我想对我来说，选择 AngularJS 与我们在 JS 世界中习惯的“嘿，让我们尝试一下这个 JS 库/框架”的流程是一样的。您获取 lib 文件，将它们添加到您的项目中，然后开始使用其 API。而与Elm，您必须开始以不同的方式处理您的工作流程和问题解决方案。
AngularJS 为您提供了很多结构，并且它与 Backbone.js 等不同，但归根结底，如果您想做一些高级 GUI 和图形行为，那么使用 AngularJS 您又要编写大量代码如果您使用 Elm，则无需编写管道样板内容。
另一方面，如果您必须开发和发布大型网络应用程序现在，对于到目前为止我们在网络上使用的常用 GUI 小部件，我倾向于选择 AngularJS，因为它更稳定。
话虽如此，我认为 Elm 是目前前端开发世界中最有趣、最有前途的事物。而且，如果我今天必须开发和发布一些图形密集型的东西，我would选择 Elm，因为人们可以用很少的几行代码来完成非常复杂的 GUI 工作。但我必须首先了解它的思维方式，并考虑到它还很年轻，并且将其与现有 JS 前端代码库集成可能并不容易，甚至不可能。
Edit:
截至 2015 年 3 月，Elm 更加强大，并且有很棒的工具（我想到了时间旅行调试器）。
Angular 仍然是，嗯，更多的是相同的。我应该指出，Angular 的方法及其每当模型更改时都会发生大量事情的方法（“双向数据绑定”）使其完全不适合基于浏览器的游戏等事物，而Elm 擅长游戏和需要良好性能的高级 GUI 内容。此外，Elm 现在有一个快速（使用虚拟 dom diff'ing 方法）HTML 库，供您需要使用 HTML 进行交流时使用。
我对 Elm 的不满是，它的类型系统并不像 e.g. 那样具有表现力。哈斯克尔的。有些人可能认为这是在要求奢侈，但事实恰恰相反，这是失去表达基本功能的能力。尤其是我们这些经验丰富的 JS 程序员，会遭受表达能力不够的静态类型系统的困扰，因为这意味着我们习惯在 JS 中轻松表达的多态代码在 Elm 中会变成类型错误，因为缺乏例如2 级类型。
幸运的是，Elm 中缺少的所有“愿望清单”功能都不存在，因为持续讨论关于他们和他们的选择。因此，可以肯定的是，它们（或最好的替代方案）最终会使用该语言。
