Comment by edanm
14 hours ago
Not true for a variety of reasons:
1. You're relying on the external service to continue providing the export functionality, or else doing regular backups.
2. The format of the exports might be proprietary, so it might be orders of magnitude more difficult to parse.
3. The export might not contain all the data.
4. Even if the export isn't to a proprietary format, it might be to a format that's much harder to parse than Markdown. Markdown is not only a standard, it's fairly readable even without any parsing, as opposed to, say, exporting in HTML. Losing some functionality (often minor, depending on what you use Obsidian for) is better than losing more or all functionality.
1. No, the data is already local, the app is already local, you're not relying on anything.
2. Or it might be orders of magnitude easier to parse vs replicating all the plugins functionality. You're just arbitrarily making the alternative worse
3. That's again something you've made up that's not a generic feature of alternative proprietary format
4. It might also be export to markdown. Again, unless you make up artificial barriers
But you can also do it the other way, for example, anything non-trivial like some large table with in-cell formatting won't be readable in your primitive plain text-based proprietary format, so it will be much worse that the unreadable Excel xml or its binary alternative, but that would still be a much preferable export format since no, you're not going to develop a new spreadsheet parser that some obsidian plugin uses to make sense of it
> it's fairly readable even without any parsing, as opposed to, say, exporting in HTML.
that's true for primitive formatting needs, but in this case there are tools that can convert html to markdown that would easily do that
> 1. No, the data is already local, the app is already local, you're not relying on anything.
That's not necessarily true. Some apps keep only cached copies of the data and the rest on the cloud. Sometimes the local files are in a binary format that is unreadable without the export functionality, and newer releases of certain apps remove the export functionality.
> 2. Or it might be orders of magnitude easier to parse vs replicating all the plugins functionality. You're just arbitrarily making the alternative worse
Obviously this depends on the exact app.
But I don't think you can credibly claim that a textual format like markdown isn't easier to parse than... well, almost any other format.
> 3. That's again something you've made up that's not a generic feature of alternative proprietary format
I didn't make it up. It depends on the alternative app you're talking about. Some export full data including all metadata, some don't include all metadata, etc.
My point is that if all the data is actually just markdown files on your computer, there is no question of whether you have all the data.
> 4. It might also be export to markdown. Again, unless you make up artificial barriers
Once again, depends on the specific app. I was a long-term user of Evernote, and still have a subscription. I just checked, and it looks like you can export to a format called "enex", or to a single html page, or to pdf. That's awesome! And the chance that you won't be able to use this in another app is next to nothing, since everyone works to be able to import Evernote.
It's still a tradeoff between the extra functionality you get from Evernote, vs. the simplicity of the "export" files you have. In Obsidian, there's no separate export, the files are stored in simple-to-read Markdown. But you get less functionality.
It's a tradeoff. I'm not saying one is better than the other. But pretending there isn't a tradeoff is quite simply wrong.
> But you can also do it the other way, for example, anything non-trivial like some large table with in-cell formatting won't be readable in your primitive plain text-based proprietary format, so it will be much worse that the unreadable Excel xml or its binary alternative, but that would still be a much preferable export format since no, you're not going to develop a new spreadsheet parser that some obsidian plugin uses to make sense of it
Yes. I wouldn't use Obsidian to do anything that would require a spreadsheet. I'd simply use Excel, since it's a billion times better at it.
I'm certainly not against using the right tool for the job, nor am I against proprietary formats in general.
1. It true since the argument about formats. You can limit storage of open format to the cloud as well.
> and newer releases of certain apps remove the export functionality.
Then you'd just use the old release with the export functionality intact. You can also make up stuff like "Obsidian can release an app that deletes/encrypts all local files, retaining only the cloud copy, and start charging for it without having any export functionality"
> But I don't think you can credibly claim that a textual format like markdown isn't easier to parse than... well, almost any other format.
This isn't markdown, but markdown + dozens of extensions, so it's very easy to claim that it's much harder to write custom parsers for dozens of formats rather than use an existing parser for some more elaborate format that doesn't need those extensions.
> the files are stored in simple-to-read Markdown
they aren't, they're stored in an undefined format depending on which extensions you use. Part of it is markdown (which is not simple to read in the non-primitive case of richly formatted docs)
> there's no separate export
That's not a benefit! It means that you can't move outside of the Obsidian ecosystem because there is no well-defined format that you could use another app with! So it's (practically) even worse than Evernote since that one is already widely supported, though theoretically it's the same.
> But pretending there isn't a tradeoff is quite simply wrong.
Yet you've failed to identify it, turns out it all "depends on the specific app"! Fine, compare apps, but the general argument was about text-based proprietary format with a chance of data loss if the ecosystem dies (or a chance of requiring a lot of effort to convert), and a generic proprietary format that can be exported into a text-based format... with the same risks!
2 replies →