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

101–110 of 190 posts

Re: ReasonML – React as first intended

#101

Post by simplify »

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.

Re: ReasonML – React as first intended

#102

Post by lf-non »

qop wrote: post #7
nazka wrote: post #2

I really want to use ReasonML in one of my next projects but I always come back to two main questions. How much is it easy to use JS components like the Calendar of Airbnb for instance? And is it really easy to use BuckleScript? The "[%bs.raw ..." and others look hard to read/use. Is it the case or just a feeling? Is there someone who already tried it enough to know the answers?

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 parameters being supported only for inline functions, etc. don't make sense for a language targeting javascript.

It is interesting to note that F# took a lot of concepts from OCaml but stripped out functors, structural typing support etc. to adapt to dotnet. These adaptations are largely required because Microsoft does not treat F# as a first class citizen (at the same level as C#) and CLR is very explicitly geared towards object oriented languages. An occasional endorsement from Microsoft does not magically obliviate these deeply ingrained design decisions in F#.

When targeting javascript these adaptions become really pointless. As demonstrated by Microsoft's own TypeScript language, Structural typing can be quite useful for interop.

It would be really nice if F# was a first class citizen in dotnet world and javascript was a first class compilation target maintained by the F# core team adapting the language to javascript target in the same way it currently adapts to dotnet. However that is not the present day reality. However typescript, despite being a javascript superset (and inheriting all its warts) has a really flexible type system and lends itself well to functional programming (as demonstrated by Giulio Canti's fp-ts [1] project).

Unlike ReasonML, however, typescript's type system is not sound. I have written a more detailed comparision [2] of TS and ReasonML. I do actively use TypeScript for my day job and mostly love it, but I am much more optimistic about ReasonML once the ecosystem matures.

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#. So, while it is not that F# is not a great language, or that you can't build great apps with F#, however, as it currently stands, I don't see any compelling advantages of preferring F# over ReasonML, unless your backend is also F# and you want to (and can) share code between frontend and backend.

My familiarity with both F# and ReasonML is quite early stage (a few weeks each) and so would welcome any corrections.

---

[1] https://github.com/gcanti/fp-ts

[2] https://lorefnon.tech/2018/05/13/reasonml-vs-typescript-firs...

[3] https://reasonml.github.io/docs/en/what-and-why.html

Re: ReasonML – React as first intended

#103

Post by cdaringe »

RussianCow wrote: post #77
Kiro wrote: post #60

Earlier quoted context omitted.

It's covered in the article: "When using ReasonML, we don't need Redux anymore. ReactReason stateless components already come with the concept of a build in reducer, which is meant to take care of the problems Redux used to address."

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.

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.

Re: ReasonML – React as first intended

#104

Post by lsadam0 »

skosch wrote: post #99
lsadam0 wrote: post #96

Earlier quoted context omitted.

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.

I'm going to blame any communication breakdown on the fact that I know nothing about ReasonML or React-Reason. However, the point of having to store state so you have something to compare against strikes me as a really odd choice for the React-Reason library to introduce, since it deviates from the functionality of React itself.

I was curious enough to glance at the React-Reason doc's and they say that `shouldUpdate` is passed a record called `oldAndNewSelf: {oldSelf: self, newSelf: self}`. Does that not have what is needed to implement the method without extra storage? For example, in standard React `shouldComponentUpdate` is passed `nextProps` & `nextState`, and since the method is in context of the previous render, we have everything we need to make the comparison without explicitly taking extra steps to store previous/next.

Maybe we are saying the same thing in different ways, I seem to be pretty good at that :).

Re: ReasonML – React as first intended

#105

Post by jasim »

ReasonML is a big con.

It is clothed in ALGOL's syntax, but underneath it is a LISP with functions that can be stored, curried, passed around, and composed on top of one another. It doesn't have a Lisp-y syntax and thus no homoiconicity nor macros, but it does have PPX. (https://whitequark.org/blog/2014/04/16/a-guide-to-extension-...)

The biggest one that Reason pulls however is its syntax. ML based languages (Hope, Haskell, Miranda, F#, Elm, Purescript etc.) have historically used the ISWIM syntax (refer Peter Landin: The next 700 programming languages), which was designed to be similar to mathematical notation. Reason ignores this great tradition and brings ML to the bread-and-butter programmer with a syntax that is more ES6 than ES6 itself.

Reason is also the first language where the four major thoughts of PL design comes together.

It packs ML's type system, which lets you create user defined types on data, unlike Simula/C++/Java/C# which commingle user defined types and classes. Interestingly enough, Stroustrup had worked with Pascal the grand-old language of commercial programming, before he went on a great rage and wrote CFront/C++. Pascal was statically typed similar to how Reason/OCaml is. It allows you to define new types that work simply on the shape of the data without the ceremony of classes. But Pascal's type system at the time was quite limited - Stroustrup referred to it as strait-jacketed in HOPL II (Prof. Wirth had meant it only to be a language for teaching after all). Simula's types and classes however appealed to him, and that paved way for the class-based type system in statically typed object-oriented languages ever since.

But this doesn't mean that Reason doesn't have support for object-oriented programming. Reason is OCaml, and the O stands for "Objective", a nod to its object system that knowledgable people like avsm has averred to as fantastical.

The Lispy roots of Reason/OCaml makes it functional, which in simple term means value-based programming, primitives like fold and map defined with recursion, and linked-lists are used for almost everything, except when it isn't. Xavier Leroy, who is both the author of Coq and OCaml is a pragmatist - the OCaml compiler code is choke full of mutation and OCaml has strong support for imperative programming but tastefully cordoned with an explicit syntax.

It is a langauge that mixes imperative, procedural, object-oriented, and functional paradigms, sitting just at the confluence of the great PL traditions that includes ALGOL, Simula, LISP, Modula, ML, and ES6 (!). It is functional programming for the masses, finally delivered!

Re: ReasonML – React as first intended

#106

Post by orbifold »

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…

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 because it compiles to native code aswell. So you are able to write both the server and client code in the same language. The fact that reason has a dsl for react is just one of the killer arguments.

Re: ReasonML – React as first intended

#107

Post by sasmithjr »

Rapzid wrote: post #92
grayrest wrote: post #29

Earlier quoted context omitted.

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

I started looking at F# because of .NET Core, and I'm really liking it. I currently use Giraffe in a project, but I'll be switching it to Saturn soon (which uses Giraffe under the hood). And I've identified a potential use case for using Fable on some already written server-side code. Ionide is great, Neptune (F# debugger for VSCode) works well, and they both are maintained by the same person as Saturn.

Rider also works pretty well with F#, which is nice if you prefer the JetBrains IDEs.

Re: ReasonML – React as first intended

#108

Post by RussianCow »

cdaringe wrote: post #103
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.

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 to if you pass everything via props.

Re: ReasonML – React as first intended

#109

Post by xamuel »

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?

JS got a bad reputation from the pre-ES6 years. Before ES6 it really was a dumpster fire. It'll probably be many years before all that bad reputation can be redeemed as people slowly discover how good ES6 is.

Re: ReasonML – React as first intended

#110

Post by danpalmer »

orbifold wrote: post #106
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…

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.
Post reply on HN