Are you using Tana in parallel, too? If so, which is your workflow and the role of each tool on it?
Absolutely.
Pages is prehistoric extinct feature that should be buried together with bad performance and laggines. The proper and effortless way of moving on a graph is blocks. And for those who don’t need any changes, it could be as simple as #page tags, without changing any workflow.
To completely feel the ease of block usage, you could try Remnote. Still open source spirit of Logseq is by far superior over other benefits that Remnote gives. Thus building a second brain that relay on your own possibilities to connect your ideas in “block like” manner will be great advantage over “page-block” approach.
So when in a block I write [[Foo]] and then I click on it, what is supposed to happen?
2 Likes
I wonder once the Database Version (yeah, we all know there is a lot of work ongoing and it is nothing for the short-mid term) where the “page” ends up as an artifact. Could everything become a “block” since they have their own UID? This conversation between @Dario_DS and @Bas_Grolleman is epic one on that regard and other cool stuff, so check it out 
https://youtu.be/vp8tSQ5r_l4?si=DhyWQlxdVev5xdQc&t=1988
1 Like
I used to say “a page is a block with a name and it can be referenced with [[name]]”. This is still true with the DB version. Indeed as I said it’s the reference by name mechanism that leads to pages, not those being saved as Markdown/Org files. So I don’t see what people mean by saying merging pages and blocks. If they mean no more Markdown/Org files, this is the case with the DB version.
Instead in Tana there is no reference by name: you reference a node by searching for it in a dropdown menu. And I guess that node needs to exist before being referenced. Instead with Logseq’s reference by name you create the reference and a new page is created.
2 Likes
If you consider the concept of “Information Container” and as such, you add an ID to propperly identify it, then Page and Block could be the same or almost the same. Block ID vs Page ID (Page Name). In Tana the motto is “everything is a Node” (Logseq’s block), therefore any Node (Block) become a Page (Information Container) of other nested nodes.
Indeed, the existence of that Information Container as a file or not is just a media matter (fille-based or not).
How much legacy the new DB version will afford to keep the Markdown file-based structure alive?
Forget about Logseq using files as persistent storage, it is irrelevant. Just think of the syntax that is meant to be copy-pastable around… that syntax is mostly Markdown but it also has [[wikilinks]] and #hashtags to make references. That syntax works cross-graph and potentially cross-app. It means “I am referencing [[Foo]] or #Foo” whatever they are. For Logseq those are containers of indented blocks, for Obsidian they are Markdown files in a folder in the filesystem. Maybe when you copy a reference from an app to another one, the target of that reference has yet to be created in the new app but no problem, the reference will be solved somehow.
So it’s not about files vs databases, it’s about a syntax that does similar things in different apps or instances of apps. Just like we do with headers, tables, bold, italics etc we think it is useful to have syntax for “relative” references (as opposed to absolute references like URLs or IDs).
5 Likes
A block is created in the root of the graph. It can even be called a “Page” type block (Remnote does this - a root block is called a “Document”. It’s still just a block, as everything’s a block).
2 Likes
@BBob I also see “Page” as a particular type of block with different system features.
Regarding file-based storage, @alex0, I am not sure that is so irrelevant at this moment, considering the number of users relying on the “file” concept stored locally using the MD. But your point about focusing on syntax is a good one, as long as we don’t relate that conversation with the DB movement. The fact that some apps use Wikilinks, others use MD links, and others use internal proprietary ones could be considered a lack of consistent standardisation, therefore an interoperability issue. And this is now, without any DB scenario in use.
I meant that it is irrelevant for this discussion if files or a DB are used as persistent storage. People seem to think the concept of pages came from files, instead they came from references using names.
3 Likes
The concepts are the same, just different names and slight variations in behavior. Remnote has “Documents” which are pages in Logseq. Rems are blocks in Logseq. Far as creating linked references, you can still link to either a Rem or a Document just as you do a block or page in losgeq but in remnote its all tied into a single function that uses double [[ to start the process. Rem’s can also be turned into Documents by specifying the Rem as a Document, logseq does not have a native feature to do this. Documents that are independent, meaning they are the root of the page, can be dragged and moved into other Documents which will absorb that Document into the parent Document, but once they are absorbed into another Document, they are no longer a separate entity. This simplifies the structure to reduce the system from feeling cluttered.
The real benefit, for me, with Remnote over Logseq, is it does not rely on local files or having to parse local files, so performance is very good and its quick and snappy. I can build out my entire knowledge graph in a single Document where Logseq would choke and die if I tried to do even a 1/4 of what I put into the Document. Remnote also has safe guards to prevent the accidental deletion of a Rem when other Rem’s are linked to it.
The DB version of logseq however could solve some of these issues… We’ll have to see how it pans out.
Small correction: in Remnote everything’s a Rem (it’s just the word they use for block).
1 Like
Ah thank you! I fixed it.
1 Like
I happen to like the page setup. I see the pages as a compilation of the various blocks I’ve created over time. I would have to see an alternative and try it to determine if I would like it.
2 Likes
In the Logseq DB Alpha it seems the name for page has changed to Node, this got my years of using Logseq brain confused to no end when I got started. And then nodes have types it seems.
If I look at All pages (that should be renamed to All Nodes I think) I see nodes with different types, like Tag, Page, Property, Journal
Taking that into account, I do like the Page setup. I’m currently thinking on the whole pages vs block debate and mentally changing to should something be in the journal or in a topic.
So a book is it’s own node with a tag #book and quotes, notes and thoughts on it are in my journal and link to the node.
This initially did my head in, because I’m used to always just add to my journal and use block embeds. But as I used this things improved, as now I’m either logging stuff (hello journal) or I’m adding notes to a specific topic (hello ctrl+k search node)
From my experience with it. It seems to make things simpler, but I need to get it into a video to really fully grasp it and boil it down to it’s core points.
1 Like
There are still pages and blocks but they are also called “nodes”. It’s to avoid saying “page/block”.
2 Likes
That explains, so it’s nodes all the way down. Thx for clearing that up.
2 Likes
And will they have some behaviour difference once they’re calle “node” within the DB version?
Yes but it’s a mess at the moment, see:
1 Like
This link elaborates a bit on their current and future efforts on having everything be a block (which they’re calling “node”):
Looks promising!
By the way, it’s interesting how similar apps tend to use similar terminology. I think Tana uses node too? And they even explicitly compare the “new tags” to “supertags” (I prefer “classes” for that, but I get that this isn’t very relatable for non-tech people).
4 Likes