ReasonML with Phoenix?

Oooo, that looks interesting! :slight_smile:

It looks kind of like a smalltalk’ish Terra. :slight_smile:

1 Like

Yeah, something like that. There are so much awesome tools outside, Clojures website and Rich Huckeys talk “Simple made easy” convinced me completely about functional programming, even when F# is still my favorite. :slight_smile:

Where do you see the differences between the Elm architecture and Links?

Heh, never heard of it, does not seem to have a lot similar on first comparison. It is built in ocaml. ^.^

1 Like

I think its propose is similar to your implementation, Bucklescript-TEA.

I add that one to the Wikipedia page of Elm, by the way.

1 Like

6 posts were split to a new topic: What are Monads?

Another vote for the OCaml syntax

###Why I choose Bucklescript

by @tcoopman

The article is more on the “vs Elm” topic (in the most complementary fashion).

3 Likes

Verbosity aside - I think there is also a failure to communicate. In the C-family of languages “the stuff between braces” are statements. In Reason the braces have been repurposed for as “begin”/“end” tokens. But as a result of previous familiarity with the C-family of languages this way of using braces is going to delay viewing everything as an expression.

3 Likes

What I dislike about { .. } is that in a language like OCaml heavily relies on record it requires extra efforts to tell if it is a code block or a record. Rust has this problem as well.

2 Likes

Ditto, and it has been repurposed for objects as well (I think tuples are (/)?), so {/} is quad-purposed in ReasonML (maybe more), this is one thing I really dislike as it is forcing them to do weird things like {1, 2, 3} or {. 1, 2, 3} or {.. 1, 2, 3} or more and other weird things just to get things unambiguous again. OCaml’s syntax may look odd to javascripters, but it is chosen for a very good reason.

Links is tierless (like Ocsigen, or Ur/Web). You write code for the client, server and datastore in the same language.

Why didn’t you use the React OCaml library, like it is used here for instance ?

Because React has a few issues that I really don’t agree with, one is that it is substantially slower than mine, much heavier code to bring in (substantially larger), much longer startup time, and it’s not very functional (in the functional programming sense).

1 Like

Kind of let my “looking into React” slide but recently went back to some tutorials that I had lined up in my queue - but I have been doing them with ReasonReact instead.

I find Bucklescript/ReasonML really makes it obvious when React is being sloppy (sometimes things get ornery in a “I’m sorry Dave, I’m afraid I can’t do that” way.).

For one there’s no setState in ReasonReact - you have to use a reducerComponent with and reducer function that returns a ReasonReact.update type.

There is no Redux integration because it has it’s own Reductive library.

Personally, I don’t see the react-router bindings going anywhere. As far as I can tell react-router has a tendency to introduce deep coupling into components - in ReasonML it makes far more sense to capture the URI essentials in a variant at the top level and to convert it as required as it gets closer and closer to the leaf components.

And JSX seems even more loosey-goosey than usual - for the time being ReasonReact.element and ReasonReact.createDomElement make frequent appearances - to the point where you wish people would just realize that JSX isn’t markup but just source for a code generator (so can we just let go of the pretense).

So depending on how serious FB is about ReasonML, it may actually cause React to clean up it’s act (or at least lead to an alternate, cleaner interface for ReasonML).

Aside:

People are reading way too much into Presentational vs Container components divide. Almost regretting I wrote that.

Dan Abramov referring to Presentational and Container Components.

In a way this seems to be in line with Elm’s “no components” stance. Traditionally people expect components to combine the presentational and behavioural UI aspects. Container/Presentation splits the traditional “visual component” into two separate responsibilities.

I was talking about the OCaml FRP library here, not Facebook React. This TodoMVC example shows how it can be used to implement something close to what Elm gives you

Hmm, a few things I immediately notice, first it seems to be far more verbose (more like the old Elm <0.16 way, which used signals/frp instead of the event processing model that it and I use now), and it looks like loops could happen where mine prevents that by holding messages if one is already being processed. where with FRP that is significantly harder to do properly and user code can easily break it (this was a problem elm had in older versions as well).

Remember, Elm is not FRP.

yes I agree it is more verbose, React is a general purpose FRP library and there, they implement TodoMVC the way it would be done in Elm… but I thought it looked OK

As they implemented it, it looks very close to how it was done in Elm back in 0.16- versions, 0.17 had the overhaul that got rid of FRP.

1 Like

Does anyone have an up to date version of how to use bucklescript with Phoenix and brunch? I’m running into some issues that I can only assume are unique to brunch.

In particular, if I set the module output to es6-global it seems to find all modules in node_modules correctly, but then brunch complains that imports cannot be done outside of a top level context (from bs-webapi). If I use the commonjs modules I get complaints about bs-platform not being available on page load. Any solid resources on how to use bucklescript with phoenix and brunch?

P.S: I likely won’t be able to change the JS build system on this project, so I kind of need it to work out with brunch even though I’d rather switch to something else.

Don’t use brunch for that part, just use bucklescript’s own watcher added to the phoenix definition (you can have multiple watchers listed), and have brunch just watch the output javascript directory (make sure to have brunch’s npm integration enabled in the config, it ‘should’ be by default), easy-peasy then. :slight_smile: