In other words, why is it 'use strict' instead of use strict?
I didn't find an answer to this question here: What does "use strict" do in JavaScript, and what is the reasoning behind it?
My guess is that it makes this instruction backwards compatible without needing any transpilation but I can't find any source.
Yes, it's for backwards compatibility. Some sources:
https://blog.maisie.ink/js-strict-mode/
Strict mode had to be an opt-in feature to maintain backwards compatibility with old scripts. Some old scripts relied on features that strict mode deprecated, and thus, would need to run in non-strict mode by default. Additionally, the opt-in syntax
'use strict';is just a string literal, which allowed new scripts to run in old browsers.
https://medium.com/jp-tech/introduction-to-strict-mode-in-javascript-fb977bab697c
[Why not change the ECMAScript specification completely instead of introducing an extra "strict mode"?] Perhaps part of it is to ensure that some backward compatibility between ES5 and the previous version is ES3, partly so that ECMAScript retains simplicity and flexibility from before, rather than being limited by the new rigid added rules
https://johnresig.com/blog/ecmascript-5-strict-mode-json-and-more/ (John Resig)
Note the syntax that’s used to enable strict mode (I love this!). It’s simply a string in a single statement that happens to contain the contents “use strict”. No new syntax is introduced in order to enable strict mode. This is huge. This means that you can turn strict mode on in your scripts – today – and it’ll have, at worst, no side effect in old browsers.
(found via this answer)
Even more authoritative:
an email by Waldemar Hartmann on the es5-discuss mailing list (apparently a precursor to es-dicuss?), found via those ancient meeting notes:
[…] the general concept of the use strict directive was that it generally followed lexical rules of ECMAScript statements and might even appear unquoted in future versions of the language that had opt-in of syntactic extensions.
the ES5 specification itself notes on the
The ExpressionStatement productions of a Directive Prologue are evaluated normally during evaluation of the containing SourceElements production. Implementations may define implementation specific meanings for ExpressionStatement productions which are not a Use Strict Directive and which occur in a Directive Prologue.
so it's not only backwards-compatible but also forwards-compatible - and this was indeed used for the "use asm"; directive later
the official paper by the spec authors Allen Wirfs-Brock and Brendan Eich on JavaScript explains the reasoning in detail:
An early issue was how the opt-in to strict mode would work. […] One possibility was to use a special form of comment as a directive. However, the ES3.1 working group was reluctant to make comments, of any form, semantically significant because JavaScript minimizers remove comments. Allen Wirfs-Brock observed that the syntax of an ECMAScript ExpressionStatement makes any expression, including those that consist of only a literal string constant, into a valid statement as long as it is explicitly or implicitly (via ASI) followed by a semicolon. That means that a statement such as
"use strict";is syntactically valid ES3 code. Because it is simply a constant value, evaluating it has no side effects in ES3. It is a no-op. It appeared quite safe to use such a statement as the opt-in for strict mode as it seemed highly unlikely that any existing JavaScript code would already have used that exact statement form and an ES3 implementation would ignore its presence in any ES5 code that was loaded. The working group adopted that idea. A statement of the form"use strict";occurring as the first statement of a script or a function body indicated that the entire script or function should be processed using strict mode semantics.
For backwards compatibility.
Browsers that don't support strict mode will simply ignore the string.
