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