Roam research

  • How good is Roam at doing what it tries to do? Can I make a (possibly more naive, but still 80/20) clone with raw Markdown or site building process along with Pelican?
  • A few complaints
    • I dont mind this particular content layout when taking notes, but it feels a little odd from a display perspective. Everything feels pretty jumbled and mixed up, and it’s apparent to a reader how they might navigate the mess effectively. To someone who’s taking the notes themselves it might not be so bad because they’re the ones who have written, they’re here to just add more. Prefer the (sub)heading and paragraph structure of typical Markdown files
      • which are virtually analogous (notice this test); paragraphs are just their list content, subheadings allow for nesting
    • Obviously hate the pricing of $30/month or $10k lifetime purchase of product. Absolutely ludicrous.
    • Hate not self hosted.
    • No Vim keybindings (not their fault, that’s more me, but still)
  • Have been thinking a lot about how I could build 80% of Roam’s features in a raw Markdown -> HTML processing system
    • Firstly, what exactly is VimWiki again? Does it do this? Do the wiki software handle creation of pages linked to (like the main roam feature)?
      • The difference between Roam and wiki is:
    • Currently use Pelican as a way of processing markdown and turning the content into nice HTML, with some of the additional structure like Jinja templating, handling tags, etc
      • How difficult would it be to add basic support for “”? So as Pelican is processing Markdown files, it builds up a dictionary of file -> [array of blocks], where we simply add to the array each time we come across reference of “file” in any MD file. That is, pretty much creates an edge list of “blocks” (piece of content, including its nested children) to inject at the end of the page itself under “references.” This actually doesn’t seem like it would be too difficult.
        • When rendering, could do exactly like roam and toss the whole blocks from other pages under the “references” header at the bottom of the page. Makes it easy to jump around
      • With this essentially big JSON object, we could also build the graph and render it as something like D3 FDG, making the nodes clickable and everything. Also not hard because the FDG is mostly boilerplate JS, and have complete control over the created graph structure. This would be brilliant.
      • Have total control over theme and templating. I can make my content look however I want, and put the pieces wherever I want. There’s a nice degree of flexibility here; question is, do I need it or will Road do it well enough.
    • Problems being static
      • One of the main issues I see here is the separation between having to write the content, and then view it separately in a browser as a website. This could break a fundamental feature of Roam, which is basically being able to fly around ideas and edit those ideas’ pages.
        • Don’t actually think that browsing around on the site to fish for ideas or talking points, and then having to go back to your editor to add something, is really that bad. Since the files are flat there’s no cding around, and you just pop in and make your edit. This is a simple solution if you don’t want to have to combine the view and editing functionality under one roof.
      • So you can either bring the editing to the browser (uh no), or you could bring the functionality to the editor (maybe?)
        • First, isn’t that just Vim wiki? Maybe it is maybe it isn’t
        • Could be as simple as being able to hover a and click or press a key to open that file in Vim. With nice graph management or fast rendering times, the references of files can be updated quickly and ready by the time the file is opened. This is pretty much the entirety of Roam’s novelty from what I can tell.
        • These things said I think Roam brings some nice things to the table, combining the editing and viewing experience all in one. I get a raw view in the block, and outside it renders the nice stuff the way it’s meant to be seen. It’s also snappy, and solves the interactivity issues I would experience on either end as mentioned above. The question becomes is that niceness worth the sacrifices mentioned in