Compare Pux to other options in PureScript land

[cies]

Options like:

• https://github.com/purescript-contrib/purescript-react
• https://github.com/paf31/purescript-thermite
• https://github.com/slamdata/purescript-halogen

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

[spicydonuts]

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?

[spicydonuts]

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]

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]

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]

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 Task component in Halogen
• The Task component in Thermite

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

[cies]

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 Task component in Halogen
• The Task component in Thermite

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