I think PureScript would have been much more popular from the get go if it used a syntax closer to existing JS syntax. This is why TypeScript is so popular, and also why CoffeeScript is now very unpopular among Javascripters.

I think the point of PureScript was to have a Haskell that would compile to JS, but which (unlike GHCJS) would have breaking changes to integrate better with JS features. Trying to look like JavaScript might be a bit hard then...

That said, I'm curious about what sorts of things you think they could have done to have a more JS-like syntax. Any ideas?

Very interesting! For those who are more involved in this field, how does PureScript compare to other functional programming languages that also compiles to javascript?

PureScript emphasizes a solid theoretical foundation. Its closest competitor, Elm, emphasizes ease of learning and use.

Both are very tastefully designed (so I've heard, I haven't used Elm myself). If you're coming from something like Haskell and really value correct abstractions go with PureScript. If you need something working right now and don't plan on pushing the boundaries of the language then Elm should be fine.

I like Elm a lot. It's much much simpler than PureScript, lacks some of the advanced features, but as an advanced user of Elm, I've found I don't really mind -- all the important stuff is there (structural types, tagged unions and polymorphism working with a type checker, for instance, is very good, even if you don't have typeclasses).

I've made dozens of web apps with Elm, and I think it's fair to say that, when I started, I wanted the deep toolkit PureScript has. It turns out if I don't get it I spend more time writing code that delivers features. This is probably not true of everyone, but it is true of me.

Edit: also, Elm has a community (hard to manage for smaller userbases, like PureScript), and they have only been kind and eager to help in my experiences.

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

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.

> 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/

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).

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."

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

The discussion from a few years ago:

https://news.ycombinator.com/item?id=8351981

Does anyone have experience with the C++ backend ?

https://github.com/pure11/pure11

OH shit! It's actually not written in JS. Good going!

does purescript support d.ts definition files for FFI?