Almost all of those are for the database release, not the production release.

Even if they are for the current production release was last April. Considering the buggy mess their product is, that’s kind of unacceptable for an app that is supposed to hold your entire lifes data.

World of Warcraft

I’m clean, I’m clean!

https://discuss.logseq.com/t/why-the-database-version-and-how-its-going/26744

I get it. And I don’t necessarily disagree with them, but it gives me concerns over the long term viability of the project. If obsidian did blocks the same way logseq did I’d probably jump ship and use that, but you can’t really brain dump in obsidian the same way you can in logseq.

Basically unmaintained at this point until they release the DB version “some day”. And you’re delusional if you think they can maintain both versions at the same time. They can’t even update the current production version that they already have without focusing all their efforts on a new app that hasn’t been released yet.

I am NOT writing a database connector unless you add an additional three months to your projects expectations.

I am NOT writing an LDAP connector.

I am NOT writing code to execute shell processes safely.

And I’m sure as hell not writing an XML parser just so I can say I did it without libraries.

JS devs that import libraries for every stupid thing (lpad comes to mind) are bad programmers, but libraries are useful and have their place.

And if my boss doesn’t want me using those libraries, they need to specify that in advance or there needs to be a company policy to that effect. Otherwise, I’m solving the problem my way since that’s what I’m getting paid to do.

Bigabyte

If they wanted me to use a specific tool or lack thereof they should have said that. Instead they said “fix this problem” and instead of writing the entire codebase from the ground up I used the tools that were available to me so I could focus on fixing the problem instead of fixing the fix to fix the fix for the fix of the problem.