- Currently Elm has a sad story addressing integration with "native" javascript libraries and Elm is too opinioated in some cases, e.g. you can only use either the built-in 'Elements' or virtual-dom Elements to render frontend. This makes it hard to build modular components (see https://groups.google.com/forum/#!topic/elm-discuss/65tiRM7S... for example)
- While the simple type system in Elm (e.g. no type classes, no monads, ...) makes beautiful error messages possible, it really limits the abstractions that I am used to coming from Haskell
- Elm/Elm-make does not generate modules that conform to a "standard" js module system - thus it will not integrate well with other js tools
- Elm syntax is lacking 'where' clauses, which results in constant reindentation of code
Don't get me wrong - I liked Elm a lot; but it just does not seem mature enough to use in production - but it looks like a great language to start learning FP.
It's like an OO programmer claiming that Smalltalk is a superior language than Elm. Besides, Purescript is squarely targeted at experienced Haskell programmers, which is not the case of Elm. Elm is an ML language, not a Haskell dialect that compiles to JS.
I also evaluated Elm, Purescript, Roy, F#, JS_of_Ocaml and ended up choosing Elm precisely for the reasons you chose to stay away from it. I only use JS for front-end stuff, I value simplicity over expressivity and I don't want to spend many weeks learning Haskell-like abstractions to start being productive in a new language (in contrast, it only took me an afternoon to start being productive in Elm).
To be clear, Haskell also comes from the ML lineage.
The root of this particular family tree is essentially a fusion of the lambda calculus-inspired parts of Algol 60 and Lisp with some new ideas for syntax that were promoted by Peter Landin in his highly influential paper from 1966, "The Next 700 Programming Languages". He called this language ISWIM; it was studied extensively but never directly implemented. Landin was also associated with Dana Scott and Christopher Strachey in their foundational work on programming language semantics.
Robin Milner was interested in the relationship between the logic underlying the semantics of programming languages and the possibility of using computers to prove propositions in that logic (a logic developed by Dana Scott in support of his semantics work). At Stanford, he and a small team (including Whitfield Diffie, who later went into cryptography...) developed a system called Stanford LCF (for Logic of Computable Functions). This was an interactive system in which the user states a main goal in the logic, then splits it to subgoals and more subgoals until they can be solved directly. Proofs were represented directly by data structures and were built directly by the proof manipulation commands, which corresponded to the inference rules of the system.
Milner moved to Edinburgh in 1973, where he worked on a subsequent version of LCF, Edinburgh LCF. Stanford LCF was limited by the size of the proof data structures; for Edinburgh LCF Milner had the idea to forget the proofs, but store the results of them; i.e. the theorems. The proof steps would be performed, but not recorded. To ensure that theorems could only be constructed via valid proofs, a meta-language was developed with a static type system that would only allow data structures corresponding to valid theorems to be built. It also allowed more sophisticated proof development, since the meta-language was a full higher-order programming language modeled after Landin's ISWIM. Exceptions were included to deal with the possibility of failure of particular proof strategies. This version was implemented in Lisp.
LCF spread to other universities; it was early on split into two parallel tracks, ML and Caml. Both have continued to be strongly associated with implementation of theorem proving systems. ML and LCF have become Standard ML and HOL; Caml has become OCaml and Coq. A lot of programming language research has also gone into ML and OCaml as languages in themselves due to their close association with the logic underlying semantics of programming languages.
Meanwhile, a language called PAL was developed in 1968 at MIT in response to ISWIM and Strachey's ideas on programming languages. David Turner, while starting his Ph.D. research at Oxford, got access to the PAL sources and used a simplified form of the language as the basis for his lectures on functional programming at St. Andrews; he called this language SASL. It was initially just a blackboard language, but a colleague surprised him by implementing it in Lisp.
In 1976, Turner changed the semantics of SASL from eager to lazy, based on a lazy version Landin's SECD machine. Somewhat later in his career, he combined ideas from lazy SASL, a cut-down version of SASL called KRC, and the ML-originated Hindley-Milner type system to form a language called Miranda. And Miranda is one of the primary influences on Haskell.
So, this leaves out a lot of other languages such as HOPE and lazy-ML that also were developed in this space. But what's interesting to me is how all these languages, from ML to Haskell, are so strongly related to Algol and thus the Pascal, C, Java, etc. languages that are more familiar to industry.
That got a lot bigger than I intended; I hope someone takes some interest from the digression.
Also, I was the only one with actual OCaml experience, and the other devs found Elm much easier to learn.
We almost went with Funscript, I think, but unfortunately F# on *nix was a no-go.
- Elm requires a painful amount of boilerplate code. A lot of this is related to the fact that it tries to do functional programming without many of the customary abstractions.
- Elm's FFI (via the ports system) is really painful to use. If you ever need to integrate to third party code, or get a value from the DOM, it's going to require creating a new port in your main module, a new listener in JS, and wiring everything up.
- A lot of Elm tools and APIs have bugs. For example, I discovered that if I built my app using the recommended Elm architecture, I couldn't use the debugger. But even some core APIs like Window.dimensions burned me more than once, with things like: https://github.com/evancz/start-app/pull/37
I've started porting the app to Purescript. I used the Purescript book, which is excellent: https://leanpub.com/purescript/read I'm especially happily with Purescript's FFI, and its generally pragmatic attitude.
However, Purescript doesn't come with a "blessed" UI library, so you have to pick. I briefly tried the ambitious Halogen library, but the sheer type-system complexity ground me down quickly. I eventually went with the Thermite library, which is a very thin library wrapper of React (< 300 lines of code). So far, Thermite has been very nice, and quite easy to use, though it could use some enhancements and tweaks.
Overall, I like Purescript a lot. My basic problem with Elm is that it tries to be very opinionated, with very few escape hatches, so when I got stuck, I tended to get stuck very hard. Whereas with Purescript, it's much easier to drop down to JavaScript, but also to "pop up" and pull a well-known abstraction out of the standard Haskell toolbox if I need one.
Another advantage of PureScript: The foreign function interface is ridiculously easy to use.
* ClojureScript: This is the only AltJS language I've done real work in and used in anger, so naturally it's the one I'd complain about the most. I don't like being negative so I'll keep it short: It doesn't provide the same increase in productivity relative to the host language as Clojure does to Java. The advantages it has over ES6 fail to make up for the loss of a huge ecosystem and this only seems to get worse because of the rate big JS community innovates (whether you'd classify this as 'churn' is another matter).
* GHCJS: One of the most impressive compilers out there that target JavaScript. If you are already spoiled by Haskell and comfortable with it's semantics and runtime system definitely go for it. But if you are approaching this from the perspective of a front end developer who's looking for a better language this will feel like learning C++ just so that you can compile it with Emscripten.
I've used GHCJS to build https://github.com/osener/markup.rocks which runs Pandoc in browsers and it's certainly the best, if not only, option if you are looking to compile some existing Haskell codebase to JavaScript. My decision to stop using it has more to do with my lack of experience with Haskell than any problems with GHCJS itself. I tried to adopt so much new stuff at once with my limited Haskell experience, Reflex, GHCJS, FRP etc., and I'm having a hard time pinpointing which ones netted the increase in program robustness I've experienced (app development in JS feels so brittle in comparison) and which ones caused my lack of productivity.
After visiting this codebase after spending more than half a year without doing any Haskell GHCJS DOM APIs were revamped and I was so unfamiliar with my codebase that I didn't know where to start converting it to the new API let alone add new features. I started exploring packages like https://hackage.haskell.org/package/react-flux to see if I can take a more conservative approach with GHCJS and get the benefit of leveraging the ready-made React components out there. Unfortunately I was also very unhappy with the 26MB uncompressed JS output and wanted to add JS based renderers for stuff like Markdown and split Pandoc to its own .js file to lazily load it when it's needed. Thinking about this I realized that my main use case for GHCJS was compiling Pandoc and once I split that up I don't need to choose between two Haskell front end libraries and write the app itself using a more pragmatic stack and get some performance benefits (GHCJS produced code is especially hard on mobile browsers).
At this point I was pretty spoiled by Haskell and wanted to keep most of it while taking a more pragmatic approach. This brought me to
* Elm: I didn't know a language could provide such a good UX until I discovered Elm. From simplicity of the syntax to compiler messages, wonderful piece of work! I won't get into it's shortcomings compared to Haskell; although I can see the usefulness of additions like Typeclasses there are lots of posts from experienced Haskellers suggesting language features, and posts from Elm's designers explaining their choices not to include these. I'm not educated enough in these matters to say anything that hasn't been said before in favor of either stance.
My real suprise wasn't lack of Typeclasses; it was how unpragmatic Elm is, especially since it's not an attempt to adapt an existing language for front end development but a language designed specifically for it. I certainly applaud their goal to create a better way to write browser apps and I understand that they are in it for the long haul but I need to be productive right now and even GHCJS has a better FFI solution than Elm. When people ask how to use a JavaScript library from Elm in mailgroups and stackoverflow, their communities stance seems to be "include CSS and rewrite the JS code in Elm". This might be fine if all you need is to rewrite Bootstrap's dropdown logic in Elm but for doing real work not being able to leverage existing open source projects will quickly invalidate any productivity benefits you get from using Elm.
I love everything about Elm and I'm sure it will keep getting better & gaining mindshare but for now I can only rationalize using it in a small well contained part of a big application that lives in an island (and it is hard to find a good fit for this). Elm programmers; please standardize a better way to use native libraries and lose that 'yuck, that's unsafe' attitude against existing solutions written in JS. After publishing a complete library by writing bindings you can always rewrite it internally in Elm one function at a time.
So Elm is not for me right now. If you are still with me, I'll finally cover...
* PureScript: For some reason, during my journey through AltJS languages I've never considered PureScript before exhausting most of my options. I think this has to do with the grumpy attitude I used to have about front end development years ago when I first started doing less and less back end work. I wanted to keep all my trusted tools and always sought solutions that would let me. I liked how ClojureScript would let me use Leiningen, GHCJS would let me use Cabal etc. to build my projects. After front end development started to be something I enjoy doing rather than something I have to do, I realized I should start seeking solutions that would let me embrace tools web community has to offer and piece well-made blocks together to create web applications rather than fighting against it and living in my own island grudgingly rewriting everything. I love how PureScript is just a part of the toolstack like CoffeeScript and each .purs file produces one .js file without any runtime. On a scale from line-to-line transpilers like CoffeeScripts to beasts like Emscripten this is the sweet spot for me.
I've been using React almost since it's first incarnation and after writing a lot of CLJS/Om code I've come to realize that HTML is the best DSL to write HTML in and plain React+JSX is the best way to create views for me. Plus, all the React components I can just grab and use give a huge advantage over any 'virtual-dom' based library like Elm-HTML, Halogen. JS leaves a lot to be desired regarding app structure, error handling, side effects, business logic etc. and fortunately you can mix-and-match PureScript with JavaScript however you like. It has a FFI system that's best-in-class and semantics that are easy to reason about and won't need a big context switch when interacting with the outside world. In fact, the approach I'm taking now doesn't require me to write the main application in PureScript with React bindings and treat the JS code to be as the 'outside world' because you can just https://github.com/ethul/purs-loader in your existing Webpack configuration and start doing require('./PurescriptModule') right away. If you are using Redux for example, you can write your Views in JS and let React+JSX do what they do best and write your Actions and Reducers in PureScript. This will give you the benefit of being able to use existing React components and concisely define browser rendering while defining your business logic & execute side effects in a safer and more expressive language.
What kind of "loss of a huge ecosystem" did you have in mind?
> …and this only seems to get worse because of the rate big JS community innovates (whether you'd classify this as 'churn' is another matter).
Last time I looked at CLJS and JS, it was the JS community that was catching up with CLJS (figwheel vs hot reloading, re-frame vs redux). People like David Nolen, Bruce Hauman and Mike Fikes are doing a lot of stellar work!
In contrast, Elm is focused on front-end work and is less expressive, but emphasizes simplicity. Elm's goal of figuring out how to simplify and distill the Haskell and ML world's abstractions is an admirable one, but as an experienced programmer interested in practical work I'd rather just go with PureScript and just learn the Haskell-like abstractions along the way. It also really helps that the PureScript compiler's javascript output is "natural" and easy to understand, without any mysterious transformations involved.
Have others looked at PureScript, Elm, Haste, GHCJS, etc and chosen differently?