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

161–170 of 190 posts

Re: ReasonML – React as first intended

#161

Post by danpalmer »

machiaweliczny wrote: post #120
danpalmer wrote: post #110

Earlier quoted context omitted.

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.

It lowers barrier to entry. You don't have - it's opt in. Not every project needs 100% type safety. I would also love option to have gradual type friendliness because when prototyping I know my program is wrong in some different part, but I want to test given component in runtime, while I haven't refactored everything yet. I think having option like 'compileWithoutTypecheck' is very good for prototyping.

You can use `Debug.crash` in Elm, or `error` or `undefined` in Haskell to achieve this. They type check to anything, but will halt execution if reached.

Re: ReasonML – React as first intended

#162

Post by RobertKerans »

skosch wrote: post #47

Currently using Reason. Here's what they don't tell you: Pros: * Compile speed is mindblowing. As in, a big project compiles within a few seconds, and incremental compiles are instantaneous. The productivity gains of this cannot be overstated; you just don't get those moments anymore when you're waiting for webpack, your mind wanders off, lets just check HN real quick, ... no, you just stay in the flow. It's great. E…

Yea, thays been very much my experience as well. Still a little bit off usable imo, docs are still very iffy, and there's only really Real World OCaml as a great learning resource for the actual language.

refmt formatting drives me a bit nuts, especially the.lines thing; it's steadily improving though.

One thing though - Belt is the WIP standard library (so OCaml), whereas JS is just bindings to JS, they're very different things. Belt produces much better JS when transpiled, and it seems a lot saner than the stdlib, but it isn't really anything to do with JS bindings.

And the pipe operator is |>, afaics |. is a typo on the Promises documentation page?

|> for reverse application, @@ for application, so

    foo |> bar |> baz
and

    baz @@ bar @@ foo
are both the same as

    baz(bar(foo))
and they work excatly the same as in other ML languages

Re: ReasonML – React as first intended

#163

Post by lilactown »

hajile wrote: post #159
lilactown wrote: post #52

Earlier quoted context omitted.

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.

Ah, hmm.

Using JS from CLJS is incredibly easy. Like I said, shadow-cljs solved all of our problems there.

Going the other way - using code written in CLJS in JS - is another matter. This is not well supported by the ecosystem. shadow-cljs has much, much better support for this than the standard ClojureScript/closure compiler, but it doesn't hold a candle to what BuckleScript does.

IME, doing a top-down transition - where you convert the top of your app to ClojureScript, that calls everything - works best. From the top, you work your way down into each feature.

ReasonML, on the other hand, works better from the bottom up. Typing your whole app is hard, so you start with some small feature that then you export to JS land (since that's so much easier with BuckleScript). From the bottom, you work your way into writing more and more features in ReasonML.

Re: ReasonML – React as first intended

#164

Post by cies »

_0w8t wrote: post #147
cies wrote: post #54

Earlier quoted context omitted.

> compared to Elm or ReasonML PureScript deserves a mention in this list as well. More full-featured and general purpose than Elm, cleaner design than ReasonML. Prolly the smallest community of the 3.

I played with PureScript a little. It has advanced type system that captures a lot of semantics of JS allowing easy interobility with JS ecosystem. But that comes with a huge price. With all those monads and monad transformers interacting with JS it is easy to end up with stateful mess. Surely, it will be typed and functional mess, but still it is hard to maintain with all state pieces spread through code hiding in l…

Elm is a lang and a FW in one. Very opinionated. Very batteries included.

PS is a lang. It compiles well to JS, but there is no friction against making it compile to native, apart from the time it takes to maintain that compiler backend.

On top of PS you may pick a FW. Some have React.js under the hood, some follow more closely The Elm Architecture.

Only with a FW, PS can be compared to Elm.

Re: ReasonML – React as first intended

#165

Post by JoshMnem »

simplify wrote: post #101
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.

Of all Facebook tech, this is the least "Facebook" of them all. ReasonML is a thin layer on top of OCaml, a language that's been around for decades. If Facebook one day abandons Reason, it would their loss more than anyone else's.

That doesn't really address the issue that the use of Facebook's software supports Facebook. The industry needs to pay more attention to the long-term results of its choices and actions.

Re: ReasonML – React as first intended

#166

Post by JoshMnem »

kodablah wrote: post #129
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.

There are alternatives to React too, like Vue.

Re: ReasonML – React as first intended

#167

Post by JoshMnem »

spraak wrote: post #141
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.

Hm I've been saying that for a while but no one seems to understand the connection, or care.

It takes time. Everyone who considers these issues should speak up.

Re: ReasonML – React as first intended

#168

Post by acemarke »

cdaringe wrote: post #139
DougBTX wrote: post #121

Earlier quoted context omitted.

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.

Action creators always felt like and unnecessary abstraction to me. To avoid the aforementioned problem, I passed down a message library, or action object that has all of the actions on it, and dispatch. It's all I need!

Sure, action creators are "unnecessary" - you can always declare action objects and action types directly inline:

    this.props.dispatch({type : "INCREMENT"});
Nothing's ever _forced_ you to use action creators, or declare your type constants separately.

However, we encourage use of action creators as a good practice. See my blog post "Idiomatic Redux: Why Use Action Creators?" [0] for some reasons, as well as the related Redux FAQ entry [1].

[0] http://blog.isquaredsoftware.com/2016/10/idiomatic-redux-why...

[1] https://redux.js.org/faq/code-structure#why-should-i-use-act...

Re: ReasonML – React as first intended

#169

Post by simplify »

kbenson wrote: post #158
simplify wrote: post #155

Earlier quoted context omitted.

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 m…

I'm still not sure I understand. Are you complaining that Reason's distribution is optimized for JavaScript developers?

Re: ReasonML – React as first intended

#170

Post by simplify »

JoshMnem wrote: post #165
simplify wrote: post #101

Earlier quoted context omitted.

Of all Facebook tech, this is the least "Facebook" of them all. ReasonML is a thin layer on top of OCaml, a language that's been around for decades. If Facebook one day abandons Reason, it would their loss more than anyone else's.

That doesn't really address the issue that the use of Facebook's software supports Facebook. The industry needs to pay more attention to the long-term results of its choices and actions.

I'm not sure what the connection is here. Is it because Facebook sponsored development of Reason? Should we consider not using anything that Facebook touches?

What if Facebook pays a developer to work on another popular library like Vue.js? Should we consider stop using Vue?

Post reply on HN