I’ve been using Roam V2 for about a month now. After actually spending some time with the new system I really love it. It is much faster than the previous version when it comes to loading/indexing the notes at startup (it’s pretty-much instantaneous).
There is also a package called org-roam-ui that enables even better graphing functionality. The only thing I still don’t like too much is the backlinks buffer, but I don’t use it as much any more and I don’t miss it too much.
Anyway, it did take a while and some tweaking to get used to the new version, but it was worth it. The original post I wrote (below) was a rant caused by the frustration of /having/ to switch-up a familiar and effective workflow, just because a developer decided to change everything. But, I’ve since learned an useful lesson; sometimes it is important to defer to the wisdom of the developer, especially if it is a trusted one.
I really love Org Roam. I started using it recently and it has transformed the way I think about note taking and writing in general.
The principles behind it are nothing new, but they were new to me. So, I’m not entirely sure if its the software I’m in love with or the general methodology it reflects.
As software, though, its features are:
Inserting links to notes and finding notes is fast. I don’t really know of a faster way. It’s not only fast in the sense of the interface and backend but, since it uses the Zettelkasten philosophy, it’s also ‘mentally’ faster. You don’t have to think about directory-structures/paths, or things like categorization. You just think in terms of ‘concepts’ or ‘ideas’, org-roam does the rest. All the files are stored in one location, without subtrees (though, you can have these if you really want), so you are just adding to this collection, then creating links to other notes on the same level. It is so liberating to not have to worry about where to ‘store’ something. The org-roam database does all the storing and categorization you really need.
Nice integration with org-mode.
The ability to generate/integrate more academic modes of note-taking, via org-roam-bibtex. Using this, I can easily search through a .bib file of references, and either (a) insert a citation, or (b) generate a new ‘note’ where I can record thoughts on that book or article. The notes will then be associated with that citation and I can easily access them when referencing that work again. Within emacs, I can even view/markup/link the pdf of the citation, and have all those notes gathered under the same citation tag.
A ‘backlinks’ window/buffer. This is just a side panel that shows all the notes that link to the one you are currently viewing.
You can view a visual representation of the overall structure of your notes using the built-in ‘graph’ function, or the additional org-roam-server package. With org-roam-server, you can even click on the different nodes and they will open in your current buffer.
There are probably many more things I’m not mentioning here, but these are the things that stand out to me.
Anyway, recently, org-roam switched to ‘Version 2’. V2 is a complete rewrite/redesign of org-roam. The underlying principles are, of course, the same. But the implementation is quite different. It seems like the ‘ontology’ of the system has changed. Notes are no longer a collection of ‘files’ linked together using org-roam links, they are now a collection of ‘nodes’, linked together using org-mode’s ID system. A node can either be a file or a heading within a file.
So, the general design of the database has changed.
Aside from this, the backlinks buffer has also changed. It is built using something similar (the same?) to the magit buffer. Because of this, there are some extra ‘features’ (folding headings, etc.)
The ‘graph’ functionality is gone, as is the org-roam-server comparability. So, no more visual representations of all the notes (admittedly, this was a bit of a ‘novelty’ aspect of org-roam, but there is still something satisfying about watching your ‘network’ of notes and links grow and develop).
The ‘search’ interface also changed. In V1, results were organised with their ‘tags’ in parentheses at the start of the filename, now the tags are separated and to the right. They remind me of how org-mode displays tags.
Overall, the design changes means org-roam is even more integrated with org-mode, and therefore is easier for the developer to maintain.
I did try switching to V2 for a while this week. You have to covert all your pre-existing notes to the new format, since the V1 forms of metadata (tags, links, etc.) are obsolete. Luckily, they include a nice script for doing this with V2. It was relatively painless.
I have to say, though, I really didn’t like V2 in its default state. The new backlinks buffer seems overly complex now, and it opened horizontally by default. When you visit a link in it, it opens within the same window. In V1 the default behaviour was that it opened in the workspace you were already working in. The V1 backlinks buffer was more of its own thing, an extra little navigation pane for viewing links. Now, it just seems like a whole additional emacs window. I also didn’t like the new tag layout for the search.
The main metadata for a node (the ID) is included at the very top of the file, under the org-mode :PROPERTIES: tag. This does give the files a bit of a cleaner look, since the tag folds away nicely by default. However, when using Deft, the file-previews, which show the first lines of a file, are just populated with these ‘properties’ tags and their strings of unique-ids. As far as I’ve seen, this is quite easy to fix, you can just configure Deft to ignore that line, but it’s still a bunch of extra lines of configuration that I really didn’t want to have to insert.
Anyway, I know I could configure all of the new things (backlinks buffer, search previews, Deft previews) to look and behave more like I’m used to and I might end up having to do that. But, one of the main things stopping me from switching over to V2 is the general shift in design from ‘files’ to ‘nodes’.
As I said above, a great thing about org-roam is that it removes a lot of the ‘mental’ effort that goes into figuring out where notes should go, what categories they fall under, etc. Now that ‘nodes’ can be both files and headings, that whole ‘mental’ organisation-process gets re-introduced. How are you supposed to decide whether a ‘node’ should be a ‘heading’ or a separate ‘file’ of its own? You have to think up a whole new set of organisation criteria, not totally unlike the kind you might consider when thinking about directories. Doesn’t a ‘file’ node become something like a ‘directory’, with ‘headings’ nodes acting like files nested within it? When searching nodes, they all do appear on the same ‘level’, but there is still something disconcerting about it.
Either way, if I were to use V2, I would probaby never use the ‘heading-node’ functionality. But, if that is the case, then why switch to V2 at all? I would love if I didn’t have to. But, I have anxiety now that at some point in the future I will /have/ to switch. All future development and discussion will be around V2.
I’ve switched back to V1 for now, but I would love to find some better reasons to embrace V2. I didn’t give it much of a chance, so I’m probably missing something. If anyone out there is using it, I’d love to hear your thoughts (email@example.com).