hujson
Dixy
hujson | Dixy | |
---|---|---|
10 | 3 | |
564 | 28 | |
0.9% | - | |
0.0 | 10.0 | |
6 months ago | about 7 years ago | |
Go | Swift | |
BSD 3-clause "New" or "Revised" License | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
hujson
- JSON for Humans (JWCC: JSON with comments and trailing commas)
-
Ron: Rusty Object Notation
That, and comments!
Personally, I really hope Human JSON, https://github.com/tailscale/hujson , will take over!
-
Unmarshal text with Go reflection - usage and internals of a library for line-oriented text
I also like the approach that the hujson library takes, where everything is a type Literal []byte and you can call (Literal).Bool(), (Literal).String(), (Literal).Int() or (Literal).Float() on it and it gives you the corresponding value out of it (or the zero value). So kinda like dynamic variables that can store anything.
-
Internet Object – A JSON alternative data serialization format
One of the variants that permit comments: https://github.com/tailscale/hujson
- HuJSON - JSON for Humans (comments and trailing commas)
- Tailscale/hujson: HuJSON: JSON for Humans (comments and trailing commas)
Dixy
-
JSON vs. XML with Douglas Crockford
I remember one time designing the simplest and most readable data format ever and came up with this https://github.com/kuyawa/Dixy after removing all I could and still make it usable
I'm leaving it here because it will never be used for anything but at least it may inspire somebody design a better format with simplicity in mind
- Dixy: Data Format Based on Dictionaries
-
Internet Object – A JSON alternative data serialization format
YAML and its "Arrays" are really broken. The problem I see with Internet Object is that it's also implying this kind of mechanism.
Every time I read about new formats, they seem to get either the 1-n relations or the n-n relations implemented well, but not both. I guess that's what's so hard about map/reduce...
Regarding YAML: somebody on HN mentioned his project DIXY a couple years ago, and it's much much _much_ easier to parse than YAML. [1] I'm using this over YAML pretty much everywhere now.
[1] https://github.com/kuyawa/Dixy
What are some alternatives?
zed - A novel data lake based on super-structured data
zed - Rethinking code editing.
jsonschema-key-compression - Compress json-data based on its json-schema while still having valid json
edn - Extensible Data Notation
set - Package set is a small wrapper around the official reflect package that facilitates loose type conversion and assignment into native Go types.
json5 - JSON5 — JSON for Humans
simdjson - Parsing gigabytes of JSON per second : used by Facebook/Meta Velox, the Node.js runtime, ClickHouse, WatermelonDB, Apache Doris, Milvus, StarRocks
proposal-json-superset - Proposal to make all JSON text valid ECMA-262