Where the ** is the grammar specification? Prose is nice, but with a BNF I could plug this into my parsing expression grammar library right quick and give it a rundown.
Good point. I'll see about making one.
Show HN: Duper – The Format That's Super
11–17 of 17 posts
Re: Show HN: Duper – The Format That's Super
#12Why no date and time?
My reasoning is that they are normally transmitted as strings in JSON, and you could use an identifier like DateTime("2025-11-02T02:33:00Z") if you need to be explicit.
Making them part of the language would increase the complexity of parsers - how would you validate that a date is actually valid? It's doable (YAML and TOML do it, after all) but requires extra steps.
Re: Show HN: Duper – The Format That's Super
#13I think a neat route would be to use this as an authoring plugin in VS Code, like prettier: write Duper (or JSON5, or whatever), and then downlevel it to regular json automatically when pressing cmd-s. You wouldn't get to keep your comments (or they could be transformed to { "//": "comment text" }). Outside of that, it's tough to compete with JSON in the "human readable unschematized serialization format" market, esp…
Duper certainly won't outperform the native JSON implementation (and it likely never will), though I do think benchmarks would be a great addition. Bundle size and binary representation are definitely things I'll keep in mind!
The config file transpiration to JSON idea is quite interesting. It's pretty similar to how I'm already defining the TextMate grammar used by the website's syntax highlighter, so I'll certainly try to incorporate that into the tooling.
Re: Show HN: Duper – The Format That's Super
#14Why no date and time?
My reasoning is that they are normally transmitted as strings in JSON, and you could use an identifier like DateTime("2025-11-02T02:33:00Z") if you need to be explicit. Making them part of the language would increase the complexity of parsers - how would you validate that a date is actually valid? It's doable (YAML and TOML do it, after all) but requires extra steps.
Although given the feedback I've received, date/time might get included into the format.
Re: Show HN: Duper – The Format That's Super
#15I think a neat route would be to use this as an authoring plugin in VS Code, like prettier: write Duper (or JSON5, or whatever), and then downlevel it to regular json automatically when pressing cmd-s. You wouldn't get to keep your comments (or they could be transformed to { "//": "comment text" }). Outside of that, it's tough to compete with JSON in the "human readable unschematized serialization format" market, esp…
Duper certainly won't outperform the native JSON implementation (and it likely never will), though I do think benchmarks would be a great addition. Bundle size and binary representation are definitely things I'll keep in mind! The config file transpiration to JSON idea is quite interesting. It's pretty similar to how I'm already defining the TextMate grammar used by the website's syntax highlighter, so I'll certainly…
It may be worth it to pipe Duper into your WASM/native code, and get back plain JSON out, which you then hand off to the runtime's `JSON.parse` with a post-processing step to support any special features needed. Something like this:
// idea of implementing public duper.parse function to lean on
// runtime's JSON.parse
//
// downlevel to json, eg binary strings become base64 normal json strings
const { jsonString, enhancements } = duper.duperToJSON(data)
// let the runtime go fast when decoding
const rawObject = JSON.parse(jsonString)
// `enhance` knows the paths to all the binary base64 strings
// and replaces them with Uint8Arrays
const decoded = duper.enhance(rawObject, enhancements)
type Path = Array
type TransformFn = (value: unknown) => unknown
type Transform = TransformFn | Enhancements
type Enhancements = Array
Re: Show HN: Duper – The Format That's Super
#16Earlier quoted context omitted.
My reasoning is that they are normally transmitted as strings in JSON, and you could use an identifier like DateTime("2025-11-02T02:33:00Z") if you need to be explicit. Making them part of the language would increase the complexity of parsers - how would you validate that a date is actually valid? It's doable (YAML and TOML do it, after all) but requires extra steps.
Although given the feedback I've received, date/time might get included into the format.
note that a DateTime w/ a UTC offset is significantly different from a DateTime w/ a TimeZone (+ optional Calendar), aka ZonedDateTime. ZonedDateTime(July 26, 2035 10:15:32pm in Instanbul) may not necessarily always be at today's value of Instant(July 26, 2035 10:15:32pm in Instanbul). If you are going to support date/time, you should not use the word "DateTime", "Date", "Time" in a way that is ambiguous (is it a ZonedDateTime, or an Instant?), or forget to include support for ZonedDateTime.
MDN page on JavaScript's Temporal library gives a good overview of the difference between the two; today's practice of encoding Instants as ISO 8601 strings in UTC (Z suffix) or at a UTC offset is okay for ephemeral data-in-motion that will be used right now, but is not a good practice for persisted data since time zones, DST rules, etc change all the time. Temporal is the JS-specific API, but these concepts apply to all handling of date/time/etc data in computer systems.
That said, v8 plans to use [temporal_rs][] as their Temporal backend.
Temporal: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
temporal_rs: https://crates.io/crates/temporal_rs
You can encode extended ZonedDateTime information to string following this RFC [Date and Time on the Internet: Timestamps with Additional Information](https://www.rfc-editor.org/rfc/rfc9557.txt)
Re: Show HN: Duper – The Format That's Super
#17Earlier quoted context omitted.
My reasoning is that they are normally transmitted as strings in JSON, and you could use an identifier like DateTime("2025-11-02T02:33:00Z") if you need to be explicit. Making them part of the language would increase the complexity of parsers - how would you validate that a date is actually valid? It's doable (YAML and TOML do it, after all) but requires extra steps.
Although given the feedback I've received, date/time might get included into the format.
DateTime handling, especially with timezone offsets, is crucial. If your format gets that right, it'll stand out...most formats still mess up time zones or rely on loose string parsing. It's key for stuff like logs, scheduling, or syncing data across systems. DuperGZ right after that! ;)