Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elm in the Real World

futurice.com

Post reply on HN
Print view View original

21–30 of 46 posts

Re: Elm in the Real World

#21

Post by danneu »

hellofunk wrote: post #8
kasbah wrote: post #6

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-writ…

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 o…

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.

Re: Elm in the Real World

#22

Post by pjmlp »

lumpypua wrote: post #19
pjmlp wrote: post #11

Earlier quoted context omitted.

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.

Any commentary on "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.

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.

Re: Elm in the Real World

#23

Post by Jabbles »

kasbah wrote: post #6

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-writ…

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

Re: Elm in the Real World

#24

Post by kasbah »

Jabbles wrote: post #23
kasbah wrote: post #6

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-writ…

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

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.

Re: Elm in the Real World

#25

Post by edko »

sjrd wrote: post #18
hellofunk wrote: post #8

Earlier quoted context omitted.

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 o…

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/

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.

Re: Elm in the Real World

#26

Post by agentgt »

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.

Re: Elm in the Real World

#27

Post by ujal »

cies wrote: post #17
seivan wrote: post #5

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?

> I guess this is like a better version of ... 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.

Re: Elm in the Real World

#28

Post by [deleted] »

kasbah wrote: post #6

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-writ…

[deleted]

Re: Elm in the Real World

#29

Post by dorfsmay »

pjmlp wrote: post #11
kasbah wrote: post #6

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-writ…

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.

Is transpiling really that different than running google closure on "native" js?

Re: Elm in the Real World

#30

Post by ujal »

kasbah wrote: post #6

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-writ…

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

Post reply on HN