Oooo, that looks interesting!
It looks kind of like a smalltalk’ish Terra.
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.
Heh, never heard of it, does not seem to have a lot similar on first comparison. It is built in ocaml. ^.^
I think its propose is similar to your implementation, Bucklescript-TEA.
I add that one to the Wikipedia page of Elm, by the way.
Another vote for the OCaml syntax
by @tcoopman
The article is more on the “vs Elm” topic (in the most complementary fashion).
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.
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.
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.
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).
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:
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.
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.