我正在研究在浏览器中做一些反应式编程，并将angular.js（http://angularjs.org/）与Elm（http://elm-lang.org/）进行比较。
每个人的相对利益/问题是什么？
答案 0 :(得分：74)
我认为他们是不同的野兽，IMO，虽然他们确实分享了尽可能陈述的目标，并采取“嘿，让我们做事的方式他们应该做的事情”的态度
现在，通过 AngularJS ，您仍处于“熟悉”区域。意思是，你在这里写了一些标记，在那里写了一些JS，然后你就可以了。与往常一样的工作流程据我所知，AngularJS的“创新”是使用其他元素类型扩展 HTML，以便您可以声明您的许多方面和行为应用程序在标记中，然后它的JS lib包含必要的机制，为您提供模板，路由，数据绑定，表单验证，本地化等。（...写这个让我想知道是否AngularJS可能有点膨胀。），这使得一个非常完整的Web应用程序开发框架。它会促使您以声明的方式编写代码。
使用 Elm ，你真正开始新的（如果你有一个“典型的”HTML / JS前端开发背景）领域。这是一种不同的方式（并且想到）GUI开发。您将使用一种全新的语言编写 - 专门用于以函数式编程方式创建GUI - 理想情况下，您永远不会处理（至少不直接）任何传统的DOM API。 Elm附带了一种“标准库”，它为您提供了随时间创建和操作图形/文本/等的工具。
您的Elm语言代码将以完全声明的方式描述您希望GUI随着时间的推移和事件（用户输入等）的外观和行为。然后，它将全部编译为HTML / JS / CSS，以便在浏览器上运行。
榆树也很年轻。这取决于你和你的需要决定这是否是一个劣势。我想我选择AngularJS就是同样的旧“嘿，让我们试试这个JS lib / framework的东西” - 我们在JS世界中习惯的过程。您获取lib文件，将它们添加到项目中，然后开始使用其API。对于 Elm ，您必须开始以不同方式处理工作流程和问题解决方案。
AngularJS为您提供了很多结构，它与Backbone.js不同，但在一天结束时，如果您想要进行一些高级GUI和图形行为，使用AngularJS，您将回归写作大量的管道样板材，如果你使用的是Elm，你就不用写了。
另一方面，如果您必须开发和发布一个大型网络应用现在，使用我们目前在网络上使用的常用GUI小部件，我会倾向于说去AngularJS，因为它更稳定。
话虽如此，我认为榆树是目前在前端开发世界中发生的最有趣和最有希望的事情。而且，如果我今天必须开发和发布一些图形繁重的东西，我会去找Elm，因为只需很少的代码就可以用它来完成非常复杂的GUI。但我必须首先考虑它的思维方式，并处理它非常年轻并将其与现有的JS前端代码库集成这一事实可能并不容易甚至可能。
修改
截至2015年3月，Elm更加强大，并且有很好的工具（想想时间调试器）。
Angular仍然存在，更多相同。我应该注意到，Angular的方法，随着时间的推移 - 每当模型更改方法（“双向数据绑定”）使得它完全不适合基于浏览器的游戏等事情，而Elm擅长于需要表现良好的游戏和高级GUI。此外，Elm现在有一个快速（使用虚拟dom diff'ing方法）HTML库，当你需要用HTML说话时。
我用榆树挑选的骨头是它的类型系统不像Haskell的。有些人可能会认为这是在追求奢侈，但恰恰相反，它却失去了表达基本功能的能力。特别是我们，经验丰富的JS程序员，受到不具有表现力的静态类型系统的困扰，因为它意味着我们习惯在JS中容易表达的多态代码在Elm中成为类型错误，因为缺少例如等级2类型。
幸运的是，Elm中缺少的所有“愿望清单”功能都不存在，因为正在进行讨论关于它们及其替代方案。因此，可以肯定的是，他们（或最好的替代方案）最终会成为该语言。
答案 1 :(得分：16)
复杂的静态图形布局和交互性在Elm中比在HTML / CSS /任何JavaScript框架中简单得多。对于Elm来说，意外的复杂性在于类型，但它非常值得learning about them - 它们有助于更好地理解，调试和修改软件，如果你来，它们应该已经为你熟悉了从功能编程背景。请注意，您也可以embed Elm in HTML/JS，因此从理论上讲，您可以逐步迁移。
答案 2 :(得分：5)
榆树对于大多数应用来说都很棒，但是当你想使用外部JS库（例如谷歌地图）时，它会变得有点复杂，因为它的外部功能接口（端口）非常严格。材料设计中所需的动画类型也证明了对Elm Architecture的挑战 - 不是说没有动画，而是它们需要比你想做的更多的布线。