Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Canvas – An open file format for infinite canvas data

jsoncanvas.org

Post reply on HN
Print view View original

71–80 of 168 posts

Re: JSON Canvas – An open file format for infinite canvas data

#71

Post by exceptione »

desmondl wrote: post #48
kepano wrote: post #15

Whoa! Didn't expect this to bubble up to the top of HN. Some context about why we created JSON Canvas: https://obsidian.md/blog/json-canvas/ We just released it today, so this is still a very nascent project. A little over a year ago we released Obsidian Canvas. The .canvas file format has felt stable enough to give it a name and resources that other apps can freely use. See the original Show HN: https://news.ycombin…

I agree with a lot of comments that it's minimal, but in my opinion that is a good thing. I'm a big fan of Obsidian, and of the things I like about it is the data source is all markdown files. Markdown is meant to be very lightweight and portable, and overcomplicating it will limit adoption and extensibility (imagine markdown vs pdf). JSON Canvas seems to follow in that spirit by being very lightweight, so a lot of i…

> 6. YAML

Please don't, it has one of the most confusing syntax out there with lists and maps, and it won't do well for parsing.

Re: JSON Canvas – An open file format for infinite canvas data

#72

Post by desmondl »

apitman wrote: post #69

Obsidian is one of the few closed-source applications I would consider relying on, due to their commitment to building around simple, open file formats. Sure, they could screw me over and start charging absurd amounts of money for their app, but high quality open source alternatives would pop up immediately. Meanwhile, as long as they don't screw me over, it's unlikely an open source alternative is going to be able t…

I completely agree. Even if they completely tank I can open my obsidian directory in a text editor or command line and still use it. I would still have access to features that are common in other apps like full text search or plain file sync. Attachments are just files in the filesystem that can be opened in any image viewer. Basically if i can’t use obsidian anymore i can still use my notebook and take notes without implementing or finding new software

Re: JSON Canvas – An open file format for infinite canvas data

#74

Post by RyanHamilton »

I would like to take this opportunity to implore everyone to not invent a new format. Avoid it at all costs. First try to follow an existing standard or say that you will support a subset. When you invent a new standard, you start small and say oh users just need to know this and look it's so simple. Then you find all the edge cases, add all the features and voila you have created a half baked implementation of an existing standard. Only if you can explicitly say many reasons why you haven't used standard X or Y create something new.

To take this specific example, some of it feels very similar to HTML. label, links, sections, groups, anchors, background fill options...I would have been tempted to define as a subset of HTML that is supported. Then if I wanted JSON, say how JSON maps to HTML. voila suddenly everything is standardly named and creatable. This means backgroundStyle is replaced by background-size = cover or contain. It means that those six preset colors are replaced by all HTML standard colors. Voila no one needs to learn different concepts or definitions. Try that existing standard, try 2 more and only if they don't work invent a new one. Please. I say this as someone that inherited standards invented by teams that I then had to try and train hundreds of users on. Funnily enough the previous people left when the coding was done, without teaching the users. THey probably left to implement version 2 elsewhere. :)

Re: JSON Canvas – An open file format for infinite canvas data

#75

Post by LordDragonfang »

asa400 wrote: post #53
chrisweekly wrote: post #38

Earlier quoted context omitted.

Crucial context: its provenance is embedded infinite canvas in Obsidian (amazing markdown-based notes app++), which supports JS but has no external datastore per se. SQLite is fantastic, but inappropriate for this use case.

Oh I read the post and a few of the other linked posts so I'm aware. If we're storing a file, we're already storing a file of some kind, so we're just talking about what kind of file it is. I'm just talking about a different set of tradeoffs one can make if that file is something other than JSON.

>If we're storing a file, we're already storing a file of some kind

It's not just a file "of some kind", it's a text file. That's one of Obsidian's key selling points - that a vault is simply a collection of text files. The "text" part is important to both Obsidian's philosophy and the majority of its users.

Re: JSON Canvas – An open file format for infinite canvas data

#76

Post by desmondl »

exceptione wrote: post #71
desmondl wrote: post #48

Earlier quoted context omitted.

I agree with a lot of comments that it's minimal, but in my opinion that is a good thing. I'm a big fan of Obsidian, and of the things I like about it is the data source is all markdown files. Markdown is meant to be very lightweight and portable, and overcomplicating it will limit adoption and extensibility (imagine markdown vs pdf). JSON Canvas seems to follow in that spirit by being very lightweight, so a lot of i…

> 6. YAML Please don't, it has one of the most confusing syntax out there with lists and maps, and it won't do well for parsing.

I haven’t had any issues with yaml in markdown frontmatter or openapi specs. What kind of issues do you see with list and maps that make you against yaml? I agree that for computers and consistency json is preferred. I already use a linter for my markdown files so I would do the same with yaml to keep lists and maps consistent

Re: JSON Canvas – An open file format for infinite canvas data

#77

Post by chatmasta »

desmondl wrote: post #48
kepano wrote: post #15

Whoa! Didn't expect this to bubble up to the top of HN. Some context about why we created JSON Canvas: https://obsidian.md/blog/json-canvas/ We just released it today, so this is still a very nascent project. A little over a year ago we released Obsidian Canvas. The .canvas file format has felt stable enough to give it a name and resources that other apps can freely use. See the original Show HN: https://news.ycombin…

I agree with a lot of comments that it's minimal, but in my opinion that is a good thing. I'm a big fan of Obsidian, and of the things I like about it is the data source is all markdown files. Markdown is meant to be very lightweight and portable, and overcomplicating it will limit adoption and extensibility (imagine markdown vs pdf). JSON Canvas seems to follow in that spirit by being very lightweight, so a lot of i…

> Markdown and JSON are meant to be non-opague file formats that prioritizes portability and human readability over other features

I don't think human readability is a critical feature of JSON at this point. If that's your priority, you can use YAML. Readable JSON is nice because for small files you can read or edit small sections of it, and it's easy to debug when manipulating it with machine code. But there are plenty of cases where a huge JSON file is still useful even if it's barely human readable.

My heuristic has always been: use YAML if you expect humans to create the file (or maintain large chunks of it), otherwise use JSON. For example, Kubernetes config is YAML because humans create it from scratch, and it would suck to do that with JSON. Whereas package.json is JSON because machine code initializes it and humans only make minor edits to specific fields.

In the case of this canvas format, I wouldn't expect humans to create the file from scratch, so use JSON over YAML. Then the question is, will humans even care about reading the raw JSON? Probably not. So why not use something like SQLite or Protobuf? The most compelling reason would be that humans writing code to interface with the format can use parsing tools from their language's standard library.

Re: JSON Canvas – An open file format for infinite canvas data

#78

Post by exceptione »

asa400 wrote: post #30

I've worked a few jobs now where application data was stored in text files of various kinds (homegrown as well as well-defined formats, JSON included) and it pretty quickly becomes a mess when you start talking about modifying it over time, evolving its schema, validating it in the face of end-user edits, ensuring threads don't write to it concurrently, etc. This strikes me as exactly the type of application data tha…

SQLite has no real types. Use SQLite if data quality is of no concern. The applicability domain of SQLite is far smaller than people think.

If you want to improve on JSON, you would have to go into an other direction. Maybe something like postgis would be helpful for extremely large canvasses.

JSON Schema is pretty powerful by the way. Checkout the documentation. SQLite is absolutely no match there. What Sqlite could bring is speed, but I dont see how in the contxt of canvas it would be of any help here.

Re: JSON Canvas – An open file format for infinite canvas data

#79

Post by desmondl »

chatmasta wrote: post #77
desmondl wrote: post #48

Earlier quoted context omitted.

I agree with a lot of comments that it's minimal, but in my opinion that is a good thing. I'm a big fan of Obsidian, and of the things I like about it is the data source is all markdown files. Markdown is meant to be very lightweight and portable, and overcomplicating it will limit adoption and extensibility (imagine markdown vs pdf). JSON Canvas seems to follow in that spirit by being very lightweight, so a lot of i…

> Markdown and JSON are meant to be non-opague file formats that prioritizes portability and human readability over other features I don't think human readability is a critical feature of JSON at this point. If that's your priority, you can use YAML. Readable JSON is nice because for small files you can read or edit small sections of it, and it's easy to debug when manipulating it with machine code. But there are ple…

Yep, I think the compelling reason of humans writing code is key here. SQLite would make it less accessible for people to write external tooling to integrate with an obsidian vault. There are lots of existing and open that support diffing/parsing/syncing/manipulating json, while with sqlite you have to not only know sql but support another application’s database schema, which third party developers are less likely to do

Re: JSON Canvas – An open file format for infinite canvas data

#80

Post by chatmasta »

apitman wrote: post #69

Obsidian is one of the few closed-source applications I would consider relying on, due to their commitment to building around simple, open file formats. Sure, they could screw me over and start charging absurd amounts of money for their app, but high quality open source alternatives would pop up immediately. Meanwhile, as long as they don't screw me over, it's unlikely an open source alternative is going to be able t…

I love Obsidian. I wish they would consider open sourcing the application. It doesn't even seem in conflict with their monetization plans, because they're already distributing the app for free, and making money with things like "Obsidian publish." They've got enough critical mass and a sufficiently thriving ecosystem of community plugins that they could only stand to benefit from open sourcing the core app.

See Mattermost for an example of a similarly positioned product that is fully open source.

Post reply on HN