Facebook retires Nuclide Atom extension | Hacker News Reader

Facebook retires Nuclide Atom extension

blog.atom.io

89 pointsmalmaud65 comments

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.

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.

It seems FB is underestimating the PR value that supporting open source brings. Microsoft, on the other hand, seems to understand it well.

It's an IDE whose only existence was due to their _wildly_ popular open source software, so they seem to understand it pretty well...

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.

No, our priorities for React and other libraries are not tied directly to internal app metrics.

What are the React project priorities tied to?

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 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.

So is there an "official" editor/IDE for React now? What's mostly used by the React team?

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.

Thanks for sharing. Curious if Nuclide is omitted because it's a given, or isn't used much internally now (https://mobile.twitter.com/amasad/status/1072930703065501696)

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.

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.

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

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.

Wait, so with Github taking complete responsibility for Atom, that means Atom and VSCode are now ultimately run/sponsored by the same company (MS)?

Yes, but under very different management.

Despite claims to the contrary, I fully anticipate the (slow) death of Atom.

Is Electron maintained separately from the Atom team?

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.

To be fair any modern IDE or text editor that supports JavaScript supports JSX

Kill 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?

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.

So, does this mean Facebook is adopting VS Code?

This can mean vscode gets remote code editing. That's nice

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.

What 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.

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.

Use emacs or vim. They work right out of the box.

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?

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.

I use 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.

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.

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.

Apparently not: https://mobile.twitter.com/amasad/status/1072930703065501696

Damn... :(

Nuclide 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.

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.

What 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.

I guess it's finally time to switch to VS Code then.

Ran horribly slow for me anyway, so no big loss.

Can 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).

Ok 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

Reply on news.ycombinator.com