How it feels to learn JavaScript in 2016

kai zhu kaizhu256 at
Sat Nov 25 23:30:25 UTC 2017

claude, mature nodejs database drivers with frozen business logic for
stability reasons are examples of libraries that you are asking to
change whenever tc39 decides to expand typeof's on a whim which may
break them.

the maintainers of sqlite3 for example have stated its in maintennance
mode (, and all
commits for the past 2 years have dealt exclusively with its build
process so it can successfully compile with each nodejs release.

i write database code myself.  what was my reaction to the
introduction of the 'symbol' typeof?  annoyance at trying to figure
out what pathological use-case a user might want to pass a 'symbol'
type to the database.  i imagine mongodb / mysql / sqlite3 maintainers
are equally annoyed with trying to figure that out.  if tc39 had
treated symbols as a regular 'object' type, then we wouldn't have that
problem, and the current undefined behavior when its encountered in db

On 11/26/17, Claude Pache <claude.pache at> wrote:
>> Le 25 nov. 2017 à 16:03, kai zhu <kaizhu256 at> a écrit :
>> i disagree.  you can write more maintainable and cleaner code with the
>> premise typeof's will never change again (and give a one-time pass for
>> symbols), instead of over-engineered paranoid code that it *may*
>> change again in the future.
> It is the responsibility of the programmer to write *forward-compatible*
> code, i.e., code that does not make assumptions that are *likely* to break
> in the future. For instance, one can *reasonably* think that the domain of
> the `typeof` operator may expand.
> Naturally, the programmer should be smart enough in order to make the
> difference between paranoia and common sense: this is part of the art of
> programming.
> —Claude

More information about the es-discuss mailing list