Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

By "playing by the rules" I meant that Elm doesn't give up the big considerations that lie outside of the purely linguistic features, unlike other ML-family JS languages.

I don't claim Elm to be a part of JS world, and your points about JS interop are correct, it's somewhat difficult if it's heavy, so using Elm as a driving for some big JS library would be a bad idea, while using some small interface for drawing charts or WYSIWYG is ok.

The private packages point is specific to how they do stuff, but I agree that it would be an improvement to allow that from package.json.



> unlike other ML-family languages

I'm curious about this comment, for my current project I chose reasonML over Elm very much because reasonML plays well with old javascript and it plays nice with the rest of the web.

My bundle is very small, compile times fast, and interop with even quite old JQuery libraries is a breeze.

Is there something else I'm giving up that I'm not aware of?


Elm doesn't allow you to call JavaScript code in Elm anymore. The reasoning is to prevent runtime exceptions. Instead, you have to go through something called ports, which is like passing JSON around. That's why there are people who complain about the Elm-JavaScript interop.


Right, when I was first exploring alternatives to Javascript was around the time Elm was removing first class FFI's in favor of ports and it was the primary reason I chose not to use it.

But the poster I responded to was saying that Elm made considerations about the wider web that none of the ML family languages had and I was hoping to find out what those might be since I'm not aware of any non-language advantages of Elm over ReasonML.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: