Kill Flow while at it.
Facebook retires Nuclide Atom extension
51–60 of 67 posts
Re: Facebook retires Nuclide Atom extension
#52Can you update the title to add Atom IDE? Perhaps more important than Nuclide itself are the Atom IDE extensions which are also being retired. https://ide.atom.io/
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).
Re: Facebook retires Nuclide Atom extension
#53Earlier quoted context omitted.
Building an app with react native at the moment, the team uses VSCode & WebStorm. Why would TypeScript be the deciding factor?
VSCode is in particular great at TypeScript, in part because it's a Microsoft language and Microsoft IDE.
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.
Re: Facebook retires Nuclide Atom extension
#54I'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.
Re: Facebook retires Nuclide Atom extension
#55Wait, so with Github taking complete responsibility for Atom, that means Atom and VSCode are now ultimately run/sponsored by the same company (MS)?
Despite claims to the contrary, I fully anticipate the (slow) death of Atom.
Re: Facebook retires Nuclide Atom extension
#56What 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
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.
Re: Facebook retires Nuclide Atom extension
#57Earlier 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?
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.
Re: Facebook retires Nuclide Atom extension
#58Kill Flow while at it.
I’m a relatively happy user of flow. Is your objection to typed JavaScript or to the fact that flow is not Typescript?
Re: Facebook retires Nuclide Atom extension
#59Earlier quoted context omitted.
There's already multiple extensions that support this.
One of the reasons I don't use VSCode is because I just want to work, not spend a week hunting down extensions for features that should be included.
Use emacs or vim. They work right out of the box.