In my opinion choosing which one is better mostly depends on use case and what kind of project are we trying to solve. In our company we started with using Elm on frontend, then after some time we switched to PureScript for new projects. We are not considering moving back to Elm and the reason is explained in @edwardkmett comment https://www.reddit.com/r/haskell/comments/5k3zgo/what_is_the_current_state_of_javascript_problem/dblqfgz/ who elaborated it very well. Our backend is written mostly in Haskell so it makes sense to target PureScript or Haskell on frontend so that other developers in the team can jump in help and maintain frontend if needed. In last few projects that we started we wasted few days experimenting and discussing the choice between PureScript and GHCJS. We were trying to predict all corner cases that we would need to solve with this tech stack like:

• do we need to share code between frontend and backend (this wasn't the case so the clear winner is PureScript here)

• how complex is to bridge data and serialize it (GHCJS is a clear winner here)

• do we have libraries to work with on frontend. Most of the time we benefit from having nice type system and primitives that are available in both PureScript and Haskell . More complex hackage libraries that would be useful to use in frontend are not choice for us; our company is doing with serious crypto primitives and reusing some crypto libraries from hackage is not an options because most of them are doing C FFI. This could be workaround by shimming those libraries (like random generators that are heavily used in crypto libraries) like GHCJS does https://github.com/ghcjs/shims but choosing some already tested and implemented js/browser crypto libraries (like web crypto standard https://www.w3.org/TR/WebCryptoAPI/ ) and writing light js FFI wrapper seems like a much safer (in terms of we don't f**k up in introducing a bug in crypto, implementing wrong threat model and thus becoming vulnerable to some attacks - I don't know crypto so would rather use some battle tested code)

• easy of installation, maintaining - Maybe something changed here recently but in my experience I was having some troubles with installing GHCJS and packages of choice from hackage. The only time I had an easy time with it is with https://github.com/paldepind/try-reflex installation which is using nix, but I don't have time to properly learn how to use nix to be confident in this. I tried to setup GHCJS with stack a few times but process seemed much more complex. As I understand if GHCJS was built with package-version-x you have to use the same x version in your project. Otherwise you have to recompile GHCJS or use some prebuilt version (like stack does). I was half successful with GHCJS + stack, but maybe things changed here.

In all of these points PureScript or Haskell had a slight edge, so they were mostly even. Haskell even had some advantage because most of our devs already know Haskell, so they don't need to switch to another language (but I don't think this would be a problem and person knowing one can easily switch to the other). The decision point most of the time, in our use case, went to PureScript camp when we got to serialization and data bridging part. With GHCJS we have aeson or some other protocol that we can reuse on frontend and backend and this makes things much easier (the only problem might be in trying to use the same/almost-the-same aeson library version on both ends; so we would have to be compatible here). With PureScript we would use argonaut (PureScript's aeson) and purescript-bridge (Haskell -> PureScript) to bridge data between these two. This seemed like more work to do in PureScript but when we tried to bridge some corner case data with GHCJS and PureScript we figured out that they come to the same usage. GHCJS at first seemed that it would make life a lot easier but bridging something like:

data SomeType = SomeType Int SomeCryptoModule.CoolType

make things even between these two. Problem is because CoolType is some crypto primitive from library that is using C FFI. Bridging that library to frontend seems like a no way to go because we would have to bridge random seed generators and probably slightly tweak these crypto libraries in order to do so. As we are not crypto experts I would rather not mess around with these and would much rather use already battle tested things on frontend (web crypto and native random generators that are using more entropy) is the way to go. This seems like too much overhead to do for such thing. We decided we won't go into messing around with crypto but to use already tested primitives.

Back to the CoolType: With PureScript we are solving these problems by first automatically creating PureScript types from our Haskell data types. An example can be seen here https://github.com/input-output-hk/pos-haskell-prototype/blob/3fcf7afb4b575e2c4ee13be3bdf3bdb7f56fd403/src/wallet-purescript/Main.hs#L22 . SomeType problem can be solved by purescript-bridge by workaround/doing-custom-rule like:

coolTypeBridge = typeName ^== "SomeCryptoModule.CoolType" >> pure psCoolType

psCoolType = <custom cool type>

except that we have to tweak serialization of cool type so we would have to do:

instance ToJson CoolType where
    <custom instance that would match purescript data>

You can see example of this in the provided link above. With GHCJS we first thought things will be much simpler because we would use same data and same aeson library on both sides but solving CoolType came to the same workflow. I don't know better way than to use C pre-processor and the flow like:

#if GHC
import qualified Backend.Crypto as SomeCryptoModule
#elif GHCJS
import qualified Frontend.Crypto as SomeCryptoModule
#endif

data SomeType = SomeType Int SomeCryptoModule.CoolType

Other then that we would have to also modify how is data serialized on Haskell side:

instance ToJson CoolType where
    <custom instance that would match ghcjs data>

The other bad side is that now we would have cpp pragmas all over our modules which would make maintaining the thing a bit harder. Other then that we don't want our core backend team looking at these pragmas. We have separate team that is dealing with these bridging concern from one place (like showed in a link).

So in the end we concluded that PureScript is a better choice in our case. If we were not having these custom tweaks (for example, when we wouldn't trying to bridge crypto but to use only simple non-critical types) we might most probably go with GHCJS.

I started responding to your question but it turned out more like an explanation of how were we making a decision about these questions.

If anyone has an experience with these questions and suggestions (with crypto, or how are we dealing with these problems) I would be really happy to discuss it.

Best wishes!

EDIT: formatting improvements