Frontend stack decision about issue-wanted

[willbasky]

	PureScript	Elm	GHCJS
libraries	middle	high	low
features	high	poor	high
JS code size	middle	low	high
JS integration	middle	high	poor
haskell bridge	middle	poor	excellent

[vrom911]

@willbasky thank you for this table! This is going to be very useful. I would like to add a couple of stuff to it. The size of the Elm js code is much smaller (especially in the newest release 0.19, which apparently has too much breaking changes and features cuts 🙁) than any other (Puserscript, GHCJS etc.). What about the bridge, the Elm's one is very broken, unfortunately. I can't say for Purescript bridge though as I had very limited experience with it, but I guess it should be slightly better at least.

[chshersh]

@willbasky I'm improved table in your comment. This Reddit comment is worth considering:

• https://www.reddit.com/r/haskell/comments/97cwg5/what_is_the_status_of_ghcjs/e47o2oo/

I'm giving my vote for PureScript and I think this is a right choice for issue-wanted. If we target low JS size and aim maximum speed than Elm is better as @vrom911 said, but it's a pain. PureScript is already good enough. And we all can learn something new. GHCJS is too huge and we don't learn anything new with it, only suffer.

[willbasky]

I also lean toward PureScript. Will the middle JS size become a problem?

[sshine]

I only have experience with Elm, but I'm not comfortable with their development process.

I've never used PureScript or GHCJS, so I haven't experienced the disadvantages in practice.

For me, the main downside of GHCJS is the code size, and the mainside downside of PureScript is having to express your data model once on the back-end and once on the front-end. Perhaps PureScript is so similar to Haskell that you can re-use / transform the data model of one into the other? Another downside of PureScript that I've read about is that it uses bower, which is a dead package manager.

So I'd lean towards GHCJS just for the bridge, but I'd be very willing to hear a veto if there are any downsides I don't know of.

[chshersh]

I don't like GHCJS because of:

• Code size
• Low amount of documentation
• Possible need to learn and use nix just to build project

After WebAssembly backend for GHCJS is implemented, it will become much better! But I would like to use frontend-specific tool for this task now. Also, again, learning purposes 🙂

bower is not a great tool, but we can live with that for now.

[chshersh]

Decided: PureScript.