Ran horribly slow for me anyway, so no big loss.
Facebook retires Nuclide Atom extension
31–40 of 67 posts
Re: Facebook retires Nuclide Atom extension
#32What are teams developing on flow recommended to use now at Facebook?
Re: Facebook retires Nuclide Atom extension
#33Earlier quoted context omitted.
Wanted to edit my comment, too late... 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)
Why not use FUSE?
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.
Re: Facebook retires Nuclide Atom extension
#34Earlier quoted context omitted.
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.
Building an app with react native at the moment, the team uses VSCode & WebStorm. Why would TypeScript be the deciding factor?
With a strongly typed codebase. VSC will advise with red squiggles straight away if a value gets a different type.
But it is another tool for large codebases that requires more work, like tests. If it's a small web project, it's probably overkill.
Re: Facebook retires Nuclide Atom extension
#35Earlier quoted context omitted.
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.
No, our priorities for React and other libraries are not tied directly to internal app metrics.
What are the React project priorities tied to?
Re: Facebook retires Nuclide Atom extension
#36What are teams developing on flow recommended to use now at Facebook?
Hopefully they invest in flow-for-vscode, which has the potential to reach parity with VSCode's amazing TS support: https://github.com/flowtype/flow-for-vscode
Re: Facebook retires Nuclide Atom extension
#37Earlier quoted context omitted.
Care to elaborate? A link works :)
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. https://github.com/libfuse/sshfs
Thanks. I tried libfuse in the past and I reached the same conclusion.
Re: Facebook retires Nuclide Atom extension
#38I 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’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.
Re: Facebook retires Nuclide Atom extension
#39I guess it's finally time to switch to VS Code then.
Re: Facebook retires Nuclide Atom extension
#40I'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.