You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
this means that user password checking needs to be done client-side
but I can't really use zxcvbn client-side because of its prohibitive compiled size:
my app's release mode wasm withoutzxcvbn: 1.4M uncompressed, 338K compressed with brotli
my app's release mode wasm withzxcvbn: 2.5M uncompressed, 753K compressed with brotli
Even though my app is using 264 other crates, zxcvbn alone doubles its download time and probably wasm compilation time too.. But is only useful when a user is signing up or changing its password.
The best solution I see to this problem would be to allow building a version of this create (behind a feature flag) without the frequency lists in the source code, and then allow loading them at runtime.
This way, the ~400K of compressed lists would only be downloaded and processed when the client code needs them without affecting loading time and "time to interactivity" :-)
I'm sure it could even be done in a non-api breaking way.
I'm willing to investigate and propose a PR if this feels reasonable to you
The text was updated successfully, but these errors were encountered:
Hello,
I'm building a web app (https://github.com/PaulGrandperrin/cachou) using your very cool library, here is my use-case:
wasm
module (built with https://github.com/yewstack/yew)zxcvbn
client-side because of its prohibitive compiled size:zxcvbn
: 1.4M uncompressed, 338K compressed with brotlizxcvbn
: 2.5M uncompressed, 753K compressed with brotlizxcvbn
alone doubles its download time and probably wasm compilation time too.. But is only useful when a user is signing up or changing its password.The best solution I see to this problem would be to allow building a version of this create (behind a feature flag) without the frequency lists in the source code, and then allow loading them at runtime.
This way, the ~400K of compressed lists would only be downloaded and processed when the client code needs them without affecting loading time and "time to interactivity" :-)
I'm sure it could even be done in a non-api breaking way.
I'm willing to investigate and propose a PR if this feels reasonable to you
The text was updated successfully, but these errors were encountered: