7 ms·

I've been looking at the options for pure-functional languages targeting JS, and it seems that PureScript is superior to Elm from a technical perspective for fu

by jey 11y ago

I've been looking at the options for pure-functional languages targeting JS, and it seems that PureScript is superior to Elm from a technical perspective for full-stack webdev. PureScript takes the approach of providing a full Haskell-like language that is "native" to the JS world. It has the features and type system of Haskell, but atop a cleaned up version of Javascript's semantics (e.g. strict evaluation, not lazy, by default). It's also well suited for both server and client code, and even has a C++11 backend in the works in addition to the native JS backend. In contrast, Elm is focused on front-end work and is less expressive, but emphasizes simplicity. Elm's goal of figuring out how to simplify and distill the Haskell and ML world's abstractions is an admirable one, but as an experienced programmer interested in practical work I'd rather just go with PureScript and just learn the Haskell-like abstractions along the way. It also really helps that the PureScript compiler's javascript output is "natural" and easy to understand, without any mysterious transformations involved. Have others looked at PureScript, Elm, Haste, GHCJS, etc and chosen differently?

jeremyjh 11y ago
Haste also generates reasonable output (it can be debugged, though it is nothing like as reasonable as purescript) and has a runtime that is only 500 lines of straightforward javascript. It had pretty haskellish runtime semantics (purescript doesn't) I was able to use my existing tools like hdevtools, and have what (with just a couple ifdefs) functions as a single code-base for client and server. But its community is just too small, its updates too sporadic. I couldn't see building a business on it. Purescript or Typescript would be the only compile-to-javascript languages I would consider for serious work.
agrafix 11y ago
I'm currently moving from Elm to PureScript. Here's why (from "strong" to "weak"): - Currently Elm has a sad story addressing integration with "native" javascript libraries and Elm is too opinioated in some cases, e.g. you can only use either the built-in 'Elements' or virtual-dom Elements to render frontend. This makes it hard to build modular components (see https://groups.google.com/forum/#!topic/elm-discuss/65tiRM7SxaA https://groups.google.com/forum/#!topic/elm-discuss/65tiRM7S... for example) - While the simple type system in Elm (e.g. no type classes, no monads, ...) makes beautiful error messages possible, it really limits the abstractions that I am used to coming from Haskell - Elm/Elm-make does not generate modules that conform to a "standard" js module system - thus it will not integrate well with other js tools - Elm syntax is lacking 'where' clauses, which results in constant reindentation of code Don't get me wrong - I liked Elm a lot; but it just does not seem mature enough to use in production - but it looks like a great language to start learning FP.
- sriku 11y ago
  Elm's extensible records are more powerful than even what Evan is willing to encourage. You can use them to implement type classes as well as first class modules, albeit with a bit of extra typing (ahem). They even permit you to have multiple "instances" for the same type if you require that.
  - agrafix 11y ago
    The problem is that it will not work for higher kinded types as that's not supported in Elm. You can not define a functor, a monad, ...
pierrebeaucamp 11y ago
Out of PureScript, Elm, Haste and GHCJS, I like PureScript the most. What sold me on this language was the JS output after compilation - PureScript doesn't translate a huge runtime to JS (like the other options), it will only include the code which is actually needed. Another advantage of PureScript: The foreign function interface is ridiculously easy to use.
pka 11y ago
I moved from Elm to PureScript 1 month ago, and I don't regret it. Here's my earlier explanation why [0]. [0] https://news.ycombinator.com/item?id=10727009 https://news.ycombinator.com/item?id=10727009
Kutta 11y ago
I looked at Elm, PureScript and GHJS, and chose PureScript for pretty much the mentioned reasons (powerful types, clean output, easy JS interop). I have a lot of experience in Haskell, and I find it refreshing that PureScript libraries and solutions have a lot of freedom to implement whatever they want, compared to the Haskell world which has a large amount of conventions to adhere to (and standard libraries to be compatible with).
rlander 11y ago
Well, "superior" is subjective in this case. It's like an OO programmer claiming that Smalltalk is a superior language than Elm. Besides, Purescript is squarely targeted at experienced Haskell programmers, which is not the case of Elm. Elm is an ML language, not a Haskell dialect that compiles to JS. I also evaluated Elm, Purescript, Roy, F#, JS_of_Ocaml and ended up choosing Elm precisely for the reasons you chose to stay away from it. I only use JS for front-end stuff, I value simplicity over expressivity and I don't want to spend many weeks learning Haskell-like abstractions to start being productive in a new language (in contrast, it only took me an afternoon to start being productive in Elm).
- ZenoArrow 11y ago
  > "Elm is an ML language, not a Haskell dialect that compiles to JS." To be clear, Haskell also comes from the ML lineage.
  - hanniabu 11y ago
    ML stands for machine learning, correct?
    - tcard 11y ago
      Not in this context. It's an old functional programming language that influences a whole family. https://en.wikipedia.org/wiki/ML_(programming_language) https://en.wikipedia.org/wiki/ML_(programming_language)
    - thedufer 11y ago
      In this context, it stands for MetaLanguage, which is a language family (and was at one point a language itself, I believe). The family includes Ocaml (see the ml there?) and Haskell, among many others.
      - mgold 11y ago
        Yup, and I have a sneaking suspicion "Elm" is "Evan's ML", except EML sounded bad.
rtfeldman 11y ago
Yes. Here's my LambdaConf 2015 talk on how I ended up at Elm from PureScript: https://www.youtube.com/watch?v=B7Iwreo1ReU https://www.youtube.com/watch?v=B7Iwreo1ReU
ekidd 11y ago
I started writing a small-to-medium-sized web application in Elm, because I wanted to try out FRP. I mentioned my experiences here: https://news.ycombinator.com/item?id=10726648 https://news.ycombinator.com/item?id=10726648 In short, Elm has some nice error messages, and it's easy to use at first. But as my app got larger, other factors became major issues: - Elm requires a painful amount of boilerplate code. A lot of this is related to the fact that it tries to do functional programming without many of the customary abstractions. - Elm's FFI (via the ports system) is really painful to use. If you ever need to integrate to third party code, or get a value from the DOM, it's going to require creating a new port in your main module, a new listener in JS, and wiring everything up. - A lot of Elm tools and APIs have bugs. For example, I discovered that if I built my app using the recommended Elm architecture, I couldn't use the debugger. But even some core APIs like Window.dimensions burned me more than once, with things like: https://github.com/evancz/start-app/pull/37 https://github.com/evancz/start-app/pull/37 I've started porting the app to Purescript. I used the Purescript book, which is excellent: https://leanpub.com/purescript/read https://leanpub.com/purescript/read I'm especially happily with Purescript's FFI, and its generally pragmatic attitude. However, Purescript doesn't come with a "blessed" UI library, so you have to pick. I briefly tried the ambitious Halogen library, but the sheer type-system complexity ground me down quickly. I eventually went with the Thermite library, which is a very thin library wrapper of React (< 300 lines of code). So far, Thermite has been very nice, and quite easy to use, though it could use some enhancements and tweaks. Overall, I like Purescript a lot. My basic problem with Elm is that it tries to be very opinionated, with very few escape hatches, so when I got stuck, I tended to get stuck very hard. Whereas with Purescript, it's much easier to drop down to JavaScript, but also to "pop up" and pull a well-known abstraction out of the standard Haskell toolbox if I need one.
osener 11y ago
I've been thinking about this a lot lately and I think you might be right. I've been using ClojureScript professionally for years, shipped some stuff with TypeScript, used GHCJS for some side-projects, and not feeling satisfied with doing front end development with any of them I spent some time catching up with new front end tech and AltJS languages over the Christmas break. Here's my highly opinionated and shallow thoughts on this matter: * ClojureScript: This is the only AltJS language I've done real work in and used in anger, so naturally it's the one I'd complain about the most. I don't like being negative so I'll keep it short: It doesn't provide the same increase in productivity relative to the host language as Clojure does to Java. The advantages it has over ES6 fail to make up for the loss of a huge ecosystem and this only seems to get worse because of the rate big JS community innovates (whether you'd classify this as 'churn' is another matter). * GHCJS: One of the most impressive compilers out there that target JavaScript. If you are already spoiled by Haskell and comfortable with it's semantics and runtime system definitely go for it. But if you are approaching this from the perspective of a front end developer who's looking for a better language this will feel like learning C++ just so that you can compile it with Emscripten. I've used GHCJS to build https://github.com/osener/markup.rocks https://github.com/osener/markup.rocks which runs Pandoc in browsers and it's certainly the best, if not only, option if you are looking to compile some existing Haskell codebase to JavaScript. My decision to stop using it has more to do with my lack of experience with Haskell than any problems with GHCJS itself. I tried to adopt so much new stuff at once with my limited Haskell experience, Reflex, GHCJS, FRP etc., and I'm having a hard time pinpointing which ones netted the increase in program robustness I've experienced (app development in JS feels so brittle in comparison) and which ones caused my lack of productivity. After visiting this codebase after spending more than half a year without doing any Haskell GHCJS DOM APIs were revamped and I was so unfamiliar with my codebase that I didn't know where to start converting it to the new API let alone add new features. I started exploring packages like https://hackage.haskell.org/package/react-flux https://hackage.haskell.org/package/react-flux to see if I can take a more conservative approach with GHCJS and get the benefit of leveraging the ready-made React components out there. Unfortunately I was also very unhappy with the 26MB uncompressed JS output and wanted to add JS based renderers for stuff like Markdown and split Pandoc to its own .js file to lazily load it when it's needed. Thinking about this I realized that my main use case for GHCJS was compiling Pandoc and once I split that up I don't need to choose between two Haskell front end libraries and write the app itself using a more pragmatic stack and get some performance benefits (GHCJS produced code is especially hard on mobile browsers). At this point I was pretty spoiled by Haskell and wanted to keep most of it while taking a more pragmatic approach. This brought me to * Elm: I didn't know a language could provide such a good UX until I discovered Elm. From simplicity of the syntax to compiler messages, wonderful piece of work! I won't get into it's shortcomings compared to Haskell; although I can see the usefulness of additions like Typeclasses there are lots of posts from experienced Haskellers suggesting language features, and posts from Elm's designers explaining their choices not to include these. I'm not educated enough in these matters to say anything that hasn't been said before in favor of either stance. My real suprise wasn't lack of Typeclasses; it was how unpragmatic Elm is, especially since it's not an attempt to adapt an existing language for front end development but a language designed specifically for it. I certainly applaud their goal to create a better way to write browser apps and I understand that they are in it for the long haul but I need to be productive right now and even GHCJS has a better FFI solution than Elm. When people ask how to use a JavaScript library from Elm in mailgroups and stackoverflow, their communities stance seems to be "include CSS and rewrite the JS code in Elm". This might be fine if all you need is to rewrite Bootstrap's dropdown logic in Elm but for doing real work not being able to leverage existing open source projects will quickly invalidate any productivity benefits you get from using Elm. I love everything about Elm and I'm sure it will keep getting better & gaining mindshare but for now I can only rationalize using it in a small well contained part of a big application that lives in an island (and it is hard to find a good fit for this). Elm programmers; please standardize a better way to use native libraries and lose that 'yuck, that's unsafe' attitude against existing solutions written in JS. After publishing a complete library by writing bindings you can always rewrite it internally in Elm one function at a time. So Elm is not for me right now. If you are still with me, I'll finally cover... * PureScript: For some reason, during my journey through AltJS languages I've never considered PureScript before exhausting most of my options. I think this has to do with the grumpy attitude I used to have about front end development years ago when I first started doing less and less back end work. I wanted to keep all my trusted tools and always sought solutions that would let me. I liked how ClojureScript would let me use Leiningen, GHCJS would let me use Cabal etc. to build my projects. After front end development started to be something I enjoy doing rather than something I have to do, I realized I should start seeking solutions that would let me embrace tools web community has to offer and piece well-made blocks together to create web applications rather than fighting against it and living in my own island grudgingly rewriting everything. I love how PureScript is just a part of the toolstack like CoffeeScript and each .purs file produces one .js file without any runtime. On a scale from line-to-line transpilers like CoffeeScripts to beasts like Emscripten this is the sweet spot for me. I've been using React almost since it's first incarnation and after writing a lot of CLJS/Om code I've come to realize that HTML is the best DSL to write HTML in and plain React+JSX is the best way to create views for me. Plus, all the React components I can just grab and use give a huge advantage over any 'virtual-dom' based library like Elm-HTML, Halogen. JS leaves a lot to be desired regarding app structure, error handling, side effects, business logic etc. and fortunately you can mix-and-match PureScript with JavaScript however you like. It has a FFI system that's best-in-class and semantics that are easy to reason about and won't need a big context switch when interacting with the outside world. In fact, the approach I'm taking now doesn't require me to write the main application in PureScript with React bindings and treat the JS code to be as the 'outside world' because you can just https://github.com/ethul/purs-loader https://github.com/ethul/purs-loader in your existing Webpack configuration and start doing require('./PurescriptModule') right away. If you are using Redux for example, you can write your Views in JS and let React+JSX do what they do best and write your Actions and Reducers in PureScript. This will give you the benefit of being able to use existing React components and concisely define browser rendering while defining your business logic & execute side effects in a safer and more expressive language.
zem 11y ago
ur/web is worth a look too: http://www.impredicative.com/ur/ http://www.impredicative.com/ur/
pixel67 11y ago
Love purscript, big advantage to frontend devs

by jey 11y ago

jeremyjh 11y ago

Haste also generates reasonable output (it can be debugged, though it is nothing like as reasonable as purescript) and has a runtime that is only 500 lines of straightforward javascript. It had pretty haskellish runtime semantics (purescript doesn't) I was able to use my existing tools like hdevtools, and have what (with just a couple ifdefs) functions as a single code-base for client and server. But its community is just too small, its updates too sporadic. I couldn't see building a business on it. Purescript or Typescript would be the only compile-to-javascript languages I would consider for serious work.

agrafix 11y ago

I'm currently moving from Elm to PureScript. Here's why (from "strong" to "weak"): - Currently Elm has a sad story addressing integration with "native" javascript libraries and Elm is too opinioated in some cases, e.g. you can only use either the built-in 'Elements' or virtual-dom Elements to render frontend. This makes it hard to build modular components (see https://groups.google.com/forum/#!topic/elm-discuss/65tiRM7SxaA https://groups.google.com/forum/#!topic/elm-discuss/65tiRM7S... for example) - While the simple type system in Elm (e.g. no type classes, no monads, ...) makes beautiful error messages possible, it really limits the abstractions that I am used to coming from Haskell - Elm/Elm-make does not generate modules that conform to a "standard" js module system - thus it will not integrate well with other js tools - Elm syntax is lacking 'where' clauses, which results in constant reindentation of code Don't get me wrong - I liked Elm a lot; but it just does not seem mature enough to use in production - but it looks like a great language to start learning FP.

sriku 11y ago
Elm's extensible records are more powerful than even what Evan is willing to encourage. You can use them to implement type classes as well as first class modules, albeit with a bit of extra typing (ahem). They even permit you to have multiple "instances" for the same type if you require that.
- agrafix 11y ago
  The problem is that it will not work for higher kinded types as that's not supported in Elm. You can not define a functor, a monad, ...

pierrebeaucamp 11y ago

Out of PureScript, Elm, Haste and GHCJS, I like PureScript the most. What sold me on this language was the JS output after compilation - PureScript doesn't translate a huge runtime to JS (like the other options), it will only include the code which is actually needed. Another advantage of PureScript: The foreign function interface is ridiculously easy to use.

pka 11y ago

I moved from Elm to PureScript 1 month ago, and I don't regret it. Here's my earlier explanation why [0]. [0] https://news.ycombinator.com/item?id=10727009 https://news.ycombinator.com/item?id=10727009

Kutta 11y ago

I looked at Elm, PureScript and GHJS, and chose PureScript for pretty much the mentioned reasons (powerful types, clean output, easy JS interop). I have a lot of experience in Haskell, and I find it refreshing that PureScript libraries and solutions have a lot of freedom to implement whatever they want, compared to the Haskell world which has a large amount of conventions to adhere to (and standard libraries to be compatible with).

rlander 11y ago

Well, "superior" is subjective in this case. It's like an OO programmer claiming that Smalltalk is a superior language than Elm. Besides, Purescript is squarely targeted at experienced Haskell programmers, which is not the case of Elm. Elm is an ML language, not a Haskell dialect that compiles to JS. I also evaluated Elm, Purescript, Roy, F#, JS_of_Ocaml and ended up choosing Elm precisely for the reasons you chose to stay away from it. I only use JS for front-end stuff, I value simplicity over expressivity and I don't want to spend many weeks learning Haskell-like abstractions to start being productive in a new language (in contrast, it only took me an afternoon to start being productive in Elm).

ZenoArrow 11y ago
> "Elm is an ML language, not a Haskell dialect that compiles to JS." To be clear, Haskell also comes from the ML lineage.
- hanniabu 11y ago
  ML stands for machine learning, correct?
  - tcard 11y ago
    Not in this context. It's an old functional programming language that influences a whole family. https://en.wikipedia.org/wiki/ML_(programming_language) https://en.wikipedia.org/wiki/ML_(programming_language)
  - thedufer 11y ago
    In this context, it stands for MetaLanguage, which is a language family (and was at one point a language itself, I believe). The family includes Ocaml (see the ml there?) and Haskell, among many others.
    - mgold 11y ago
      Yup, and I have a sneaking suspicion "Elm" is "Evan's ML", except EML sounded bad.

rtfeldman 11y ago

Yes. Here's my LambdaConf 2015 talk on how I ended up at Elm from PureScript: https://www.youtube.com/watch?v=B7Iwreo1ReU https://www.youtube.com/watch?v=B7Iwreo1ReU

ekidd 11y ago

I started writing a small-to-medium-sized web application in Elm, because I wanted to try out FRP. I mentioned my experiences here: https://news.ycombinator.com/item?id=10726648 https://news.ycombinator.com/item?id=10726648 In short, Elm has some nice error messages, and it's easy to use at first. But as my app got larger, other factors became major issues: - Elm requires a painful amount of boilerplate code. A lot of this is related to the fact that it tries to do functional programming without many of the customary abstractions. - Elm's FFI (via the ports system) is really painful to use. If you ever need to integrate to third party code, or get a value from the DOM, it's going to require creating a new port in your main module, a new listener in JS, and wiring everything up. - A lot of Elm tools and APIs have bugs. For example, I discovered that if I built my app using the recommended Elm architecture, I couldn't use the debugger. But even some core APIs like Window.dimensions burned me more than once, with things like: https://github.com/evancz/start-app/pull/37 https://github.com/evancz/start-app/pull/37 I've started porting the app to Purescript. I used the Purescript book, which is excellent: https://leanpub.com/purescript/read https://leanpub.com/purescript/read I'm especially happily with Purescript's FFI, and its generally pragmatic attitude. However, Purescript doesn't come with a "blessed" UI library, so you have to pick. I briefly tried the ambitious Halogen library, but the sheer type-system complexity ground me down quickly. I eventually went with the Thermite library, which is a very thin library wrapper of React (< 300 lines of code). So far, Thermite has been very nice, and quite easy to use, though it could use some enhancements and tweaks. Overall, I like Purescript a lot. My basic problem with Elm is that it tries to be very opinionated, with very few escape hatches, so when I got stuck, I tended to get stuck very hard. Whereas with Purescript, it's much easier to drop down to JavaScript, but also to "pop up" and pull a well-known abstraction out of the standard Haskell toolbox if I need one.

osener 11y ago

I've been thinking about this a lot lately and I think you might be right. I've been using ClojureScript professionally for years, shipped some stuff with TypeScript, used GHCJS for some side-projects, and not feeling satisfied with doing front end development with any of them I spent some time catching up with new front end tech and AltJS languages over the Christmas break. Here's my highly opinionated and shallow thoughts on this matter: * ClojureScript: This is the only AltJS language I've done real work in and used in anger, so naturally it's the one I'd complain about the most. I don't like being negative so I'll keep it short: It doesn't provide the same increase in productivity relative to the host language as Clojure does to Java. The advantages it has over ES6 fail to make up for the loss of a huge ecosystem and this only seems to get worse because of the rate big JS community innovates (whether you'd classify this as 'churn' is another matter). * GHCJS: One of the most impressive compilers out there that target JavaScript. If you are already spoiled by Haskell and comfortable with it's semantics and runtime system definitely go for it. But if you are approaching this from the perspective of a front end developer who's looking for a better language this will feel like learning C++ just so that you can compile it with Emscripten. I've used GHCJS to build https://github.com/osener/markup.rocks https://github.com/osener/markup.rocks which runs Pandoc in browsers and it's certainly the best, if not only, option if you are looking to compile some existing Haskell codebase to JavaScript. My decision to stop using it has more to do with my lack of experience with Haskell than any problems with GHCJS itself. I tried to adopt so much new stuff at once with my limited Haskell experience, Reflex, GHCJS, FRP etc., and I'm having a hard time pinpointing which ones netted the increase in program robustness I've experienced (app development in JS feels so brittle in comparison) and which ones caused my lack of productivity. After visiting this codebase after spending more than half a year without doing any Haskell GHCJS DOM APIs were revamped and I was so unfamiliar with my codebase that I didn't know where to start converting it to the new API let alone add new features. I started exploring packages like https://hackage.haskell.org/package/react-flux https://hackage.haskell.org/package/react-flux to see if I can take a more conservative approach with GHCJS and get the benefit of leveraging the ready-made React components out there. Unfortunately I was also very unhappy with the 26MB uncompressed JS output and wanted to add JS based renderers for stuff like Markdown and split Pandoc to its own .js file to lazily load it when it's needed. Thinking about this I realized that my main use case for GHCJS was compiling Pandoc and once I split that up I don't need to choose between two Haskell front end libraries and write the app itself using a more pragmatic stack and get some performance benefits (GHCJS produced code is especially hard on mobile browsers). At this point I was pretty spoiled by Haskell and wanted to keep most of it while taking a more pragmatic approach. This brought me to * Elm: I didn't know a language could provide such a good UX until I discovered Elm. From simplicity of the syntax to compiler messages, wonderful piece of work! I won't get into it's shortcomings compared to Haskell; although I can see the usefulness of additions like Typeclasses there are lots of posts from experienced Haskellers suggesting language features, and posts from Elm's designers explaining their choices not to include these. I'm not educated enough in these matters to say anything that hasn't been said before in favor of either stance. My real suprise wasn't lack of Typeclasses; it was how unpragmatic Elm is, especially since it's not an attempt to adapt an existing language for front end development but a language designed specifically for it. I certainly applaud their goal to create a better way to write browser apps and I understand that they are in it for the long haul but I need to be productive right now and even GHCJS has a better FFI solution than Elm. When people ask how to use a JavaScript library from Elm in mailgroups and stackoverflow, their communities stance seems to be "include CSS and rewrite the JS code in Elm". This might be fine if all you need is to rewrite Bootstrap's dropdown logic in Elm but for doing real work not being able to leverage existing open source projects will quickly invalidate any productivity benefits you get from using Elm. I love everything about Elm and I'm sure it will keep getting better & gaining mindshare but for now I can only rationalize using it in a small well contained part of a big application that lives in an island (and it is hard to find a good fit for this). Elm programmers; please standardize a better way to use native libraries and lose that 'yuck, that's unsafe' attitude against existing solutions written in JS. After publishing a complete library by writing bindings you can always rewrite it internally in Elm one function at a time. So Elm is not for me right now. If you are still with me, I'll finally cover... * PureScript: For some reason, during my journey through AltJS languages I've never considered PureScript before exhausting most of my options. I think this has to do with the grumpy attitude I used to have about front end development years ago when I first started doing less and less back end work. I wanted to keep all my trusted tools and always sought solutions that would let me. I liked how ClojureScript would let me use Leiningen, GHCJS would let me use Cabal etc. to build my projects. After front end development started to be something I enjoy doing rather than something I have to do, I realized I should start seeking solutions that would let me embrace tools web community has to offer and piece well-made blocks together to create web applications rather than fighting against it and living in my own island grudgingly rewriting everything. I love how PureScript is just a part of the toolstack like CoffeeScript and each .purs file produces one .js file without any runtime. On a scale from line-to-line transpilers like CoffeeScripts to beasts like Emscripten this is the sweet spot for me. I've been using React almost since it's first incarnation and after writing a lot of CLJS/Om code I've come to realize that HTML is the best DSL to write HTML in and plain React+JSX is the best way to create views for me. Plus, all the React components I can just grab and use give a huge advantage over any 'virtual-dom' based library like Elm-HTML, Halogen. JS leaves a lot to be desired regarding app structure, error handling, side effects, business logic etc. and fortunately you can mix-and-match PureScript with JavaScript however you like. It has a FFI system that's best-in-class and semantics that are easy to reason about and won't need a big context switch when interacting with the outside world. In fact, the approach I'm taking now doesn't require me to write the main application in PureScript with React bindings and treat the JS code to be as the 'outside world' because you can just https://github.com/ethul/purs-loader https://github.com/ethul/purs-loader in your existing Webpack configuration and start doing require('./PurescriptModule') right away. If you are using Redux for example, you can write your Views in JS and let React+JSX do what they do best and write your Actions and Reducers in PureScript. This will give you the benefit of being able to use existing React components and concisely define browser rendering while defining your business logic & execute side effects in a safer and more expressive language.

zem 11y ago

ur/web is worth a look too: http://www.impredicative.com/ur/ http://www.impredicative.com/ur/

pixel67 11y ago

Love purscript, big advantage to frontend devs