New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compare Pux to other options in PureScript land #67

Open
cies opened this Issue Sep 13, 2016 · 3 comments

Comments

Projects
None yet
3 participants
@cies
Copy link

cies commented Sep 13, 2016

Options like:

I have a hard time to choose between them, a highlevel overview of what sets them apart would be awesome!

@spicydonuts

This comment has been minimized.

Copy link
Contributor

spicydonuts commented Sep 13, 2016

Here's a short summary

purescript-react

  • a PS wrapper around React's API
  • no opinions
  • React API is actually pretty complex and stateful, so purescript-react can get pretty complicated
  • more boilerplate -- you'd likely start to build up your own abstraction over it if you used it directly
  • written by Phil, the original PS creator

purescript-thermite

  • a higher-level wrapper around purescript-react
  • uses lenses (Phil's profunctor lens library)
  • some really cool ideas but can be pretty hard to understand if you don't know lenses well
  • a thermite app builds one react component, so you might use thermite and purescript-react in combination for a complete, multi-component app
  • also written by Phil

purescript-halogen

  • not a React wrapper -- uses virtual-dom
  • might someday abstract the vdom implementation so you can use it over React too (maybe)
  • most complicated (but probably also the most type-safe)
  • used in production by Slamdata

purescript-pux

  • simplest of the React wrappers (one of the reasons it isn't built on purescript-react)
  • pre-17 Elm architecture
  • relatively easy to import regular React components
  • you can also export Pux apps and use them within JS React applications
  • excluding the previous two bullets, a Pux app consists of one component with a large render function, using the elm architecture and signals instead of setState
  • probably the most opinionated in terms of app architecture (though still flexible if you step into JS FFI)

purescript-elm

  • port of Elm's libraries and concepts to PS
  • still a work in progress (it was really close and then Elm 17 was released; not sure if it's caught up yet)
  • the end goal is to be able to take an Elm app, tweak the syntax a bit where necessary (: -> ::, record updates, etc) and have a working PS

Is that what you're looking for?

@cies

This comment has been minimized.

Copy link
Author

cies commented Sep 14, 2016

Wow. Yes, and thanks very much!

I'd put this straight into the readme :), very informative.

On Sep 13, 2016 18:26, "Michael Trotter" notifications@github.com wrote:

Here's a really short summary purescript-react

  • a PS wrapper around React's API
  • no opinions
  • React API is actually pretty complex and stateful, so
    purescript-react can get pretty complicated
  • more boilerplate -- you'd likely start to build up your own
    abstraction over it if you used it directly
  • written by Phil, the original PS creator

purescript-thermite

  • a higher-level wrapper around purescript-react
  • uses lenses (Phil's profunctor lens library)
  • some really cool ideas but can be pretty hard to understand if you
    don't know lenses well
  • a thermite app builds one react component, so you might use thermite
    and purescript-react in combination for a complete, multi-component app
  • also written by Phil

purescript-halogen

  • not a React wrapper -- uses virtual-dom
  • might someday abstract the vdom implementation so you can use it
    over React too (maybe)
  • most complicated (but probably also the most type-safe)
  • used in production by Slamdata

purescript-pux

  • simplest of the React wrappers (one of the reasons it isn't built on
    purescript-react)
  • pre-17 Elm architecture
  • relatively easy to import regular React components
  • you can also export Pux apps and use them within JS React
    applications
  • excluding the previous two bullets, a Pux app consists of one
    component with a large render function, using the elm architecture and
    signals instead of setState
  • probably the most opinionated in terms of app architecture (though
    still flexible if you step into JS FFI)

purescript-elm

  • port of Elm's libraries and concepts to PS
  • still a work in progress (it was really close and then Elm 17 was
    released; not sure if it's caught up yet)
  • the end goal is to be able to take an Elm app, tweak the syntax a
    bit where necessary (: -> ::, record updates, etc) and have a working
    PS

Is that what you're looking for?


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#67 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAh9glJiQSbFuQhkpDAJdTcB9CfIAU7ks5qps6UgaJpZM4J7dgA
.

@cies

This comment has been minimized.

Copy link
Author

cies commented Sep 22, 2016

For purescript-halogen you say:

most complicated (but probably also the most type-safe)

I think that it could use better wording. Maybe "advanced" instead of "complicated" fits better. Here some code examples from the implementation of a todo app using both libs:

The code is functionally very similar, but in the Halogen case it is quite a bit simpler on the eyes (easier types and less data massaging needed).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment