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

91–100 of 190 posts

Re: ReasonML – React as first intended

#91

Post by danpalmer »

(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 Elm world from issues in JS. This is one of the reasons we've decided to choose it. It is much more than a prototype, this was something that factored into our decision making process heavily.

I'm sure there are great things about Reason, but I can't help but feel that the impact will be limited because it doesn't take a stronger viewpoint.

Re: ReasonML – React as first intended

#92

Post by Rapzid »

grayrest wrote: post #29
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..

It's in an early stage but the Saturn [1] project is aiming to compete with Phoenix more directly. The owner is a fairly prolific F# open source contributor and presented it at NYC F# last month but that's about all I know about it. [1] https://github.com/SaturnFramework/Saturn

That's fantastic! I gave F# a look right after MS announced dotnet was being open source and have been excited for it's "arrival" ever since. The pieces seem to be coming together, albeit very slowly..

* "Official" Cross platform support -> dotnet core FTW!

* Cross-IDE intellisense support -> Ionide, Check!

* Dotnet core support -> Check, finally(and make sure to set Ionide to use core)!

* F# to javascript cross compilation project with some traction -> Fable, check(Fable needs serious documentation help though)!

* A great framework competing head on with Phoenix -> Hopefully soon :)

The potential just seems sooo massive. Hopefully it blows up quicker than Haskell ;)

Re: ReasonML – React as first intended

#93

Post by crimsonalucard »

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…

Nobody mentioned the biggest reason. True functional programming coupled with type checking leads to more modular programs with significantly less bugs. I don't know about ReasonML, but a similar framework called ELM delivers Zero run time errors. Zero. Languages that eliminate entire classes of errors from type errors to run time errors should be the future evolution of programming languages. React+redux was only a small step in the right direction.

Re: ReasonML – React as first intended

#94

Post by oweiler »

ocaml201627 wrote: post #45

Throwaway since embarrassed to ask this: What is the knock against Javascript? Not trolling, besides lack of types it seems like a pretty darn solid, ubiquious, elegant/straightforward language to get things done. For people with strong opinions about this, what is so horrifying about Javascript to you?

It's not just the lack of static typing. It's weakly typed, so implicit conversions can happen when you don't expect them. A standard library which lacks the most basic functionality. Historical baggage(arguments, var, ...). Prototypical inheritance without proper language support. null vs. undefined. Async by default (that point may be debatable ;)).

Re: ReasonML – React as first intended

#95

Post by skosch »

rdrey wrote: post #80
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…

Thanks for this. I was looking for a thorough comparison with Elm. If you had to start a brand new project, which would you choose? Do you believe that struggling through the learning curve is worth it?

I don't know. Take a weekend and try out both, you'll learn what you like best. Both are great and frustrating at the same time, it depends on what you consider the bigger pain point. If you don't mind slow compile times, difficult JS interop, no JSX at all, lots of boilerplate, you can have code that is pure shining beauty and elegance (Elm) ... or you can have an absolute beast of an engine (Ocaml) covered in nasty duct tape with sticky residue and silver spraypaint on top (BS/ReasonML).

Give it two years though, and both will be amazing.

Re: ReasonML – React as first intended

#96

Post by lsadam0 »

skosch wrote: post #89
lsadam0 wrote: post #79

Earlier quoted context omitted.

> shouldComponentUpdate is hard-coded to `true` As in you can't override it? `shouldComponentUpdate` resolving to true in the absence of a custom method or PureComponent usage is standard React behavior: https://github.com/facebook/react/blob/7350358374036c0834ea6...

Well, you can (it's called `shouldUpdate` in ReasonML) but it doesn't work. You have to make it a reducerComponent, manually keep track of the previous props as if they were mutable state, and then do the comparison explicitly. This is from a conversation I had just a few days ago on the offical Discord chat.

There very well could be something I'm not understanding. What you are describing still sounds like standard React.JS behavior. Unless you use a PureComponent, or explicitly implement your own `shouldComponentUpdate` method, then `shouldComponentUpdate` will always resolve `true`.

Re: ReasonML – React as first intended

#97

Post by skosch »

bam365 wrote: post #88
boyswan wrote: post #65

Earlier quoted context omitted.

Also for your issue with deeply nested options, have a look at this https://medium.com/w3reality/working-with-option-using-maybe...

And if you don't want to implement the option monad yourself, there's the bs-abstract library, which contains a bunch of category theory definitions and implementations. I have gotten a lot of mileage out of it even in the small amount of ReasonML I have written. That plus ppx_let offers a pretty good monadic programming experience.

Those are both helpful suggestions, thanks guys. I've looked at some of those blog posts and github threads before but haven't tried it out.

In the end, however, it's more bolted-on pieces that should be part of the language if you ask me.

Re: ReasonML – React as first intended

#98

Post by pcx »

I've been a very heavy user of React with Flowtype. At some point, one would encounter the limitations of having just a type checker instead of a full-blown statically typed language. Also, the build story of the react ecosystem is not that great, especially with Webpack being so slow. There certainly are more issues that come with JS being JS. ReasonML looks like a good attempt to solve these problems. Certainly work checking out.

Re: ReasonML – React as first intended

#99

Post by skosch »

lsadam0 wrote: post #96
skosch wrote: post #89

Earlier quoted context omitted.

Well, you can (it's called `shouldUpdate` in ReasonML) but it doesn't work. You have to make it a reducerComponent, manually keep track of the previous props as if they were mutable state, and then do the comparison explicitly. This is from a conversation I had just a few days ago on the offical Discord chat.

There very well could be something I'm not understanding. What you are describing still sounds like standard React.JS behavior. Unless you use a PureComponent, or explicitly implement your own `shouldComponentUpdate` method, then `shouldComponentUpdate` will always resolve `true`.

You're not wrong; it's stateless components I'm talking about.

I should have been clearer: it'd be okay if `true` were simply the default, but the crux of the issue is that you can't even implement your own `shouldUpdate` as the function doesn't provide the previous props (like it does in React), so you have nothing to compare against – unless you laboriously store them yourself as state.

Re: ReasonML – React as first intended

#100

Post by tonyhb »

zodiac wrote: post #78
tonyhb wrote: post #42

Earlier quoted context omitted.

Yes it does. I had to build an autocomplete functor which generates an Autocomplete component for arbitrary types when I used ReasonML for my personal budgeting app.

do you happen to have code online?

I just pushed to github.

Here's the functor: https://github.com/tonyhb/reasonable-native-budget/blob/mast...

Here's the functor being applied: https://github.com/tonyhb/reasonable-native-budget/blob/1f69...

Caveats: haven't committed some time and it was my first ReasonML/React Native app.

Post reply on HN