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).
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.
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?
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.
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 nodespineapple, 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.
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.
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.
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:
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.
