We are just talking on how we can enhance JS without “breaking the web”. And the solution we are talking about is to make a major revision of JS (JS version 2), instead of breaking the current one (JS version 1).
From: Brendan Eich [mailto:brendan.e...@gmail.com] Sent: Tuesday, July 25, 2017 5:51 PM To: Alexander Craggs <alexan...@debenclipper.com>; doodad-js Admin <dooda...@gmail.com>; es-discuss@mozilla.org Subject: Re: FW: Removal of language features This thread makes me want to unsubscribe from es-discuss. I think I recreated the list. :-( Please read https://esdiscuss.org/topic/no-more-modes and https://esdiscuss.org/topic/use-es6-any-plans-for-such-a-mode#content-2. "Don't break the web" is not some vague high-minded notion of TC39's. It's a consequence of hard-to-change browser-market game theory. No browser wants to risk (however small the risk) breaking what might be more of the web than one thinks at first. It's very hard to find out what "the web" is and prove absence of breakage (paywalls, firewalls, archives, intranets, etc.). There's very little gain and potentially much pain, which could mean support calls and market share loss. This is not just a browser market failure. Developers don't want their code broken, until they stop using something and then ask for it to be removed. That is not globally coordinated so it won't fly, as browser market share depends in part on developer testing and use of browsers. Ecosystem effects mitigate against breaking the web in deep ways, _in general_. Yet ECMA-262 has broken compatibility in a few edge cases. And browser competition led to some dead limbs and underspecified pain-points (e.g., global object prototype chain). And Google people seem to be leading the Web Intervention Community Group, which wants to break the web a bit (rather than block 3rd party ad/tracking scripts :-P). So perhaps we can break some DOM APIs such as sync touch events, without also breaking gmail :-). The jury is still out in my view, but Chrome has enough market power to push and assume more risk than other browsers. Core language changes are different in kind from sync touch events. It's very hard to plan to remove anything on a practical schedule or order-of-work basis. Engine maintainers likely still hate more modes, and users should too. New syntax as its own opt-in still wins, although this obligates TC39 to work on future-proofing, e.g., : after declarator name in declaration for type annotation syntax. So based on 22+ years doing JS, I believe anything like opt-in versioning for ES4, a la Python3 or Perl6, is a non-starter. Period, end of story. Ok, I'm not unsubscribing -- but I hope more people read and search https://esdiscuss.org/ and engage with history instead of coming as if to a blank slate. Santayana's dictum applies. /be On Tue, Jul 25, 2017 at 2:10 PM Alexander Craggs <alexan...@debenclipper.com <mailto:alexan...@debenclipper.com> > wrote: I think version interoperability is a must in a world of Webpack & Browserify. On 25/07/2017 21:12:58, doodad-js Admin <dooda...@gmail.com <mailto:dooda...@gmail.com> > wrote: * How are you going to deal with scenarios that don't have extensions, e.g. REPL or inline JS. For inline, that’ll be: <script type=”application/javascript.2>...</script> For REPL, I don’t know... I didn’t think about this one :-) It should be based of the content of the page. And I don’t know if we should allow to mix different versions together. That’s things we’ll have to clarify. * Are extensions going to be released often, or is this going to be a one time thing? Just at another new major revision of JS, which should not happen before a long time. * would it make more sense to start on js7 instead of js2 No, because ES6, ES7, ... are still JS 1. From: Alexander Craggs [mailto:alexan...@debenclipper.com <mailto:alexan...@debenclipper.com> ] Sent: Tuesday, July 25, 2017 3:54 PM To: doodad-js Admin <dooda...@gmail.com <mailto:dooda...@gmail.com> >; es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> Subject: Re: FW: Removal of language features I'm sorry, I missed that suggestion. That definitely sounds significantly better than a new MIME type. Although two thoughts I have are: - How are you going to deal with scenarios that don't have extensions, e.g. REPL or inline JS. - Are extensions going to be released often, or is this going to be a one time thing? For example, would we increment the version number with the current JS version (js6, js7 etc) and if so, would it make more sense to start on js7 instead of js2? _______________________________________________ es-discuss mailing list es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> https://mail.mozilla.org/listinfo/es-discuss <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> www.avg.com
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
