Live data from Hacker News

Facebook retires Nuclide Atom extension

blog.atom.io

61–67 of 67 posts

Re: Facebook retires Nuclide Atom extension

#61
post #40

Earlier quoted context omitted.

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

Re: Facebook retires Nuclide Atom extension

#62
post #58
post #51

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.

Re: Facebook retires Nuclide Atom extension

#63

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

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.

Re: Facebook retires Nuclide Atom extension

#64
post #8

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.

Re: Facebook retires Nuclide Atom extension

#65

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

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

Re: Facebook retires Nuclide Atom extension

#66
post #52
post #48

Earlier quoted context omitted.

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

Re: Facebook retires Nuclide Atom extension

#67
post #8

Earlier quoted context omitted.

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.

Post reply on HN