The rationale for strict mode

David-Sarah Hopwood david.hopwood at
Thu Nov 13 14:53:08 PST 2008

Section 4 of the Kona draft says:

# [...] A scripting language is intended for use by both professional
# and nonprofessional programmers. To accommodate non-professional
# programmers, some aspects of the language are defined to be tolerant
# of programmer mistakes. However, such tolerance can easily result in
# programs containing undiscovered errors that professional programmers
# would wish to discover and correct. To facilitate such error detection
# script can be explicitly declared to use a "strict" variant of the
# full ECMAScript language that provides enhanced error detection as well.

However, being "tolerant of programmer mistakes" is a very different
thing than *failing silently* on errors that are commonly caused by
programmer mistakes, which is what ES3, and ES3.1 in non-strict
mode, actually do.

One could make a convincing argument that the behaviour that is
most tolerant of mistakes is to report error conditions resulting
from the mistake as soon as possible, in as many cases as possible.
For that reason, I would strongly advise anyone teaching JavaScript
to teach the ES3.1-strict subset, *especially* to beginning

The basic technical rationale for strict mode is that there were
some language design flaws that we couldn't compatibly fix without
using an opt-in. Strict mode is that opt-in. It has nothing much
to do with whether programmers are professional, or amateur, or

I understand why, for political reasons, the standard document can't
actually say that the lax semantics and silent failures of JavaScript
were just bad language design. However, if it can't say that then it
should at least avoid trying to rationalize historical mistakes. The
text quoted above does not provide a helpful or accurate rationale
for either mode.

Suggested change:
 - delete the above two sentences.
 - add the following, perhaps before the "A scripting language ..."

   ECMAScript code can be run in two modes, "strict" and "non-strict"
   (these may be mixed in the same program). Strict mode reports many
   error conditions, such as accessing a non-existent property of an
   object, by throwing an exception. In non-strict mode these
   conditions silently cause the operation to be ignored or the
   'undefined' value to be used as the result. Previous versions of
   ECMAScript supported only the non-strict semantics. Although the
   strict semantics are generally preferable, the behavior could not
   be compatibly changed without adding strict mode as an "opt-in"

David-Sarah Hopwood

More information about the Es-discuss mailing list