Skip to content
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

Front End Framework #1

Open
4 tasks
parsonsmatt opened this issue Dec 26, 2015 · 4 comments
Open
4 tasks

Front End Framework #1

parsonsmatt opened this issue Dec 26, 2015 · 4 comments

Comments

@parsonsmatt
Copy link
Owner

There are two main points to this project: 1) Build an application with functional programming techniques, 2) Make something useful to fill a perceived void in the market. Since learning is a big part of what I want to accomplish here, I'm going to document what I want to do for a "minimal implementation" for each framework/methodology I want to attempt (unless I decide one is simply superior).

  • Authentication
  • Registration
  • Logging a session (with no helpers/tooltips/analysis/parsing/etc)
  • Local storage

I'm intending on attempting a build for the following:

If none of the above end up being nice enough, I'll just do it with a JavaScript front end and call it a learning experience. This thread will document my general experiences with the various approaches as well.

On a general level, the big pros/cons that I can see for JavaScript are:

Pros:

  • React, Immutable, Redux, etc. make development fairly tolerable.
  • The JavaScript tooling is pretty enviable -- webpack hot loader is neat!
  • Tons of work is already done and the ecosystem has libraries for everything.
  • And, this is the biggest one: boilerplate around sending/receiving JSON is essentially 0. On the server, Aeson and Servant reduce the boilerplate around de/serialization.

Cons:

It's JavaScript.

@parsonsmatt
Copy link
Owner Author

PureScript Halogen

(this comment will be edited to reflect my current opinion as I feel like doing so)

I'm finding that I'm writing a ton of boiler plate around lenses, AJAX, serializing and deserializing my types, etc. Halogen is a fantastic framework for building out the UI, but there doesn't seem to be a good solution in PureScript-land for doing AJAX conveniently.

@parsonsmatt
Copy link
Owner Author

Elm

Elm was a very nice and friendly experience when I was briefly demonstrating it, but the lack of type classes (or similar means of abstraction) and the verbose de/serialization code negated many of the benefits. There seems to be good work around generating Elm client from Servant, and the Haskell-Elm bridge. These would make Elm much nicer to use, and potentially give it the leg up over PureScript despite having a less powerful core language.

@kozak
Copy link

kozak commented Oct 11, 2016

I would be very interested in your current opinion :)

@parsonsmatt
Copy link
Owner Author

I'm pretty sold on PureScript these days. Since I wrote that evaluation, they've done a lot of work on reducing boilerplate, and it's pretty easy to do PS codegen from Haskell types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants