One of the big reasons that Phosphor includes its own virtual DOM implementation, is because of React's patents clause. In the wake of the Apache foundation forbidding the "react+patents" license in dependencies, Facebook relicensed RocksDB as dual Apache/GPL. It's reasonable to assume that React will follow suit:
facebook/react#10191

Should that happen, what is the communities feedback on releasing a Phosphor 2.0 which does not include @phosphor/virtualdom and replaces all internal uses of that package with React?

If we do this, it will be the first external runtime dependency for Phosphor.

cc @ellisonbg @jasongrout @birdsarah @bollwyvl @jdetle @blink1073 @afshin @ian-r-rose @gnestor

I think this would be a really great thing! It would save @sccolbert a ton of work and open up the project to a lot more contributors from the React community. It would also allow bundled extensions to make use of open source React components. It could also make it more straight-forward to provide and consume JupyterLab UI components (e.g. dropdown, right-click menu, toolbar, etc.).

I also concur with Grant.

I agree with @gnestor as well

Even without the benefit broader community uptake or support, these gains are themselves nontrivial:

• 100% inter-compatibility guarantee when functional components are exported
• Free high-end implementation of virtual DOM whose ongoing development comes from upstream and is reliable

What components use a VDOM implementation right now? The menu bar, the tab bar, and the command palette?

One thing not addressed in the above notes: of all the VDOM implementations out there, why React specifically? For one, it clearly has the largest community adoption, and presumably the greatest momentum. It does seem like we can't make the vdom implementation swappable because of the hard dependency.

Thinking of embedding one of these phosphor components in another page: Are there any problems with having React as a dependency that interfere with other uses of React on a page? Does React require being a singleton, so there would need to be some sort of deduping and possible version conflicts if React is used elsewhere on the page?

What components use a VDOM implementation right now? The menu bar, the tab bar, and the command palette?

CommandPalette, Menu, MenuBar, and TabBar.

why React specifically

For all the reasons you mention.

Are there any problems with having React as a dependency that interfere with other uses of React on a page?

React would just need to be importable through whatever bundler you choose. We wouldn't be shipping our own copy.

React would just need to be importable through whatever bundler you choose. We wouldn't be shipping our own copy.

Oh right, I forgot you aren't distributing a webpack bundle.

Are there any problems with having React as a dependency that interfere with other uses of React on a page? Does React require being a singleton, so there would need to be some sort of deduping and possible version conflicts if React is used elsewhere on the page?

Yes, having more than 1 version of React loaded on a page can definitely cause issues. However, seeing as though we are using webpack to bundle everything together (including 3rd party extensions.), we should be able to dedupe and control which version of React is provided.

Anything that deduplicates effort seems like a good thing.

We have been building up a collection of ui elements that we call ui-kit that all rely on VDom. We have the intention to make it public, just haven't yet. This has been a decent amount of work and if there's a chance this means that we could move to something from a larger community effort that would be great.

It appears that Facebook has reached a no-op decision:

https://code.facebook.com/posts/112130496157735/explaining-react-s-license

I am very disheartened by this. The most painful part is that the post appears to clarify Facebook's intent to use the patent clause as a weapon in their overall patent strategy. I would summarize their position in this way, "if you are feeling uncomfortable with the react.js patent retaliation clause, then good, cause that is why it is there."

I will be working with NumFOCUS folks this week to figure out a path forward.

Yep. Saw that last night :(

It seems the wider community is also realizing they weren't paying close enough attention to the clause. https://news.ycombinator.com/item?id=15050841

https://medium.com/@raulk/if-youre-a-startup-you-should-not-use-react-reflecting-on-the-bsd-patents-license-b049d4a67dd2

In light of this, I think the safest way forward right now is to not adopt React in Phosphor.