Ben Newman benjamin at
Mon Oct 2 17:38:03 UTC 2017

Taking a step back from the details of this proposal, I have some thoughts
about why it seems to be struggling to find support.

In no particular order, I would say this proposal

   - relies on microbenchmarks, which can be misleading
   - disregards Amdahl's Law <>,
   by pretending that real-world JS CPU usage is commonly/ever dominated by
   min/max computations
   - replaces two O(n) loops with another O(n) loop that does slightly more
   work on each iteration, resulting in no complexity improvement, and a
   fairly modest (< 2x) constant factor improvement
   - doesn't seem to provide usability/learnability improvements for any
   particular group of JS developers (for example, novice programmers)
   - doesn't seem to prevent any common bugs in JS code

As a member of TC39, I regret that we have not provided a clearer set of
criteria for what it takes to get a new function into the standard library.
While I can't speak for the committee as a whole, my suspicion is that this
proposal is unlikely to meet that standard. It's a fine idea, but so are
many other functions that you can implement in a normal (non-standard)

I would also challenge the committee to think about (or link to!) any
concrete written criteria that someone with an idea for a proposal could
use to assess its chances of acceptance. Imagine how much time we could


On Mon, Oct 2, 2017 at 12:12 PM Xavier Stouder <xavier at> wrote:

> JDecker: Just added your solution on the benchmark, it beats every
> others solution and it's a elegant solution.
> Kai Zhu: We can't see the screenshot. But please take in consideration
> that it's been a long time that ECMAScript isn't only used in webapp,
> and that some of applications using it can eat more than a million
> numbers.
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list