I went in for an interview recently for the react core team and the guy who interviewed me said Facebook was trying to edge away from open source. He mentioned it’s not worth it to them as much as it was before. Too much to maintain.
I manage the React Core team. That sounds wrong to me.
Facebook has not made any meaningful changes in its OSS strategy. It has always been the case that it takes energy to maintain projects in OSS and that for projects that are not used much by external folks it might not be worth the energy.
However, we are continuing to develop React with OSS as a first class citizen, doubling down on our investment in React Native in open source, and likely to still open source new projects as they make sense.
I think people on our team use VSCode, Sublime Text, and Vim. Almost all editors these days have good support for React, so we don't have any official one (nor do we feel the need to).
VSCode has particularly good integration with TypeScript, so perhaps choose it if you are otherwise undecided.
I’m not questioning typed JS, 100% behind that, we regrettably use flow, partly because React Native Typescript support wasn’t great (so I am told).
I guess I should have asked if FB recommended TS over flow nowadays
VSCode is also written in Typescript. I believe the teams work closely to ensure that new versions of TS are supported right away, and features are added to take advantage of them.
A shame, in an ideal world there would be the benefit of outside contributions that made less internal work needed, so overall would be a win for Facebook. But probably this is related to Atom itself being taken over by VSCode, the number of users (and maybe contributors) appears to be going down. I wonder if Atom Xray will ever come out https://github.com/atom/xray
That is only true if the outside contributes things that facebooks actually needs and if they are on a level of quality which facebooks wants. Often enough projects grow beyond the initial goal and at the end the maintainer is buried in meaningless work (for his own goals) and can't focus anymore on his own important things.
Good point. Although an OSS maintainer can be strict and refuse contribs on features they don't want to support. And by breaking down Nuclide, some individual packages like the Python debugger etc, probably can be very well defined and have a significant overlap between what they (Facebook) and other companies want, without much room for deviation. As opposed to say the general VCS support (they mostly want Mercurial that Facebook uses internally, whereas most outside users use git).
It still needs your requisite that contribs are of high quality.
Perfectly rational. Obviously they want to keep React closer to the chest as that directly impacts their core product. Things on the periphery are probably better left to others; I'd imagine it's more effective to donate dollars than hours for those kinds of projects.
I believe that their internal organisation has changed too. Product Infrastructure, who open sourced GraphQL, React, Relay, Flow, etc. was rolled into a core team, whose priorities are undoubtedly tied directly to internal a app metrics.
Good to hear that's still the case. I'm particularly worried about Flow, given that it's generally not trending well against TypeScript in terms of adoption, and because the team has never been super-engaged with the open source community. Would Facebook consider publicly clarifying intent to support less successful projects into the next 12 to 24 months?
I’m surprised to see an engineer admit this during an interview (assuming it is true, sophiebits has mentioned that it she doesn’t agree with this). Presumably this is the time when you talk about how much cool open source work you do?
An engineer at a big company is still just a dude or a gal. Not everyone in a multi-thousand person company will toe the company line or are in lock step.
Lying in the interview might bring them on but if they really want to do OSS and they don’t get that chance.. they’ll probably leave real soon, and then that’s wasted time onboarding someone.
I will really miss the remote development experience. It didn't get a lot of visibility because Nuclide's scope was much broader. It was also a pain to setup (compiling Watchman from source on Linux servers...) but after the initial setup it was way better than anything else out there (FUSE mounts, rmate, etc). Hopefully VSCode will get there soon.
I've been out of the React Native loop, but I seem to remember Nuclide was FB's canonical IDE for React Native and Hack - does that mean there's not an official way of using those environments any more?
In the past, a new platform required a new language which required a new IDE. Fortunately those days things less tied together. React Native is mostly using JavaScript which can be productively edited with a lot of editors and IDEs.
So the fact that Nuclide was there didn't mean that you had to use it (and the vast majority didn't) in order to write React Native.
I find this a little disingenuous, since React and React Native documentation rarely if ever feature code examples in any actual flavor of standard JavaScript and the 'blessed' way of writing React app involves quite a bit of embedded XML (JSX), which editors need to know how to deal with.
I don't want Flow to exactly die, but I wish Facebook have since love to running Flow on Windows, especially things like making Flow run faster and improving the VSCode plugin. Yeah maybe FB doesn't use any Windows machines, but it's claimed that Flow has full support for Windows. The reality is that Flow runs very very slow on Windows.
So in a way, I do object that Flow is not Typescript - I wish it had as much cross-platform viability as Typescript.
Nuclide has always had a ton of value for Facebook itself as we could build a lot of Facebook-specific integrations and ship a new version to all the developers every week. It's now the most used editor at Facebook.
This announcement is about the open source version of Nuclide, which has never received a lot of love and didn't have a lot of adoption.
Not necessarily. It may be that the current ecosystem works as well or better than Nuclide did, so there's no longer a positive value proposition there for continuing.
What I mean by remote code editing is not logging in the remote machine and use something like rmate, but having the entire project available in your ide and being able to edit, do source control stuff, even build and debug without logging on that machine. Nuclide provided all that (for FB dev servers)
This would mean things (compile, run, debug, etc) would be done on the local machine, not on the remote one. Not to mention the network lag if a huge codebase.
What I usually just do is open up a terminal in the FUSE mounted directory and an SSH session in another tab. Run everything on the remote machine and make edits on the local machine using any editor I want.
RE: building, compiling without login etc - I have a bunch of aliases that let me do that remotely with ssh. You're still "logging in" but don't need to deal with anything major.
I've found that FUSE/sshfs (at least on Mac) doesn't survive network reconnects. Switching WiFi networks, or even having the computer go to sleep, is enough to put it in a state where it can neither be used nor unmounted cleanly.
They probably are referring to something like SSHFS that allows you to mount remote filesystems over SSH using FUSE. I have tried this and it doesn't work well.
That's interesting, because it's the reason I do use vscode. I just want to work and it takes a whole of 5 minutes to setup and get going, on basically any OS I want. It can't be light weight and also include every feature everyone wants.
This is much needed. The extension has been broken for our team for a couple months now. No clear resolution. The Flow suggestions in an editor are basically unusable right now.
It would seem that https://github.com/atom/atom-languageclient is still under active development. Hopefully this means that the core Atom team will continue to work on language server features.
A fairly substantial PR was accepted recently to integrate the typescript server as the language client for atom-ide: https://github.com/atom/ide-typescript
It appears the project isn't dead, but there aren't any Facebook maintainers working on it (and there haven't been for nearly a year).
