Eliminate the concept of pages

Any chance the DB version will allow eliminating the concept of pages altogether, therefore also eliminating the need to choose between block and page when adding content?

This is how Remnote does it, and it’s incredibly powerful and elegant. Everything is a block.

This makes it frictionless to rearrange the content hierarchy, without the need to move blocks between pages, or turn blocks into pages, and vice-versa.

Of course, one can always promote a certain block to be a “page” (or “document” in Remnote’s terminology), but all that does is tag it as such, so it can show as items in the sidebar. They’re still blocks.

I can’t see the benefit from having such distinction be hard coded. My understanding is that Pages exist to mimic the fact that blocks live in .md files. With DB, this limitation won’t be in place anymore.

PS: For those who aren’t very familiar with Remnote: although their current focus is on flashcards and spaced-repetition, the app is also a full featured wysiwyg outliner (the best I know). I’ve used it for years, and never cared for the flashcards feature (which I’m sure is probably great). The reason I want to move away from Remnote is that they’re not Open Source. This also greatly limits innovation and flexibility, especially in terms of plugin development (they allow the community to create plugins, but impose limitations to those that might replace paid features).

2 Likes

The distiction emerges because wikilinks and hashtags exist. But at least the DB version embeds pages in a way that makes they feel more integrated with the outliner UI: you can basically decide that “starting from this block, it is its own page”. For me it is the best approach.

1 Like

They can still exist in a block-only system. They can point to any block. Remnote does that.

Unless I misunderstood what you wrote?

I don’t know Remnote but in Logseq the main purpose of wikilinks and hashtags is to tag blocks and their children to populate Linked References and Queries accordingly. If this inheritance of tags wasn’t confined inside pages, wouldn’t we have a lot of loops to the point that everything tags everything?

Thanks for explaining!

How so? Could you give an example?


Perhaps I didn’t explain properly how a block-only approach works. Everything is a block, and every block can link to (or reference) any other block, but each block still has a “home” (for many people, that’s the journal pages, which are essentially blocks representing dates). I don’t see this leading to any potential loops, unless for some very specific queries?

You can have transclusion (or portals) to a block, allowing it to show in multiple locations, and I can see this possibility leading to loops for some very specific queries, but that should be unlikely and easily avoidable.

I understand the desire for further simplification, but Logseq’s current approach has its own advantages.

I use pages as the equivalent of folder-tags, that is, the …

… for each and every block.

New content is always added as blocks in the most relevant page, and then referenced elsewhere. This creates a node-edge system, where pages are the nodes and their content the edges, which works exceptionally well (that is, better than everything else I’ve tried) for me. The viability of this node-edge system relies on clear distinction between pages and blocks.

1 Like

Interesting. Do you mean you never link to pages? (i.e. in the graph they’re always “the root of a tree”?)

Links to pages are actually quite common in my workflow. An example:

  • [[Pineapple]] is a [tropical]([[the tropics]]) [[fruit]].

This block resides in the page (node) pineapple. As an edge, the block connects the nodes pineapple, the tropics and fruit. Retrieval of this block is possible through any one of the three nodes.

The name of each node is a noun/object. Edges denote connections among multiple nodes. This creates a web, not a tree. Whether this method of note-taking makes sense depends on your purpose.

Thanks for explaining.

Maybe I didn’t fully understand what you are describing, because I don’t understand why that can’t be represented in a blocks-only system.

Of course there are ways to specify, and differentiate between, different types of blocks. But why waste time and energy on this when we already have a nice, intuitive implementation?

And as @alex0 has pointed out, an all-block implementation could result in issues with, or confusion about, inheritance. With pages as distinct entities from blocks, inheritance is clear-cut and intuitive.

All-blocks might be better than pages-and-blocks for you. For some others it’s worse.

2 Likes

Check this page and try to imagine what it would look like with blocks only:

block - tag - page, it is very ingeniously structured; and shortly, without pages, the tags will have nowhere to go

2 Likes

Sorry, I see no reason why this can’t be implemented with a block-only approach…

1 Like

Yes, the block-only approach can perfectly emulate any other system (since it doesn’t dictate any overarching structure or logic).

In order to accommodate this alternative workflow I talk about, which I see as much more flexible and natural (not to mention it’s the most natural choice for a db-based app, which logseq will soon become).

Between two systems, one that favours a certain approach, and another that allows implementing any approach, I’ll always prefer the latter.

Note that, in theory I can emulate my desired block-only workflow within logseq’s current page/block logic, simply by using a single page for my entire graph. I never did it because I assume this would lead to performance issues, considering all of that would live in a single .md file.

Can you explain why so?

In a block-only system, tags are also blocks.

If I have:

  • Book 1 #book
  • Book 2 #book

Clicking on the tag #book simply opens up that block, which you can use for whatever you want, such as describing what a book is. And at the bottom of that block (when zoomed into it), you also see all references to it.

(The system is much more versatile than that. You can tag any block with any other block if you want.)

Just use {{embed [[page]]}} in a page to embed all the other page and then use this CSS to make them look like blocks and collapse them just like blocks:

To me that seems very awkward, which is why I hope the db version allows the more flexible block-only system.

If I have:

  • Block 1
  • Block 2
    – Block 2a
  • Block 3

If I decide to have Block 1 be a child of Block 2, I want to need to simply drag it there.

The solution you suggested wouldn’t allow such flexibility.

I don’t know why you think it doesn’t work. I do it all the time.

I might have misunderstood then. Sorry if that was the case. I thought the embedded page would show as a root block.

Regardless, this would still be a workaround.

I’d like logseq to properly support this, which is why I did the original comment in the db post.

You are saying that it can be implemented, and others are explaining why it should not be. For obvious reasons, that one can do something does not mean they should do that.

1 Like