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.
2 Likes
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
My concern is with the change to a database that was written by the Logseq developers. I don’t want to get locked into one ecosystem without the ability to easily change. Getting locked into a database system makes me uneasy. Over time, promises made by the current leaders end up being broken. Change happens. I’m looking at other options just in case.
1 Like
As long as Logseq provides a proper export to Markdown then moving ecosystems should be easy enough. And because it’s a local app they can’t suddenly take that functionality away.
To me the more important aspect is the license, see
logseq/LICENSE.md at master · logseq/logseq · GitHub
Why is this important? It means that if the developers would start locking people in another company could just fork the codebase and make an alternative with 0 migration issues and build a commercial business out of it. That’s a very strong commitment to users that is very hard to find in a lot of other solutions.
4 Likes
One of the reasons that it is taking so long to finish the beta is that they don’t have a lot of developers. One reseason for this is the size of the code base and the lack of documentation for it. So, training new developers is not practical.
Sure, someone could try to fork the project but how long would it take to become familiar enough to make changes with the added consideration that it is written in closure?