futursolo / stylist-rs

A CSS-in-Rust styling solution for WebAssembly Applications
https://crates.io/crates/stylist
MIT License
370 stars 22 forks source link

Add more feature flags #49

Closed futursolo closed 2 years ago

futursolo commented 2 years ago

The size of stylist has doubled since the fork from css-in-rust and still increasing.

This issue aims to add more feature flags to minimise the final bundle size by allowing users to disable unused features.

WorldSEnder commented 2 years ago

If you want to split the yew-specific features, I propose that "yew_integration" switches on some default finer grained ones, and that the details are controlled by specific ones.

yew_integration = ["yew_use_media_query", "yew_use_style"]
yew_use_media_query = ["yew", "web-sys/MediaQueryList", "gloo-events"]
yew_use_style = ["yew"]

In my experience wasm-pack is sufficient to eliminate most unused functions from the final bundle and the added compile time doesn't yet hurt the default experience too much. Thus, yew_integration becomes a sort of default switch for yew features and the actual impl hides behind more specific features.

futursolo commented 2 years ago

In my experience wasm-pack is sufficient to eliminate most unused functions

If this is actually working reliably, it will improve the user experience for everyone. (e.g.: I can remove feature parser and simply give debug assertions to everyone and users will only pay for runtime parser if it is actually used in release mode.)

Unfortunately, this is not always the case.

Whilst I don't know what code can be effectively tree-shaken by wasm-opt and what cannot, use_media_query and use_style seems to be able to be tree-shaken effectively at the moment.

Thus, yew_integration becomes a sort of default switch for yew features and the actual impl hides behind more specific features.

If the code can be effectively tree-shaken, do we still need a feature flag for each feature?

WorldSEnder commented 2 years ago

(e.g.: I can remove feature parser and simply give debug assertions to everyone and users will only pay for runtime parser if it is actually used in release mode.)

If the code can be effectively tree-shaken, do we still need a feature flag for each feature?

Features that enable optional dependencies (i.e. nom with parser, syn with macros, yew with yew_integration) have a second purpose besides just shrinking the bundle: helping compile time. E.g. with macros, the whole compilation pipeline has to wait for syn to compile I think. Might be worth to spend some time checking this and other techniques