Org-roam causes less complications than DenoteπŸ”—


Disclaimer: While I haven't understood the use-case of Denote, I'm sure it has one. This is just directed at the reader who is feeling attracted to Denote due to a perception of "simplicity".

Denote is … simple in the wrong way, in my opinion.

Aside: I like the author, but I disagree with his view of when to use Org, just because of a complex codebase. My plaintext has no reason not to be in Org markup!

(Even if all copies of org-mode.el in the world got deleted or something, it would still have no reason not to be in Org markup over any other! I could probably fork markdown-mode to understand Org syntax in a day, and then I'd once again be at least feature-par with markdown files, and so there's no reason to even "preventatively" stick with Markdown today.)

It sounds like to him, Org's complexity feels very present while editing an Org file, but it's not to me. I do not see anything but the text I'm wanting to write.

I was troubled by the introduction of a denote: link type, worrying how they would survive export, but I'm calmed since I read that Denote will also read regular id: links. Phew!

The strict filename structure creates a roadblock for me. I export many of my Org-roam files to a directory of HTML files, and I rely on the Org exporter to automatically resolve id: links and replace them with relative paths. Which means the filename of each org-roam file ends up determining the URL to each of my posts – good thing the filenames don't matter to org-roam! I wouldn't want the Denote format in the URL! With Denote I cannot just use org export as a drop-in solution. Now I must dig into the source code and hack it to work with Denote's limitations.

Now here's why I call it not-simple. I think simple software allows seamless composition with other software, instead of creating roadblocks!

Org-roam v2 is the most natural way I can see to implement a zettelkasten. I've thought so at least since 2015-05-20 (predating org-roam).

Most complaints I've seen have less to do with technical tradeoffs, and more to do with people not knowing what to do when they can do everything. They like Denote because its limitations lead to someone writing a manual explaining one correct usage, and I guess people who have not previously thought much about file-naming schemes perk up at the "hey, that's smart!" file naming scheme, and so they feel compelled to buy into it just to pay respect to beauty, or something.

One complaint about org-roam is potential desync between filename and #+TITLE. I'm not worried about that, because there is no filename, there is only #+TITLE. For the purpose of my homepage, I made a small command that auto-renames a file based on the title.

SQL is goodπŸ”—

The org-roam-db is a godsend sometimes. When I customize my export process, I'm able to query the database for all kinds of things, like,

  • I can add a backlinks section (discovering the backlinks requires a DB query!)
  • when there's a link somewhere to an external resource, and I happen to have a note about that resource, then transform that link into a link to the note (requires a DB query!)
  • give a CSS class to links based on the tags of the target note (requires a DB query!)

Sure, EmacsQL is janky sometimes. When it acts up or fails to compile, your org-roam system feels big, messy and fragile. But does a SQL dependency mean org-roam is overengineered?

Let me put it this way. Imagine making a zettelkasten system from scratch, a good one. You want the dream, you want it to take over your life, you want it to be useful beyond your wildest expectations. Isn't it immediately obvious that your system is gonna end up having a SQLite database at some point?

So it's great that someone already built it in. If they didn't, you'd have to get around to doing it yourself.

So you also skip the whole process where you eventually realize, "hey, what if we just base all the code around this SQL layer, refactor away the rest, and arrive at a beautifully simple design?!" That's exactly what org-roam is: "a database abstraction layer for Org-mode", quoting the source code.

(OK, the current org-roam codebase is hard to understand/hack, but it's on us to fix!)

What links here

Created (14 months ago)