5 ms·

Big obsidian fan, but I will say: notes being “just markdown” is not entirely true depending on how you use obsidian. If you are a plug-in heavy user, and those

Big obsidian fan, but I will say: notes being “just markdown” is not entirely true depending on how you use obsidian. If you are a plug-in heavy user, and those plugins introduce new syntax and lots of JavaScript functionality, you are accumulating a bespoke custom syntax that only works on your copy of obsidian with your set of plugins. Obsidian and those plugins are still free and are a huge benefit, but just something to keep in mind regarding data hygiene and longevity.

edanm 1y ago
True, but the format is still text. In a "catastrophe", you can always just a) ignore these, or b) write custom code to process them (e.g. port the plugin to VSCode or whatever). Still far better than a proprietary format.
- eviks 1y ago
  A proprietary format with an export function allows you the same inconvenience of having to write code for processing.
  - Xss3 1y ago
    No. You might not be able to load the program to get to the export button. They might paywall it away. Etc.
    - eviks 1y ago
      No, there is no paywall or etc. This is not an imaginary anything goes area, but simple note taking where you have local client with locally synced data which can always export, so this risk doesn't exist
  - edanm 1y 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.
    - eviks 1y ago
      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
      - edanm 1y ago
        > 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.
krick 1y ago
Very much this. I cannot even fully agree with "plug-in heavy" remark: I mean, how heavy must it be, to be considered "plug-in heavy"? I consciously tried to limit plugin usage. But it really gets pretty wild soon. I was relatively lean for maybe the first 6 months, but when some patterns of how I use it become clear enough, it becomes pretty evident how inefficient many super-common situations are and how I can fix them just by installing a plugin. Fast-forward a year, and all your vault structure implicitly relies on the quirks of Obsidian search behavior, the markdown you write is extremely obsidian-flavored markdown, and you don't even remember how to write LaTeX without LaTeX-Suite shortcuts.
- datadrivenangel 1y ago
  I've been using Obsidian for years now and besides some experiments use zero plugins. What inefficient patterns are you running into?
theshrike79 1y ago
I've thought about this and I think Templater and Dataview are the two plugins I'd miss if Obsidian was sold to a VC tomorrow and enshittified. And I'm pretty sure both will be forked and modified to run independently of Obsidian within a week of the theoretical enshittification.
joseda-hg 1y ago
If you're willing to reimplement them in your own obsidian-like editor anyway, I don't quite see the difference I wouldn't so I keep to markdown and minimize plugins where aplicable, if I need to run for the hills, I don't expect to lose much

edanm 1y ago

True, but the format is still text. In a "catastrophe", you can always just a) ignore these, or b) write custom code to process them (e.g. port the plugin to VSCode or whatever). Still far better than a proprietary format.

eviks 1y ago
A proprietary format with an export function allows you the same inconvenience of having to write code for processing.
- Xss3 1y ago
  No. You might not be able to load the program to get to the export button. They might paywall it away. Etc.
  - eviks 1y ago
    No, there is no paywall or etc. This is not an imaginary anything goes area, but simple note taking where you have local client with locally synced data which can always export, so this risk doesn't exist
- edanm 1y 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.
  - eviks 1y ago
    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
    - edanm 1y ago
      > 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.

krick 1y ago

Very much this. I cannot even fully agree with "plug-in heavy" remark: I mean, how heavy must it be, to be considered "plug-in heavy"? I consciously tried to limit plugin usage. But it really gets pretty wild soon. I was relatively lean for maybe the first 6 months, but when some patterns of how I use it become clear enough, it becomes pretty evident how inefficient many super-common situations are and how I can fix them just by installing a plugin. Fast-forward a year, and all your vault structure implicitly relies on the quirks of Obsidian search behavior, the markdown you write is extremely obsidian-flavored markdown, and you don't even remember how to write LaTeX without LaTeX-Suite shortcuts.

datadrivenangel 1y ago
I've been using Obsidian for years now and besides some experiments use zero plugins. What inefficient patterns are you running into?

theshrike79 1y ago

I've thought about this and I think Templater and Dataview are the two plugins I'd miss if Obsidian was sold to a VC tomorrow and enshittified. And I'm pretty sure both will be forked and modified to run independently of Obsidian within a week of the theoretical enshittification.

joseda-hg 1y ago

If you're willing to reimplement them in your own obsidian-like editor anyway, I don't quite see the difference I wouldn't so I keep to markdown and minimize plugins where aplicable, if I need to run for the hills, I don't expect to lose much