Client-side web programming in Haskell: A retrospective

[k_bx]

There's one very important thing that people miss when they mention Elm vs PureScript (or others) which bothers me.

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!

[idoubtit]

> Elm is playing the JS world's game (obeying the rules)

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. https://news.ycombinator.com/item?id=21204761

[toastal]

What doesn't 'playing by the rules' even mean? It feels like a highly subjective and disingenuous comment. Elm's focus on SPAs is fine and good, but very narrow compared to what JavaScript can do. Elm's port system, it's way to interop with JavaScript, can't do synchronous code which can be a no-go. All of your bullet points apply the same reasons people say to use ReasonML. PureScript offers the same safety if you 'play' by its rules.

I do Elm at my job every day, but it has serious competition.

[kbp]

You're mixing your "playing by JS' rules" point with just general Elm features. Faster compilation speed, faster executables, and smaller executables are not JS' rules, they're just generally desirable things to have. "Faster than Webpack" and "no runtime exceptions" are certainly not the JS world's rules (does Purescript have runtime exceptions?). That a typical JS developer can get up to speed quicker in Elm seems very nebulous to me; why? Could you elaborate more on what you're talking about? How is Purescript not playing by JS rules, other than being (I assume) slower than Elm?

[crtlaltdel]

> you can take a JS dev and they'll be productive in two weeks in Elm

i’ve never been a big fan of these sorts of assertions. not everyone picks things up at the same rate.

[UserIsUnused]

I wonder of what of those points would be impact had typeclasses been implemented into ELm.

[dmjio]

This post dismisses Elm on the basis of lack of typeclasses, but fails to mention miso (https://haskell-miso.org), that includes typeclasses. Miso is Elm-as-an-embedded-DSL written as a Haskell library for GHCJS that allows one to share types on the front and backend, take advantage of the entire Haskell ecosystem and has experienced commercial use.

[cies]

I agree that Miso deserves a mention. It seems to be very actively maintained.

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.

https://github.com/dmjio/miso

[chrisdone]

After our bad experience in 2016 using GHCJS on a big project, we haven't considered it for anything since. Anything that arrived after that related to GHCJS just hasn't been on my radar ("a history of my own experience in this problem space").

[iElectric2]

Note that Elm has typeclasses, they are just not exposed in the language: https://medium.com/@terezk_a/haskell-in-elm-terms-type-class...

[zoul]

Considering that Elm seems to be by far the most stable, usable and used alternative, just dismissing it for the lack of typeclasses seems a bit short sighted to me. Is this a case of avoiding success at all costs? :)

[chrisdone]

Elm can be looked at like Haskell on training wheels, in a good way, and that simplicity very likely contributed to its popularity.

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.

[alipang]

There are some ways in which Haskell's type system actually makes it significantly better at Elm's core job than Elm itself.

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.

[1] http://hackage.haskell.org/package/folds-0.7.5/docs/Data-Fol...

[2] http://www.haskellforall.com/2013/08/composable-streaming-fo...

[nilkn]

Elm confronted a dizzying amount of abstraction and category theory prevalent in Haskell implementations of FRP and over time converged on a solution so amusingly simple that it ended up dropping the FRP branding entirely because it just seemed silly. Elm absolutely succeeded and gained real-world traction because it took what was at that point an overly academic and unsuccessful idea and aggressively pursued simplification. Perhaps one could argue that this pursuit had a cost as well -- e.g., the lack of typeclasses -- but I just don't think Elm would exist without that driving mission.

[pxtail]

Is Elm still dependent on one maintainer[0]?

[0]https://news.ycombinator.com/item?id=16511478

[UserIsUnused]

>considering that Elm seems to be by far the most stable, usable and used alternative

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.

[ruiseal]

Seems like it. There are some tasks in Elm which would benefit from typeclasses but in my experience they're not so common to be much of a concern. Sure, I'd like typeclasses but I'm not dropping down to JS just because of their absence.

[toastal]

Of note v5-rc of PureScript's Halogen helps with some of the complications. It's been in RC for several months waiting for all of the documentation to wrap up, but I used it on a small project a few months ago and didn't have too many problems outside trying to understand how to wire up requestAnimationFrame to emit events on init. It's worth another look once it's released.

Some documentation on the v5 changes: https://github.com/slamdata/purescript-halogen/blob/master/d...

[weavie]

V5 of Halogen is the nicest frontend framework I have ever used. It is a bit frustrating that the docs are taking so long to come out so it can be released properly, but in terms of using it the framework is good to go and in my opinion well worth the effort to learn how to use it.

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/

[Benjmhart]

I actually PR's these docs a couple weeks back. In short halogen v5 greatly simplifies a lot of the complexity around parent/child components.

[lmm]

Did you ever look at ScalaJS? I found it surprisingly pleasant and reliable, and while Scala is not Haskell, it is a mature language with typeclasses and probably the best tooling support (in terms of IDEs etc.) of anything in this space.

[sambeau]

Maybe I'm missing the point here but I couldn't see where this article mentions what they were trying to do in a web client.

Surely that should be the first variable to consider?

[chrisdone]

Fat clients of all kinds (cryptocurrency wallets, medical devices, data analysis, log viewers, etc.), depends on the client.

[iElectric2]

While there was a novelty budget consideration, I miss comparison for:

* 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.

[dorian-graph]

> Our meeting notes are long and detailed, the brief summary: we don’t feel comfortable with GHCJS, Reflex is great but also costly (double novelty budget), Halogen is a better architecture than Elm. PureScript and Halogen come out as the best possible choice. Other things considered: ClojureScript, TypeScript, Rust, ReasonML, Elm, OCaml.

I would love to read these notes!

[gwern]

A summary at the top and maybe a table of all the options would be useful additions here.

[al3x1]

Haskell in web rocks!

[lolc]

It does seem rocky when reading that retrospective.