
Messenger.com Now 50% Converted to Reason - erwan
https://reasonml.github.io/community/blog/#messengercom-now-50-converted-to-reason
======
reustle
Looks like Reason has the same PATENTS license as React, for those wondering:

[https://github.com/facebook/reason/blob/master/PATENTS.txt](https://github.com/facebook/reason/blob/master/PATENTS.txt)

~~~
jeswin
This is one of the better patent grants out there. If a company intends to use
patents as a weapon, then Reason is not for them. Of course, if FB sues you
first and you counter sue, the grant does not terminate. Seems fair.

I wish they go one step further and say, if you sue or threaten to sue anyone
(not just FB) over patents, then the grant terminates automatically.

~~~
andreyf
By "use patents as a weapon" you mean "ever plan to enforce patents against
Facebook"? That's quite a stretch.

Still, folks more knowledgeable than me on this topic say it's not a big deal:
[https://medium.com/@dwalsh.sdlr/react-facebook-and-the-
revok...](https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revokable-
patent-license-why-its-a-paper-25c40c50b562)

~~~
namelost
Many people around these parts reject software patents as immoral, because
software is just applied mathematics and mathematics should not be patentable.

So yes, any use of a software patent offensively is malicious.

~~~
setzer22
Software can ve very far from mathematics. Your argument applies to
algorithms, but personally I don't think that React falls under the category
of algorithms (it _may_ use algorithms, though).

------
sotojuan
I've heard that Reason is essentially what Jordan Walke (React creator) was
trying to make with React. Maybe that's wrong, but he's the head of this
project and it looks great. Also props to FB engineering for having faith in
him with React and this.

Wondering if Reason will take off and what it will mean for languages like Elm
or ClojureScript.

~~~
chenglou
Yes, the first prototype of React was written in SML; we then moved onto
OCaml.

Jordan transcribed the prototype into JS for adoption; the SML version of
React, however great it might be, would have died in obscurity. The Reason
project's biggest goal is to show that OCaml is actually a viable, incremental
and familiar-looking choice. We've been promoting this a lot but I guess one
blog post and testimonial helps way more.

There's inevitably gonna be a bit of doubt at the viability of Reason at
first; but to make an argument from authority: Jordan and the team made
ReactJS take off even though everyone hated it at first (browse the first
HN/Reddit threads; they weren't rosy). I was there to witness it too. I'd like
to say we're rather experienced at handling the social aspect required to make
such project take off potentially, at least. Technically speaking, deferring
to OCaml is a safe bet.

What it means for Elm/ClojureScript: [https://reasonml.github.io/guide/what-
and-why#dont-like-reas...](https://reasonml.github.io/guide/what-and-why#dont-
like-reason)

We've explicitly listed Elm & ClojureScript on our Why page as good
alternatives to check. I've personally used both. The world is big enough for
more of such languages.

~~~
agumonkey
Hold on, what's the history of react ? and why sml ? Note that I love SML, I'm
just extremely surprised about the whole thing.

~~~
chenglou
Honestly I believe modeling such thing in JS as an initial iteration would
have drastically changed what ReactJS is today, and likely for the worse. No
proof of that, aside from the fact that iterating it in SML gave the rather
paradigm-shifting ReactJS we know today.

Can't speak for Jordan but I'm guessing that the answer is "it just felt
right". So you can consider ReactJS as a manual program extraction from SML.

I'm not sure whether the original one was ever fully finished. I think there
was a blocker from the React reconciler that SML couldn't solve in its type
system? It needed GADT and existential, which is why he moved onto OCaml.
Related:
[https://drup.github.io/2016/08/02/difflists/](https://drup.github.io/2016/08/02/difflists/)

So in a sense, we knew for a while now that ML would work out, somewhat
demonstrated by the real-world usage of React. The technical merits are there;
the social ones, definitely not. Thus Reason, which you can view as ReactJS
finally going back to its root through ReasonReact, and with the social aspect
properly being worked on.

~~~
agumonkey
Anything else that started as an sml project ? was react always a Fb project
or was it a personal thing from Jordan that caught the eye of a Fb manager ?

~~~
chenglou
Not that I'm aware of. Though it'll be a shame if React is a one-off. Can't
comment on the rest.

~~~
agumonkey
Thanks nonetheless

------
Xeoncross
> external get_internal : map 'a 'b => 'a => Js.undefined 'b = "get"
> [@@bs.send];

I like languages that are readable. This is starting to look like codegolf.
[https://github.com/reasonml-community/reason-react-hacker-
ne...](https://github.com/reasonml-community/reason-react-hacker-
news/blob/master/src/JSMap.re)

~~~
mej10
readability is a function of familiarity

EDIT:

Sorry, I just don't like when people share shallow and negative thoughts about
projects that take away from meaningful discussion.

Why is the OP comment shallow? Because obviously _some_ people find it
readable which would suggest that it is familiarity that is the problem -- not
some universal quality of the language.

~~~
cgmg
Readability is determined by more than familiarity.

~~~
abiox
do you have examples in mind that are orthogonal to familiarity?

~~~
cgmg
Language design. Even if you're very familiar with Malbolge, other languages
are far more readable.

------
sargun
I'm really excited about reason. The front end community is adopting
functional programming (concepts) at breakneck speed. I think this opens us up
to more advanced type systems, and generative testing (property testing, say).

These are exciting times.

~~~
chenglou
Pretty much. The goal of Reason is to make some weighted compromises* in order
to allow folks (like you?) to have an easier time convincing your colleagues
that OCaml's a good bet, disregarding their past experiences with similar
languages. For example, being scarred by FP assignments back from university
is one of the top feedbacks. If we show that ReasonReact allows folks to write
apps just the same, plus a familiar syntax that makes the first tries easier,
then you yourself can skip over all these bikesheddings and help your
colleagues further.

* Having a different syntax isn't without cost for the existing OCaml community, but so far most have been very supportive

~~~
jnbiche
> being scarred by FP assignments back from university is one of the top
> feedbacks

It's funny, seeing awesome FP assignments in SML and OCaml is one of the few
things that makes me really want to go back and do a computer science degree.
Alas, it seems like functional languages are disappearing from universities
one by one these days, only to be replaced by Python or Java.

~~~
chenglou
You (and I) are definitely in the minority here. "Go back and do a computer
science degree" is probably the opposite wish of lots of software engineers,
in terms of quantity.

From what I know, there are at least three classes in some universities
(forgot the names) whose professors/TAs told me they were teaching Reason to
decent success. Reason's also used in this users study:
[https://arxiv.org/pdf/1708.07583.pdf](https://arxiv.org/pdf/1708.07583.pdf).
Reason removes the unfamiliarity part in order for them to get to the core of
the research, which is still done in OCaml.

Don't lose hope! =)

------
arianvanp
It fills my heart with joy that the javascript community is adopting so many
functional paradigms and languages.

I come from a heavy haskell background, and don't have a lot of ML experience
so gave been betting on Purescript recently. But reason seems really nice.
Good luck with the port! A success for Functional Programming

------
radium3d
I just discovered messenger lite after uninstalling the main bloated battery
sucking messenger app and I'm sad they chose not to release it in my country.
It's fantastic! Also messenger.com really needs a lite browser app version for
phones and to improve their browser version of Facebook. They're really out of
the loop in my opinion. Since removing all Facebook apps, including instagram
and going to browser app only I've increased my battery life significantly.

------
skybrian
Based on the roadmap [1], they are about to change function call syntax to be
more like JavaScript. It seems like good stuff, but beware unstable language.

[1]
[https://reasonml.github.io/community/roadmap](https://reasonml.github.io/community/roadmap)

~~~
chenglou
The transition will be seamless and already planned, no worries.

Btw, for more justification on the syntax change, I've written a short answer
here:
[https://www.reddit.com/r/reasonml/comments/6v2olv/new_syntax...](https://www.reddit.com/r/reasonml/comments/6v2olv/new_syntax_after_pr_1299/dly4aa7/)

------
danpalmer
Over the last 8 months or so I've found Messenger.com get slower and less
stable. Killing browsers or tab processes, or having to refresh the page
because it's become unresponsive, has become more and more common.

This could well be completely unrelated, but it has been one of the driving
factors to me moving more to WhatsApp's web interface.

~~~
amedvednikov
Try out eul:

[https://eul.im](https://eul.im)

It's a native desktop client for Skype, Slack, Facebook, WhatsApp and many
others. It's only 4 MB, it has minimal CPU usage, and it can handle hundreds
of thousands of messages without lag.

Facebook support is coming tomorrow, WhatsApp is going to be supported next
week.

~~~
ComputerGuru
Interesting find. It opens an embedded browser window to OAth with Slack, but
after that closes nothing happens to the main window (i.e. the account never
gets added).

Incredible how it has a seemingly from-scratch cross-platform UI without
framework bloat; but it doesn't seem to work...

~~~
amedvednikov
It should work. Right now there can be a ~10 second delay for very large Slack
teams.

If you still get nothing after 10 seconds, could you please submit a bug
report via the built-in '?' form? If it's a public team, please include the
URL.

Thanks

~~~
lifty
I am having the same issue. Once I log in to Slack nothing happens in the main
window. My team is very small. I submitted a bug report as advised. Thanks for
the nice work!

~~~
amedvednikov
This has been fixed in v0.22. Can you try again?

------
microcolonel
For those wondering, Reason is basically transpiled to very similar OCaml,
with some focus on platforms like the web. I think some folks at Facebook
might be interested in Reason becoming to them as Java is to Google.

~~~
hoppelhase
The site states

> Powerful, safe type inference means you rarely have to annotate types, but
> everything gets checked for you.

Why did they create a new language? Isn't this what they made Flow for? Or
does Flow rely heavily on annotations? I did not follow up the development of
Facebook's projects recently. This is the first time I have heard of that.

~~~
chenglou
Ocaml's two decades old. We're doing the very opposite of inventing a new
language. I'm on the team and I personally am not capable of creating a
language (not to mention recreate an entire ecosystem?) at the same level as
OCaml.

~~~
cpeterso
Does the Reason team contribute code upstream to OCaml or is the language more
of a hard fork starting from OCaml?

~~~
yawaramin
Reason is basically a syntax transformation from a JavaScript-like syntax to
the classic OCaml syntax. Thus, they can sit on top of any existing OCaml
compiler (e.g. ocamlc, ocamlopt, BuckleScript) without having to fork
anything. The Reason team is working hard right now to build up a community
around ReasonReact. On top of their upstream contributions, they are
generating massive publicity and goodwill towards OCaml the language itself.

~~~
cpeterso
Cool. I didn't realize Reason was so loosely coupled from the underlying OCaml
compiler.

------
chenglou
Hello! Reason team member here.

With that kind of exposure comes some pretty negative snarks & unrelated
criticisms that are hard to counter in a post/tweet. I've left a few replies
on this thread but I'll still try my best to answer the questions here =) (but
before that, please do give [https://reasonml.github.io/guide/what-and-
why](https://reasonml.github.io/guide/what-and-why) a look).

~~~
kirillzubovsky
I have to admit this is the first time I've heard about Reason. Could you help
me understand the reason for it?

Is this because Microsoft has TypeScript, Apple has Swift, and so now Facebook
has Reason to keep all your application in your more/less proprietary format?

Further, if you already have React, then why not write everything in React and
then just extend it with the features you've built into Reason?

Pardon if these aren't clever questions, but I'd love to understand the big
selling points here. Thanks!

~~~
chenglou
Hey! It's weird: it's not the first time we get questions like yours and I'm
not sure where such confusion comes from! Reason and React are two things.
Reason's a syntax on top of OCaml, the programming language. ReactJS' a UI
library. Messenger.com _is_ written in React, lots of which are, specifically,
in ReasonReact, which is Reason bindings for ReactJS (the rest, plain
ReactJS).

Reason's open-source, as well as
ReasonReact([https://github.com/reasonml/reason-
react](https://github.com/reasonml/reason-react)). Using BuckleScript the
OCaml-to-JS compiler, we compile to normal JS code with minimal runtime.

Here's why we made it: [https://reasonml.github.io/guide/what-and-
why](https://reasonml.github.io/guide/what-and-why)

------
userbinator
I can offer a contrary datapoint: As someone who has never used this language
before, so has never seen its error messages either before nor after, it took
me far longer to parse and understand the "after" error message than the
"before"; I immediately saw _is not compatible_ and understood, while the more
verbose message doesn't have anywhere near the same clarity --- "But somewhere
wanted" made me do a reparse, and I'm still not completely sure what it's
trying to say, or what "somewhere" is. Even the "before" is unnecessarily
verbose to me --- I'd prefer something more like this:

    
    
        Error:%s:%d:%d-%d: incompatible type: expected %s, found %s
    

_Display the error-ing line(s), right inside the terminal._

 _Seeing that you 'd usually focus on a single error rather than trying to get
an overview of all errors_

IMHO these are not good changes --- chances are that many errors have a common
cause which may be far away, and fixing that will make them all disappear.
This encourages "code tunnel-vision", making small patches to "fix" each error
("the compiler says the error is here, so I must try to fix it here somehow"),
which in the long term can cause massive duplication and decrease the overall
quality.

Then again, I don't use JS so maybe the culture is very different, but the
"gradual increase of verboseness" seems to be a common trend among other
languages, that I strongly disagree with. Writing in six words ("We've found a
bug for you!") what could be expressed in one ("Error") does not help anyone
except possibly the most noobish of programmers, which one should hope to
learn and thereby advance from their level anyway; unless you treat your
developers as incapable of learning and disposable, it is counterproductive
--- or perhaps I should say un-Reason-able(!) --- to optimise for the extreme
beginner at the expense of the experienced.

/rant

~~~
chenglou
You're reading the wrong blog post btw; this is about messenger.com adoption.

Happy to discuss that other blog post somewhere else (discord.gg/reasonml)

~~~
jnbiche
To be fair, it's very hard to tell your blog posts are actually separate
posts, and not just headers for different sections. Yes, there's the dateline,
but otherwise it's indistinguishable from a longer, multi-part blog post.

------
rtpg
I've been using messenger.com to great effect for the past couple of months. I
can justify completely blocking facebook.com most of the time while still
being able to talk to people

Highly recommend

~~~
sotojuan
You can actually use Messenger with a deactivated Facebook account - pretty
cool if you just don't want to bother with Facebook at all.

~~~
rtpg
I'm not that woke yet, there's still some friends whose updates I like to see

Time boxing my FB usage at least stops the "scroll forever" behavior I used to
have

------
mykeliu
It's great that Messenger is being worked on. I wish they'd also work on
improving the UI instead of spending time tacking on half-baked features, but
that's probably a discussion for another time and place.

I _have_ noticed fairly recently that searching chat histories is much faster
and more reliable than it used to be, so that's a plus.

------
jakebasile
I'm a heavy Messenger user. Love the service. I mostly use it on my iPhone and
iPad and those apps work well (I wish they had SiriKit integration...). I use
the web interface when I have to, but I would really prefer a full native
client for macOS as their web client routinely stops getting notifications and
cannot make voice calls in Safari. The Windows 10 client is also painfully
underdeveloped but at least it's not bound up in a browser tab.

On topic, ML is a neat language family but I just couldn't get into it when I
tried F# back in the day. I'm a Clojure fanatic through and through but the
more projects using functional languages the better, even if it does use
static types!

~~~
parthdesai
On a related note, their App on Android is shit, utter shit. I have a budget
Moto G and my phone lagged till i uninstalled messenger. And on top of that,
Facebook won't let me access messenger from their mobile website. Firefox used
to work for me, but it doesn't anymore. Have to resort to mbasic.facebook.com.

So much for mission of connecting the entire world, Zuck.

~~~
pipeep
I've got an old 2013 Moto X, and I've recently started using Messenger Lite on
it. You'll likely need to manually install the APK, because it's not available
in the Play store for the US market, but it's definitely a lot faster.

[https://www.theverge.com/2017/5/18/15659414/facebook-
messeng...](https://www.theverge.com/2017/5/18/15659414/facebook-messenger-
lite-how-to-install)
[https://play.google.com/store/apps/details?id=com.facebook.m...](https://play.google.com/store/apps/details?id=com.facebook.mlite&hl=en)

------
tybit
Are there any plans for polishing the backend experience?

The progress for front end looks very promising, however as someone that likes
the look of Reason but isn't interested in front end I found getting into
Reason with the native toolchain was no easier than OCaml.

------
acidandy
Great to read such quick and informed replies by chenglou and spicyj from the
team.

------
jypepin
wow first time I hear about reason. So would that imply facebook would end up
ditching Flow for reason instead? Cause reason is basically a replacement for
JS+Flow right? Am I understanding this correctly?

------
EGreg
Can someone give an overview of what Reason accomplishes and why people would
use it? The github page doesn't do much in the way of that.

~~~
Ezku
Try giving this page a read: [https://reasonml.github.io/guide/what-and-
why/](https://reasonml.github.io/guide/what-and-why/)

------
sid-kap
Since I upgraded my google-chrome-stable version on my Linux machine to
60.0.3112.78, I've been getting a "Could not display composer" error where the
composer should be on Messenger.com. If someone on the Messenger team sees
this, could you please look into this issue? (I submitted this issue through
feedback but didn't hear back from anyone.)

~~~
knodi
So now they have 11 issues this year.

~~~
chenglou
That section's still in JS

------
AceJohnny2
Is this representative of Facebook's language direction? Away from (their
flavor of) PHP and towards OCaml/Reason?

~~~
firasd
Pretty sure it's only being used on the front-end. Even their more established
project React isn't used on the server.

~~~
chenglou
Right. Though the Ads thing the post mentions uses Reason natively (aka
ocamlopt). Not on the server, but as a tool for the front end.

------
mijoharas
Messenger.com is really buggy, I've had a `Could not display composer` error
message for months every time I open the page, so I can't type anything into
it. (just double checked and it still exists). Unfortunately, seeing how
slowly facebook responds to bug reports I haven't even bothered.

------
polskibus
I wonder what would be the quality improvement if they switched to Typescript
and TSX instead of Ocaml/Reason?

------
k__
I don't understand. This is just a landing page for the app and not an
alternative web interface

~~~
crummy
It is a web interface on desktop (and possibly some mobile platforms?)

~~~
k__
Ah okay. tried it on my android device and just got a link to the play store.

------
marczellm
I would really like to know about what tech stack the Windows 10 apps use.

~~~
harrygeez
Just curious -- why specifically? I personally never used the app.

~~~
marczellm
I'm using it and it's very slow and looks and behaves like some weird iOS
port.

------
rocky1138
Is this a good thing?

~~~
yawaramin
[https://www.reddit.com/r/programming/comments/6z6kje/half_of...](https://www.reddit.com/r/programming/comments/6z6kje/half_of_facebook_messenger_codebase_now_converted/dmt9pbv/?st=j7ewwxqv&sh=9244b99b)

------
systems
does messenger on the web and mobile, use the same code base, or are they
completely separate?

~~~
spicyj
They're separate.

------
stuaxo
Oh great, more JS frameworks.

------
nkkollaw
For a moment I got really scared that this was a new framework that everyone
was going to [have to] migrate to.

~~~
spicyj
I hope you don't ever feel like you _have to_ migrate to anything we release!
Even inside Facebook, there's flexibility in what tools you use and you're
free to choose any tools that get the job done.

~~~
nkkollaw
I'm still using Gulp ;-)

I meant more as the webdev community, everyone seems to love to throw a
ridiculous amount of time and money away by switching to a completely new
stack—for apparently no reason—every 6 months.

About 80% of the devs I know spend hours on tooling and force users to
download a ridiculous amount of JavaScript to use React with projects where
the dashboard is a list of messages sent via a contact form, where the only
functionality is to mark as read.

I React cool? Sure, and I use it. Do I have to use the same tech as the
biggest site in the world for my super-small projects—like most people do
because that's what you do? Probably not.

Am I stuck in the 90s and force a page refresh every time? Nope, but I spend
days learning something—and of course part of my job is learning new
things—but not 80% of the time, and it's not cool to make existing projects
obsolete after 6 months.

I just think the whole thing is getting a little big ridiculous.

It was probably more ranting than not about your project, I apologize :-)

BTW, if you work at Facebook, can you explain why creating Yarn vs. improving
NPM..? They seem to do the same exact thing in the same exact way from the
user point of view, with Yarn being a lot faster and with better command
naming.

