> WeakReferences,
-1 footgun most web-devs have no idea how to use correctly (including me)

> OGG manipulation,
-0.5 slightly prefer it as an npm module

> MPEG manipulation,
-0.5 slightly prefer it as an npm module

> builtin support for Kerberos,

> Bzip2 bindings,
-1 use nodejs child_process system calls to bzip2.  i don’t see any common 
use-case for bzip2 other than file-to-file operations which can be accomplished 
with shell-scripting.

> Zlib bindings,
already a nodejs builtin

> configurable random number generation,
-1 Math.random is good-enough for most use-cases.  for the normal-distribution 
use-case, its easy enough to write your own transform with sine/cosine.

> OpenSSL bindings,
already a nodejs builtin

> simple hashing,
+1 would be nice to have

> drivers for databases,
+1 a STABLE nodejs sqlite3 builtin is sorely needed for embedded systems 
(instead of the flaky npm module), but need to nag nodejs folks, not tc39

> ImageMagick bindings,
-1 use nodejs child_process system calls to imagemagick.  i'm skeptical builtin 
bindings would be significantly more efficient enough to be worth the effort.

> arbitrary precision math,
-0.5 generally against due to it confusing people with 2 different numeric 
types, though i slightly sympathize with accounting/finance use-cases for 
decimal arithmetic.

> statistics support,
+1 would be useful

> GPG support,

> PostScript support,
-1 use nodejs child_process system calls, as bindings would not be 
significantly more efficient.

> Judy Arrays,
-1 too esoteric and confusing to understand what the use-cases are for most 

> neural networks,
-1 slightly too big a scope, and more the domain of wasm

> Lua integration,

> FTP support,
-0.5 i don’t see much use-case for an ftp-client but i may be wrong

> XML support,

> 9 data structures,
-1 javascript is a high-level language with a builtin feature-set targeted for 
expressing high-level concepts like ajax, file-uploads, event-handling, 
dom-manipulations, programmable forward/reverse proxies, etc.  its NOT a 
low-level language for creating esoteric data-structures and algorithms in 
academia that have little relevance to web-development.

> recursive iterators
javascript already has recursive closures that i frequently use like recursive 

> On Aug 6, 2017, at 5:40 PM, Michał Wadas <> wrote:
> I disagree.
> PHP have WeakReferences, OGG manipulation, MPEG manipulation, builtin support 
> for Kerberos, Bzip2 bindings, Zlib bindings, configurable random number 
> generation, OpenSSL bindings, simple hashing, drivers for databases, 
> ImageMagick bindings, arbitrary precision math, statistics support, GPG 
> support, PostScript support, Judy Arrays, neural networks, Lua integration, 
> FTP support, XML support, 9 data structures, recursive iterators with well 
> defined interfaces etc.
> All of them are missing in JavaScript. PHP have extremely bloated standard 
> library - and JS have very minimal one. 
> On Sun, Aug 6, 2017 at 4:32 AM, kai zhu < 
> <>> wrote:
> 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 < 
> <>> 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]: 
> <>
> _______________________________________________
> es-discuss mailing list
> <>
> <>
> _______________________________________________
> es-discuss mailing list
> <>
> <>

es-discuss mailing list

Reply via email to