7 ms·

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 opti

by kasbah 11y ago

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). [0] https://github.com/switchface/helm https://github.com/switchface/helm [1] https://github.com/kasbah/mooltipass.hid-app https://github.com/kasbah/mooltipass.hid-app [2] http://kitnic.it/ http://kitnic.it/ | https://github.com/monostable/kitnic https://github.com/monostable/kitnic (work in progress)

hellofunk 11y ago
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.
- kasbah 11y ago
  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.
- sjrd 11y ago
  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. [1] http://www.scala-js.org/doc/interoperability/ http://www.scala-js.org/doc/interoperability/
  - edko 11y ago
    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.
    - gb 11y ago
      There's some work towards that in PureScript: https://github.com/kRITZCREEK/psc-ide https://github.com/kRITZCREEK/psc-ide provides an interface for multiple editors, seems like Atom, Emacs, Vim and VS are available currently.
- danneu 11y ago
  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.
pjmlp 11y ago
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.
- kasbah 11y ago
  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.
- cies 11y ago
  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 :)
- lumpypua 11y ago
  Any commentary on "The Birth and Death of Javascript"? https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... As far as I can tell, Javascript the runtime is a juggernaut that there's no stopping. If a platform gets popular tooling fixes itself.
  - pjmlp 11y ago
    Personally, even though I also do have quite some webdev experience, I am wishing that mobile native development wins. But on HN that is a sure way to be downvoted.
    - KingMob 11y ago
      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.
Jabbles 11y ago
Someone paid you to write something and you chose to use a language that is (only now) on version 0.16?
- kasbah 11y ago
  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.
- mercurial 11y ago
  I'll point out that React is itself on version 0.14. Version numbers don't mean much.
deleted 11y ago
[deleted]
ujal 11y ago
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. https://github.com/NoRedInk/take-home https://github.com/NoRedInk/take-home
- kasbah 11y ago
  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.

by kasbah 11y ago

hellofunk 11y ago

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.

kasbah 11y ago
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.
sjrd 11y ago
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. [1] http://www.scala-js.org/doc/interoperability/ http://www.scala-js.org/doc/interoperability/
- edko 11y ago
  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.
  - gb 11y ago
    There's some work towards that in PureScript: https://github.com/kRITZCREEK/psc-ide https://github.com/kRITZCREEK/psc-ide provides an interface for multiple editors, seems like Atom, Emacs, Vim and VS are available currently.
danneu 11y ago
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.

pjmlp 11y ago

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.

kasbah 11y ago
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.
cies 11y ago
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 :)
lumpypua 11y ago
Any commentary on "The Birth and Death of Javascript"? https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... As far as I can tell, Javascript the runtime is a juggernaut that there's no stopping. If a platform gets popular tooling fixes itself.
- pjmlp 11y ago
  Personally, even though I also do have quite some webdev experience, I am wishing that mobile native development wins. But on HN that is a sure way to be downvoted.
  - KingMob 11y ago
    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.

Jabbles 11y ago

Someone paid you to write something and you chose to use a language that is (only now) on version 0.16?

kasbah 11y ago
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.
mercurial 11y ago
I'll point out that React is itself on version 0.14. Version numbers don't mean much.

deleted 11y ago

[deleted]

ujal 11y ago

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. https://github.com/NoRedInk/take-home https://github.com/NoRedInk/take-home

kasbah 11y ago
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.