Yes it’s a different language that compiles to JavaScript, but unlike other languages that do this, Elm exists solely to excel at front-end web development.
Ironically, that Redux and React equivalents are some of the “batteries included” in Elm can make it harder to pitch because at first it seems like you’d have to add that stuff in.
The set of languages on state-of-JS is therefore artificially constrained to what the creators of the survey think deserves a place there, rather than the actual community thinks.
I'm a fan of elm, but but overall population of functional programmers is quite small, so I wouldn't be shocked of Elm, PureScript, and Reason had similar populations of developers.
The compiler can do compile-time checks that wouldn't be possible if it were implemented as a library instead.
No, because javascript isn't machine code, it's a high-level interpreted language. The metaphor of javascript as "bytecode" is just that - a metaphor.
>The compiler can do compile-time checks that wouldn't be possible if it were implemented as a library instead.
Fair enough, but it doesn't actually change the grammar of the language, because those new "primitives" have to be implemented in, and interpreted as, javascript.
This is a psychological distinction, not a technical one. There is no fundamental difference between machine code, byte code, or a “real” programming language. There were machines that executed lisp, and at the dawn of time people programmed in assembly. Heck, people programmed in machine code (punch cards) and assembly was a programming language!
Scala introduces a hell of a lot of “new primitives” over jvm bytecode, and type erasure compiles it all down to the jvm anyway. Or JavaScript, if you use scala.js.
This is, in fact, precisely what compilers do (or transpilers—again: psychological distinction, technically the same thing). That is their job, their function: translating from one language into another. As long as both are Turing complete, you can do anything.
But, I don't think the distinction is entirely psychological. Every numeric type is implemented in javascript as a floating point Number, that's all javascript has. New types aren't added to javascript when other languages compile to it, they're compensated for within the limits of what a javascript parser considers valid code, either through existing javascript types or facades which imitate types. Whatever Scala or any other language considers an Int, BigInt, Double, etc. must still be implemented as a Number when compiled to javascript, or some object which imitates the semantics of the original language. But an Int() object in javascript is still not an integer.
It doesn't make sense to say that languages which compile to javascript add anything to the language. Or maybe I just don't understand types, and they really do, and it really doesn't matter. But to me, the distinction seems to matter.
I should probably stop tilting at this particular windmill, though.
Yes it does! That's the entire point.
It doesn't change the grammar of the language that the generated code is using, but you don't care, because you're not writing in that language.
But that's the grammar I was talking about, so no it doesn't.
So sure, what Elm gives you can be done with just a framework, but it wouldn't be very productive. There is a reason why hardly anybody programs in assembler anymore (unless they have a good reason). Higher-level languages provide better abstractions, allow you to write more expressive code, are safer etc.
The point of Elm is not just the architecture, it's the language that allows you to write robust websites with little to no debugging necessary, all maintaining that robustness no matter how much you extend, tweak and refactor the codebase without having to be an expert in the language.
"Zero runtime exceptions" is no exaggeration, it's a reality in practice guaranteed by the compiler, meaning "after all it's compiled to js" makes no sense.
In Elm you don't have exceptions, so the framework does not accomodate for them like, say, React does.
It's also a pure language, so the separation of main state mutation and other side-effects without Elm the language is nothing more than convention, so you're not doing any better than Redux+Redux saga on that point.
I'd suggest you try out Elm in a small project and see for yourself why it makes no sense to try to make it fit in the context of JavaScript.
It's simply that Elm the framework was designed without regard for the problems of other languages, and making full use of the features of Elm the language.
On the other hand, Redux was inspired by Elm to replicate the same model in JavaScript while accounting for the deficiencies of that language. The closest you can get to Elm is probably that.
The biggest thing here is that Elm does not allow mutation. This turns out to be great because it eliminates little pockets of state that make your app’s behavior hard to predict and that eventually cause bugs. It also seems like it would be very hard to bolt this on to JavaScript; you’d have to break existing code and then your runtime would miss out on the performance benefits of assuming everything is immutable.
Elm also removes classes, inheritance, == vs ===, and a bunch of other JS junk drawer stuff that turns out to be unnecessary when you have immutability and a thorough type system.
“Perfection is not when there’s nothing more to add, only when there’s nothing more to take away.”
Isn't immutability a problem in a garbage collected environment? I come from a C++ and ActionScript background, and on the ActionScript side garbage collection was a major issue. Would I not have the same if not worse issues in Elm?
Or you could have a runtime development option to detect mutations similar to existing redux-type solutions. This also still doesn't explain why the need for a new language instead of decoupling the two. As I mentioned in another comment, all these features make working in Elm probably a superior experience, but I fail to see why it's mandatory and the mandatory-ness is what makes this a much harder sell.
In a large enough codebase, reaching every code path is non-trivial. It’s very easy to write code that only runs when it gets a certain response from a server, and at that point you need an entire integrated environment, plus a humongous space of configuration and use cases. (Or highly detailed mocks and 100% test coverage, which is even more rare.)
By contrast, you get that much certainty every time an Elm program compiles.
Maybe it’s possible to statically analyze JS to the point where you can get the same guarantees as compiling from a stricter language, but that seems very very hard.
Except that it unfortunately falls short of that.
Quite a few projects (Node.js and Backbone) achieved wide adoption before 1.0.0.
For the record I’m not sure the Elm project has any claim one way or another, apart from the current version of 0.18 and the main contributors having large code bases in production at private companies.
So maybe it’s not that damning, and we still haven’t heard the GPs thoughts on how Elm has fallen short for them.