Agreed. I would even call such initiative premature optimization, with unknown gain compared to just optimize the WebView component in the native shell if that's ever needed. More so for any new startup trying to enter the KMS space in general.
I don't think Notion need to worry about FB. I think Notion might need to be worried about the potential market saturation caused by how easy it will be for a small team of 3 to clone Notion (and all of its integration, API, and so on) on all platform perfectly in a weekends. At that point, it's not the technology bottleneck anymore but more so a battle over branding and minor UX improvement.
I think this is the key reason why going hybrid native with a lightweight WebView was needed at Notion. If there was a ProseMirror-like standard library for rich text editor available for crossplatform, with:
- Native editor for IOS
- Native editor for Android
- Native editor for Web
- Electron/Native desktop, etc...
These editor can share code via a clean architecture inspired state plugin hyerachy that's swappable (i.e, a shared provider that swap out state and data routing per platform). Then with metro or esbuild you can selectively prune the code branch. The UI can be done in RN-web if lazy or straight up native code. It doesn't matter at this level.
Then, anyone who wanted to clone Notion can consume this component in their RN app. However, this is against Notion interest atm afaik, since Notion must keeps its advantage (make it harder for people to clone Notion). I'd argue it will try to shutdown such an initiative until it found a better way to have an edge on these competitor (or maybe shift to a new market)