@H2CO3: I'm a big fan of
serde, and it is one of the reasons why I love Rust. The main reason why I'm looking for alternatives is, as @glowcoil mentioned, that it's a heavy dependency. I don't care about this for myself, but I'm working on something that probably would be useful to other people, and I don't want to force
serde on them for my small crate.
I was thinking about having two options for de-/serialization (one would be
serde, for people who use
serde anyway), and put them behind feature flags.
there are legitimate reasons not to use
Of course. However, OP listed exactly none of them, other than "I want to avoid it".
Yes, I probably should have provided more information regarding my use-case.
In addition to the above: I'm working on a command line tool and lib that checks if a CSS class exists in a CSS stylesheet. For example, I'm using Tailwind CSS with a static-website generator I'm building in Rust, and I'd like to validate CSS classes at build and/or compile time (e.g. in my
tera templates). I'm pretty sure, that would be useful to other people.
There is one step where CSS classes are extracted from a CSS stylesheet, and cached in a file (this would happen only when the stylesheet changes, for example via the cli tool and a file watcher).
Then later, the application would load the data from the file to validate CSS classes.
One approach would be to offer
miniserde (which is by the same author as
serde, and therefore most likely properly implemented) as options for de-/serialization via cargo features.
Besides that, I just had another idea:
For a different project I used the quote crate (also by the amazing author of
serde) to generate API code for Rust (a command line tool that takes JSON as input, and writes Rust source code to files).
I could do the same with my struct from above.
The benefit would be, that the CSS validation crate wouldn't require any dependency for deserializing at all.
The workflow would be like this:
- The stylesheet is changed
- The CLI tool extracts the CSS classes and writes them in the form of Rust source code to a file that is defined by the user
- The application is re-compiled (e.g. a web application, or a static-website generator)
The main disadvantage I see is, that every change to the stylesheet would require a re-compilation (which wouldn't be a problem for myself, but maybe for others).
However, I guess that this would be the best option for binary size (which probably only would be relevant for people who want to include my crate into a WASM application to check CSS classes dynamically at run-time. For example from within a
tera template, or when CSS classes are computed at run-time).
I'm also not sure, if most people would be comfortable having a code generator adding source files directly into their 'src' directory.
A procedural macro probably would be another option, but would require re-compilation at every CSS change as well. I don't have any experience with procedural macros, so I don't know if there would be other disadvantages.