I really like Elm and have become an intermediate user of it (as well as Haskell). I felt like I really understood what Elm signals are about and made some optimisations to Helm [0] based on that.
I pushed to use it for a contract for an open source application [1]. Ultimately that wasn't a success due to various factors but it's interesting to note that the client dropped Elm after I left and hired people to re-write everything in JS.
In retrospect Elm really wasn't the right choice for that project because it wasn't mature enough (and maybe I hadn't been using it for long enough either). The lack of any kind continuation monad for managing effects at that point (later added to the language as Tasks) and the cumbersome interop with JS (still an issue) were real sticking points. It's just frustrating when you have a problem that can be solved trivially with a state-mutating for loop and you have no easy mechanism to do it. The boilerplate required to use Chrome's messaging within the app was really painful.
I tried to use Elm again for a personal project, a kind of gallery website with a JS search function [2]. After starting an initial prototype in Elm I switched to using React (which I had never used before) and found I was much more productive (even though the code is messier). Having a much bigger repository of re-usable modules and being able to take short cuts is really valuable at this stage of development (and the server-side compilation ability is really cool).
These experiences have made me wonder about the real-world place for Elm and how long it would take for it to rival something like React. I definitely think there is a lot of value in learning Elm to help you think about state in your application in a more higher level way but I would really hesitate in advocating to use it for real-world project at this stage (it does depend on the project of course).
I strongly believe that for any language that compiles to JS to be successful, seamless integration with existing JS is absolutely required. This is the main selling point of Clojurescript which, while I enjoy Clojure a lot, is a dynamically typed language like JS itself, and I wish I could interact with JS in a stricter way. If Elm can improve on its interop, it has potential to be a strong force. But this is true of any new language. If you can't easily interop with the lowest common denominator language in the platform you build for, your language is too restricted for meaningful use. This is why Rust integrates well with C, because it has to, or it is irrelevant in many cases. This is why Clojure interops seamlessly with Java. Elm needs to get this point, or it will remain a niche hobby language avoided by professionals.
I think that's a bit unfair as Elm is already seeing some professional use.
Though on the subject of inter-op, Purescript might be what you are looking for if you want a strongly-typed, Haskell-like language, compiled to JS with a less cumbersome foreign function interface.
Your point still stands though, I hope Elm comes up with some good ways to say "trust me I know what I am doing" and "here is some JS, run it".
EDIT: Though it might be that that goes against the whole premise of the language.
I use Elm in production and I feel like I have a sufficient interop toolkit between implementing tasks (writing native modules) and ports.
Unlike Clojurescript, Elm interacts with your explicitly defined Javascript boundary rather than tries to let you mix it all together in the same soup.
The person you're responding to points out that they were more productive once they refinanced their code to take on some technical debt, but that's always an available trade-off in programming.
And this is why Scala.js interops seamlessly with JavaScript. [1] Most of the time, you don't even know whether you're calling other Scala.js code or JavaScript libraries, and it's all typed. If you want to interact with JS in a stricter way, you should check it out.
Scala.js is simply amazing: powerful, performant, acceptable compiled code size, easy interoperation with JS, lots of well-tested libraries, a good community, and excellent IDE tools.
I am very tempted to start learning Elm and Purescript. They both seem very elegant languages, but I keep postponing it until there is an IDE with good code completion, to ease the learning curve.
There's some work towards that in PureScript: https://github.com/kRITZCREEK/psc-ide provides an interface for multiple editors, seems like Atom, Emacs, Vim and VS are available currently.
Well the Elm architecture inspired ClojureScripts re-frame and JavaScripts Redux. Both of those handle state similar to Elm. You are right that Elm is not ripe for primetime but Elm's value stretches far beyond its handling of state.
Also make sure to checkout NoRedInk's take-home and its server-side usage of Elm including server-side rendering.
100% agree and it makes me try and handle state in a similar way even in plain Javascript without any libraries.
Will check out take-home more when I get a chance, I did see some murmurs on the Elm mailing list of how it would be easy to do server side rendering. What impressed me about React's was that I could just call a function and get the HTML as a string. My project is statically generated so that was exactly what I needed.
Personally I don't buy into any "Compiles to JS" language for production code, other than for dabbling.
The JavaScript compatibility problems across browsers are already enough, for me to sell to customers yet another layer to debug that might not even be properly supported by the respective browser debugging tools.
I look at compile-to-JS as a temporary solution until WebAssembly is the norm. No way that in 2016+ the best we have for web development (most common case of GUI development) is JS :)
I'm personally hoping the future holds some way to blend the openness/interoperability of the web with the performance of native apps. Maybe React Native, maybe web assembly, etc.
I hope that pure mobile development doesn't win, because the mobile app ecosystems are way more controlled than desktops/servers, and if everything went Android/iOS, it would be a major loss for freedom.
Yes, the source-map support in browsers really needs to improve. NodeJS is another matter though as, in my experience, it maps seamlessly.
I think Coffeescript, TypeScript and Babel (ES6 and JSX) are completely different beasts to Elm though. I can look at the compiled output of these languages and debug that, I don't really need source maps (though they would be nice).
I guess the idea for Elm is, you won't need to debug as you won't get runtime errors.
Either you're stuck with ES4 (and worse, you can kiss goodbye to a large number of NPM modules which are ES6+) or you still need a transpiler and a system to package your scripts, handle polyfills, etc.
It's just difficult to do non-trivial JS development without only "raw Javascript" in 2016.
We used to be RequireJS/jQuery based on the frontend. While this obviously depends on what kind of application you have, attempting to develop complex UI in jQuery is not an experience I'd describe as "pleasant", nor does it naturally lead to creating reusable components.
On the other hand, switching to React + Redux + webpack (and NPM) has changed development from "we can't do that" or "let's copy paste from some other component" to "I'll have something by tomorrow" and "I'll reuse the generic React widget I made last time". It's really a game-changer.
Also, ES6 >> ES4. Destructuring doesn't bring you what real pattern-matching does, but it's still a lot nicer than what ES4 gives.
Actually, we manage to mostly support IE 8 through a combination of Babel and polyfills. You don't necessarily need to forgo modern goodness in order to support prehistoric browsers.
Yes, it was 0.14 at the time I believe, though that version number doesn't really mean that much. Would you have been more comfortable with 1.0.0? That's what the core library was at. Anyway, I should have realised there were some essential components missing and the JS interop would be a major road-block for this application.
To clarify further: I normally work as a firmware/electronics engineer so this was a bit of an experiment all around. I didn't charge my normal rates either.
I've been involved with the Elm community for a couple years now and I haven't noticed a recent push to get people to talk about it more. I think people are just trying it out and getting excited by it.
I don't know if my case is representative, but as a backend dev I'm still on the fence with javascript and at the same time eagerly wanting to step in the frontend realm, because, well Internet. And it seems that elm finally got the right combination of reliability (functional, immutable....) and friendliness (nice syntax, good docs...) for me to cross the rubicon.
Add to the mixture charismatic personalities like R. Feldman and E. Czaplisky and this could be the answer.
The problem is that to get anything done on the Internet, you will need easy use of existing third-party libraries for a wide range of stuff, or you end up spending huge amounts of time implementing protobuf handling, websockets, ajax, webgl and the myriad of other important technologies that you may likely encounter in those areas. Excellent libraries for that stuff are out there, but Elm makes it hard to interop with them... for now. I really hope that changes.
One thing I like about Elm over the plethora of Javascript converters is that it is its own language devoted to one runtime (js) and a very different language than most (syntax wise). The same goes for Coffeescript as well.. for the most part at least.
I particularly don't like general purpose language to JS converters like Scala.js, Clojurescript, GWT, etc because I think these converters can cause some cognitive dissonance (based on past experiences). That is I actually think its better to have different languages for different environments but I suppose not everyone shares that belief.
I guess this is like a better version of using TypeScript, React, *Flux and RxJS. Mostly because Elm seems to have everything builtin while you might have issues with TS typedefinitions.
Also their success/fail tasks for HTTP calls reminds me of flux actions being dispatched.
Dispatch action for an http class and then dispatch another action for success or failure. Or did I miss understand?
Make sure to look at PureScript as well. It is a much less "opinionated" cousin of Elm. By opinionated I mean that Elm pulls HTML and CSS into the code, and has functional reactive programming built in; in PureScript these are libraries.
I am currently into Elm and intend to transition to Haskell/GHCJS at some point. I've also looked into PureScript but don't really see how it fits between Elm and GHCJS.
Yeah, the JS world currently is very pro-modularization, but I already saw some discussions on Twitter from the React/Flux people how that creates too big barrier of entry for the newcomers. One of the things that draw people to Angular is that it has almost everything that you need included - it's easier to say to someone "just use Angular", than "try React, with Redux, and Router, and Webpack - it will take some time to configure it, but it's worth it".
Well, it has it's benefits.
I don't like Redux and I like Reflux so it allows me to do that.
Then again Rails does let you switch out compatible parts. By compatible I mean if it adheres to "Railties", e.g. using ActiveModel for replacing Pgsql with MongoDB.
I have a couple of projects in mind that would require some level of JS front end, and Elm sounds like something interesting to look at since I've not done more than dabble with JS a bit.
That said, every time I see a post about it I can't help the immediate response of "didn't pine replace that?"
I pushed to use it for a contract for an open source application [1]. Ultimately that wasn't a success due to various factors but it's interesting to note that the client dropped Elm after I left and hired people to re-write everything in JS.
In retrospect Elm really wasn't the right choice for that project because it wasn't mature enough (and maybe I hadn't been using it for long enough either). The lack of any kind continuation monad for managing effects at that point (later added to the language as Tasks) and the cumbersome interop with JS (still an issue) were real sticking points. It's just frustrating when you have a problem that can be solved trivially with a state-mutating for loop and you have no easy mechanism to do it. The boilerplate required to use Chrome's messaging within the app was really painful.
I tried to use Elm again for a personal project, a kind of gallery website with a JS search function [2]. After starting an initial prototype in Elm I switched to using React (which I had never used before) and found I was much more productive (even though the code is messier). Having a much bigger repository of re-usable modules and being able to take short cuts is really valuable at this stage of development (and the server-side compilation ability is really cool).
These experiences have made me wonder about the real-world place for Elm and how long it would take for it to rival something like React. I definitely think there is a lot of value in learning Elm to help you think about state in your application in a more higher level way but I would really hesitate in advocating to use it for real-world project at this stage (it does depend on the project of course).
[0] https://github.com/switchface/helm
[1] https://github.com/kasbah/mooltipass.hid-app
[2] http://kitnic.it/ | https://github.com/monostable/kitnic (work in progress)