Come si confronta Elm con ClojureScript?

Question

Sto raggiungendo un punto in cui la codifica della GUI con il pattern MVC orientato agli oggetti di Backbone.js sta diventando piuttosto complessa e si guarda intorno ad altri paradigmi. MDV, FRP, ECS, oh mio.

In che modo Elm confronta con ClojureScript? Dove si sovrappongono?

Entrambe sono lingue molto diverse da JS che vengono compilate in JS. Comprendo che Elm è un linguaggio di programmazione reattiva funzionale (FRP). ClojureScript non è necessariamente FRP, ma puoi farlo con FRP. Elm si compila con Haskell e ClojureScript con JVM, quindi entrambi sono requisiti extra per un negozio Node.

Forse si riduce a Clojure vs Haskell.

Answer 1

Entrambi ti costringono a utilizzare uno stile di programmazione più dichiarativo/funzionale rispetto al puro JS. ClojureScript è più simile a una sostituzione JS, mentre Elm è più simile a un sostituto per l'intero stack di sviluppo Web (HTML/CSS/JS).

Altre differenze:

• sintassi Elm è molto più Haskell-like
• ClojureScript è molto più vicino di sintassi tradizionale Lisp
• Elm è altamente ottimizzato per i valori che variano nel tempo ("segnali" a Elm)
• ClojureScript è più maturo e si possono trovare alcuni strumenti di sviluppo dolce per esso (plug-in Eclipse, LightTable, etc.)
• Elm è staticamente tipizzato, ClojureScript è dinamicamente tip ed

Spero che questo aiuti. Sto ancora imparando entrambe queste lingue quindi potrei aver perso qualcosa.

Answer 2

solo per aggiornare questo per il 2017.

Elm non è più FRP, che è andato via un paio di uscite fa, a favore della Elm Architettura.

La principale vittoria di Elm è che ha un sistema di tipo statico che consente al compilatore di fare molte asserzioni sulla correttezza del programma in fase di compilazione. Ad esempio, sai per certo che non ci sarà mai un momento in cui una dichiarazione di un caso non copre un caso specifico. O che l'HTML dalla funzione di visualizzazione produrrà un evento che l'aggiornamento non sa come gestire.

Altri vantaggi Elm

• grandi messaggi di errore
• pacchetti sono applicate delle versioni Semantic
• Pacchetti e strumenti tendono ad avere nomi davvero evidente

Answer 3

Sono entrambi FRP (Programmazione reattiva Funzionale) al loro centro - il che significa che hanno un albero mappato al DOM e rendono solo il rendering di quel componente o dei bambini che devono essere resi.(come qualcuno ha sottolineato prima, Elm ha abbandonato i principi FRP per perseguire la propria idea)

Entrambi compilano in JavaScript (sebbene con la libreria ClojureScript/Om o Reagent si possano ottenere oggetti React effettivi nel proprio js) bianco Elm fa le sue cose. Non mi piace che Elm debba essere installato tramite npm anche se czapliki come capisco sta lavorando su un programma di installazione standalone)

Elm è più bello secondo me perché gestisce lo stato un po 'più coder friendly e ha una molto bella (come detto -) Sintassi di Haskell-like e anche spostare RuntimeErrors in CompileTimeErrors che è molto più piacevole come sviluppatore - in più ha una più semplice manutenibilità del codice. D'altra parte, cljs ha molte librerie - alcune di esse come ho già detto restituiscono i componenti React reali (cljs/Om corrisponde a 1: 1 con R.js LifeCycle) - altri semplicemente rispettano la mentalità FRP e LifeCycle senza diventare ingombranti da esso. Potrebbe desiderare di esaminare Om/Next con un modo GraphQL di chiamare i dati da un endpoint e ha eliminato i chan asincroni che sono stati usati in plain cljs/Om.

E 'una questione di gusto ad essere onesti, ma io per primo preferirei Elm (avendo scritto in entrambe le lingue). Se invece va con cljs assicuratevi di avere una bella libreria e non fare roba in cljs vaniglia o te ne pentirai quando si desidera mantenere 5k + LOC. (Guardare in alto Fulcro, reagente, om, OmNext, hoplon , ecc)