Guidelines and General Direction for Standard Library Proposals

kai zhu kaizhu256 at
Sun Aug 6 02:32:25 UTC 2017

my thoughts are the opposite. javascript (similar to perl and php) already
has a huge number of specialized builtin functions and methods accumulated
over its 20+ year evolution that pretty much solves every practical problem
encountered in frontend programming (and effectively backend as well). the
problem is a failure to educate new programmers on how to use existing
builtins to elegantly solve everyday problems, instead of having them
ignorantly reinvent things on their own.

the mindset to writing javascript programs is more akin to writing perl
programs, e.g. "how do i leverage builtins to implement the requested
one-off UX feature using elegant perl-like one-liners", instead of "how do
i create extra abstractions, classes, and modules to implement this one-off
UX feature".
My thoughts: big source of JavaScript criticism is its small standard
library and community attempts to solve that issue - hundreds of small
modules. Significant part of lodash should be present in standard library.
My lodash selection - chunk, dropWhile, first, last, flatten, fromPairs,
pull, without, takeWhile, zip, flatMap, keyBy, property, groupBy,
partition, sample, shuffle, sortBy, ary, memoize, once, operators as
functions, clamp, inRange, get, mapKeys, mapValues, pickBy, many strings
operations, attempt, constant, flow, noop, range.

On Sat, Aug 5, 2017 at 1:22 PM, T.J. Crowder <tj.crowder at farsightsoftware.
com> wrote:

> I'd find it helpful to have:
> 1. A general steer from TC39 as to whether the committee are committed
> to a robust, feature-rich standard library, or a minimal one (with the
> expectation of a rich ecosystem of libraries, presumably).
> 2. Guidelines of what to consider when proposing standard library features.
> The latter can come from the community; the former needs to come from TC39.
> We see a fair number of simple lib function proposals on the list, it
> would be useful to have some guidelines for what's worth properly
> proposing and what's likely to be a non-starter.
> Naveen Chawla's [recent suggestion][1] is a good case in point: A
> standard lib function for taking an array (ideally, an iterable) and
> creating an object with properties referencing the elements by one of
> their property's values. (One could easily argue for a Set version as
> well.) Ignoring the details of his suggestion, this is a simple
> operation that I've needed in every codebase I've ever worked on. I
> haven't proposed it (having considered doing so repeatedly) because my
> perception had been that TC39 wants to keep the standard lib small.
> But with the additions in 2015, 2016, and 2017, is that simply not the
> case (anymore)?
> Apologies if either (1) or (2) already exist and I've overlooked them.
> -- T.J. Crowder
> [1]:
> ty-element-element-property
> _______________________________________________
> es-discuss mailing list
> es-discuss at

es-discuss mailing list
es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list