For those unfamiliar with elm:<p>I would sum it up as:<p>-) a stripped down, simplified version of Haskell<p>-) with a good concept for side effects<p>-) that compiles to Javascript<p>-) gearded towards writing type safe frontend code for the Browser<p>-) strongly nudging you towards a clean, well architected app structure (see 'the Elm Architecture').<p>I think it's on the tipping point right now:<p>if enough people jump on board, the language get's good documentation, and the library ecosystem grows, I see a great future for Elm.<p>Otherwise, it will dwindle away soon into the endless annals of forgotten languages.
The docs / language manual is emberassingly sparse right now.<p>The Elm dev(s?) really need to fix the Architecture Tutorial and write a proper language handbook.<p>Right now, the bad docs are pretty off-putting to someone coming to the language.<p>It's a shame, really, because I think Elm is great.
While I love Elm, after the recent release that replaced Signals, it's going to take a long time for me to bet anything with money on it. My toy app didn't have many dependencies, but when <i>so much</i> breaks on upgrading the runtime it's a hard sell.<p>(Not to disparage the change or the work behind it! I think it was the right call, and again, love the language and community. Just expressing, after the last experience, that I'll wait until 1.0 since the language is still undergoing drastic changes)
Isn't this basically the same strategy every challenger technology takes to replacing an incumbent one? The problem is your organization has to be willing to bet on Elm as a tool. What does the org do if you leave, get sick, or are terminated? In many ways choosing niche technologies with esoteric syntax or paradigms is like holding your organization hostage IMO.<p>Now does that mean nobody should ever choose a new language or other tool? No, but the cost of adoption needs to be evaluated. I use Kotlin where I work right now and I had to address the same questions initially. The argument for Kotlin was that it's not that different than Java and most good Java developers can pick it up easily OR Scala developers (though they might do that begrudgingly...).
Shocked to see no mention of PureScript [0] on this thread, which is also a Haskell-like language that compiles to JavaScript.<p>PureScript has the notable advantages of generating mostly-readable JavaScript and working in node. [1]<p>[0] - <a href="http://www.purescript.org/" rel="nofollow">http://www.purescript.org/</a>
[1] – <a href="http://try.purescript.org/" rel="nofollow">http://try.purescript.org/</a> – click "Show JS Output"
By Elm you mean that language that changes all its core functionalities[1] every day? I've tried it some months ago, now when I was about to try it again in a new project, I discovered everything I had learn is useless.<p>[1]: <a href="http://elm-lang.org/blog/farewell-to-frp" rel="nofollow">http://elm-lang.org/blog/farewell-to-frp</a>
I've never been a fan of doing front-end web programming because of my distaste for Javascript. Elm solved that problem for me. I like the syntax, type checking, and I've never had any code that passed the Elm compiler error out on me in production.<p>I also like the functional programming aspect of Elm, and the syntax is quite nice (similar to Haskell, only smaller and easier to learn).<p>I found this site useful for getting started with Elm 0.17: <a href="https://www.gitbook.com/book/evancz/an-introduction-to-elm/details" rel="nofollow">https://www.gitbook.com/book/evancz/an-introduction-to-elm/d...</a>
I wish there was a way/documentation to embed in a vanilla js app ,like with IIFE or something instead of required the whole <div id="app"></div>
Is it me or is the bundle generated by Elm a bit too big? Maybe it's gotten better lately but I've always thought it overkill for simple apps.