Wie vergleicht sich Elm mit ClojureScript?

Question

Ich erreiche einen Punkt, wo GUI-Programmierung mit Backbone.js objektorientierten MVC-Muster sehr komplex wird, und sich auf andere Paradigmen umsehen. MDV, FRP, ECS, oh mein.

Wie funktioniert Elm im Vergleich zu ClojureScript? Wo überschneiden sie sich?

Beide Sprachen sind sehr unterschiedlich zu JS, die zu JS kompiliert werden. Ich verstehe, dass Elm eine funktionale reaktive Programmierung (FRP) Sprache ist. ClojureScript ist nicht notwendigerweise FRP, aber Sie können FRP damit machen. Elm kompiliert mit Haskell und ClojureScript mit der JVM, also sind beide zusätzliche Anforderungen für einen Knoten-Shop.

Vielleicht läuft es gerade auf Clojure vs Haskell.

Answer 1

Beide erzwingen, dass Sie einen deklarativen/funktionalen Programmierstil als reines JS verwenden. ClojureScript ist eher ein JS-Ersatz, während Elm eher ein Ersatz für den gesamten Web-Entwicklungs-Stack (HTML/CSS/JS) ist.

Weitere Unterschiede:

• Elm Syntax ist viel mehr Haskell-like
• ClojureScript ist viel näher an traditionellen Lisp Syntax
• Elm hoch für zeitlich veränderliche Werte ("Signale" in Elm optimiert)
• ClojureScript ist reifer und Sie können einige süße Entwicklungswerkzeuge dafür finden (Eclipse-Plug-Ins, LightTable, etc.)
• Elm ist statisch typisiert, ClojureScript ist dynamisch typ ed

Hoffe das hilft. Ich lerne immer noch diese beiden Sprachen, damit ich etwas verpasst habe.

Answer 2

Nur diese zu aktualisieren für 2017.

Elm ist nicht mehr FRP, die ein paar Versionen vor zugunsten der Elm Architektur ging.

Der Hauptgewinn von Elm ist, dass es ein statisches System hat, das dem Compiler ermöglicht, viele Behauptungen über Programmkorrektheit zur Kompilierzeit zu machen. Zum Beispiel wissen Sie, dass es nie eine Zeit geben wird, in der eine Fallanweisung nicht einen bestimmten Fall abdeckt. Oder dass der HTML-Code aus der View-Funktion ein Ereignis erzeugt, mit dem das Update nicht umgehen kann.

Andere Elm Vorteile

• Große Fehlermeldungen
• Pakete haben Semantic Versioning
• Pakete erzwungen und Werkzeuge sind in der Regel wirklich offensichtlich Namen haben

Answer 3

Sie sind beide FRP (Functional Reactive Programming) im Kern - das heißt, sie haben einen Baum, der dem DOM zugeordnet ist und nur die Komponente oder die Kinder darstellt, die gerendert werden müssen.(wie jemand schon früher darauf hingewiesen hat, hat Elm die FRP-Prinzipien aufgegeben, um seine eigene Idee von ihnen zu verfolgen)

Sie beide kompilieren in JavaScript (obwohl mit ClojureScript/Om-Bibliothek oder Reagenz könnten Sie tatsächliche React-Objekte in Ihrem js bekommen) weiß Elm macht ihr eigenes Ding. Ich mag nicht, dass Elm über npm installiert werden muss, obwohl czapliki, wie ich verstehe, an einem Standalone-Installer arbeitet)

Elm ist meiner Meinung nach schöner, weil es Zustand ein wenig mehr coder freundlich und es hat eine sehr nette (wie erwähnt -) Haskell-artige Syntax und auch Sie verschieben die RuntimeErrors in die CompileTimeErrors, die als Entwickler viel angenehmer ist - und es hat einfachere Code-Wartbarkeit. Auf der anderen Seite, Cljs hat viele Bibliotheken - einige von ihnen, wie ich bereits erwähnte React Components (Cljs/Om 1: 1 mit R.js LifeCycle entspricht) - andere einfach die FRP und LifeCycle Mentalität respektieren, ohne zu belasten von ihm. Vielleicht möchte ich in Om/Next mit einer GraphQL-Methode zum Aufrufen von Daten von einem Endpunkt suchen und hat die asynchronen Chans, die in plain cljs/Om verwendet wurden, gelöscht.

Es ist Geschmackssache um ehrlich zu sein, aber ich würde Elm (in beiden Sprachen geschrieben) bevorzugen. Wenn Sie jedoch mit cljs gehen, stellen Sie sicher, dass Sie eine nette Bibliothek bekommen und nicht in Vanille cljs tun, oder Sie werden es leid, wenn Sie 5k + LOC pflegen wollen. (Fulcro, Reagent, Om, OmNext, Hoplon usw.)