[thelambentonion]

IMO, PureScript has some very interesting advantages in comparison to other functional languages targeting JavaScript.

It has a very strong type system, a compiler that can produce optimized and human readable JavaScript, and dead simple FFI. It _also_ doesn't rely on a runtime like Elm or GHCJS do, so the resulting code size is typically much smaller.

It's also been used to build some really interesting and unique takes on the frontend design problem (cf. Pux [0] and Halogen [1]).

[0] https://github.com/alexmingoia/purescript-pux

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

[hawkice]

The Elm runtime does tend to bother me, despite it being smaller than jQuery (I've lived in a country with ~40kb/s internet... it's brutal out there if you pile on those kilobytes). But with dead code elimination plus a smarter inlining system I think this concern _could_ evaporate.

[sjrd]

> and dead simple FFI

That's very accurate. So dead simple that as soon as you want to manipulate something else than primitive values and functions from JS, you hit a dead end. How do you read a field from a JS object? How do you call a JS method? For all these things, you have to write "bridge" JS code that exposes JS libraries in a way that PureScript is happy with.

It's also striking to me that the documentation of PureScript FFI [1] has to teach you what the output of the compiler will be so that you can use the FFI. Am I really supposed to know about those `$`s? What if the compiler improves and changes its internals?

I'm sorry if my comment is perceived as a rant, but I can never understand how people can call PureScript's FFI good. Compare it to interoperability in TypeScript, ClojureScript, or Scala.js, and it is way behind!

[1] http://www.purescript.org/learn/ffi/

[kika]

It sounds like bashing.

Here's my unfinished, but working code, interfacing Google Apps Script to Purescript https://github.com/kika/purescript-google-appsscript/tree/ma...

Please tell me what is so _dead_ in it.

Though I'm pretty new to Purescript and to the Haskell world in general, it took me almost no effort to write this code once I figured out how Data.Function (renamed Data.Function.Uncurried in the latest Purescripts) works. Probably your issue with Purescript FFI was about not being aware of these helpers (which don't do much help per se, but remove ugly clutter of nested functions in JS code).

[sjrd]

I guess my comment qualifies as bashing. It still is what I think, though.

Look at your own code from https://github.com/kika/purescript-google-appsscript/tree/ma... There is more JS code than PureScript! Why? Because you need bridge JS code for pretty much every JS library you want to call. Which is precisely the point I make in the grand-parent:

"For all these things, you have to write "bridge" JS code that exposes JS libraries in a way that PureScript is happy with."

[gilmi]

I also had a pleasant experience and didn't hit a dead end. I documented my experience here: http://gilmi.xyz/post/2016/05/09/ld35