[ANN] Jzon — a library to encode and decode JSON

Hello, I’ve done a small proof-of-concept library to deal with JSON: https://github.com/nkrkv/jzon

I’m using bs-json and it’s cool, but…, it is not pipe-first and so kinda doesn’t fit perfectly the idiomatic ReScript. And it encourages completely isolated encoding and decoding which is quite error-prone if you talk with JSONs to yourself (for example in a [micro-]service project). Kudos to @glennsl, I just trying to take another look to the problem.

How is it? Feedback is much welcomed. Not all features are implemented yet but the basis is ready. I’ll extend this if I see the concept makes sense.

10 Likes

I am curious about your reactions to bs-decode and whether you have a distinct direction that you want jzon to take relative to bs-decode.

Conceptually like JsonCodec right?

Though execution-wise, it’s definitely appreciated that this is a single dependency-less file.

1 Like

Hey @nkrkv, another question: have you benchmarked this? What order of magnitude vs native json are we talking about here?

Jzon is a decoding and encoding library whereas bs-decode supports only the former, as I understand.

:man_facepalming:

I did not found this library when I was looking for something similar. Now I see, yes, they are quite similar. One notable difference though is where the lib boundary is drawn. JsonCodec offers to define codecs that take tuples in and give tuples out. And Jzon requires the functions to construct/destruct the destination type, so that, codecs take objects in and give objects out.

No, unfortunately, found no spare time to arrange a solid experiment. Yet.

Very cool library! Coming from Elm, this feels right, like elm-json and elm-codec.

In my opinion it would be better to publish it as rescript-json or @nkrkv/rescript-json and have the module called Json instead of Jzon.

1 Like

Ah, I don’t mind duplication if it’s an improvement in terms of perf/stability/idiomaticness/etc (IF!).

But yeah, some benchmarks would be nice!

Thanks. I realized that aspect, but I was curious about comparing just the “decode” approach.