11 ms·

This is very interesting. It is a serialization format generalized to handle real references, including circular ones, and more complex data-types than JSON can

This is very interesting. It is a serialization format generalized to handle real references, including circular ones, and more complex data-types than JSON can handle. I think it's a very poor tagline, since "eval in reverse" sounds useless, and this lib is anything but. (no affliation btw) The down-side is that a consumer has to run a full-blown eval() (as opposed to the more restricted JSON.parse()). This isn't that much of a downside in a typical webapp since you have full control over the browser process anyway, but it's deadly for cross-domain. The upside is considerable for certain data-structures that are hard to represent in JSON efficiently, e.g. with a lot of denormalization. A key concern for me is runtime efficiency, particularly compared to JSON.stringify.

personjerry 11y ago
Yeah, the "eval in reverse" tagline and the cuteness of its name ("lave") made me think it was something for amusement.
- jedschmidt 11y ago
  My original HN submission was clearer, but alas didn't go anywhere: https://news.ycombinator.com/item?id=11185365 https://news.ycombinator.com/item?id=11185365
jedschmidt 11y ago
Absolutely. The downside of running a full-blown eval() exists in JSON too, it's just that the eval() there is taking place in the reviver function, which requires a lot more coordination than a self-contained file. As far as efficiency, I'd think for most uses the issue would be on the JSON.parse end. In this case, lave might be more efficient, since JSON reviving often ends up creating temporary objects that need to GC'ed after reification.
- javajosh 11y ago
  Interesting. I'd like to whip up some simple benchmarks tomorrow, and I'll share what I find. Also, it would be interesting to support other data-types, such as the ones that come with Immutable.js. That would be slick.
abecedarius 11y ago
It's not a new idea (not to knock the OP). http://wiki.erights.org/wiki/Safe_Serialization_Under_Mutual_Suspicion/Introducing_Data_E#Unserialization_as_Evaluation http://wiki.erights.org/wiki/Safe_Serialization_Under_Mutual... calls it uneval instead of lave, and attributes it to Jonathan Rees. See http://wiki.erights.org/wiki/Safe_Serialization_Under_Mutual_Suspicion/Abstract_and_Introduction http://wiki.erights.org/wiki/Safe_Serialization_Under_Mutual... for more on the security issues -- this was all for the E language, but I guess most of it could carry over to modern Javascript. One aspect that wouldn't: in E when you resolve a promise it becomes (http://gbracha.blogspot.com/2009/07/miracle-of-become.html http://gbracha.blogspot.com/2009/07/miracle-of-become.html) the resolution. Data-E uses this to express reference cycles.

personjerry 11y ago

Yeah, the "eval in reverse" tagline and the cuteness of its name ("lave") made me think it was something for amusement.

jedschmidt 11y ago
My original HN submission was clearer, but alas didn't go anywhere: https://news.ycombinator.com/item?id=11185365 https://news.ycombinator.com/item?id=11185365

jedschmidt 11y ago

Absolutely. The downside of running a full-blown eval() exists in JSON too, it's just that the eval() there is taking place in the reviver function, which requires a lot more coordination than a self-contained file. As far as efficiency, I'd think for most uses the issue would be on the JSON.parse end. In this case, lave might be more efficient, since JSON reviving often ends up creating temporary objects that need to GC'ed after reification.

javajosh 11y ago
Interesting. I'd like to whip up some simple benchmarks tomorrow, and I'll share what I find. Also, it would be interesting to support other data-types, such as the ones that come with Immutable.js. That would be slick.

abecedarius 11y ago

It's not a new idea (not to knock the OP). http://wiki.erights.org/wiki/Safe_Serialization_Under_Mutual_Suspicion/Introducing_Data_E#Unserialization_as_Evaluation http://wiki.erights.org/wiki/Safe_Serialization_Under_Mutual... calls it uneval instead of lave, and attributes it to Jonathan Rees. See http://wiki.erights.org/wiki/Safe_Serialization_Under_Mutual_Suspicion/Abstract_and_Introduction http://wiki.erights.org/wiki/Safe_Serialization_Under_Mutual... for more on the security issues -- this was all for the E language, but I guess most of it could carry over to modern Javascript. One aspect that wouldn't: in E when you resolve a promise it becomes (http://gbracha.blogspot.com/2009/07/miracle-of-become.html http://gbracha.blogspot.com/2009/07/miracle-of-become.html) the resolution. Data-E uses this to express reference cycles.