It's doubtful Facebook actually has any relevant patents to license (or revoke a license for) though. OCaml and JS themselves act as prior art for any conceivable thing you would patent for Reason.
Remember that copyright and patent law are separate things. If there are no actual patents, then Facebook's BSD + Patents grant just becomes a normal BSD license.
Oh please, Microsoft uses React in production. Skype app is built on React Native. The business value of a startup has little to do with the tech stack, by the way.
no - you didnt understand what I meant. if you are going to get acquired by a company that has a potential patent dispute (of any kind), then this license is dangerous.
Now, people will still use React - because its javascript and at the end of the day, you can rewrite your web stack faster.
Imagine if you have a React Native app already distributed, a Caffe2 ai pipeline in production... or if your logic is in Bucklescript. Much harder to move away if your acquiring company is in a dispute.
> Facebook ... grants to each recipient of the Software ... license under any Necessary Claims, to make, have made, use, sell, offer to sell, import, and otherwise transfer the Software.
This doesn't say that they're granting you a license to their patents, just their software. In fact, about patents they go beyond to say:
> ... no license is granted under Facebook’s rights in any patent claims that are infringed by (i) modifications
to the Software made by you or any third party or (ii) the Software in combination with any software or other technology.
IMO that's pretty clearly saying you don't actually have any license to their patents. Regarding the termination clause:
> The license granted hereunder will terminate....
It seems pretty clear the only license granted hereunder is the one to use the software; in other words if you sue FB for patent infringement you lose the right to use React/Reason.
Literally every lawyer who has looked at that license agrees that your interpretation is wrong.
Also, licenses like this have standard language; if you're even slightly familiar with how such language is interpreted, you'd realise that this represents two independent licenses to two different things, which terminate in different cases.
Also, Facebook has publically explained what the language means to them, and yes, that would be legally binding on them.
Plus:
> IMO that's pretty clearly saying you don't actually have any license to their patents.
Right, a document titled "additional grant of patent rights" that "grants to each recipient of the Software [...] a perpetual, worldwide, royalty-free, non-exclusive, irrevocable (subject to the termination provision below) license under any [claim of a patent owned by Facebook that is
necessarily infringed by the Software standing alone], isn't a grant of patent rights?
I'm sorry, but literally everything you've said is wrong. I highly suggest you read the analysis of an actual lawyer, such as the one I linked in the comment you're replying to, because you appear to have no clue what you're talking about.
The FAQ is not a binding contract. There is no reason to believe anything outside of the license itself, and the license sais you'll lose it if you file a patent infringement claim.
People lie. It happens. Facebook is not exactly the most noble company in the world.
I think they dropped the ball on it, quality-wise. But that's not a RN thing, that's a Skype team thing. Instagram works just fine and it runs a significant chunk of its code on RN. For that matter, so does Discord, which also runs great.
I hope Facebook stops using this soon...
So that we can stop having the same conversation about it every time anything happens regarding any of their open source projects.
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.
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.
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).
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.
It's better not to use software to force people to change their behavior. It's open source software. That means something. Or used to, at least. We've come from the ideals of the GPL down to defensive/active countermeasures of corporation vs corporation conflict.
In order to open the software to more people. The license here is a defensive move solely to limit damage.
Which is fine, I get it. There's nothing wrong with it. I'm just lamenting that Software Matters Now. At this point it's less about having an open culture of sharing and more "We own this."
The thing is, this patent grant wording seems to say that if you are using React, and Facebook infringes on your patents (software or otherwise), and you defend your patents by suing Facebook, you lose the right to use React. So I think it's good to be aware of that.
Which is effectively the same, since if you're now violating an additional patent by continuing to use React, you just gave Facebook additional munition to potentially use against you.
Right now, none, but I was talking about the potential of the thing, Facebook might apply for a React-related patent in the future and if you have an entirely React-based project, that say your company depends on, it's going to be a problem.
1) Anyone could apply for a patent on anything. IBM could apply for a patent on some core tech used in your own 100% home rolled web stack. I mean, I have no reason to think they will, but if we're just pulling stuff out of the air that might happen, that seems just as likely.
2) ...actually, more likely. Because a patent application must be filed within 1 year of public disclosure or its barred, and React has been out for years. So...
> Facebook might apply for a React-related patent in the future
Yeah, I'd prefer Facebook to declare to not participating in the software patent fiasco at all and to lobby for it not being allowed, but at present, my thinking is that it just seems like having the ability to EXPLICITLY revoke you a patent grant is actually worse than having an implicit one, since then it will probably would be harder to argue for Facebook that they have the ability to explicitly revoke something that is part of the license as a whole, but I accept that I might be wrong on this as IANAL.
They always have that power tho - technically an implicit grant in a license is very very weak. It's already had case-law that shows that it only applies in very very specific situations.
An explicit grant gives you much more power generally. Their ability to revoke is limited to specific situations and that's a reasonable tradeoff. It's still more rights than you have without the patent grant.
It absolutely does not say that. If there are patented works in React (and even FB has said they don’t know if there are) then the React code is still covered by the license.
Basically this whole topic is FUD (the Apache situation most people don’t actually under and just repeat incorrect information around).
Let’s say you remove the patents license, as most people here seem to want, what do you have?
The exact same situation as if you sued FB over patents and they revoked it that so many ppl are complaining about.
The license without the grant has an implicit grant anyhow. This is less strong than what they added: an explicit grant.
> It absolutely does not say that. If there are patented works in React (and even FB has said they don’t know if there are) then the React code is still covered by the license.
What I said was, if you sue Facebook for infringing on your patents then, by my reading, you lose the React software license. I didn't say that you lose the license if React contains patented works.
I saw the whole Linux v SCO thing so I hate FUD as much as the next guy, but I am literally going by the words in that document. I'm not adding or embellishing. Maybe my interpretation is wrong--I'm not a lawyer--but this is what I see when I read it.
> Let’s say you remove the patents license ... if you sued FB over patents and they revoked it that so many ppl are complaining about.
As I explained, my reading is that if Facebook removes the patent grant and you were to sue them, they could not revoke the React software license, which is what I believe they can do now.
Again, I know my reading may be wrong. But I am going by the exact wording of the patent grant.
Reason and BuckleScript are distributed together, but they are not the same project, and they have different licenses. If you use BuckleScript, you could simply choose to not use Reason.
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.
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.
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.
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/
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.
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 ?
> we're rather experienced at handling the social aspect required to make such project take off potentially
I would be really interested in hearing what you guys do in that regard. I think a lot of worthy open-source projects fail not on their merits, but for their execution of the social aspect.
I think ClojureScript's growth won't be impacted. Those folks do their own thing. There's a lot of innovative stuff in that community. Particularly fascinating watching the alternative approach to building good software by intentionally pursuing means other than static typing. That said, I tend to be on the static side of spectrum. There's a good amount of overlap between Reason and Elm. Elm may have a wider scope, is built for apps specifically, which I love. On the other hand, Reason is OCaml and OCaml is OCaml, which is great. Exciting times.
Nope I meant wider, with respect to what responsibilities they take on. Elm does more stuff. It's a language and framework/architecture for building apps. Reason is just a language, though with a more powerful type system, which perhaps is what you meant. Unlike Elm, it's meant to be paired with React or other frameworks to get the job done. It has a narrower scope because it does less stuff.
Elm has limited itself only to the scope of building applications in the browser; therefore, it's scope is much narrower. A general purpose language aims to be ergonomic for most use cases, which means supporting constructs that may not be necessary for e.g. front end development, but may be a huge quality of life enhancer for server side applications, hardware, etc.
It needs to be powerful and flexible enough to allow things like React or other frameworks to be built in it. Elm has only the Elm way, nothing more.
Perhaps scope wasn't the right word. I think we agree. If Reason is to be considered a general purpose language, then Elm is DSL for web apps. In that domain, it tries to be all you need, which is what my context of scope was. Reason is more suitable for probably all other domains.
That's not readable. But you're not supposed to write that kind of code normally. You only need that when you need to interop with anything in native JS land, and most of that interop is already done for you so you can just use existing bindings.
I think you'll find that any code that deals with foreign function interfaces and interop with the host environment is ugly in any language.
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.
Thanks for the support. It's hard though, isn't it? We get the same arguments on a weekly basis. Folks categorically refuse to check out OCaml because of its syntax. At one point the Reason creator decided to just go and satisfy the familiarity aspect through syntax change (still ongoing; the above snippet will get better too).
It scales easier to settle the debate by just fulfilling the demand rather than encountering each such argument and spend literally years debating about them.
I think fulfilling the demand is the right approach. Elixir seems like a good example to follow in that regard. I mean sure, readability is a function of familiarity, but it's also true that some languages have syntax that is more intuitive than others, which means they are easier to become familiar with. If a language can be human-friendly and approachable like ruby or python without compromising on semantics, then why not try to have it both ways?
Nah I'm the Reason janitor. I declined joining the Reason team because I thought joining messenger was a better way to help Reason move in directions products folk understood; it paid off =)
Anyways, since I'm basically doing Reason 24/7 I kinda consider myself to be on the team.
Agreed. I'd argue that the classic `for (int i = 0; i < n; i++)` loop isn't very readable unless you have seen for loops several times, in which case it is pretty easy to read.
I had almost forgotten about this! But, now that you mention it: yes! I remember being completely mystified by that thing when I first saw it. "Which part does what, when now?" Took a long time to read naturally without conscious deconstruction.
I encourage everyone who thinks that is unreadable to try APL and read https://news.ycombinator.com/item?id=13565743 , or even just try learning a completely different human language --- anything east-Asian is probably going to be initially completely unreadable to those familiar with English and other Latin-family languages.
Agreed, but that is quite readable to someone familiar with ML-based languages: Define a function get_internal which takes a map from objects of type 'a to type 'b, and an object of type 'a, and return a wrapper around objects of type 'b or "undefined"s. Action of get_internal is ""get" [@@bs.send]", which I don't recognize. I would guess it's a javascript interop syntax, which returns a function consistent with get_internal's type signature.
You're not constrained to use one-letter names for type variables, or to drop names of argument variables, but it turns out to be very handy, and it only takes reading a couple of hundred lines of code to get comfortable with this notation.
Most of that code (the part between the `:` and the `=`) is just the type annotation, which actually acts as documentation :)
My guess in this case is that get_internal is a function that receives two parameters (a map with keys of type `a` and values of type `b`, and a key of type `a`) and returns a value of type `b` or `undefined`, if the key is missing. The return is wrapped in an option type so you don't mix the `b`s with the `undefined`s.
That said, this is a very weird example to pick because the actual implementation of the function is not in this file. Assuming that in Reason the @@ means the same as in Ocaml, that `@@` is placeholder that tells the code preprocessor where to insert the actual code for the implementation of `get`. The actual logic for the get function would be in the preprocessor.
The `[@@bs.get]` attribute tells the BuckleScript compiler (Reason's JavaScript backend) to emit a JavaScript object 'get' operation wherever its corresponding function (in this case `get_internal`) is used.
These can be used to do the sort of metaprogramming that people used to do with camlp4. If you want to search more, the other keyword for googling would be "ppx".
It has no readability issue when you know the basic syntax
* "external" is an FFI declaration
* "get_internal" is the local symbol name
* ":" introduces the type signature, so "get_internal" is a function from a "map 'a 'b" (aka Map<A, B> in more C-style generics) and an 'a to a Js.undefined 'b
Agree, can someone explain me what does `ignore @@ context##drawImage sprite.img sx sy sw sh dx dy dw dh` mean? I coulnd't find `ignore` in Reason docs
Casting is a bit of a wrong term here, since that's not at all what happens. `ignore` is just a function that takes any argument and returns `()` (unit). That's useful because sometimes you want to throw away the result of the computation (usually a side effect), so you can just call `ignore` on it and get a `()` value out.
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).
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
> 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.
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. Reason removes the unfamiliarity part in order for them to get to the core of the research, which is still done in OCaml.
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
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.
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.
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.
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.
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...
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.
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!
This looks like it could be really awesome. A feature request if you don't mind: it'd be fantastic if you could allow users to export their previous conversations somewhere. Bonus points if it can be done automatically (real-time and/or on a backup schedule).
Wow, that's something I've been looking for for years, especially including xmpp.
Are you the author? It's hard to trust company logins to a binary blob, coming from a page with no information at all (no about/contact, empty github profile). Looks very fishy at the moment.
Last time I tried Eul it was very rough around the edges, and the fact it’s not using system controls for things like text entry means it’s probably going to take quite a while before it’s mature enough for regular use.
It's a lot more stable now. Controls are closer to system controls, although it's not ideal of course. It's going to be out of beta next month, so it won't take too long.
To be honest, hope you don't mind the criticism, but I think using custom controls was the wrong choice.
I dislike Slack/etc because they are non-native which means they are slow, and behave incorrectly. Eul will address the speed, but without the native controls it's unlikely to behave correctly.
Behaviour I'd be looking for to match system controls: text field editing, including shortcut keys, accessibility of controls using system accessibility attributes (which can be used for screenreaders, productivity apps and OS scripting), pervasive drag and drop support, proxy icons, copy/paste (with rich-text formatting where necessary).
There's a lot to do, much of which comes "for free" or at least "discounted" when using system controls. I really hope you prove me wrong and I wish you all the best with this. I may well end up using Eul anyway because of the speed, but I thought I'd try and provide my motivation for why using system controls is such a key part of my dislike for Electron apps.
Glad I'm not the only one. For a messaging app it does the whole messaging part pretty poorly. Typing often becomes very laggy. And this is on a fully loaded MBP. I have a feeling it has to do with rich links. Noticed that chats with a lot of them over time become harder to use.
How can you know something is unrelated and yet still be trying to track it down? Are you running two versions of the code, in production, where this live action comparison is possible? Because if not this response reeks of Google/Microsoft engineers who always shift the blame.
It's not the Reason sections; if you've seen BuckleScript's output you'd know that the JS artifacts are almost like hand-written code. I've checked almost every diff.
Not sure how much I can say, but the leak is somewhere in the subscriptions, which isn't in Reason. Ironically the goal is to convert that section to Reason so that refactoring can finally be done (I've left that part out of the blog post just in case). Messenger produced the grandfather of Flux; it's not the easiest thing to refactor.
Proving that a given error isn't caused by X is a very different matter from working out what does cause it, and even after that, fixing it is another matter again.
I really wish it didn't have any sort of logic around checking the user agent. I often spoof mine and it's annoying when messenger.com doesn't load because of it.
What's your actual browser? The most common cause I can think of would be if we think you have a newer browser than you do and serve you too-new code as a result. If that's the case, using an older version in the string might help.
Is there a reason you guys are doing UA sniffing instead of a Modernizr-esque strategy? Would it have too much of a runtime cost? Or is it just about syntax and serving a transpiled blob would make it bigger? Genuinely curious
We do this both for polyfills and for different compiled code in some cases. Since we need this on the first request (and care about perf on that first request), it's less practical to use JS to decide. User-Agent works well in practice.
You're correct. It performs terribly. On my 2016 macbook it takes 20.48 seconds just to load the interface from refresh according to Firefox devtools. Yes, a lot of this is network traffic. It's still terrible for a chat app. I have PS4 games that start in 20 seconds.
This is weird. I was skeptical at first, because I could have swore it wasn't this inefficient, but then I just went there and experienced similar results on a 2016 chromebook; 19.83 seconds.
Could it be all the separate CSS files they're linking?
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.
> 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.
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.
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.
We do contribute to upstream, and we've even hired a few renown OCamlers (can't say more atm, sorry). As a matter of fact I've kept a list of Reason's contributions, PRs or otherwise. I'll publish it in due time.
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 a look).
I'm a PureScript fan myself, but I like what reason is doing. There are a _lot_ of JS projects out there that would benefit from being converted to a language with a real type system, and it's good there are people approaching this problem from all sides.
EDIT: If anyone reading this hasn't tried a language with an OCaml or Haskell-based type system, consider giving it a shot. If you're just familiar with static type systems from languages like Java I promise you this will be a totally different experience.
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!
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). Using BuckleScript the OCaml-to-JS compiler, we compile to normal JS code with minimal runtime.
Reason isn't proprietary - it's essentially just a syntactical skin over OCaml to make it more appealing to JavaScript developers.
OCaml has some nice features - algebraic datatypes, complete type coverage, and pattern matching - that would be clunky to retrofit into JavaScript, hence this project.
One question: could you have an RSS feed set up for the blog?
Reason sounds interesting and something I'd like to stay up to date on until the time comes that I want to experiment with something and want to think of Reason, but without a feed to subscribe to I'm going to forget about it ;)
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.
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.
Oh wow I totally missed that. Read it as the same blog post. I jumped right past the date line without even seeing it. The URL's anchor tag didn't update when scrolling, which probably contributed.
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
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.
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!
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.
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.
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.
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?
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.)
Can you submit a bug report when this happens and email me a link to your Facebook profile so I can look into it? My email is the domain in my profile, replacing .com with @fb.com.
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.
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.
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.
https://github.com/facebook/reason/blob/master/PATENTS.txt