16 ms·

ReasonML – React as first intended

235 points by spking 8y ago

nazka 8y ago
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?
- rase- 8y ago
  Very easy to use components between JS react and ReasonML react. Docs describe this process well. As for the bucklescript macros, the most frequent ones are easy to get used to. bs.raw is a very last resort macro that is almost never used. Highly recommend giving ReasonML a try.
- girvo 8y ago
  If you’re willing to give up type safety it’s easy, it’s moderately harder if you want to stay in the type box
- thardus 8y ago
  ppx (like `[%bs.raw ...`) are indeed tricky. They mostly seem to be used around the FFI. My experience has been that if you're going to use JS components from within Reason, you just type the portions of the JS interface that you'll actually use, and that's pretty much always a subset. When you're outside the FFI, the language really shines in build speed and output. Support of ES Modules out of the box is nice too.
- qop 8y ago
  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.
  - Rapzid 8y ago
    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..
    - grayrest 8y ago
      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 https://github.com/SaturnFramework/Saturn
      - Rapzid 8y ago
        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 ;)
        sasmithjr 8y ago
        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.
- simplify 8y ago
  bs.raw is actually really easy to use, but it's not encouraged since it's mostly a stepping stone to "real" bindings. There is definitely a learning curve to JS bindings, but it pays off as you only have to learn them once.
- weavie 8y ago
  The reason I found JS interop confusing in Bucklescript is there are multiple ways to do it, so it wasn't obvious which was the right way. I think a lot of that is due to the fact that Js is ultimately a very different language from OCaml, and so to get the two to work together there were quite a large number of different scenarios to cater for. Once I got over that hump, it was all fairly simple.
bastawhiz 8y ago
As a bit of a meta point, I find it really distracting when authors make random sentences bold. What you believe to be important is not necessarily what I'll find important, and the added emphasis breaks my flow.
- seanwilson 8y ago
  I'm assuming it's more to help with skim reading.
  - posterboy 8y ago
    This is best done using the first sentence of a paragraph. Make a statement first and support it with the rest of the paragraph. At least that's a style judges use on verdicts. That way I can skim a long text easily enough. The opposite is having a conclusion at the end. That's used for opinions. A severe disagreement (not to say error) can be found faster if building an argument from the ground up. If your conclusion is somewhere in the middle and scattered all over the place, you might want to highlight that indeed. I prefer stream of conscioussness for quick notes, but bringing it into a proper format can help to refine the argument.
- jimmy1 8y ago
  Placing emphasis on things is commonplace. Sometimes it's in the form of a literary device such as hyperbole and sometimes it's done typographically. You shouldn't read it as being "random" but accept it as part of the works. The author clearly intended to draw attention to those sentences and given it is his or her article, it should be accepted as part of the article and the overall message attempting to be conveyed.
  - bastawhiz 8y ago
    I'm fine with it when there's one or two. Every paragraph does not need an emphasized sentence.
davedx 8y ago
I'm reminded of the Hacker News post that introduced me to React from David Nolen back in 2013, where he first introduced ClojureScript's take on React, Om: http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs http://swannodette.github.io/2013/12/17/the-future-of-javasc... Interested to take this for a spin.
- masklinn 8y ago
  > ClojureScript's take on React, Om His take on React in ClojureScript would probably be a better qualifier, there have been others. Reagent is a popular alternative take on a cljs React interface.
- grayrest 8y ago
  Om isn't so much a take on React as it is a take on the state management layer and it uses React under the covers. I believe it's been largely superseded by re-frame [1], which follows the Redux / TEA model. There is an Om Next and that's basically a take on Falcor / Relay using the Datomic pull syntax but I haven't heard that much about it outside the talks where he was announcing it. [1] https://github.com/Day8/re-frame/ https://github.com/Day8/re-frame/
  - Scarbutt 8y ago
    Why doesn't Clojurescript eliminates the need for something like Redux where Reason does? as mentioned in the article.
    - lilactown 8y ago
      IME using ClojureScript, you don't really need something like Redux/re-frame all that often either. Once you've handled local state and remote data dependencies, you have like 10% of your app state left. That can easily be solved with a global atom (a la re-frame) or something like the new React context API. Our understanding of how to handle state, remote data fetching, etc. has grown a lot over the last few years. Both the React & ClojureScript ecosystem went all-in on global state stores like Redux because, at the time, we thought we needed it. It felt like, if we needed a global state store for one thing, that it made more sense to just put everything in there for cohesiveness. It also was hard to determine up-front what was needed globally (mostly data IME) and what was only needed locally. It turns out that local state and something like apollo/relay/"suspense" for remote data solve the 80-90% case, and now we're getting better tools like React context to handle the last 10%. I don't think that Redux/re-frame is going away, but the number of apps that I would implement with them has gone way down over the years.
transfire 8y ago
But can it app?
- k__ 8y ago
  Pretty much, yes. https://dev.to/kayis/reason--react-native https://dev.to/kayis/reason--react-native
desireco42 8y ago
When I wanted to try Reason, tooling was just not there, coming from Elm, I was really put off by things being not more streamlined. I would keep an eye, as I like Ocaml etc, but at the moment Elm provides much better experience to me. Oh yes, big thing is that interop with Reason is way simpler then in Elm.
- simplify 8y ago
  The tooling has really come along since 6 months ago, FWIW. You can now get started by installing a single npm package[0], and editor support is quite good[1]. [0] https://reasonml.github.io/docs/en/quickstart-javascript.html https://reasonml.github.io/docs/en/quickstart-javascript.htm... [1] https://reasonml.github.io/docs/en/global-installation.html https://reasonml.github.io/docs/en/global-installation.html
  - desireco42 8y ago
    Let me try it again, I kind of decided to wait it out a little bit until things are better :) Thanks.
dmitriid 8y ago
I'm always confused by statements like "You don't need Redux, you have reducer components". Reducer components don't solve the problem of a centralized/shared/common state and interactions between components.
- yashafromrussia 8y ago
  Exactly my thought. It seems to me that it's just internal component state.. not application state
  - lilactown 8y ago
    I think that Redux provides two things that people like: 1. A pattern to organize their state in that was testable and repeatable 2. A way to maintain global app state without prop drilling I think that (1) is actually the reason that many people pick Redux in the first place. The amount of global, app-wide state in /most/ applications is fairly small IME. I think that the ReasonML team (which works semi-closely with the React team) is banking on things like Apollo, "suspense", the new context API and other things to further reduce the need for a global state store like Redux. The ReasonReact devs are trying to follow the principal of least power in providing something that solves (1) for component-level state, which solves the 80%, and wait for the rest of the ecosystem to shake out for the rest.
- boyswan 8y ago
  I thought this and was put off at first, but have come to the conclusion that you really don't need redux (I've used it thoroughly for years). We've been converting a large JS react app to Reason, and strongly typed props solves a lot of problems. Passing props down multiple children is no longer a burden, and you'll never have that "prop spreading madness". For anything that reaaally requires some sort of global state, you can use the new react context api. The only danger of writing in reasonml is spoiling javascript for yourself
  - cies 8y ago
    > The only danger of writing in reasonml is spoiling javascript for yourself Curing yourself :)
amenod 8y ago
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 because there were no standard of encapsulation, separation of concerns and similar. Why would someone who knows React want to switch to ReasonML?
- ch4s3 8y ago
  For the same/similar reasons, more or less. You get a great type system, merlin(a great analysis tool), faster compilation, all kinds of great compile time checks, and you can still use react.
  - mLuby 8y ago
    Those are all good things, but they aren't really the same reason. Parent describes JQuery to React as spaghetti code -> reasonable code, whereas React to ReasonML sounds like reasonable code -> reasonable code (with better tooling).
    - ch4s3 8y ago
      Yeah, I agree but would say reasonable code -> slightly more maintainable, reasonable code. Sure, the low hanging fruit is gone, but it's a similar reason. What I'm getting at is that you can write spaghetti React pretty easily, and people do. One of the core promises of using an ML to do react is that its harder to mess with state all over the app and wind up with a big bowl of spaghetti.
    - cies 8y ago
      JS code can be a pain to maintain (in the membrane... joke, sorry, I'll stop). And FB knows this. That's why they developed ReasonML: great JS interop, but much better maintenance story (than both JS and TS) because of the stronger typing discipline. On a large code base, increased maintainability can be a huge commercial advantage.
binnesjohn 8y ago
Please, keep a away from facebooks any technology. Sandbox, bad licencing and real bad conditions and terms. Privacy matters to me. Fact is, facebook do not provide it. They sell my data to most bidder.
JoshMnem 8y ago
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.
- kevmo314 8y ago
  One reason I don't use Elm and Purescript is that enforcing the purity of functions can be a pain. While pure functions are great in theory, sometimes having a non-pure function is much easier, and I'm okay with my codebase being 99% pure functions.
  - purescript 8y ago
    PureScript has a lenient FFI so you can choose to use 99% pure functions if you like (at your own risk).
  - JoshMnem 8y ago
    My point is more about ethics in tech than a specific language. I expected downvotes, but wish that the industry were different.
- scottmf 8y ago
  We can always fork these things if it comes down to it.
  - JoshMnem 8y ago
    If it were going to be forked, then it would already have been forked. The unethical nature of Facebook is not well-hidden.
- tfranco 8y ago
  Interesting... we covered ELM a few weeks ago: https://www.imaginarycloud.com/blog/elm-javascript-reinvented-1-overview/ https://www.imaginarycloud.com/blog/elm-javascript-reinvente...
k__ 8y ago
I'm still waiting for the async stuff they have planned.
deleted 8y ago
[deleted]
maxiepoo 8y ago
Does ReasonML have ML's nice module/functor system? That would be a huge advantage over elm.
- tonyhb 8y ago
  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.
  - zodiac 8y ago
    do you happen to have code online?
    - tonyhb 8y ago
      I just pushed to github. Here's the functor: https://github.com/tonyhb/reasonable-native-budget/blob/master/re/Shared/Form.re#L385 https://github.com/tonyhb/reasonable-native-budget/blob/mast... Here's the functor being applied: https://github.com/tonyhb/reasonable-native-budget/blob/1f694c7fa173fde7588ef8a2cb74b9a156b00497/re/NewEntry/NewExpense.re#L19 https://github.com/tonyhb/reasonable-native-budget/blob/1f69... Caveats: haven't committed some time and it was my first ReasonML/React Native app.
ocaml201627 8y ago
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?
- cies 8y ago
  I tend to disagree with: darn solid and elegant. It is easy to write flaky code in JS and rarely the language helps you to go for the elegant solution. On this front ReasonML brings huge value to the table.
- boyswan 8y ago
  Since moving from javascript to reason/ocaml, i'm genuinely nervous about refactoring Js now. Helpful compiler errors are literally life changing, and being able to handle options with Some/None means no more nasty undefined bugs. You can do a lot of funky things with javascript, and it's easy to convince yourself that because you can do it, you should do it. With reason I've found I can achieve pretty much anything with a far more concise set of tools, and I can't hack my way around problems - I'm forced to deal with them the correct way. Being forced to do things in a certain way has a massive benefit, and encourages consistency. You can look at 5 different javascript projects and each one of them will most likely be completely different.
- Can_Not 8y ago
  I love JavaScript, but also recognize when some other things are better (in the useful, pragmatic, non-edgy, non-trendy sense). Bucklescript/reasonML seem to be a way to use something better and keep what I like about JS without starting at zero in the job market or ecosystem. Specific example: if reasonML gets big enough then all react jobs are potentially reasonML jobs. In the bigger picture, purescript/elm/bucklescript/reasonML/clojurescript all have one problem. There's a lot of hype about how much better they are, but also the job market for them is nearly empty. This makes it difficult to justify spending a lot of time evaluating them before the jobs exist. I end up using flow or typescript in the short run.
- 8y ago
skosch 8y ago
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. Elm, on the other hand, is sloooow. * Type inference works really well. 9/10 times I don't even need to annotate anything and the compiler just knows. The only runtime errors I've ever run into were related to JS externals; the peace of mind knowing "if it compiles, it really works" is a game-changer even compared to TS. * Error messages are (for the most part) fantastic and really helpful. * Editor integration is solid, if a bit painful to set up at times. * The ability to drop in the occasional chunk of dirty `[%bs.raw {...}]` is nice, and a clear advantage over Elm. Cons: * JSX support is a joke. You have to wrap every string in `(ReasonReact.String("bla"))`. You have to wrap arrays in `(ReasonReact.array(...))`. Passing children to components is supposed to be easy but will make you rip your hair out for sure. Etc., etc. But I'm sure it'll get there eventually. * Refmt (the autoformatter) works pretty well but has lots of rough edges still. For instance, it removes all empty lines. * State management isn't the greatest. Passing down props works alright but often it's just easier to keep things in a central Redux-ish store, especially because every. little. thing. needs to be passed down explicitly for the type checker to work. * shouldComponentUpdate is hard-coded to `true` right now; there is no shallow comparison by default so everything always re-renders. Will be fixed medium- to long-term, I've been told. Workarounds exist but are pretty gnarly. Elm is much better at this. * The standard library is a mess. ReasonML has its own, but forget about it; you'll fall back on Belt (the BuckleScript one), which 8/10 times has what you need but then is split into "Belt" parts and "Js" parts for unknown reasons and isn't always complete (e.g. I constantly need to convert from lists to arrays and back, because some utility functions only exist for one of the two, also for no real reason). There is piping syntax (|> and |.) but it's never clear which one to use; sometimes the data goes in first, sometimes it goes in last. You get used to it eventually, but Elm is a land of milk and honey in comparison. * Lack of sugar: For instance, you'll end up making heavy use of option types, which are great obviously. Unfortunately there's no easy access syntax, so you end up with deeper and deeper levels of nested `Js.Option.getWithDefault()` and/or pattern matching. * Documentation is meh overall. ReasonML is well documented, but it's only a very thin layer on top of BuckleScript. It took me hours of trial and error to figure out JS interop in practice, setting up "comparators" just to create a `set(int)` etc. 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. I think this will take another year or two to iron out. Overall, I haven't found an option yet that truly works well. Elm is beautiful but slow and will drown you in boilerplate. ReasonML is fast and mighty but the UX isn't there yet. React+Redux+Typescript+Babel+Webpack have everything you need but it's a pain to set up and maintain, it's slow, and you can never trust it 100%. (Edit: I should note that both Elm and ReasonML have amazing communities with very active, friendly and responsive dev teams that really and truly want the best for their languages. I have huge respect for both and I would encourage anyone to give them a try, just don't expect a perfectly polished experience yet.)
cies 8y ago
You could even use ReasonML without React, and build complex web apps, by going an even more Elm-like route with: https://github.com/OvermindDL1/bucklescript-tea https://github.com/OvermindDL1/bucklescript-tea Here some demo code (in ReasonML, not OCaml): https://github.com/feluxe/bs-tea-starter-kit/blob/master/src/Demo.re https://github.com/feluxe/bs-tea-starter-kit/blob/master/src...
senoroink 8y ago
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 hand has happily given you the grab bag and has helped you support your production happens with the most professional, enterprise release structure. Disclosure: Used to do only frontend development with Ember but switched jobs and now use React/Ember
- hknd 8y ago
  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 the time when they released 1.0. But today I just think their are better options available) 1: https://auth0.com/blog/face-off-virtual-dom-vs-incremental-dom-vs-glimmer/ https://auth0.com/blog/face-off-virtual-dom-vs-incremental-d... 2: https://guides.emberjs.com/release/ https://guides.emberjs.com/release/ 3: https://github.com/facebook/react https://github.com/facebook/react vs https://github.com/emberjs/ember.js https://github.com/emberjs/ember.js 4: https://gist.github.com/Restuta/cda69e50a853aa64912d https://gist.github.com/Restuta/cda69e50a853aa64912d
  - senoroink 8y ago
    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.
    - boyswan 8y ago
      I'm only guessing that's because you have prior experience with Ember and are only starting to use react now. I find code written in ReasonML is 100x more maintainable than anything written in javascript, whether it's react or ember
danpalmer 8y ago
(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.
- orbifold 8y ago
  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.
  - danpalmer 8y ago
    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.
    - machiaweliczny 8y ago
      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.
pcx 8y ago
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.
jasim 8y ago
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-points-in-ocaml/ 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!
kbenson 8y ago
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 all the dependencies and make sure paths are correct, etc is a PITA, and a lot to ask of someone that's trying to evaluate whether it's worth incorporating in a new/existing project. Provide a precompiled download with Node, npm/yarn, etc, and all the modules you need preinstalled, (just set the correct env vars to tell it to use it, such at PATH and some lib path) and you drastically reduce the overhead to not just trying it out, but actually using it.
- pgt 8y ago
  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 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.
  - loginx 8y ago
    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.html https://reasonml.github.io/docs/en/quickstart-javascript.htm...
ioddly 8y ago
Somewhat OT, but is the origin story of React written down completely somewhere? I often see bits and pieces like how it was originally prototyped in ML, would like to know more.
leshow 8y ago
> 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.
- pyrale 8y ago
  http://package.elm-lang.org/packages/chrilves/elm-io/1.2.1hile http://package.elm-lang.org/packages/chrilves/elm-io/1.2.1hi... elm is a frontend language, you are not forced to use tea. You can bypass the `program` entry point and use monadic-style command chaining for instance.
  - leshow 8y ago
    Sorry on the late reply, but your URL fails and I'm not sure I follow what you're talking about. I enjoyed Elm quite a bit @ version 0.16, then they got rid of signals and forced everyone to use TEA. To say that they aren't forcing you to use it isn't true. AFAIK, you can't even publish a module that interfaces with javascript without Evan's permission.
arvinsim 8y ago
I got curious about ReasonML when I recently applied to a frontend job that strongly preferred candidates with ReasonML along with the standard React and Typescript requirement. I am using the approaching the mercenary approach to my career so I am interested if ReasonML would be a good long term bet. What do you guys think?

235 points by spking 8y ago

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?

rase- 8y ago
Very easy to use components between JS react and ReasonML react. Docs describe this process well. As for the bucklescript macros, the most frequent ones are easy to get used to. bs.raw is a very last resort macro that is almost never used. Highly recommend giving ReasonML a try.
girvo 8y ago
If you’re willing to give up type safety it’s easy, it’s moderately harder if you want to stay in the type box
thardus 8y ago
ppx (like `[%bs.raw ...`) are indeed tricky. They mostly seem to be used around the FFI. My experience has been that if you're going to use JS components from within Reason, you just type the portions of the JS interface that you'll actually use, and that's pretty much always a subset. When you're outside the FFI, the language really shines in build speed and output. Support of ES Modules out of the box is nice too.
qop 8y ago
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.
- Rapzid 8y ago
  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..
  - grayrest 8y ago
    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 https://github.com/SaturnFramework/Saturn
    - Rapzid 8y ago
      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 ;)
      - sasmithjr 8y ago
        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.
simplify 8y ago
bs.raw is actually really easy to use, but it's not encouraged since it's mostly a stepping stone to "real" bindings. There is definitely a learning curve to JS bindings, but it pays off as you only have to learn them once.
weavie 8y ago
The reason I found JS interop confusing in Bucklescript is there are multiple ways to do it, so it wasn't obvious which was the right way. I think a lot of that is due to the fact that Js is ultimately a very different language from OCaml, and so to get the two to work together there were quite a large number of different scenarios to cater for. Once I got over that hump, it was all fairly simple.

bastawhiz 8y ago

As a bit of a meta point, I find it really distracting when authors make random sentences bold. What you believe to be important is not necessarily what I'll find important, and the added emphasis breaks my flow.

seanwilson 8y ago
I'm assuming it's more to help with skim reading.
- posterboy 8y ago
  This is best done using the first sentence of a paragraph. Make a statement first and support it with the rest of the paragraph. At least that's a style judges use on verdicts. That way I can skim a long text easily enough. The opposite is having a conclusion at the end. That's used for opinions. A severe disagreement (not to say error) can be found faster if building an argument from the ground up. If your conclusion is somewhere in the middle and scattered all over the place, you might want to highlight that indeed. I prefer stream of conscioussness for quick notes, but bringing it into a proper format can help to refine the argument.
jimmy1 8y ago
Placing emphasis on things is commonplace. Sometimes it's in the form of a literary device such as hyperbole and sometimes it's done typographically. You shouldn't read it as being "random" but accept it as part of the works. The author clearly intended to draw attention to those sentences and given it is his or her article, it should be accepted as part of the article and the overall message attempting to be conveyed.
- bastawhiz 8y ago
  I'm fine with it when there's one or two. Every paragraph does not need an emphasized sentence.

davedx 8y ago

I'm reminded of the Hacker News post that introduced me to React from David Nolen back in 2013, where he first introduced ClojureScript's take on React, Om: http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs http://swannodette.github.io/2013/12/17/the-future-of-javasc... Interested to take this for a spin.

masklinn 8y ago
> ClojureScript's take on React, Om His take on React in ClojureScript would probably be a better qualifier, there have been others. Reagent is a popular alternative take on a cljs React interface.
grayrest 8y ago
Om isn't so much a take on React as it is a take on the state management layer and it uses React under the covers. I believe it's been largely superseded by re-frame [1], which follows the Redux / TEA model. There is an Om Next and that's basically a take on Falcor / Relay using the Datomic pull syntax but I haven't heard that much about it outside the talks where he was announcing it. [1] https://github.com/Day8/re-frame/ https://github.com/Day8/re-frame/
- Scarbutt 8y ago
  Why doesn't Clojurescript eliminates the need for something like Redux where Reason does? as mentioned in the article.
  - lilactown 8y ago
    IME using ClojureScript, you don't really need something like Redux/re-frame all that often either. Once you've handled local state and remote data dependencies, you have like 10% of your app state left. That can easily be solved with a global atom (a la re-frame) or something like the new React context API. Our understanding of how to handle state, remote data fetching, etc. has grown a lot over the last few years. Both the React & ClojureScript ecosystem went all-in on global state stores like Redux because, at the time, we thought we needed it. It felt like, if we needed a global state store for one thing, that it made more sense to just put everything in there for cohesiveness. It also was hard to determine up-front what was needed globally (mostly data IME) and what was only needed locally. It turns out that local state and something like apollo/relay/"suspense" for remote data solve the 80-90% case, and now we're getting better tools like React context to handle the last 10%. I don't think that Redux/re-frame is going away, but the number of apps that I would implement with them has gone way down over the years.

transfire 8y ago

But can it app?

k__ 8y ago
Pretty much, yes. https://dev.to/kayis/reason--react-native https://dev.to/kayis/reason--react-native

desireco42 8y ago

When I wanted to try Reason, tooling was just not there, coming from Elm, I was really put off by things being not more streamlined. I would keep an eye, as I like Ocaml etc, but at the moment Elm provides much better experience to me. Oh yes, big thing is that interop with Reason is way simpler then in Elm.

simplify 8y ago
The tooling has really come along since 6 months ago, FWIW. You can now get started by installing a single npm package[0], and editor support is quite good[1]. [0] https://reasonml.github.io/docs/en/quickstart-javascript.html https://reasonml.github.io/docs/en/quickstart-javascript.htm... [1] https://reasonml.github.io/docs/en/global-installation.html https://reasonml.github.io/docs/en/global-installation.html
- desireco42 8y ago
  Let me try it again, I kind of decided to wait it out a little bit until things are better :) Thanks.

dmitriid 8y ago

I'm always confused by statements like "You don't need Redux, you have reducer components". Reducer components don't solve the problem of a centralized/shared/common state and interactions between components.

yashafromrussia 8y ago
Exactly my thought. It seems to me that it's just internal component state.. not application state
- lilactown 8y ago
  I think that Redux provides two things that people like: 1. A pattern to organize their state in that was testable and repeatable 2. A way to maintain global app state without prop drilling I think that (1) is actually the reason that many people pick Redux in the first place. The amount of global, app-wide state in /most/ applications is fairly small IME. I think that the ReasonML team (which works semi-closely with the React team) is banking on things like Apollo, "suspense", the new context API and other things to further reduce the need for a global state store like Redux. The ReasonReact devs are trying to follow the principal of least power in providing something that solves (1) for component-level state, which solves the 80%, and wait for the rest of the ecosystem to shake out for the rest.
boyswan 8y ago
I thought this and was put off at first, but have come to the conclusion that you really don't need redux (I've used it thoroughly for years). We've been converting a large JS react app to Reason, and strongly typed props solves a lot of problems. Passing props down multiple children is no longer a burden, and you'll never have that "prop spreading madness". For anything that reaaally requires some sort of global state, you can use the new react context api. The only danger of writing in reasonml is spoiling javascript for yourself
- cies 8y ago
  > The only danger of writing in reasonml is spoiling javascript for yourself Curing yourself :)

amenod 8y ago

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 because there were no standard of encapsulation, separation of concerns and similar. Why would someone who knows React want to switch to ReasonML?

ch4s3 8y ago
For the same/similar reasons, more or less. You get a great type system, merlin(a great analysis tool), faster compilation, all kinds of great compile time checks, and you can still use react.
- mLuby 8y ago
  Those are all good things, but they aren't really the same reason. Parent describes JQuery to React as spaghetti code -> reasonable code, whereas React to ReasonML sounds like reasonable code -> reasonable code (with better tooling).
  - ch4s3 8y ago
    Yeah, I agree but would say reasonable code -> slightly more maintainable, reasonable code. Sure, the low hanging fruit is gone, but it's a similar reason. What I'm getting at is that you can write spaghetti React pretty easily, and people do. One of the core promises of using an ML to do react is that its harder to mess with state all over the app and wind up with a big bowl of spaghetti.
  - cies 8y ago
    JS code can be a pain to maintain (in the membrane... joke, sorry, I'll stop). And FB knows this. That's why they developed ReasonML: great JS interop, but much better maintenance story (than both JS and TS) because of the stronger typing discipline. On a large code base, increased maintainability can be a huge commercial advantage.

binnesjohn 8y ago

Please, keep a away from facebooks any technology. Sandbox, bad licencing and real bad conditions and terms. Privacy matters to me. Fact is, facebook do not provide it. They sell my data to most bidder.

JoshMnem 8y ago

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.

kevmo314 8y ago
One reason I don't use Elm and Purescript is that enforcing the purity of functions can be a pain. While pure functions are great in theory, sometimes having a non-pure function is much easier, and I'm okay with my codebase being 99% pure functions.
- purescript 8y ago
  PureScript has a lenient FFI so you can choose to use 99% pure functions if you like (at your own risk).
- JoshMnem 8y ago
  My point is more about ethics in tech than a specific language. I expected downvotes, but wish that the industry were different.
scottmf 8y ago
We can always fork these things if it comes down to it.
- JoshMnem 8y ago
  If it were going to be forked, then it would already have been forked. The unethical nature of Facebook is not well-hidden.
tfranco 8y ago
Interesting... we covered ELM a few weeks ago: https://www.imaginarycloud.com/blog/elm-javascript-reinvented-1-overview/ https://www.imaginarycloud.com/blog/elm-javascript-reinvente...

k__ 8y ago

I'm still waiting for the async stuff they have planned.

deleted 8y ago

[deleted]

maxiepoo 8y ago

Does ReasonML have ML's nice module/functor system? That would be a huge advantage over elm.

tonyhb 8y ago
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.
- zodiac 8y ago
  do you happen to have code online?
  - tonyhb 8y ago
    I just pushed to github. Here's the functor: https://github.com/tonyhb/reasonable-native-budget/blob/master/re/Shared/Form.re#L385 https://github.com/tonyhb/reasonable-native-budget/blob/mast... Here's the functor being applied: https://github.com/tonyhb/reasonable-native-budget/blob/1f694c7fa173fde7588ef8a2cb74b9a156b00497/re/NewEntry/NewExpense.re#L19 https://github.com/tonyhb/reasonable-native-budget/blob/1f69... Caveats: haven't committed some time and it was my first ReasonML/React Native app.

ocaml201627 8y ago

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?

cies 8y ago
I tend to disagree with: darn solid and elegant. It is easy to write flaky code in JS and rarely the language helps you to go for the elegant solution. On this front ReasonML brings huge value to the table.
boyswan 8y ago
Since moving from javascript to reason/ocaml, i'm genuinely nervous about refactoring Js now. Helpful compiler errors are literally life changing, and being able to handle options with Some/None means no more nasty undefined bugs. You can do a lot of funky things with javascript, and it's easy to convince yourself that because you can do it, you should do it. With reason I've found I can achieve pretty much anything with a far more concise set of tools, and I can't hack my way around problems - I'm forced to deal with them the correct way. Being forced to do things in a certain way has a massive benefit, and encourages consistency. You can look at 5 different javascript projects and each one of them will most likely be completely different.
Can_Not 8y ago
I love JavaScript, but also recognize when some other things are better (in the useful, pragmatic, non-edgy, non-trendy sense). Bucklescript/reasonML seem to be a way to use something better and keep what I like about JS without starting at zero in the job market or ecosystem. Specific example: if reasonML gets big enough then all react jobs are potentially reasonML jobs. In the bigger picture, purescript/elm/bucklescript/reasonML/clojurescript all have one problem. There's a lot of hype about how much better they are, but also the job market for them is nearly empty. This makes it difficult to justify spending a lot of time evaluating them before the jobs exist. I end up using flow or typescript in the short run.
8y ago

skosch 8y ago

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. Elm, on the other hand, is sloooow. * Type inference works really well. 9/10 times I don't even need to annotate anything and the compiler just knows. The only runtime errors I've ever run into were related to JS externals; the peace of mind knowing "if it compiles, it really works" is a game-changer even compared to TS. * Error messages are (for the most part) fantastic and really helpful. * Editor integration is solid, if a bit painful to set up at times. * The ability to drop in the occasional chunk of dirty `[%bs.raw {...}]` is nice, and a clear advantage over Elm. Cons: * JSX support is a joke. You have to wrap every string in `(ReasonReact.String("bla"))`. You have to wrap arrays in `(ReasonReact.array(...))`. Passing children to components is supposed to be easy but will make you rip your hair out for sure. Etc., etc. But I'm sure it'll get there eventually. * Refmt (the autoformatter) works pretty well but has lots of rough edges still. For instance, it removes all empty lines. * State management isn't the greatest. Passing down props works alright but often it's just easier to keep things in a central Redux-ish store, especially because every. little. thing. needs to be passed down explicitly for the type checker to work. * shouldComponentUpdate is hard-coded to `true` right now; there is no shallow comparison by default so everything always re-renders. Will be fixed medium- to long-term, I've been told. Workarounds exist but are pretty gnarly. Elm is much better at this. * The standard library is a mess. ReasonML has its own, but forget about it; you'll fall back on Belt (the BuckleScript one), which 8/10 times has what you need but then is split into "Belt" parts and "Js" parts for unknown reasons and isn't always complete (e.g. I constantly need to convert from lists to arrays and back, because some utility functions only exist for one of the two, also for no real reason). There is piping syntax (|> and |.) but it's never clear which one to use; sometimes the data goes in first, sometimes it goes in last. You get used to it eventually, but Elm is a land of milk and honey in comparison. * Lack of sugar: For instance, you'll end up making heavy use of option types, which are great obviously. Unfortunately there's no easy access syntax, so you end up with deeper and deeper levels of nested `Js.Option.getWithDefault()` and/or pattern matching. * Documentation is meh overall. ReasonML is well documented, but it's only a very thin layer on top of BuckleScript. It took me hours of trial and error to figure out JS interop in practice, setting up "comparators" just to create a `set(int)` etc. 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. I think this will take another year or two to iron out. Overall, I haven't found an option yet that truly works well. Elm is beautiful but slow and will drown you in boilerplate. ReasonML is fast and mighty but the UX isn't there yet. React+Redux+Typescript+Babel+Webpack have everything you need but it's a pain to set up and maintain, it's slow, and you can never trust it 100%. (Edit: I should note that both Elm and ReasonML have amazing communities with very active, friendly and responsive dev teams that really and truly want the best for their languages. I have huge respect for both and I would encourage anyone to give them a try, just don't expect a perfectly polished experience yet.)

cies 8y ago

You could even use ReasonML without React, and build complex web apps, by going an even more Elm-like route with: https://github.com/OvermindDL1/bucklescript-tea https://github.com/OvermindDL1/bucklescript-tea Here some demo code (in ReasonML, not OCaml): https://github.com/feluxe/bs-tea-starter-kit/blob/master/src/Demo.re https://github.com/feluxe/bs-tea-starter-kit/blob/master/src...

senoroink 8y ago

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 hand has happily given you the grab bag and has helped you support your production happens with the most professional, enterprise release structure. Disclosure: Used to do only frontend development with Ember but switched jobs and now use React/Ember

hknd 8y ago
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 the time when they released 1.0. But today I just think their are better options available) 1: https://auth0.com/blog/face-off-virtual-dom-vs-incremental-dom-vs-glimmer/ https://auth0.com/blog/face-off-virtual-dom-vs-incremental-d... 2: https://guides.emberjs.com/release/ https://guides.emberjs.com/release/ 3: https://github.com/facebook/react https://github.com/facebook/react vs https://github.com/emberjs/ember.js https://github.com/emberjs/ember.js 4: https://gist.github.com/Restuta/cda69e50a853aa64912d https://gist.github.com/Restuta/cda69e50a853aa64912d
- senoroink 8y ago
  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.
  - boyswan 8y ago
    I'm only guessing that's because you have prior experience with Ember and are only starting to use react now. I find code written in ReasonML is 100x more maintainable than anything written in javascript, whether it's react or ember

danpalmer 8y ago

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

orbifold 8y ago
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.
- danpalmer 8y ago
  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.
  - machiaweliczny 8y ago
    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.

pcx 8y ago

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.

jasim 8y ago

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-points-in-ocaml/ 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!

kbenson 8y ago

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 all the dependencies and make sure paths are correct, etc is a PITA, and a lot to ask of someone that's trying to evaluate whether it's worth incorporating in a new/existing project. Provide a precompiled download with Node, npm/yarn, etc, and all the modules you need preinstalled, (just set the correct env vars to tell it to use it, such at PATH and some lib path) and you drastically reduce the overhead to not just trying it out, but actually using it.

pgt 8y ago
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 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.
- loginx 8y ago
  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.html https://reasonml.github.io/docs/en/quickstart-javascript.htm...

ioddly 8y ago

Somewhat OT, but is the origin story of React written down completely somewhere? I often see bits and pieces like how it was originally prototyped in ML, would like to know more.

leshow 8y ago

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

pyrale 8y ago
http://package.elm-lang.org/packages/chrilves/elm-io/1.2.1hile http://package.elm-lang.org/packages/chrilves/elm-io/1.2.1hi... elm is a frontend language, you are not forced to use tea. You can bypass the `program` entry point and use monadic-style command chaining for instance.
- leshow 8y ago
  Sorry on the late reply, but your URL fails and I'm not sure I follow what you're talking about. I enjoyed Elm quite a bit @ version 0.16, then they got rid of signals and forced everyone to use TEA. To say that they aren't forcing you to use it isn't true. AFAIK, you can't even publish a module that interfaces with javascript without Evan's permission.

arvinsim 8y ago

I got curious about ReasonML when I recently applied to a frontend job that strongly preferred candidates with ReasonML along with the standard React and Typescript requirement. I am using the approaching the mercenary approach to my career so I am interested if ReasonML would be a good long term bet. What do you guys think?