PRNG - currently available solutions aren't addressing many use cases

David Bruant bruant.d at
Tue Dec 1 21:45:43 UTC 2015

Le 01/12/2015 20:20, Michał Wadas a écrit :
> As we all know, JavaScript as language lacks builtin randomness 
> related utilities.
> All we have is Math.random() and environment provided RNG - 
> window.crypto in browser and crypto module in NodeJS.
> Sadly, these APIs have serious disadvantages for many applications:
> Math.random
> - implementation dependant
> - not seedable
> - unknown entropy
> - unknown cycle
> (...)
I'm surprised by the level of control you describe (knowing the cycle, 
seeding, etc.). If you have all of this, then, your PRNG is just a 
deterministic function. Why generating numbers which "look" random if 
you want to control how they're generated?

> window.crypto
> - not widely known
This is most certainly not a good reason to introduce a new API.

> As we can see, all these either unreliable or designed mainly for 
> cryptography.
> That's we need easy to use, seedable random generator
Can you provide use cases the current options you listed make impossible 
or particularly hard?

> Why shouldn't it be provided by library?
> - average developer can't and don't want to find and verify quality of 
> library - "cryptography is hard" and math is hard too
A library or a browser implementation would both need to be "validated" 
by a test suite verifying some statistical properties. My point is that 
it's the same amount of work to validate the "quality" of the 

> - library size limits it usability on Web
How big would the library be?
How much unreasonable would it be compared to other libraries for other 
use cases?
I'm not an expert on the topic, but of the few things I know, it's hard 
to imagine a PRNG function would be more than 10k

> - no standard interface for PRNG - library can't be replaced as 
> drop-in replacement
We've seen in the past that good libraries become de-facto standard (at 
the library level, not the platform level) and candidate to being 
shimmed when the library is useful and there is motivation for a drop-in 
replacement (jQuery > Zepto, underscore > lodash). This can happen.
We've also seen ES Promises respect the Promise A+ spec or close enough 
if they don't (I'm not very familiar with the details).


More information about the es-discuss mailing list