Here's my message: Elm is playing the JS world's game (obeying the rules) and it's winning it!
- you can take a JS dev and they'll be productive in two weeks in Elm
- the compiled code will be smaller than react's
- compilation time is less than in webpack (and compiler's reaction is under 0.2 secs most of the time)
- performance of your app is better
- no runtime exceptions
PureScript and others, unfortunately (at least in many cases), take a different direction: they don't play the game at all, staying in their own, very different one. But hey, they have type-classes!
I disagree, though the meaning isn't clear. Elm is interesting, but it's not part of the JS world, and it doesn't come close.
Just recently, the Norway Railways described their experience with Elm. It was largely positive, but one of the main two negative points was the difficulty to interoperate with JS libraries. They tried it, and failed hard (many runtime errors). BTW, the other pain point was the restrictions on packaging, which is quite orthogonal with the (npm) JS world.
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.
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?
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.
I do Elm at my job every day, but it has serious competition.
PureScript is a tremendous language, and I'd be happy to see it more widely used, and your points about JS interop and SPA focus are true of course, but I would argue that the step for ditching FFIs are better for some of the same reasons that were listed.
With Elm you can't, for example, use the browsers Intl API to get plurals, currencies, dates, etc. This is the type of thing you want to partially apply/instantiate with your locale, then use it synchronously at the view level with your model for display. You just don't have the access to do this because a proposal must be made and approved by the Elm team. It'll probably be good API, but you'll be SOL in the meantime (for possibly years). This isn't a dev cycle that works for every person, team, or project.
i’ve never been a big fan of these sorts of assertions. not everyone picks things up at the same rate.
uncurry ($) (hasField @x r) == r
setField @x r (getField @x r) == r
On the other hand, if you reject GHCJS then Miso is out of the running immediately. And the reason to reject GHCJS (big bundles, as mention in the article) is something you dont have in Elm/PureScript/ReasonML.
We already tried Fay as a team (15kloc codebase to write an IDE), which was literally Haskell without type-classes. We've learned that we want type-classes, YMMV.
Type classes could certainly be argued to be one of those things, but also just existential types makes "reducers" a lot more pleasant to work with.
Check out e.g. Edward Kmett's library or read e.g. Gabriel Gonzales' post on folds if you want to know more.
I wonder, does Elm not having type classes is actually a feature that boosted its success, or is it just missing because of the author stubbornness ?
I think Elm did right into focusing in SPA rather than being yet another language compiling to JS.
I dont think so. It did help make errors very straight forward and prolly also keeps compile times low.
The author's stubbornness is, in my view, more in that he does not support (actually prevents where he can) making Elm usable outside of the browser (like what Node did to JS).
Some documentation on the v5 changes: https://github.com/slamdata/purescript-halogen/blob/master/d...
A great resource for learning about Halogen that has been updated to V5 is Thomas Honeymans Real World project : https://github.com/thomashoneyman/purescript-halogen-realwor...
I'm working on a few tutorials for V5 too, but finding the time to be prolific is hard : https://codersteve.dev/tags/halogen/
Surely that should be the first variable to consider?
* ease of development
* time to learn the language
* documentation: tutorials, etc
* ease of hiring
Architecture is a tiny cost you have to pay for using something else.
Then again, for a consultancy using Haskell, PureScript is the right choice.
I would love to read these notes!