Hacker News new | ask | show | jobs
by conaws 2341 days ago
Play in the Sandbox on the help db for an hour and see if you still think this.
2 comments

I did - it's slicker with better UX for sure, but technically what's different?
Blocks (paragraphs with subtrees) as first class objects with uids that can be pointed to.

Pages as filterable collections of backlinks from blocks.

A datalog engine for structured data via attributes.

Collaborative real time editing.

But you're mostly right - UX that comes from that is the thing that matters.

It looks like the main differences are the bidirectional links and the automated creation of those links.
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.

[0]: https://www.mediawiki.org/wiki/Help:What_links_here

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.

Might not be for you.

Most of benefit is in the new workflows you get via backlinks.

Lots of good feedback in their comment.

You told them to try it. They did, and wrote up feedback. Your reply, after you told them to do it, is dismissive.

A good deal of the feedback remains applicable even if you’re ‘sold’ on the benefit.

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.
Off the top of my head, probably the Backlinks API[1].

There's also ongoing experimental work toward making the parser's backlinks support more usable.[2]

[1]: https://www.mediawiki.org/wiki/API:Backlinks

[2]: https://www.mediawiki.org/wiki/Extension:AdvancedBacklinks