埃尔姆和ClojureScript相比怎么样？

Question

我已经到了用Backbone.js面向对象的MVC模式进行图形用户界面编码变得相当复杂的地步，并对其他范例进行了回顾。MDV，玻璃钢，ECS，噢，天啊。

榆树与ClojureScript相比如何？它们在哪里重叠？

这两种语言都与编译为JS的JS非常不同。据我所知，Elm是一种功能反应编程(FRP)语言。ClojureScript不一定是玻璃钢，但你可以用它做玻璃钢。Elm用Haskell编译，ClojureScript用JVM编译，所以这两个都是Node的额外要求。

也许它只是归结为克洛尔对哈斯克尔。

Answer 1

这两种方式都迫使您使用比纯JS更具有声明性/函数式的编程风格。ClojureScript更像是JS的替代品，而Elm更像是整个web开发堆栈(HTML/CSS/JS)的替代品。

其他差异：

• Elm语法更像Haskell。
• ClojureScript更接近于传统的Lisp语法。
• Elm对时变值(Elm中的“信号”)进行了高度优化。
• ClojureScript更成熟，您可以找到一些很好的开发工具(Eclipse插件、LightTable等等)。
• Elm是静态类型的，ClojureScript是动态类型的。

希望这能有所帮助。我还在学习这两种语言，所以我可能错过了一些东西。

Answer 2

只是为了更新2017年的数据。

榆树不再是玻璃钢，这是几个版本前，赞成榆树建筑。

Elm的主要优点是它有一个静态类型系统，允许编译器在编译时对程序正确性作出许多断言。例如，您知道一个事实，即永远不会有一个案例语句不涵盖特定情况。或者视图函数中的HTML将产生更新不知道如何处理的事件。

其他榆树优势

• 重大错误信息
• 包已强制进行语义版本控制*
• 软件包和工具往往有非常明显的名称。

*语义版本控制是描述这里的惯例。它是表单major.minor.patch的数字版本标识符，可以像2.3.4 <= 2.5.0一样进行比较，因此开发人员一眼就可以看到所做的更改类型。

在Elm中，如果FooModule 4.2.3向函数引入了一个向后不兼容的更改(Foo : Int -> Bool变为Foo : Int -> String -> Bool)，那么该包将不会被接受到官方储存库中，除非主版本也会递增以表示一个突破性的更改(例如，它可以被上传为FooModule 5.0.0)。在ELM0.14中，引入了榆树包装工具来强制执行此规则。

Answer 3

它们都是FRP ()的核心，这意味着它们有一个映射到DOM的树，并且只呈现需要呈现的组件或子组件。(正如早些时候有人指出的那样，埃尔姆已经放弃了玻璃钢原则，转而追求自己的想法。)

它们都是在JavaScript中编译的(尽管使用ClojureScript/Om库或Reagent，您可以在js中获得实际的响应对象)，而Elm则是自己做的事情。我不喜欢Elm必须通过npm安装，尽管据我所知，czapliki正在开发一个独立的安装程序)

在我看来，Elm更好一些，因为它管理状态更友好一些，它有一个非常好的(如前面提到的)类似Haskell的语法，而且您还可以将RuntimeErrors移动到CompileTimeErrors中，这对于开发人员来说更容易接受，而且它具有更容易维护的代码。

另一方面，cljs有lotsa库--正如我提到的返回实际反应组件(cljs/Om匹配1:1与R.js LifeCycle匹配)--其他库只是尊重玻璃钢和LifeCycle思想而不受其影响。可能需要查看Om/Next，它有一种从端点调用数据的GraphQL方式，并放弃了在普通cljs/Om中使用的异步chans。

老实说，这是一个品味问题，但我一个人更喜欢榆树(用两种语言写过)。但是，如果你使用cljs，请确保您有一个很好的库，不要使用香草cljs，否则当您想要维护5k+ LOC时，您会感到很抱歉。(查找Fulcro，Reagent，om，OmNext，hoplon等等)