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

121–130 of 190 posts

Re: ReasonML – React as first intended

#121

Post by DougBTX »

RussianCow wrote: post #108
cdaringe wrote: post #103

Earlier quoted context omitted.

Historically a single connected root has been frowned upon. I'm not so sure it should still be feared now that you can use PureComponents and FSCs the whole way down. ShouldComponentUpdate calls are cheap in pure-town.

For me, it's not a matter of performance, but rather of convenience. If I have a deeply nested component that needs to dispatch an action or access a part of the global state, I don't want to have to pass that all the way down through every other component in the hierarchy. The grandparent of a "Like" button shouldn't need to know the details of how it's implemented with regards to the global state, but it's forced t…

The newly official Context API might change things here, since it will be much easier to pass state down to grandchildren. I’ve not been keeping up to date with the plans for what react-redux will do with the new API yet, could be interesting.

Re: ReasonML – React as first intended

#122

Post by qop »

lf-non wrote: post #102
qop wrote: post #7

Earlier quoted context omitted.

It's not any less convenient than React appears to be. Disclaimer: I've only used it for small Todo project, I'm not a front end guy. Disdisclaimer: I've not used React at all. However, if you need really strong JS interop, consider something like F#'s Fable. F# is gaining a lot of momentum and now that SAFE stack is apparently Microsoft-blessed, I expect it to continue growing even more.

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…

If ocaml gets multicore finished before 20XX, do you think that f# developers who came from outside dotnet could be coaxed to ocaml?

Also, to just jump in what your comment was actually about, I think the prospect of writing f# is generally a more friendly experience for those using it for the web. Or especially those using azure. Getting started with f# with ionide and vscode is literally the most pleasant onboarding I've experienced since ruby. It just goes! Amazing.

But yeah, I think reason is great too. I really like that ocaml has a centralized, external package management story. Using paket+fake isn't like a bad experience, and I mean, I wrote scala for a couple years, I can always find gratitude for a build tool of its NOT sbt, but it's awkward at times and feels like a bit more work than it should be. Of course from Microsoft's perspective, being able to jump around dotnet libs is a major boon.

You do web development primarily? I've been eyeballing TS lately, you think that's probsbly a better choice for more professional work until reasonml gets bigger pants to wear?

Re: ReasonML – React as first intended

#123

Post by tfranco »

danpalmer wrote: post #91

(Caveat, we're adopting Elm and so I'm a little biased) I think this article's conclusion of Reason being the enterprise grade and mainstream implementation of Elm, and Elm being a "prototype" is a little unfair to Elm. Elm has developed a mature ecosystem in many ways, in a relatively short space of time, and two of the main reasons for that are the purity and the way the JS interop works. It explicitly shields the…

Just for the sake of completion, we covered ELM a few weeks ago: https://www.imaginarycloud.com/blog/elm-javascript-reinvente...

Re: ReasonML – React as first intended

#124

Post by spraak »

danpalmer wrote: post #110
orbifold wrote: post #106

Earlier quoted context omitted.

Well Reason is really Ocaml, which has a much better type system than Elm (functors, open variants, a class system) , powerful meta programming (the react extension is just syntactic sugar around that) and is now backed by at least three large corporations (Facebook, Bloomberg and JaneStreet). It has a proven track record of handling large sophisticated projects and is not restricted to the web front end niche becaus…

The type system might be more powerful, my point is more that if you can bypass it and integrate directly with JS, then people will, and then much of that value is lost. Elm doesn’t have that problem.

You can type your JS bindings

Re: ReasonML – React as first intended

#125

Post by phillipcarter »

lf-non wrote: post #102
qop wrote: post #7

Earlier quoted context omitted.

It's not any less convenient than React appears to be. Disclaimer: I've only used it for small Todo project, I'm not a front end guy. Disdisclaimer: I've not used React at all. However, if you need really strong JS interop, consider something like F#'s Fable. F# is gaining a lot of momentum and now that SAFE stack is apparently Microsoft-blessed, I expect it to continue growing even more.

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 consume JS libraries, TS definition files, etc. For example:

"The following F# semantic and syntactic features are also available:

* Records and Unions

* Structural Equality/Comparison

* Comprehensions (seq, array, list)

* Computation Expressions

* Pattern Matching

* Active Patterns

* Object Expressions

* Units of measure"

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

[0]: fable.io/docs/compatibility.html

Re: ReasonML – React as first intended

#126

Post by orbifold »

danpalmer wrote: post #110
orbifold wrote: post #106

Earlier quoted context omitted.

Well Reason is really Ocaml, which has a much better type system than Elm (functors, open variants, a class system) , powerful meta programming (the react extension is just syntactic sugar around that) and is now backed by at least three large corporations (Facebook, Bloomberg and JaneStreet). It has a proven track record of handling large sophisticated projects and is not restricted to the web front end niche becaus…

The type system might be more powerful, my point is more that if you can bypass it and integrate directly with JS, then people will, and then much of that value is lost. Elm doesn’t have that problem.

Not everyone has a greenfield project the fact that it integrates with JavaScript seamlessly and generates readable JavaScript is an advantage. They go as far as providing a plug-in for the standard JavaScript build flow, so you can basically start by just converting one file. On the other hand ocaml’s package manager (opam) and build system (jbuilder) are much better than elms equivalent and nothing is stopping you from using those for a greenfield project.

Re: ReasonML – React as first intended

#128

Post by pgt »

kbenson wrote: post #119

I think ReasonML would see much faster adoption if they provided a stand-alone binary, or at least a pre-installed environment, which could be downloaded and installed as a whole. ReasonML has a lot that makes it attractive to people that aren't already entirely invested in the JS/Node ecosystem, but doing the whole dance to make sure Node is installed correctly, and then using npm or yarn to install bucklescript and…

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 we don't assign enough nearly credence to the cost of trialling new things when we are already operating at our mental limits. By the time I am in a sufficiently quiet spot to try your thing, I'm probably exhausted after a long day of work. So make it as self-exemplary as possible. Steve Krug nailed it in "Don't Make Me Think." (https://www.sensible.com/dmmt.html)

I.e. What is the correct number of buttons to start/stop your microwave: one or two? The answer is zero: your food should already be warm.

Re: ReasonML – React as first intended

#129

Post by kodablah »

JoshMnem wrote: post #31

Using Facebook's software supports Facebook. I think the industry should move away from that instead of adopting more of their technology. Programmers should start considering these things. Alternatives: Elm, Purescript, etc. Edit: I recommend stopping and thinking a bit about ethics of technology choices before reactively downvoting.

Completely agree. We all have to capitulate sometimes, but rarely with new, less-used tech. I have the same feeling towards GraalVM. Sure we may use Java, React, etc because their ecosystem outweighs their maintainers but that doesn't mean we have to with lesser-adopted things. Reduced adoption is also the best, least-judging way we can send messages to high quality developers that remain at these places.

Re: ReasonML – React as first intended

#130

Post by gildas »

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…

> From my point of view, React solved a real problem. JS before React (at least old-skool, with jQuery & co.) was simply unmaintainable

Why would someone who knows Dojo or GWT want to switch to React?

Post reply on HN