[antouank]

After doing a couple of contracts on Elm projects for several months, and returning now back to a React-Redux stack project, I cannot emphasize enough how much better working with Elm is.

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.

[StreamBright]

I am more interested in the details that just this blank statement that everything is better. After trying Elm several times we failed to implement even basic things in it that we could do in React/Redux easily. For an average JS developer Elm is totally alien tech compare to React or Angular. For Haskell programmers Elm is pretty appealing because of the familiar syntax and type system, but the intersection of Haskell programmers and frontend developers are pretty small.

[antouank]

     For an average JS developer Elm is totally alien tech compare to React or Angular

To turn your argument the other way. The JS landscape, where "trendy" libraries change every few months, is also alien to anyone that doesn't keep with the latest libraries every few months. Is that not worse? I don't have to explain "JS fatigue", it's a fact.

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.

[computerex]

Nothing is forcing you to use the trendiest JS libraries. Feel free to do your side projects in vanilla JS or with whatever library you want.

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.

[antouank]

I don't want to, but the "market" is forcing me.

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.

[tarr11]

Agree in general that Elm is nicer than Redux. However...

>>> 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...

[rtfeldman]

> Elm is still in alpha, and is adding and removing breaking features all the time.

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. :)

[0] https://www.npmjs.com/package/elm-upgrade

[StreamBright]

Well sure, but as an architect/CTO I do not care about trendy, I care only about properly working, easy to develop and maintain and wildly used so I can hire for. Elm is none of these at the moment, but React is.

[rtfeldman]

Properly working, check.

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

[hellofunk]

The most common stance on hiring Elm developers is to not look for people with experience with Elm (because there are relatively few) but people who are smart and willing to learn it. It is a different way than for hiring in other languages.

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).

[Albert_Camus]

> I care only about properly working, easy to develop and maintain and wildly used so I can hire for. Elm is none of these at the moment, but React is.

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.

[enalicho]

If you get stuck on anything, come tell us about it on Slack. We can help you get unstuck! The majority of Elm users come from JS -- so while the syntax is different, it should not to be too hard to pick up. This is one of the reasons that Elm has avoided complex features from Haskell. It's really not very much like Haskell beyond syntax. Redux is very much like Elm, seeing as it is an implementation of the Elm Architecture.

[BoiledCabbage]

> I cannot emphasize enough how much better working with Elm is.

>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.

[jnbiche]

> I've been programming a long time, and elm shattered my views of the relationship between a coder and his/her compiler.

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.

[tomtheelder]

I would disagree strongly with this, but I don't quite know how to put my objection into words. The enforced functional purity, "true" and incredibly friendly compiler, and the robust message system are all things that I don't think you really get in those other languages. To me, it's a bit like saying that you get all the benefits of Haskell in Java, because Java is also statically typed.

[jnbiche]

Please read my comment again, I said "many if not most" of the benefits. And I was referring specifically to the tire system, not the language as a whole.

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?

[simplify]

I've tried to use flow three times now, but the tooling just isn't there yet. It might be better now, but Facebook doesn't seem to invest heavily in developer UX.

[jnbiche]

What problem did you have?? I've been using Flow.js for work for several years now, to great success. I feel very uncomfortable now writing plain JS.

[fbonetti]

Cons of using Typescript:

* 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
    }

* It's impossible to validate that external JSON data is the correct type at runtime. If a JSON API returns something weird, you're going to get a runtime error.

[jnbiche]

> Lack of purity.

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.

[Skinney]

I've used both Typescript and Flow, and this breaks down in practice. At least, it did for me.

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.

[jnbiche]

This is trivial to avoid with a linter (which is a good idea to use anyway with JavaScript). For Flow, there's an eslint plugin that allows you to raise an error on the use of any weak type, such as `any` [1]. I'd be very surprised if the same doesn't exist for TypeScript.

1. https://github.com/gajus/eslint-plugin-flowtype#eslint-plugi...

[Skinney]

Cool! Does it enforce third-party libraries as well? A thing that typescript and/or flow doesn't support, is JSON. What if a JSON object doesn't match the type? This can cause sneaky bugs later :/

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.

[jnbiche]

> Cool! Does it enforce third-party libraries as well?

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.

[fulafel]

That's like saying an angry bear has many of the benefits of a bicycle. It may be factually true but the downsides of riding an angry generally outweigh the benefits, and anyway it's a different kind of thing altogether from a bicycle.

[laughinghan]

It's nothing like that. The downsides of riding an angry bear relative to a bicycle also apply relative to just walking, to the point that it's always better to just walk than to ride an angry bear for transportation. The downsides of Flow.js or TypeScript relative to Elm don't at all apply relative to vanilla JS, it's often better to use them rather than vanilla JS.

[gcanti]

working on a fp library for TypeScript if you want to take a look https://github.com/gcanti/fp-ts

[antouank]

Not perfect, but definitely a much better tool for that work (big front-end apps). JS was not meant for that, it's been stretched far from what it was (quickly) designed for.

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 :)