One of the devs here - totally true, our help docs and landing page don't really show half of what you can do. Help docs have a lot if you dig around though.
Bi-directional links are visible if you go to the What Links Here [0] section of a page. Notably though it doesn't include "unlinked references" (as Roam refers to it), which is quite useful.
You can still fish that up if you need to either from the UI's search or the search API, but in poking Roam that felt like a potential anti-feature around ambiguous terms, for instance with no clear way to flag a particular reference as not relevant to a term.
OK. I have. I do still think this. The interface differences — which I acknowledge, and are significant, and maybe that's worth the switch — haven't landed that way for me yet. But I just do not see any differences in functionality, and I'd have to give up _a lot_ to get the interface.
The live-edit interface is double-edged. It's a split-second more convenient to edit but easier to make mistakes and harder to revert anything more than a typo. Every time I miss a TODO I end up editing the TODO instead and breaking it.
There's nothing in here that's appreciably better than MW's raw editor. I can't enable multi-cursor editing in Roam, and I doubt it would ever be an option across nodes/list items.
If I run the window vertically (or especially push to 1/3 screen width) I lose all value from the right sidebar.
There seems to be a lot of functionality tucked into right-click menus that are inconsistent, _extremely_ context-sensitive, and in some cases require considerable dexterity that I don't have. (Right click the _bullet_ for formatting?) Why aren't they keyboard shortcuts for these functions?
Block editing and versioning are neat, but less powerful than MW templates — again, a feature for me, probably not for the target audience? It's easy to create new versions in blocks — too easy, because how do I remove one I've added by accident? Are whole pages versioned?
The inline reverse mentions/backlinks are nice, though I don't know what they're good for yet. I already easily take advantage of backlinks in MW without needing them cluttering the inline content, and I can already sketch out how to add them in MW using its API if I can better grok the value of surfacing them. Otherwise they're already — at most — a click and keyboard shortcut away.
Surfacing full-text search results in the live search bar drags the interface down immensely, and isn't what I want out of that bar _at all_. That's the only thing I can see that's net negative. Browser lag on the third letter of a four-letter word was measurable in seconds — just chill out and let me enter the word.
The on-page context filters are neat. That's a feature that would legit take some work to implement in MW.
Bottom line, if the hook is "embeddable backlinked content in a lightweight editor", I get that in a non-VisualEditor MediaWiki install, plus a superior text editor and an API. And the API — again, to me, acknowledging that if I don't see the value Roam adds to that model, then I guess I'm not the audience — is still by itself a total dealbreaker even before I get to not being _able_ to self-host, not seeing the backup/restore story, not having any offline editing options, and not having a useful mobile editing story.
question for anyone who may be interested - what would it take to implement those workflows with backlinks in MediaWiki - or is it just outright impossible due to current data structures used.
