[pka]

Tangential, but some very cool things are happening in Purescript-land, especially when it comes to row types or UI research:

* https://github.com/natefaubion/purescript-variant (open variant types)

* https://github.com/natefaubion/purescript-run (extensible effects implementation based on purescript-variant)

* https://github.com/ajnsit/purescript-concur (time-reifying UI framework, there's also a Haskell and a JS implementation of Concur)

* https://github.com/arthurxavierx/purescript-comonad-ui-todos (comonadic UIs)

* https://github.com/paf31/purescript-purview (incremental lambda calculus UI library, this is mind blowing!)

* https://github.com/paf31/purescript-sdom (declarative diff-less UI library)

There's also [0], a mature UI framework used in production at Slamdata. Lumi [1] are writing their frontend in Purescript.

What I especially like about Purescript is that the community is open to experimentation, while at the same time not being afraid to backtrack when things turn out to be a bad idea, like the row tagged Eff monad. The recent addition of QualifiedDo is a good example of this, which allows you to rebind >>= in the following manner:

  test :: forall m a. I.IxMonad m => m a a String
  test = I.do
    a <- I.pure "test"
    b <- I.pure "test"
    I.pure (a <> b)

Imo, there simply is no better way for a Haskeller to target JS at the moment.

[0] https://github.com/slamdata/purescript-halogen

[1] https://www.lumi.com

[casmclas]

I've tried several times to use Purescript to target web browsers. I got frustrated by Bower - it's especially hard to start a new project using tools that say "don't use me, I'm deprecated". There was a huge amount of fairly sloppy javascript boundary code. And - it turns out - I like laziness.I dunno, I wish I could run ghc code efficiently in a web browser. But even though I can't, I much prefer to run ghc code inefficiently in a web browser than run a language intended to facilitate binding to javascript's sloppy semantics.

When I tried using ps-concur or some other ps gui libraries, I didn't feel inclined to keep progressing. When I learnt reflex with ghcjs, I built stuff, and I kept finding new things I wanted to build.

The best way for a Haskell to target browsers at the moment is via ghcjs. Hopefully one day it'll be with a ghc-to-wasm compiler.

[pka]

I think Bower was just a "good enough" solution when Purescript was initially implemented. Afaik, people are moving away from it in favor of spago [0] or psc-package [1].

JS' semantics are pretty much opaque when staying in Purescript. Of course all bets are off when using the FFI, but then again the same goes for GHCJS.

One major thing in favor of GHCJS is the ability to share code between backend and frontend, but that's not a concern when e.g. the backend is written in another language anyway.

EDIT: Also, Purescript on the backend (targeting node or native code) is slowly becoming a thing as well, as this is what this submission is about :)

[0] https://github.com/spacchetti/spago

[1] https://github.com/purescript/psc-package

[virtualwhys]

> but that's not a concern when e.g. the backend is written in another language anyway.

well, for anyone who's been in this situation, it should be a concern, since it's incredibly easy to get out of sync between backend and frontend (e.g. model, validation, etc.).

Ideally we could all code in preferred-language; target all major platforms using a single/universal UI framework, and call it a day...but reality is messier than that, we're often forced to code apps in multiple languages, multiple UI frameworks (if targeting native iOS + Android, and browser/PWA), and hope it all comes together such that the house of cards stays standing through language/framework/platform upgrades.

[pka]

I agree, but what I meant is that if you're forced to use a language other than Haskell on the backend, than there's no advantage in choosing GHCJS over Purescript in terms of code sharing.

[tmountain]

You don't have to use Bower. I've been writing PureScript for a good while now, and I've never used Bower directly.

https://github.com/spacchetti/spago

[runeks]

This is indeed interesting research. But I think Elm makes more sense if your client-side logic is relatively simple, so that you're basically just defining a view in your frontend code.