Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ReasonML – React as first intended

imaginarycloud.com

Post reply on HN
Print view View original

151–160 of 190 posts

Re: ReasonML – React as first intended

#151

Post by lf-non »

phillipcarter wrote: post #125
lf-non wrote: post #102

Earlier quoted context omitted.

I like F# and believe the author has done an amazing job evolving a functional language on the dot net platform but there are simply too many design choices in F# geared around C# compatibility and limitations of CLR being an object oriented language that when you switch to a different compilation target, these language aspects begin to look like bizarre warts. Things like limitations on statically resolved type para…

> tl;dr: The 80% best practices parity between ReasonML and modern functional javascript which the "What & Why" page of official documentation [3] talks about, does not exactly hold true for F#. The bulk of F# is functions acting on values modeled by types. This maps directly to JS. In the F# and .NET compatibility document[0], you'll note that all "core F#" components map directly to JS. And of course, you can consu…

I am not at all contesting the value in the good parts of F#. It was my first foray into a functional language, and I was left seriously impressed.

> Do you have specific examples where F# semantics cannot map to JS such that the "80% rule" also does not hold?

Yes, my comment was around some of the C# compatibility things, which don't make sense when compiling to other targets.

> Tuples vs struct tuples distinction.

> Having both modules and namespaces

> Explicit interfaces

> The strange coupling of SRTP and inlining

I find OCaml's support for structural typing in classes and polymorphism to be more flexible than the above.

In typed FP, runtime reflection is seldom used, and I believe reflection support (and associated overhead) should have to be explicitly opted in.

I also faced weird issues when tracing the source of an exception in an async workflow, and some incomprehensible errors around automatic generalization. But this was a long time back and I no longer have the full context. These may have since been addressed.

My intent was certainly not to criticise F#. It has been developed and is used by people far smarter than me. It is just that after a preliminary evaluation I have not found a strong reason to prefer Fable over bucklescript in the absence of a more deeper commitment to dotnet stack.

I am also really fond of many modern JS features like Module Filepath 1:1 correlation, explicit imports, ES6 proxies, tagged template literals (placeholders etc.) which TypeScript elegantly inherits from JS. Support for intersection types in typescrpt is also very handy.

Re: ReasonML – React as first intended

#152

Post by kbenson »

loginx wrote: post #137
pgt wrote: post #128

Earlier quoted context omitted.

As a masochist who has been willing to put up with the ecosystem pain of Clojure & ClojureScript for the love of the language, I can corroborate that it was a PITA to try ReasonML. By the time I was done installing ReasonML to my machine, I was done trying Reason - ML and OCaml seem great, but I have limited mental resources and they are over-invested elsewhere. This serves to inform future technology trials, because…

Pardon me if I'm being dense here, but can't you just try out reasonML with a quick npm install from any platform? That's what they say in their "Quick Start" docs here: https://reasonml.github.io/docs/en/quickstart-javascript.htm...

IIRC from when I looked into it and got it working a few months back, you npm install bucklescript, wihch gives you a compiler to convert reason to JS, so to do any testing that actually includes a real world equivalent experience (such as include it in a sample webpage, maybe with React), you're talking about using webpack or something to bundle all the dependencies and steps into a deployment procedure.

Since it compiles to JS, and uses a JS lib and ecosystem to install the utilities that do the cross-compile, it's sort of like if to try out Python you had to first download and install a C compiler and C libraries used in Python, and compile python from scratch, just to try it out, because no pre-existing binaries, packages or installers existed. If that was the only way to try out Python (or Ruby, or Perl, or anything), you would get a lot less people trying it out, and a lot less willing to go through all that in their build chain (in case python updates, right?) if easier alternatives exist.

Just because your language compiles to another language, that doesn't mean to you get to ignore the on-boarding experience to that extent. At least not if you really want to succeed.

Re: ReasonML – React as first intended

#153

Post by BLanen »

simplify wrote: post #34
amenod wrote: post #17

Honest question: why would someone use this instead of React? From my point of view, React solved a real problem. JS before React (at least old-skool, with jQuery & co.) was simply unmaintainable. It was often easier to thow old projects away and start anew than to maintain what inevitably became a tangled mess of callbacks and global variables. Not because of incompetency of developers (at least I hope so ;) but bec…

ReasonML has more potential. Aside from its excellent type system (one of the best), it can also compile to native code. This has several benefits: - Frontend: Your tools are fast. The ReasonML-to-JS compiler is already an order of magnitude faster that TypeScript, etc. Fastpack is a native bundler in the works that aims to bundle your project in under a second (and faster for incremental builds). - Mobile & Desktop:…

I mean, why even use node for the backend?

Re: ReasonML – React as first intended

#154

Post by Rapzid »

qop wrote: post #115
Rapzid wrote: post #8

Earlier quoted context omitted.

1k upvotes. I check in on Fable and F# semi frequently but SAFE has somehow slipped under my radar. I wonder if the ionide project will get some extra support.. Suave though... Nothing against Suave, but it's not the Phoenix competitor the ecosystem is in dire need of. I was under the impression some newer frameworks like Giraffe were going to fill that void..

Are you aware of https://github.com/SaturnFramework/Saturn ? It's what the S in safe is actually meant to be, not suave. It's very similar, in heart anyways, to phoenix. The fsharp community is fighting what is essentially an uphill battle. We have ML but we've got to jump through dotnet hoops to get shit done. One man's cruft is another man's feature. I doubt ionide will support SAFE, but maybe they will have a sist…

I had not! Looking into it now..

Ionide could just use some extra help I mean; it appears to be the work of just one guy. Hopefully with the increased interested in F# web development it will get some extra love more ala omnisharp.

Re: ReasonML – React as first intended

#155

Post by simplify »

kbenson wrote: post #152
loginx wrote: post #137

Earlier quoted context omitted.

Pardon me if I'm being dense here, but can't you just try out reasonML with a quick npm install from any platform? That's what they say in their "Quick Start" docs here: https://reasonml.github.io/docs/en/quickstart-javascript.htm...

IIRC from when I looked into it and got it working a few months back, you npm install bucklescript, wihch gives you a compiler to convert reason to JS, so to do any testing that actually includes a real world equivalent experience (such as include it in a sample webpage, maybe with React), you're talking about using webpack or something to bundle all the dependencies and steps into a deployment procedure. Since it co…

There's no ignoring going on. Reason exists on its own because it's not opinionated on what sort of app you're trying to build – frontend, backend, native, or some combination thereof.

If you're looking to build a web app with react (the subject of the article) then you can whip one up using one of their generators https://reasonml.github.io/reason-react/docs/en/installation...

Re: ReasonML – React as first intended

#156

Post by RobertKerans »

crooked-v wrote: post #146
RussianCow wrote: post #77

Earlier quoted context omitted.

Reducers are only one (and IMO the least important) part of using Redux with React; the other part is `connect`, which lets you pass global state directly into a deeply nested component without passing it all the way down the tree via props. Unless I'm mistaken, ReactReason doesn't offer an alternative to that.

The new context API can probably help with that. Pass an object through context that contains the reducer state of a root level component (or a getState() or whatever), plus a dispatch function. Blam, Redux-equivalent without a separate library.

ReasonReact doesn't have Context, the API is unstable so they aren't binding to it.

Re: ReasonML – React as first intended

#157

Post by RussianCow »

RobertKerans wrote: post #156
crooked-v wrote: post #146

Earlier quoted context omitted.

The new context API can probably help with that. Pass an object through context that contains the reducer state of a root level component (or a getState() or whatever), plus a dispatch function. Blam, Redux-equivalent without a separate library.

ReasonReact doesn't have Context, the API is unstable so they aren't binding to it.

The new API as of 16.3 is stable, so I suspect ReactReason will support it soon (if it doesn't already, by default).

https://reactjs.org/docs/context.html

Re: ReasonML – React as first intended

#158

Post by kbenson »

simplify wrote: post #155
kbenson wrote: post #152

Earlier quoted context omitted.

IIRC from when I looked into it and got it working a few months back, you npm install bucklescript, wihch gives you a compiler to convert reason to JS, so to do any testing that actually includes a real world equivalent experience (such as include it in a sample webpage, maybe with React), you're talking about using webpack or something to bundle all the dependencies and steps into a deployment procedure. Since it co…

There's no ignoring going on. Reason exists on its own because it's not opinionated on what sort of app you're trying to build – frontend, backend, native, or some combination thereof. If you're looking to build a web app with react (the subject of the article) then you can whip one up using one of their generators https://reasonml.github.io/reason-react/docs/en/installation...

> There's no ignoring going on. Reason exists on its own because it's not opinionated on what sort of app you're trying to build

I think either I wasn't clear, or you completely misunderstood me. My point, that Reason should have a standalone installer or package that gives you a working Reason as simply as possible without a whole build infrastructure required, is only bolstered by this statement.

I don't think it matters if it's the Reason-to-Ocaml targeted, or Reason-to-Javascript, or one for each, or one that includes both. Having to install one language, and then use tooling and package managing from that language to install another, strikes me as somewhat ridiculous in this day and age. just ship the entire tooling stack abstracted away.

Re: ReasonML – React as first intended

#159

Post by hajile »

lilactown wrote: post #52
Scarbutt wrote: post #33

Earlier quoted context omitted.

How's Clojurescript interop story? what always holds me from using these compile to JS langs is the fear that the gains you get from using a better/nicer language are completely destroyed by all the interop churn.

As someone who's done a bunch of interop in ReasonML & ClojureScript, ClojureScript interop blows ReasonML away (in terms of ease) at the language level. The current problem with ClojureScript interop is the Google Closure compiler's support for stuff on npm. I switched our team to using shadow-cljs[0] and it solved all of those problems. Would highly recommend. [0] http://shadow-cljs.org/

What level of inter-opt? If you want to gradually convert from JS to clojurescript, it seemed like a huge amount of work.

Re: ReasonML – React as first intended

#160

Post by bastawhiz »

jimmy1 wrote: post #22
bastawhiz wrote: post #5

As a bit of a meta point, I find it really distracting when authors make random sentences bold. What you believe to be important is not necessarily what I'll find important, and the added emphasis breaks my flow.

Placing emphasis on things is commonplace. Sometimes it's in the form of a literary device such as hyperbole and sometimes it's done typographically. You shouldn't read it as being "random" but accept it as part of the works. The author clearly intended to draw attention to those sentences and given it is his or her article, it should be accepted as part of the article and the overall message attempting to be conveye…

I'm fine with it when there's one or two. Every paragraph does not need an emphasized sentence.
Post reply on HN