In every single aspect. I just wish that it will get mainstream as soon as possible.
His article is spot on, and agrees with what I've seen, and most others that used Elm. Just look it up.
For an average JS developer Elm is totally alien tech compare to React or Angular
For example, I just got into a new team, and I have to now use what they use. I've been doing JS for 4+ years, and that stack I'm facing now, is alien and confusing to me. I have to invest time and learn what the hell those redux-sagas are, or what "magic" create-react-app tools hide, and in general, it's very confusing so far.
With Elm, I spent a few weeks 1 year ago to learn the language, and that was it. All the libraries are very simple to use because of the language. I doubt that learning "redux-sagas" will help me a year from now.
Also, Elm, gives a very coherent package. You don't have to transpile or add a linter, or a type checker, or stitch new libraries every few months because the trend changed. No webpack or babel or eslint or immutable.js or typescript or flow or any of those.
Not to go into the part of the safety and confidence the compiler gives you. Typescript or flow are not even close to that quality and guarantee level. Note that again you have to learn their syntax and configure them, so that's again a cost on top of learning JS. And they are as much alien as Elm.
FWIW, I start now side-projects in Elm, and I get things done way faster than with JS. And that's also what I see from other people as well, regardless of whether they come from JS or another language.
The constantly churning and evolving JS ecosystem isn't necessarily a bad thing, although it does demand some attention. On the flip side, there is a lot of pre-written reusable code and more gets added daily.
From an ecosystem point of view, elm doesn't hold a candle to JS. Also, you don't have to learn every single JS library out there. You don't have to use redux-sagas. Use whatever you want.
Yes, I know there are a lot of tools and a lot of options and that can be exhausting. But I don't think that's necessarily a bad thing.
Being a contractor, I change teams and projects all the time. And most of the time when I join a team with an existing project, the devs that started it are pretty opinionated on everything.
So sadly simple vanilla JS is not an option if you want to be a preferable candidate for projects. Most of the teams prefer piling libraries upon libraries cause they think it will make things "convenient" or because it's the new exciting trendy library. Whereas I've seen the opposite in the long-term, they make things more complicated and eventually impossible to maintain/reason with.
I'm not trying to sell Elm to anyone, if you don't like it, don't use it. But to me the advantages are quite obvious and I'd take it over any JS framework/library out there. I just hope I could use it at work as well. There are only a few Elm jobs out there right now.
Easy to develop and maintain, big check.
Widely used so you can hire - it's usually easier to hire Elm developers because there are more people who want to use it than jobs hiring for it. The opposite is true for JS. So...better than check, at least for right now! :)
Here is a CTO giving a talk about his company's experiences with Elm:
"Elm from a business perspective" - https://www.youtube.com/watch?v=DvQI1KntMhk
As a CTO and the author of the OP, I can say with confidence this statement is false. Elm works correctly, is easy to develop in, and is easy to train developers that have experience in other languages to write Elm.
For example:
https://groups.google.com/forum/#!msg/elm-discuss/92dXqmB4nJ...
But this is common in niche languages. Most of my background is in Clojure, which has a vastly larger userbase than Elm, but it can still be very difficult to find good developers for it. Many of the professional Clojure developers I know learned the language on the job when they went to work for a company that used it. I wouldn't doubt it is similar with Elm. I saw a presentation once by a CTO of a company that started using Elm in production, and he mentioned that hiring is one of the larger risks to adopting it. But that shouldn't necessarily stop anyone, depends on a company's goals (and spirit).
>>> You don't have to transpile or add a linter, or a type checker, or stitch new libraries every few months because the trend changed.
Elm is still in alpha, and is adding and removing breaking features all the time. (See ports for example) [1]
>>> No webpack or babel or eslint or immutable.js or typescript or flow or any of those.
If you are integrating elm into any kind of existing application, you will likely need webpack. [2]
>>> I doubt that learning "redux-sagas" will help me a year from now.
Given redux is an order of magnitude more popular than Elm is, and Redux Saga is the most popular effects handler library for Redux, I would not agree with this statement. Learning about generators is valuable regardless.
[1] https://github.com/elm-lang/elm-platform/blob/master/upgrade...
[2] https://www.elm-tutorial.org/en/04-starting/03-webpack-1.htm...
Elm has had 2 releases since 2015 which had breaking changes. The elm-upgrade[0] tool has automated away a lot of the upgrade progress, and the compiler tells you about all the remaining things that need to change.
Put another way, Elm doesn't actually change very often, and when it does, it is typically a smooth ride. (I've been around for 5 breaking releases, and all but one of them were very easy.)
> If you are integrating elm into any kind of existing application, you will likely need webpack.
If that existing application is already using webpack, then sure, you'll probably keep it. But you don't need it for Elm.
For example, we use Elm at work (on a 150,000 LoC Elm code base) and we actually moved away from Webpack because Elm doesn't need it and we weren't happy with its UX. :)
>In every single aspect. I just wish that it will get mainstream as soon as possible.
I completely agree - I will be a huge benefit to the industry when elm is as common as js. The concepts it introduces, the benefits it shows are all huge.
I've been programming a long time, and elm shattered my views of the relationship between a coder and his/her compiler. It went from being that thing you have to "pass" to see your code work, to instead a faithful companion. Like having a trusted dog with you in the woods - an extra set of senses to help you out on your way.
Elm is not perfect (no language is) -but being perfect isn't the goal. A practical transition story, huge productivity gains and extremely maintainable code.
And sure, when more people join Elm, bad-written libraries or silly paradigms will crop up, but I'm confident it won't be as bad as the JS landscape is today.
Time will tell I guess. -- Now back to stitching those JS libraries to write some code that might work. Bills have to be paid :)
I love Elm as much as the next guy, but be aware that you can get many, if not most, of these same benefits while working in JS if you use Flow.js or Typescript. I prefer Flow because the community is more oriented toward functional programming vs OOP in Typescript, but they're both capable static analyzers for JS.
Listen, I love pure functional languages, but the step up from JavaScript to flow in program correctness is greater than the step up from flow to elm (in my opinion). Flow even has sum types.
Have you actually tried flow?
Problem with both Typescript and Flow is that it requires discipline from you, your team, and those who provide third party libraries. If someone was lazy and inserted `any` at a key location, you can start having familiar bugs even if the type checker tells you everything is fine.
1. https://github.com/gajus/eslint-plugin-flowtype#eslint-plugi...
I'm not saying that typescript/flow is bad. Whenever I have to use node.js, I end up using typescript. But I've been bitten several times by the fact that typescript isn't as strict as Elm forces things to be.
Yes, as long as you lint those libraries, too.
> A thing that typescript and/or flow doesn't support, is JSON. What if a JSON object doesn't match the type?
That's why you do runtime validations of your incoming JSON if you feel like you can't trust the data (and if it's an external API, you probably can't). How is this different from Elm?
> But I've been bitten several times by the fact that typescript isn't as strict as Elm forces things to be
In my experience with Flow, between the Flow analyzer and accompanying linter, you can make it just about as strict as you want with respect to types. The main thing you'll miss (as discussed elsewhere) is that unlike Elm, there's no way to guarantee referential transparency with JS and Flow.
Me, personally, I take short-cuts when I'm pressed for time, stressed, or in a bad mood (which happens more often than I'd like to admit). I can always improve the code later (which turns into never). In Elm, I can't cut corners (as easily). This makes me write better code using Elm, which in turn makes me happier.
You --can-- get the same experience with Javascript, but it does require more from you, the developer.
* Lack of purity. You can unintentionally trigger side effects from a function that's a supposed to simply return a value.
function add(x: number, y: number): number {
fireTheMissiles()
return x + y
}
I agree. Which is why I said "many if not most" benefits, not all benefits.
> It's impossible to validate that external JSON data is the correct type at runtime.
Not sure I understand what you're saying. Of course you'll get a runtime error if your external JSON is the wrong type, what else could you do? Accept the data and enter an inconsistent state?
However, similar to the Elm JSON validation, in Typescript and Flow, you can write schemas to to runtime validation of external JSON. There are multiple libraries for this.