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

131–140 of 190 posts

Re: ReasonML – React as first intended

#131

Post by senoroink »

hknd wrote: post #90
senoroink wrote: post #76

I'm still convinced that in the world of frontend development, Ember is the only framework that hasn't screwed over its users. My guess is that at Facebook there's too many smart people with differing opinions. Hence, we have to do an insane amount of research to construct the grab bag of pulling things together. And once that grab bag is complete, Facebook says "here's the new cool way to do it". Ember on the other…

You are comparing a view library (react) with a full framework (ember). Ofc you are supposed to pull things together with react, that's exactly what's intended. Compared to react, ember is: slow (1), more difficult to learn (2), has a much smaller community (3) and, most important aspect to me, has a huge footprint (4). (I'm not against ember, it might have some nice aspects and features. It was really nice during th…

I don't disagree with any of your points. React is faster. React has a larger community. All of it, I agree.

But. When it comes to productivity (actually building something and maintaining it), I can achieve way more in Ember.

Re: ReasonML – React as first intended

#132

Post by e12e »

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…

Not to mention a real compiler for building executables as well, should that be of interest.

Re: ReasonML – React as first intended

#133

Post by leshow »

> A while ago I've written a series of articles about the Elm language and they are not that different from each other.

The main difference IMO is that Elm is not really a general purpose language, you must use the Elm architecture to use it. It is only meant for frontend web applications.

Re: ReasonML – React as first intended

#134

Post by christophilus »

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

Yeah. The OCaml compiler is just crazy fast. It's like Go, but with a super nice functional language. The compiler seems to be doing a heck of a lot of heavy-lifting in such a small amount of time. I'd be interested in a talk about how it manages that, if anyone knows of one.

Re: ReasonML – React as first intended

#135

Post by e12e »

qop wrote: post #122
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…

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

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

Pfft. Run reasonml/ocaml on node, one event loop pr core, and use message passing for synchronisation / distributing work ;-)

I'm only half-joking.

Re: ReasonML – React as first intended

#136

Post by disease »

crimsonalucard wrote: post #93
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…

Well said. When we went from JavaScript to TypeScript we completely eliminated any errors we had associated with types. Then we turned on the noImplicitAny and strickNullChecks options and completely got rid of our 'x is not a function of y' and 'z is not defined' errors.

Re: ReasonML – React as first intended

#137

Post by loginx »

pgt wrote: post #128
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…

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...

Re: ReasonML – React as first intended

#138

Post by christophilus »

cies wrote: post #54
actsasbuffoon wrote: post #44

Earlier quoted context omitted.

Typescript, Redux, and Immutable.js work together as a pretty compelling stack, but they involve a fair bit of boilerplate compared to Elm or ReasonML. Elm provides type safety, immutable data structures, and state management in a very compact but readable way. In fact, Redux was strongly inspired by Elm's state management. All of these stacks are perfectly acceptable choices, so it comes down to a matter of personal…

> 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 like PureScript a whole lot. Something that ClojureScript and Reason seem to have on PureScript is really efficient persistent structures being the default, at least if I remember correctly. It's been a while, but I seem to recall PureScript giving me nice, functional syntax that under the hood did lots of native JS object / array copies.

Re: ReasonML – React as first intended

#139

Post by cdaringe »

DougBTX wrote: post #121
RussianCow wrote: post #108

Earlier quoted context omitted.

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.

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!

Re: ReasonML – React as first intended

#140

Post by justincormack »

joobus wrote: post #116
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…

> You're effectively required to grok all of JS, Reason, Bucklescript, and OCaml at once, and draw from all of them to piece together your code. This was my experience as well. Also, while it may theoretically be possible to compile native code with reason, the core focus of reasonml is javascript frontend development at the moment. > On the native side, since Reason's just a syntax transform: yes, they work with Rea…

Yeah the native code story has been deferred and using OCaml directly is currently far easier. This will change.
Post reply on HN