7 ms·
Facebook retires Nuclide Atom extension
- philosopherlawr 8y agoSo, does this mean Facebook is adopting VS Code?
- pbalau 8y agoThis can mean vscode gets remote code editing. That's nice
- bdcravens 8y agoThere's already multiple extensions that support this.
- reaperducer 8y agoOne 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.
- evv 8y agoWhat do you use instead? Personally I've found that VSCode has great out-of-the-box functionality for front-end/JS development, in comparison to Atom and SublimeText.
- borzale 8y agoThat'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.
- catacombs 8y agoUse emacs or vim. They work right out of the box.
- pbalau 8y agoWanted 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)
- akhilcacharya 8y agoWhy not use FUSE?
- pbalau 8y agoCare to elaborate? A link works :)
- ricketycricket 8y agoThey 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 https://github.com/libfuse/sshfs
- pbalau 8y agoThanks. I tried libfuse in the past and I reached the same conclusion.
- akhilcacharya 8y agoI use https://osxfuse.github.io/ https://osxfuse.github.io/ Big file changes are never going to be fast (even doing git operations is pretty slow) but remote interaction can be done via ssh in another tab.
- imbiased 8y agoThis 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.
- bdcravens 8y agoNot 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.
- underwater 8y agoApparently not: https://mobile.twitter.com/amasad/status/1072930703065501696 https://mobile.twitter.com/amasad/status/1072930703065501696
- pbalau 8y agoDamn... :(
- amasad 8y agoNuclide replaced FBIDE, the internal pre-setup web IDE that Facebook used. Having a pre-setup environment is a huge productivity boost: - dev env onboarding takes a minute instead of a week - employees can code "on the go" So predictably, if they get rid of Nuclide there needs to be an alternative and doubtful they've built something new because... why.
- vjeux 8y agoNuclide 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.
- anontechworker 8y agoI 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.
- imbiased 8y agoA 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 https://github.com/atom/xray
- PurpleRamen 8y agoThat 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.
- imbiased 8y agoGood 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.
- booleandilemma 8y agoIt seems FB is underestimating the PR value that supporting open source brings. Microsoft, on the other hand, seems to understand it well.
- imbiased 8y agoCan 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/ https://ide.atom.io/
- straws 8y agoIt would seem that https://github.com/atom/atom-languageclient 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.
- deleted 8y ago[deleted]
- maxyme 8y agoA fairly substantial PR was accepted recently to integrate the typescript server as the language client for atom-ide: https://github.com/atom/ide-typescript 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).
- imbiased 8y agoOk sorry, the atom-ide-ui package is dead. I’m not sure how the IDE features are split between the ui and individual language server packages
- s_m 8y agoI'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?
- vjeux 8y agoIn 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.
- pandeiro 8y agoI 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.
- alex504 8y agoTo be fair any modern IDE or text editor that supports JavaScript supports JSX
- k__ 8y agoRan horribly slow for me anyway, so no big loss.
- mirekrusin 8y agoWhat are teams developing on flow recommended to use now at Facebook?
- rattray 8y agoHopefully 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 https://github.com/flowtype/flow-for-vscode
- kangax 8y agoThis 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.
- twoheadedboy 8y agoI guess it's finally time to switch to VS Code then.
- jtolds 8y agoWait, so with Github taking complete responsibility for Atom, that means Atom and VSCode are now ultimately run/sponsored by the same company (MS)?
- mraison 8y agoI 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.
- dzonga 8y agoKill Flow while at it.
- haney 8y agoI’m a relatively happy user of flow. Is your objection to typed JavaScript or to the fact that flow is not Typescript?
- kumarharsh 8y agoI 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.