wasm-bindgen: JsValue serde support shouldn't go through serde_json

Going through serde_json ends up including a bunch of f64 formatting code, which is quite code size heavy.

I’m not super familiar with implementing serde serializers and deserializers, but if we can express “we only support things that can AsRef<JsValue>” as a trait bound for serialization, then I think we can go directly into and from JsValue without stringifying. This could be a perf win as well.

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 16 (15 by maintainers)

Most upvoted comments

Okay, I’ve finally published a wasm-bindgen + Serde integration as a separate library - https://github.com/cloudflare/serde-wasm-bindgen.

There are few reasons for that at the moment. First, it makes it’s a bit easier to maintain that way as it has own tests, benchmarks and stability guarantees which we might want to play with over time. Another, more important, issue is that, in order to support more JavaScript types and idiomatic conversions, it’s not strictly compatible with current serde-json-based APIs (JsValue::from_serde, JsValue::into_serde) and might convert values differently.

If that’s okay, I’d love to eventually replace Serde support in wasm-bindgen to use serde-wasm-bindgen instead of serde-json under the hood, but I don’t know what stability guarantees wasm-bindgen currently provides for Serde integration.

I suppose this will require waiting for a breaking change release? If so, it might be worth just pointing users to the external crate in docs for now, and eventually either switching or removing current wasm-bindgen from_serde/into_serde APIs.

Either way, I hope that’s okay and solves the issue, and let me know what you think about further integration!

RReverser on May 17, 2019

Okay, file-size savings of WASM+Brotli look promising now too (used against benchmarks which parse/serialize a bunch of structures with either one or the other library):

| json wasm+br | wasm-bindgen wasm+br | % – | – | – | – Os | 118,891 | 92,339 | -22% Os + strip | 100,886 | 74,141 | -27% O3 | 129,316 | 92,541 | -28% O3 + strip | 120,387 | 83,615 | -31%

Getting there!

RReverser on Apr 16, 2019

This serde-serialize feature is causing circular dependency issues, see https://github.com/tkaitchuck/aHash/issues/95#issuecomment-881152315. Would it make sense to deprecate this feature and simply tell users to use the serde-wasm-bindgen library? Given that wasm-bindgen is essentially mandatory on wasm32-unknown-unknown, it depending on serde (even optionally) is likely to keep causing issues.

josephlr on Jul 16, 2021

I’m currently working on a generic solution for this to improve performance of one of my projects. Is it possible to assign this issue to me for tracking?

RReverser on Mar 22, 2019

Hey @RReverser is there somewhere I can see your work on writing the serde (de)serializers? They sound awesome!

derekdreery on Apr 9, 2019