Another thought: What will JavaScript code look like once 99% of browsers in
use support ES6? Will we have a language with coherent semantics and a
simple structure? That is: is there a way to drop some of the trickiness,
long term? And which of the approaches gets us there?
In the short term, while people are making the transition, the rule
would be stated as above “If you want the new stuff, turn on strict
mode or wrap a module around it.” Later, once ES6 is everywhere, it
would instead be stated as "Turn on strict mode or code in a module in
order to code in JavaScript. If you don't, you'll be coding instead in
an insane JavaScript fossil that exists merely for compatibility with
old ES3 code. No one even understands its scoping rules."
I'd like to add one JS coder's view, and a suggestion (at the end).
Not long ago, the ES situation -to me- looked like this:
- ES3 engines are dying
- ES5 is about to be in-practice standard (a state now achieved?)
- if you want to look ahead or catch more silly errors, use ES5 strict
- because ES3 engines aren't quite dead, ES5 strict mode
is a pragma that will be ignored by those engines
- ES6 will start from ES5 strict mode
While complicated as status quo, there was a clear progression
path: use ES5 now, move to ES5 strict when possible, in anticipation
of ES6. In particular, it was clear that ES3 dependence or ES5 sloppy
mode were temporary, with very short remaining intended life-time,
and their problematic features, as far as addressed in ES5 strict mode,
were on their way out for ES6 (such as 'with').
These days, 'with' and sloppy mode are still in ES6, and there is
talk of supporting them and ES3-dependent code in combination
with ES6-new-features, perhaps forever ("can't deprecate the web"),
together with in-the-wild code that depends on non-ES features.
The quotes at the top of this message echo Andreas' argument
(ES future is longer than ES past) against a state of discussion that
gives high prominence to the past (support unmaintained code).
In other languages, I would suggest tooling as a remedy (automated
code upgrade, as done for Cobol and the year 2000 issue), but for
JS, that route seems impractical (analysis being undecidable, and
owners of unmaintained JS code being greater in number and
having smaller budgets than those of unmaintained Cobol code).
// suggestion
Perhaps there is a way to make the automated upgrade
problem solvable/cheap? Instead of ES6+ supporting sloppy
mode and strict mode and mixtures of new features with
sloppy mode indefinetly, how about turning the situation
on its head:
- ES6 engines default to strict mode, with new features
(the cleaner future)
- ES6 engines support a "use ES5" pragma
that switches off both new features and strict mode
(give a helping hand to support old code)
- ES6 engines ignore "use strict"
- ES3/5 engines ignore "use ES5"
// end suggestion
That way, you don't have to version to use new language
(the current standard), only to use old language. And all
code owners have to do to support unmaintained code
is to slap "use ES5" in front of it - easily automated.
ES engine implementers would have to support ES5 mode,
but at least they wouldn't have to support mixtures of ES5
sloppy mode and ES6+ features. ES5 mode would treat
ES6 features the way an ES5 engine would.
As an added bonus, future ES committees would have an
easier time querying the web for code still relying on ES5.
Perhaps some day, ES5 mode will no longer be needed,
but meanwhile ES6+ won't be complicated by it.
Just a thought,
Claus
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
