W jaki sposób Elm porównuje się do ClojureScript?

Question

Dochodzę do punktu, w którym kodowanie GUI za pomocą zorientowanego obiektowo wzoru MVC Backbone.js staje się dość skomplikowane i rozgląda się wokół innych paradygmatów. MDV, FRP, ECS, o mój.

W jaki sposób Elm porównać do ClojureScript? Gdzie się pokrywają?

Oba języki są bardzo różne od JS kompilujących się z JS. Rozumiem, że Elm to język programowania funkcjonalnego reaktywnego (FRP). ClojureScript niekoniecznie jest FRP, ale możesz zrobić z nim FRP. Elm kompiluje się z Haskell i ClojureScript z JVM, więc oba te są dodatkowe wymagania dla sklepu Node.

Może to tylko sprowadza się do Clojure vs Haskell.

Answer 1

Obie strony zmuszają Cię do używania bardziej deklaratywnego/funkcjonalnego stylu programowania niż czysty JS. ClojureScript jest bardziej podobny do zamiennika JS, podczas gdy Wiąz bardziej przypomina zamiennik całego stosu tworzenia stron WWW (HTML/CSS/JS).

Inne różnice:

• składnia Elm jest znacznie bardziej Haskell-like
• ClojureScript jest znacznie bliżej do tradycyjnej Lisp składni
• Elm jest wysoce zoptymalizowany dla wartości zmiennych w czasie ("Sygnały" w Elm)
• ClojureScript jest bardziej dojrzały i można znaleźć na nim słodkie narzędzia programistyczne (wtyczki Eclipse, LightTable itp.)
• Wiąz jest statycznie typowany, ClojureScript jest dynamicznie typowany ed

Mam nadzieję, że to pomoże. Nadal uczę się obu tych języków, więc mogłem coś przeoczyć.

Answer 2

Wystarczy zaktualizować to do 2017

Elm nie jest już FRP, że odeszła kilka komunikatów temu na rzecz Elm Architektury.

Główną wygraną Elma jest to, że ma system typu statycznego, który pozwala kompilatorowi na wykonanie wielu twierdzeń o poprawności programu w czasie kompilacji. Na przykład, wiesz na pewno, że nigdy nie będzie czasu, w którym orzeczenie nie obejmuje konkretnego przypadku. Albo, że HTML z funkcji widoku wygeneruje zdarzenie, którego aktualizacja nie wie, jak sobie poradzić.

Inne zalety Elm

• Wielkie komunikaty o błędach
• Paczki są egzekwowane semantycznej wersjonowanie
• Pakiety i narzędzia mają zwykle bardzo oczywistych nazw

Answer 3

Są zarówno FRP (Functional Reactive Programowanie) w ich rdzeniu - co oznacza, że ​​mają drzewo mapowane na DOM i renderują tylko ten komponent lub dzieci, które wymagają renderowania.(jak zauważył ktoś wcześniej, Elm porzucił zasady FRP, aby realizować własne pomysły)

Obie kompilują się w JavaScript (chociaż z biblioteką ClojureScript/Om lub Reagent można uzyskać rzeczywiste obiekty React w twoim js) biały Elm robi swoje. Nie podoba mi się, że Wiąz musi być zainstalowany przez npm chociaż czapliki jak rozumiem działa na samodzielnym instalatorze)

Wiąz jest ładniejszy moim zdaniem, ponieważ zarządza stanem trochę bardziej przyjazny dla koderów i ma bardzo ładny (jak wspomniano) - składnia podobna do Haskella, a także przenosisz RuntimeErrors do CompileTimeErrors, który jest znacznie bardziej przyjemny jako programista - i ma łatwiejszą łatwość obsługi kodu. Z drugiej strony cljs ma biblioteki lotsa - niektóre z nich, jak wspomniałem, zwracają rzeczywiste składniki reakcji (cljs/Om mecze 1: 1 z R.js LifeCycle) - inne po prostu szanują mentalność FRP i LifeCycle bez obciążania się przez to. Może zajrzeć do Om/Next za pomocą metody GraphQL, która wywołuje dane z punktu końcowego i zrzuciła asynchroniczne kanały, które były używane w zwykłym cljs/Om.

To uczciwa sprawa, ale wolałabym Elm (napisany w obu językach). Jeśli jednak pójdziesz z cljs, upewnij się, że masz fajną bibliotekę i nie rób rzeczy w wanilii cljs lub będziesz żałować, gdy chcesz zachować 5k + LOC. (Szukaj Fulcro, Reagent, om, OmNext, hoplon itp.)