7 ms·

Client-side web programming in Haskell: A retrospective

163 points by mxschumacher 7y ago

toastal 7y ago
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/docs/Changes%20in%20v5.md https://github.com/slamdata/purescript-halogen/blob/master/d...
- weavie 7y ago
  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-realworld 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/ https://codersteve.dev/tags/halogen/
- Benjmhart 7y ago
  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.
zoul 7y ago
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? :)
- ruiseal 7y ago
  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.
- UserIsUnused 7y ago
  >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.
  - cies 7y ago
    > does Elm not having type classes is actually a feature that boosted its success 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).
- alipang 7y ago
  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-Fold.html http://hackage.haskell.org/package/folds-0.7.5/docs/Data-Fol... [2] http://www.haskellforall.com/2013/08/composable-streaming-folds.html http://www.haskellforall.com/2013/08/composable-streaming-fo...
  - hellofunk 7y ago
    Yeah, but I’d love to see the average JavaScript developer get up and running with Haskell in just two weeks.
k_bx 7y ago
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!
- toastal 7y ago
  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.
  - verttii 7y ago
    This is so spot on. Asynchronous ports are troublesome in a lot of cases. That's why I don't usually do my apps in Elm.
  - k_bx 7y ago
    By "playing by the rules" I meant that Elm doesn't give up the big considerations that lie outside of the purely linguistic features, I've listed some of them. 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.
    - toastal 7y ago
      I think you might be missing part of the philosophy. If you take a look at purescript-web-dom, most of the browser APIs have merely been wrapped. This saves you work and you can use it if needed, but it is encourage to use this as a foundation to build better APIs/DSLs (heck, steal them from Elm). Elm does a similar thing under the covers, and they release an often better API than the browsers, however, you can't use this intermediate representation to build alternative APIs and many times you have to wait years for anything to even pop-up in elm-explorations because nothing is satisfactory if it doesn't improve upon the browser's standard. This philosophy has its pros and cons, and while sometimes the APIs can be clunky in PureScript because it's just wrapping the browser API, I never felt straight-up blocked by a missing feature. 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.
dmjio 7y ago
This post dismisses Elm on the basis of lack of typeclasses, but fails to mention miso (https://haskell-miso.org 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.
- chrisdone 7y ago
  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").
  - dmjio 7y ago
    Would you be able to share more details as to what caused this bad experience? My experience with GHCJS on a big project has been the opposite.
- cies 7y ago
  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 https://github.com/dmjio/miso
  - dmjio 7y ago
    There is a company that has a 400 module miso application and the bundle size is not an issue (https://www.polimorphic.com https://www.polimorphic.com). After closure compilation GZIP'ing, pre-rendering and caching of the JS, it's a one-time cost, and is negligible due to pre-rendering. We build websites for users, who care only about experience, not about how large the payload is. Payload only matters insomuch as it adversely affects user experience. This argument is strictly a developer concern and is in no way correlated with end-user feedback. There are many <1MB js payload size websites with 0 users.
sambeau 7y ago
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 7y ago
  Fat clients of all kinds (cryptocurrency wallets, medical devices, data analysis, log viewers, etc.), depends on the client.
iElectric2 7y ago
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.
al3x1 7y ago
Haskell in web rocks!
- lolc 7y ago
  It does seem rocky when reading that retrospective.
draw_down 7y ago
> We didn’t want to write JavaScript. There’s a surprising number of techniques we tried to avoid doing so. Good grief. You can just write JS. It's OK.
lmm 7y ago
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.
dorian-graph 7y ago
> 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 7y ago
A summary at the top and maybe a table of all the options would be useful additions here.

163 points by mxschumacher 7y ago

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/docs/Changes%20in%20v5.md https://github.com/slamdata/purescript-halogen/blob/master/d...

weavie 7y ago
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-realworld 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/ https://codersteve.dev/tags/halogen/
Benjmhart 7y ago
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.

zoul 7y ago

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? :)

ruiseal 7y ago
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.
UserIsUnused 7y ago
>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.
- cies 7y ago
  > does Elm not having type classes is actually a feature that boosted its success 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).
alipang 7y ago
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-Fold.html http://hackage.haskell.org/package/folds-0.7.5/docs/Data-Fol... [2] http://www.haskellforall.com/2013/08/composable-streaming-folds.html http://www.haskellforall.com/2013/08/composable-streaming-fo...
- hellofunk 7y ago
  Yeah, but I’d love to see the average JavaScript developer get up and running with Haskell in just two weeks.

k_bx 7y ago

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!

toastal 7y ago
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.
- verttii 7y ago
  This is so spot on. Asynchronous ports are troublesome in a lot of cases. That's why I don't usually do my apps in Elm.
- k_bx 7y ago
  By "playing by the rules" I meant that Elm doesn't give up the big considerations that lie outside of the purely linguistic features, I've listed some of them. 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.
  - toastal 7y ago
    I think you might be missing part of the philosophy. If you take a look at purescript-web-dom, most of the browser APIs have merely been wrapped. This saves you work and you can use it if needed, but it is encourage to use this as a foundation to build better APIs/DSLs (heck, steal them from Elm). Elm does a similar thing under the covers, and they release an often better API than the browsers, however, you can't use this intermediate representation to build alternative APIs and many times you have to wait years for anything to even pop-up in elm-explorations because nothing is satisfactory if it doesn't improve upon the browser's standard. This philosophy has its pros and cons, and while sometimes the APIs can be clunky in PureScript because it's just wrapping the browser API, I never felt straight-up blocked by a missing feature. 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.

dmjio 7y ago

This post dismisses Elm on the basis of lack of typeclasses, but fails to mention miso (https://haskell-miso.org 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.

chrisdone 7y ago
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").
- dmjio 7y ago
  Would you be able to share more details as to what caused this bad experience? My experience with GHCJS on a big project has been the opposite.
cies 7y ago
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 https://github.com/dmjio/miso
- dmjio 7y ago
  There is a company that has a 400 module miso application and the bundle size is not an issue (https://www.polimorphic.com https://www.polimorphic.com). After closure compilation GZIP'ing, pre-rendering and caching of the JS, it's a one-time cost, and is negligible due to pre-rendering. We build websites for users, who care only about experience, not about how large the payload is. Payload only matters insomuch as it adversely affects user experience. This argument is strictly a developer concern and is in no way correlated with end-user feedback. There are many <1MB js payload size websites with 0 users.

sambeau 7y ago

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 7y ago
Fat clients of all kinds (cryptocurrency wallets, medical devices, data analysis, log viewers, etc.), depends on the client.

iElectric2 7y ago

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.

al3x1 7y ago

Haskell in web rocks!

lolc 7y ago
It does seem rocky when reading that retrospective.

draw_down 7y ago

> We didn’t want to write JavaScript. There’s a surprising number of techniques we tried to avoid doing so. Good grief. You can just write JS. It's OK.

lmm 7y ago

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.

dorian-graph 7y ago

> 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 7y ago

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