Re: Removal of language features

[Allen Wirfs-Brock]

> On Jul 26, 2017, at 11:02 PM, Michael Kriegel 
>  wrote:
> 
> Maybe TC39 should think about a deprecation plan, which includes rules for 
> fairness between browser vendors. For example, if the feature `RegExp.$1` 
> shall be removed. Then:
> 1. At date X, the feature gets marked as deprecated.
> 
> 2. Within 6 Months from X, all browser vendors must…
> 
TC39 has absolutely no authority to tell browser vendors (or anybody else) that 
they must do something.

All TC39 can do is publish specifications that say what a conforming 
implementation must do. It is completely up to implementations to choose to 
conform or not. 


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[Mike Samuel]

On Thu, Jul 27, 2017 at 1:33 AM, Isiah Meadows  wrote:
> I agree. The only people who really have a stake in this discussion apart
> from committee members are implementors, and trust me: they really don't
> like having to support features deprecated for over a decade.

I am not an implementor, but I would like to restake my claim as a
security practitioner that I made in

https://esdiscuss.org/topic/removal-of-language-features#content-7


> My only question at this point is: would it be possible to emit deprecation
> warnings for some features, so it would be easier to remove some of the
> legacy bloat? (example: `RegExp.$1`)

Linters were mentioned earlier as a mechanism for this.  The problem,
as Brendan pointed out, is that you have to get the usage rate very
low or have browsers coordinate closely on breaking the holdouts.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[Boris Zbarsky]

On 7/27/17 2:02 AM, Michael Kriegel wrote:

4. At a fixed date (e.g. 24 Months after X) all browsers must stop
supporting the feature


How do you plan to enforce this?

Please note that the people representing browsers in this committee may 
not (and afaict generally do not) make ship/no-ship product decisions 
for their browsers, so the can't even credibly commit to what you suggest.



Authors of Websites, for which there is still interest, will update
their code. Other websites will just break and nobody will care.


Unfortunately, you're wrong.  That's because interest is asymmetric: 
_users_ may have interest in a site even if the _author_ does not.  So 
it's quite possible (and in fact has happened before) that sites will 
not be updated, they will break, and users will in fact care.


This happens all the time, even with well-advertised multi-year 
deprecations, well publicized cutoff times and large companies that have 
the resources to update their sites if they want to.  See the story of 
Google Hangouts, for example.



So I do not see a risk of "breaking the web" when there is such a clear
plan set up. There would be just the question how browser vendors could
be punished, if they do not comply and try to get an advantage over
other browsers by continuing support of those old features...?


Good luck with that.

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Andreas Rossberg]

On 27 July 2017 at 14:23, Mark  wrote:

>
> if Joe User observes that a website suddenly got notably slower with a new
> version of their browser then they will blame the browser.
>
> This is a rather large assumption to make and, at the same time, I don’t
> think it is true. When users go to a slow-loading website, I think it’s
> much more likely they’ll blame the website developer. If an application
> runs slow on your OS, you wouldn’t blame it on the OS vendor. Similarly, if
> an application I just upgraded runs slow on my mobile device, I wouldn’t
> automatically assume it's the phone manufacturer.
>
I'm talking about the situation were they upgrade the browser and observe
that a known site runs slower afterwards than it did before. Nothing else
changed. Of course they gonna blame it on the browser update, and correctly
so.



> ​
>
> On Thu, Jul 27, 2017 at 7:55 AM kai zhu  wrote:
>
>> On Jul 27, 2017, at 5:43 PM, Andreas Rossberg 
>> wrote:
>>
>>
>> That is not always true. For example, ES6 has caused some notable
>> performance regressions for ES5 code initially, due to extensions to the
>> object model that made it even more dynamic. The new @@-hooks were
>> particularly nasty and some cases required substantial amounts of work from
>> implementers just to get back close to the previous baseline performance.
>> Parsing also slowed down measurably. Moreover, many features tend to add
>> combinatorial complexity that can make the surface of "common cases" to
>> optimise for in preexisting features much larger.
>>
>>
>> I’ve noticed chrome 59 freezing more when initially loading pages.  Maybe
>> its due to performance-penalty of extra parser complexity, maybe not.
>> Also, the chrome-based electron-browser has gotten slower with each release
>> over the past year, when I use it to test mostly es5-based browser-code.
>> Can’t say about the other browser-vendors as I don’t use them as much.
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Mark]

*Reposting (with edits) because I accidentally sent this to only Andreas*

if Joe User observes that a website suddenly got notably slower with a new
version of their browser then they will blame the browser.

This is a rather large assumption to make and, at the same time, I don’t
think it is true. When users go to a slow-loading website, I think it’s
much more likely they’ll blame the website developer. If an application
runs slow on your OS, you wouldn’t blame it on the OS vendor. Similarly, if
an application I just upgraded runs slow on my mobile device, I wouldn’t
automatically assume it's the phone manufacturer.
​

On Thu, Jul 27, 2017 at 7:55 AM kai zhu  wrote:

> On Jul 27, 2017, at 5:43 PM, Andreas Rossberg  wrote:
>
>
> That is not always true. For example, ES6 has caused some notable
> performance regressions for ES5 code initially, due to extensions to the
> object model that made it even more dynamic. The new @@-hooks were
> particularly nasty and some cases required substantial amounts of work from
> implementers just to get back close to the previous baseline performance.
> Parsing also slowed down measurably. Moreover, many features tend to add
> combinatorial complexity that can make the surface of "common cases" to
> optimise for in preexisting features much larger.
>
>
> I’ve noticed chrome 59 freezing more when initially loading pages.  Maybe
> its due to performance-penalty of extra parser complexity, maybe not.
> Also, the chrome-based electron-browser has gotten slower with each release
> over the past year, when I use it to test mostly es5-based browser-code.
> Can’t say about the other browser-vendors as I don’t use them as much.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[T.J. Crowder]

On Thu, Jul 27, 2017 at 12:55 PM, kai zhu
 wrote:
> I’ve noticed chrome 59 freezing more when initially loading
> pages. Maybe its due to performance-penalty of extra parser
> complexity, maybe not.

Much more likely due to the major changes in V8 v5.9:
https://v8project.blogspot.co.uk/2017/05/launching-ignition-and-turbofan.html

-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[kai zhu]

On Jul 27, 2017, at 5:43 PM, Andreas Rossberg  wrote:
> 
> That is not always true. For example, ES6 has caused some notable performance 
> regressions for ES5 code initially, due to extensions to the object model 
> that made it even more dynamic. The new @@-hooks were particularly nasty and 
> some cases required substantial amounts of work from implementers just to get 
> back close to the previous baseline performance. Parsing also slowed down 
> measurably. Moreover, many features tend to add combinatorial complexity that 
> can make the surface of "common cases" to optimise for in preexisting 
> features much larger.


I’ve noticed chrome 59 freezing more when initially loading pages.  Maybe its 
due to performance-penalty of extra parser complexity, maybe not.  Also, the 
chrome-based electron-browser has gotten slower with each release over the past 
year, when I use it to test mostly es5-based browser-code.  Can’t say about the 
other browser-vendors as I don’t use them as much.___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Andreas Rossberg]

On 27 July 2017 at 12:07, Mark  wrote:

> I think it is a mistake to assume that a developer has a right to always
> have optimal performance without requiring anything to get it.  It almost
> sounds like you're saying that there should be no cost to the consumer for
> choosing not to evolve with the language.
>

In an ideal world, I would agree. But that's not how the game theory works
out on the web. What Brendan already pointed out wrt breaking sites also
applies to performance regressions: if Joe User observes that a website
suddenly got notably slower with a new version of their browser then they
will blame the browser. That effect is further elevated by tech reviews
often performing measurements with hopelessly outdated benchmarks. So no
browser vendor can afford significant regressions, unless they have an urge
to look bad in public perception.



>
> Things we buy into in life (not just a coding language) will depreciate in
> value and will require either an upgrade or a replacement or significant
> maintenance and, if not done, the consumer will suffer the consequences of
> choosing to remain stagnant. And the longer the stagnation, the greater the
> change needed to put the consumer in the same (or better) position they
> were in before the depreciation got so bad.
>
> That said, I'm still struggling to see a real need to remove older JS
> features.
>
> On Thu, Jul 27, 2017 at 5:44 AM Andreas Rossberg 
> wrote:
>
>> On 27 July 2017 at 11:00, Mark  wrote:
>>
>>> It has already been mentioned that there is likely no performance
>>> degradation when adding new features.
>>>
>>
>> That is not always true. For example, ES6 has caused some notable
>> performance regressions for ES5 code initially, due to extensions to the
>> object model that made it even more dynamic. The new @@-hooks were
>> particularly nasty and some cases required substantial amounts of work from
>> implementers just to get back close to the previous baseline performance.
>> Parsing also slowed down measurably. Moreover, many features tend to add
>> combinatorial complexity that can make the surface of "common cases" to
>> optimise for in preexisting features much larger.
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Mark]

Yeah, but performance issues are different from not being
backwards-compatible.

I think it is a mistake to assume that a developer has a right to always
have optimal performance without requiring anything to get it.  It almost
sounds like you're saying that there should be no cost to the consumer for
choosing not to evolve with the language.

Things we buy into in life (not just a coding language) will depreciate in
value and will require either an upgrade or a replacement or significant
maintenance and, if not done, the consumer will suffer the consequences of
choosing to remain stagnant. And the longer the stagnation, the greater the
change needed to put the consumer in the same (or better) position they
were in before the depreciation got so bad.

That said, I'm still struggling to see a real need to remove older JS
features.

On Thu, Jul 27, 2017 at 5:44 AM Andreas Rossberg 
wrote:

> On 27 July 2017 at 11:00, Mark  wrote:
>
>> It has already been mentioned that there is likely no performance
>> degradation when adding new features.
>>
>
> That is not always true. For example, ES6 has caused some notable
> performance regressions for ES5 code initially, due to extensions to the
> object model that made it even more dynamic. The new @@-hooks were
> particularly nasty and some cases required substantial amounts of work from
> implementers just to get back close to the previous baseline performance.
> Parsing also slowed down measurably. Moreover, many features tend to add
> combinatorial complexity that can make the surface of "common cases" to
> optimise for in preexisting features much larger.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Andreas Rossberg]

On 27 July 2017 at 11:00, Mark  wrote:

> It has already been mentioned that there is likely no performance
> degradation when adding new features.
>

That is not always true. For example, ES6 has caused some notable
performance regressions for ES5 code initially, due to extensions to the
object model that made it even more dynamic. The new @@-hooks were
particularly nasty and some cases required substantial amounts of work from
implementers just to get back close to the previous baseline performance.
Parsing also slowed down measurably. Moreover, many features tend to add
combinatorial complexity that can make the surface of "common cases" to
optimise for in preexisting features much larger.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Mark]

I've been following this thread since it started. Maybe it's in here
somewhere and I missed it throughout these many comments. But...

It has already been mentioned that there is likely no performance
degradation when adding new features. If performance is an issue because a
developer is using legacy/outdated methods in their code, the developer
should just update their methods to use the newer better ones in the newer
API that was introduced.

Alternatively, JS has done a good job of adding new features that are
optional and that do not affect outdated ones, so there is nothing lost
here. If you don't want to use a new feature, don't use it... ever (if
necessary).

So can someone give me at least a couple of hard use cases where
introducing a new JS feature requires the removal of another? And not
removing the feature, would cause significant harm to the future of the
language? I don't mean just some anecdotal or insignificant case like
having to choose a different reserved word because it was already used
before (i.e. will we run out of words? :) )

AFAICT, the committee is working extremely hard to introduce some pretty
new and exciting things to JS every day .
And I don't think this progress would be improved that much by removal old
JS features. So I'm seriously having trouble understanding the assumption
that we need to remove JS features just to move the language forward.
​


On Thu, Jul 27, 2017, 4:30 AM Bruno Jouhier  wrote:

> > 3. At a fixed date (e.g. 12 Months after X) all browsers must show a
> > warning to the user (e.g. red address bar, etc.), when the website he
> > visits uses a feature from the deprecation list: "The website you are
> > visiting uses features, which will be removed in the future. Please ask
> > the website owner to update his website." - All browser vendors are
> > obliged to start this warning beginning with that date - so the browser
> > has to check for the date.
>
> My step mother calls me: Bruno, there is a strange message on my screen.
> Can you help! I reassure here.
>
> > 4. At a fixed date (e.g. 24 Months after X) all browsers must stop
> > supporting the feature, which means that they just refuse to show that
> > broken website and instead show a message to the user, that the website
> > cannot be shown anymore, because its features are not supported anymore.
>
> My step mother calls again: my tablet is broken, can you fix it?
>
> The web site that my step mother was visiting was built by the
> non-profit accountant's nephew eight years ago. He is climbing a mountain.
>
> We see things with our technologist eyes. Many (most?) web users don't
> understand whether something is wrong with the browser or with the server,
> or with the network (and they don't care). For them it is just "broken".
>
> We've broken the web. My step mother is happy with her apps.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Bruno Jouhier]

> 3. At a fixed date (e.g. 12 Months after X) all browsers must show a
> warning to the user (e.g. red address bar, etc.), when the website he
> visits uses a feature from the deprecation list: "The website you are
> visiting uses features, which will be removed in the future. Please ask
> the website owner to update his website." - All browser vendors are
> obliged to start this warning beginning with that date - so the browser
> has to check for the date.

My step mother calls me: Bruno, there is a strange message on my screen.
Can you help! I reassure here.

> 4. At a fixed date (e.g. 24 Months after X) all browsers must stop
> supporting the feature, which means that they just refuse to show that
> broken website and instead show a message to the user, that the website
> cannot be shown anymore, because its features are not supported anymore.

My step mother calls again: my tablet is broken, can you fix it?

The web site that my step mother was visiting was built by the
non-profit accountant's nephew eight years ago. He is climbing a mountain.

We see things with our technologist eyes. Many (most?) web users don't
understand whether something is wrong with the browser or with the server,
or with the network (and they don't care). For them it is just "broken".

We've broken the web. My step mother is happy with her apps.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[Isiah Meadows]

ch
>> helps anyone...
>>
>> I see TC39 members/supporters who say, there is no issue for them still
>> having the old features in place:
>>
>> Brendan Eich (TC39): "There's no evidence (I'm sitting in a TC39
>> meeting) other than grumping from a few that we are near the point of JS
>> painted into a corner by backward compatibility."
>>
>> Andreas Rossberg (google): "As for the reoccurring assumption that
>> deprecation would help simplifying JavaScript implementations: no, not
>> to a relevant degree (...) And clearly, modes or versions only make
>> things worse in that regard."
>>
>>
>> Can't we agree on the following:
>>
>> "As long as TC39 members do not feel being painted into a corner because
>> of backwards compatibility and as long as browser vendors do not
>> indicate having trouble maintaining the old features and as long as
>> those old features are not security risks by design, there is no need to
>> discuss further about the removal of language features."?
>>
>> As a developer, "a user" of JavaScript I have no problem with features
>> around, which I do not use. If there are features a group of people (and
>> even if it were the whole JS developer community) agrees to be evil,
>> they can agree not to use them. And as a developer using JavaScript I am
>> thankful for the great work the TC39 and browser vendor guys do to keep
>> this all rolling. And if they say one time, that they (for a good
>> reason) have to abandon a feature, which I used and maybe even liked, I
>> would spend all time necessary on making my software work without it.
>> That being said I see no value in us developers discussing about
>> removing old features which we just do not like.
>>
>>
>> On 27.07.2017 01:14, Tab Atkins Jr. wrote:
>> > On Wed, Jul 26, 2017 at 3:37 PM, Florian Bösch 
>> wrote:
>> >> On Thu, Jul 27, 2017 at 12:18 AM, Brendan Eich > >
>> >> wrote:
>> >>> The solution is not to hate JS. It's not going to change incompatibly.
>> >>> Rather, you can use linters, "transpilers", compilers, voluntary
>> unchecked
>> >>> subsets -- all possible today.
>> >>
>> >> So basically "the best way to use JS is to not use JS". Awesome.
>> > That's the downside of shipping your programs to customers as source,
>> > and letting them use any of 100+ compilers of varying ages and quality
>> > to compile your code.  (There's plenty of upsides, of course.)
>> >
>> > As Brendan said, examples of other languages don't really apply,
>> > because they compile on the developer end, and just ship binaries to
>> > customers. (Or something that has the same effect, like shipping
>> > source+interpreter to customers in a package.)  If you want to benefit
>> > from those network dynamics, you have to compile on your end, or in
>> > the language of today, "transpile".
>> >
>> > That doesn't mean "not use JS" - Babel and related projects let you
>> > use modern JS, and you can apply whatever restrictions you want.  Or
>> > you can go ahead and abandon JS, and use one of the myriad of
>> > alternative transpilation languages. Whatever floats your boat.
>> >
>> > But you can't get around the mathematics.  Delivering plain source,
>> > without a well-controlled compiler monopoly, means breaking changes
>> > are very, very hard to make.  Best to make peace with it and engineer
>> > around it, rather than futilely fight it.
>> >
>> > ~TJ
>> > ___
>> > es-discuss mailing list
>> > es-discuss@mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>>
>> --
>> Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 •
>> CH-6340 Baar • www.actifsource.com • +41 56 250 40 02
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> --
> Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 
> Baar • www.actifsource.com • +41 56 250 40 02
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[Bill Frantz]

On 7/26/17 at 3:18 PM, brendan.e...@gmail.com (Brendan Eich) wrote:


If you are concerned about JS pedagogy or marketing, the solution already
practiced is to subset. Just as when teaching English or another evolved,
irregularity-ridden living language.


The real problem with bloat is reading code, not writing it. 
However, if a reader can easily look up a nearly abandoned, but 
still supported, construct to find out what it does and what 
footguns it includes, that situation is probably better than 
having some unmaintained web site fail when a new version of a 
browser comes out that no longer supports that construct.


YMMV - Bill

-
Bill Frantz| Re: Hardware Management Modes: | Periwinkle
(408)356-8506  | If there's a mode, there's a   | 16345 
Englewood Ave
www.pwpconsult.com | failure mode. - Jerry Leichter | Los Gatos, 
CA 95032


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[Michael Kriegel]

Maybe TC39 should think about a deprecation plan, which includes rules 
for fairness between browser vendors. For example, if the feature 
`RegExp.$1` shall be removed. Then:


1. At date X, the feature gets marked as deprecated.

2. Within 6 Months from X, all browser vendors must have taken this 
feature up in their deprecation list and show a deprecation warning in 
the console.


3. At a fixed date (e.g. 12 Months after X) all browsers must show a 
warning to the user (e.g. red address bar, etc.), when the website he 
visits uses a feature from the deprecation list: "The website you are 
visiting uses features, which will be removed in the future. Please ask 
the website owner to update his website." - All browser vendors are 
obliged to start this warning beginning with that date - so the browser 
has to check for the date.


4. At a fixed date (e.g. 24 Months after X) all browsers must stop 
supporting the feature, which means that they just refuse to show that 
broken website and instead show a message to the user, that the website 
cannot be shown anymore, because its features are not supported anymore.


5. All browser versions released after that must have the feature 
permanently disabled or removed.


Authors of Websites, for which there is still interest, will update 
their code. Other websites will just break and nobody will care. 
Companies using browser based internal tools may decide to stick with 
older browser versions for that purpose, which is totally fine, it's 
their risk (security holes, etc.?)


(Optional idea at step 2: If the website author enabled it, the browser 
tries to send a deprecation warning to deprecation-warn...@whatever.ch 
where whatever.ch is the domain of the website the user visited. Or 
maybe this should be communicated to the web server which may then send 
a message itself)


So I do not see a risk of "breaking the web" when there is such a clear 
plan set up. There would be just the question how browser vendors could 
be punished, if they do not comply and try to get an advantage over 
other browsers by continuing support of those old features...? Maybe 
search engine developers could agree on degrading websites which use 
deprecated features after point 3 in time, which would reduce the 
interest of people in that web site and increase the will of the website 
owner to improve.


This was just thinking out loud... I will stick to every decision TC39 
makes about language feature removal.



On 27.07.2017 07:33, Isiah Meadows wrote:


I agree. The only people who really have a stake in this discussion 
apart from committee members are implementors, and trust me: they 
really don't like having to support features deprecated for over a decade.


My only question at this point is: would it be possible to emit 
deprecation warnings for some features, so it would be easier to 
remove some of the legacy bloat? (example: `RegExp.$1`)



On Thu, Jul 27, 2017, 01:21 Michael Kriegel 
<mailto:michael.krie...@actifsource.com>> wrote:


I read this discussion for a long time and I do not see anything which
helps anyone...

I see TC39 members/supporters who say, there is no issue for them
still
having the old features in place:

Brendan Eich (TC39): "There's no evidence (I'm sitting in a TC39
meeting) other than grumping from a few that we are near the point
of JS
painted into a corner by backward compatibility."

Andreas Rossberg (google): "As for the reoccurring assumption that
deprecation would help simplifying JavaScript implementations: no, not
to a relevant degree (...) And clearly, modes or versions only make
things worse in that regard."


Can't we agree on the following:

"As long as TC39 members do not feel being painted into a corner
because
of backwards compatibility and as long as browser vendors do not
indicate having trouble maintaining the old features and as long as
those old features are not security risks by design, there is no
need to
discuss further about the removal of language features."?

As a developer, "a user" of JavaScript I have no problem with features
around, which I do not use. If there are features a group of
people (and
even if it were the whole JS developer community) agrees to be evil,
they can agree not to use them. And as a developer using
JavaScript I am
thankful for the great work the TC39 and browser vendor guys do to
keep
this all rolling. And if they say one time, that they (for a good
reason) have to abandon a feature, which I used and maybe even
liked, I
would spend all time necessary on making my software work without it.
That being said I see no value in us developers discussing about
removing old features which we just do not like.


On 27.07.2017 01:14, Tab Atkins Jr. wrote:
> On W

Re: FW: Removal of language features

[Isiah Meadows]

I agree. The only people who really have a stake in this discussion apart
from committee members are implementors, and trust me: they really don't
like having to support features deprecated for over a decade.

My only question at this point is: would it be possible to emit deprecation
warnings for some features, so it would be easier to remove some of the
legacy bloat? (example: `RegExp.$1`)

On Thu, Jul 27, 2017, 01:21 Michael Kriegel 
wrote:

> I read this discussion for a long time and I do not see anything which
> helps anyone...
>
> I see TC39 members/supporters who say, there is no issue for them still
> having the old features in place:
>
> Brendan Eich (TC39): "There's no evidence (I'm sitting in a TC39
> meeting) other than grumping from a few that we are near the point of JS
> painted into a corner by backward compatibility."
>
> Andreas Rossberg (google): "As for the reoccurring assumption that
> deprecation would help simplifying JavaScript implementations: no, not
> to a relevant degree (...) And clearly, modes or versions only make
> things worse in that regard."
>
>
> Can't we agree on the following:
>
> "As long as TC39 members do not feel being painted into a corner because
> of backwards compatibility and as long as browser vendors do not
> indicate having trouble maintaining the old features and as long as
> those old features are not security risks by design, there is no need to
> discuss further about the removal of language features."?
>
> As a developer, "a user" of JavaScript I have no problem with features
> around, which I do not use. If there are features a group of people (and
> even if it were the whole JS developer community) agrees to be evil,
> they can agree not to use them. And as a developer using JavaScript I am
> thankful for the great work the TC39 and browser vendor guys do to keep
> this all rolling. And if they say one time, that they (for a good
> reason) have to abandon a feature, which I used and maybe even liked, I
> would spend all time necessary on making my software work without it.
> That being said I see no value in us developers discussing about
> removing old features which we just do not like.
>
>
> On 27.07.2017 01:14, Tab Atkins Jr. wrote:
> > On Wed, Jul 26, 2017 at 3:37 PM, Florian Bösch  wrote:
> >> On Thu, Jul 27, 2017 at 12:18 AM, Brendan Eich 
> >> wrote:
> >>> The solution is not to hate JS. It's not going to change incompatibly.
> >>> Rather, you can use linters, "transpilers", compilers, voluntary
> unchecked
> >>> subsets -- all possible today.
> >>
> >> So basically "the best way to use JS is to not use JS". Awesome.
> > That's the downside of shipping your programs to customers as source,
> > and letting them use any of 100+ compilers of varying ages and quality
> > to compile your code.  (There's plenty of upsides, of course.)
> >
> > As Brendan said, examples of other languages don't really apply,
> > because they compile on the developer end, and just ship binaries to
> > customers. (Or something that has the same effect, like shipping
> > source+interpreter to customers in a package.)  If you want to benefit
> > from those network dynamics, you have to compile on your end, or in
> > the language of today, "transpile".
> >
> > That doesn't mean "not use JS" - Babel and related projects let you
> > use modern JS, and you can apply whatever restrictions you want.  Or
> > you can go ahead and abandon JS, and use one of the myriad of
> > alternative transpilation languages. Whatever floats your boat.
> >
> > But you can't get around the mathematics.  Delivering plain source,
> > without a well-controlled compiler monopoly, means breaking changes
> > are very, very hard to make.  Best to make peace with it and engineer
> > around it, rather than futilely fight it.
> >
> > ~TJ
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
> --
> Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340
> Baar • www.actifsource.com • +41 56 250 40 02
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[Michael Kriegel]

I read this discussion for a long time and I do not see anything which 
helps anyone...


I see TC39 members/supporters who say, there is no issue for them still 
having the old features in place:


Brendan Eich (TC39): "There's no evidence (I'm sitting in a TC39 
meeting) other than grumping from a few that we are near the point of JS 
painted into a corner by backward compatibility."


Andreas Rossberg (google): "As for the reoccurring assumption that 
deprecation would help simplifying JavaScript implementations: no, not 
to a relevant degree (...) And clearly, modes or versions only make 
things worse in that regard."



Can't we agree on the following:

"As long as TC39 members do not feel being painted into a corner because 
of backwards compatibility and as long as browser vendors do not 
indicate having trouble maintaining the old features and as long as 
those old features are not security risks by design, there is no need to 
discuss further about the removal of language features."?


As a developer, "a user" of JavaScript I have no problem with features 
around, which I do not use. If there are features a group of people (and 
even if it were the whole JS developer community) agrees to be evil, 
they can agree not to use them. And as a developer using JavaScript I am 
thankful for the great work the TC39 and browser vendor guys do to keep 
this all rolling. And if they say one time, that they (for a good 
reason) have to abandon a feature, which I used and maybe even liked, I 
would spend all time necessary on making my software work without it. 
That being said I see no value in us developers discussing about 
removing old features which we just do not like.



On 27.07.2017 01:14, Tab Atkins Jr. wrote:

On Wed, Jul 26, 2017 at 3:37 PM, Florian Bösch  wrote:

On Thu, Jul 27, 2017 at 12:18 AM, Brendan Eich 
wrote:

The solution is not to hate JS. It's not going to change incompatibly.
Rather, you can use linters, "transpilers", compilers, voluntary unchecked
subsets -- all possible today.


So basically "the best way to use JS is to not use JS". Awesome.

That's the downside of shipping your programs to customers as source,
and letting them use any of 100+ compilers of varying ages and quality
to compile your code.  (There's plenty of upsides, of course.)

As Brendan said, examples of other languages don't really apply,
because they compile on the developer end, and just ship binaries to
customers. (Or something that has the same effect, like shipping
source+interpreter to customers in a package.)  If you want to benefit
from those network dynamics, you have to compile on your end, or in
the language of today, "transpile".

That doesn't mean "not use JS" - Babel and related projects let you
use modern JS, and you can apply whatever restrictions you want.  Or
you can go ahead and abandon JS, and use one of the myriad of
alternative transpilation languages. Whatever floats your boat.

But you can't get around the mathematics.  Delivering plain source,
without a well-controlled compiler monopoly, means breaking changes
are very, very hard to make.  Best to make peace with it and engineer
around it, rather than futilely fight it.

~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


--
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar 
• www.actifsource.com • +41 56 250 40 02


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[Tab Atkins Jr.]

On Wed, Jul 26, 2017 at 3:37 PM, Florian Bösch  wrote:
> On Thu, Jul 27, 2017 at 12:18 AM, Brendan Eich 
> wrote:
>>
>> The solution is not to hate JS. It's not going to change incompatibly.
>> Rather, you can use linters, "transpilers", compilers, voluntary unchecked
>> subsets -- all possible today.
>
>
> So basically "the best way to use JS is to not use JS". Awesome.

That's the downside of shipping your programs to customers as source,
and letting them use any of 100+ compilers of varying ages and quality
to compile your code.  (There's plenty of upsides, of course.)

As Brendan said, examples of other languages don't really apply,
because they compile on the developer end, and just ship binaries to
customers. (Or something that has the same effect, like shipping
source+interpreter to customers in a package.)  If you want to benefit
from those network dynamics, you have to compile on your end, or in
the language of today, "transpile".

That doesn't mean "not use JS" - Babel and related projects let you
use modern JS, and you can apply whatever restrictions you want.  Or
you can go ahead and abandon JS, and use one of the myriad of
alternative transpilation languages. Whatever floats your boat.

But you can't get around the mathematics.  Delivering plain source,
without a well-controlled compiler monopoly, means breaking changes
are very, very hard to make.  Best to make peace with it and engineer
around it, rather than futilely fight it.

~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: FW: Removal of language features

[doodad-js Admin]

I feel like a reticence on starting a new version of JS. After all, JS is only 
at version 1 and has survived at least 20 years. Every software, including 
languages, are having major versions with breaking changes. And I don’t see why 
JS should be an exception. That just would be great to make a big cleanup, 
stabilize things, make real classes, a real type system (dynamic or static) ... 
But maybe that’s reserved for another new Web language after all.

 

From: Brendan Eich [mailto:brendan.e...@gmail.com] 
Sent: Wednesday, July 26, 2017 6:19 PM
To: Florian Bösch 
Cc: T.J. Crowder ; doodad-js Admin 
; es-discuss 
Subject: Re: FW: Removal of language features

 

Languages have warts, not just JS. No cleanup is perfect, and more warts come 
over time. If your point is merely about a "language you hate" but must 
perforce use  on the Web, I think you should be happy right now. The solution 
is not to hate JS. It's not going to change incompatibly. Rather, you can use 
linters, "transpilers", compilers, voluntary unchecked subsets -- all possible 
today.

 

If you then object to having to use a tool or a subsetting discipline, I'm not 
sure what to say. The `with` statement is not forcing you to use it. Avoid it!

 

If you are concerned with the "painting into the corner" problem for engine 
implementors, the big ones are all in the room here and they can cope.

 

If you are concerned about JS pedagogy or marketing, the solution already 
practiced is to subset. Just as when teaching English or another evolved, 
irregularity-ridden living language.

 

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[Florian Bösch]

On Thu, Jul 27, 2017 at 12:18 AM, Brendan Eich 
wrote:

> The solution is not to hate JS. It's not going to change incompatibly.
> Rather, you can use linters, "transpilers", compilers, voluntary unchecked
> subsets -- all possible today.
>

So basically "the best way to use JS is to not use JS". Awesome.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Brendan Eich]

On Wed, Jul 26, 2017 at 11:59 AM Michał Wadas  wrote:

> I know that's hard to remove features from the web. That's why I propose 
> *clear
> and well defined *route to clean up language.
>

Instead of asserting in bold, why not answer the questions I posed in reply
to your clear but incomplete proposal?

Suppose TC39 said "with" was going away in 2027. Who among content owners,
developers they hire sporadically, or browser users visiting their sites
would do anything, and why would they do it? If a browser in 2027 ships
without "with" support ahead of other major browsers, what happens to its
support costs and market share?


> Browsers already "broke" the web many times. Java Applets are dead.
> ActiveX is dead (though some government websites still require it). Flash
> will be dead in few years. And some sites stopped working because of this.
>

You are citing proprietary plugins. The Web of which JS is a part is
defined by open standards from Ecma, WHATWG, W3C, IETF. We survived plugins
dying (and good riddance, in general; credit to Flash for filling gaps and
still doing things the standard Web cannot do well -- this is to the shame
of the Web, no argument).

Ok, so proprietary or not, plugins died and that has costs. But they are
borne by sites who dropped those plugins, one by one. They are not imposed
(at least not till Brave, or now with the plan to kill Flash by 2020 among
Adobe and the big four browsers) from the client side. Again, the
browser-market game theory does not work. Please respond to this clear and
well-defined point :-P.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[Brendan Eich]

Languages have warts, not just JS. No cleanup is perfect, and more warts
come over time. If your point is merely about a "language you hate" but
must perforce use  on the Web, I think you should be happy right now. The
solution is not to hate JS. It's not going to change incompatibly. Rather,
you can use linters, "transpilers", compilers, voluntary unchecked subsets
-- all possible today.

If you then object to having to use a tool or a subsetting discipline, I'm
not sure what to say. The `with` statement is not forcing you to use it.
Avoid it!

If you are concerned with the "painting into the corner" problem for engine
implementors, the big ones are all in the room here and they can cope.

If you are concerned about JS pedagogy or marketing, the solution already
practiced is to subset. Just as when teaching English or another evolved,
irregularity-ridden living language.

/be

On Wed, Jul 26, 2017 at 3:06 PM Florian Bösch  wrote:

> On Wed, Jul 26, 2017 at 11:41 PM, Brendan Eich 
> wrote:
>>
>> Those languages forked and some modernized (I remember Fortran 77). Those
>> are all quite a bit older than JS. I would also suggest they are for the
>> most part stunning successes. We've learned a lot from them.
>>
>
> Yes, but we'll also want people to *want* to use a language. Not just use
> it because eons ago something has been written in them and now there is no
> way out. JS has to keep pace or it will end up like those languages, some
> relic from the past that nobody uses if they can possibly avoid it. I don't
> think the mission brief of JS can be "The best language you hate using but
> can't avoid using anyway."
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[Florian Bösch]

On Wed, Jul 26, 2017 at 11:41 PM, Brendan Eich 
wrote:
>
> Those languages forked and some modernized (I remember Fortran 77). Those
> are all quite a bit older than JS. I would also suggest they are for the
> most part stunning successes. We've learned a lot from them.
>

Yes, but we'll also want people to *want* to use a language. Not just use
it because eons ago something has been written in them and now there is no
way out. JS has to keep pace or it will end up like those languages, some
relic from the past that nobody uses if they can possibly avoid it. I don't
think the mission brief of JS can be "The best language you hate using but
can't avoid using anyway."
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[Brendan Eich]

On Wed, Jul 26, 2017 at 12:14 PM Florian Bösch  wrote:

> On Wed, Jul 26, 2017 at 9:00 PM, T.J. Crowder <
> tj.crow...@farsightsoftware.com> wrote:
>>
>> keeping it alive and healthy beyond its browser-limited existence.
>>
>
> Many languages (including Python and Perl)  concluded that at some point
> things have to be "cleaned up".
>

You have not addressed my points about the difficulty of removing things on
the Web. Citing Perl and Python implies you want opt-in versioning, which I
had proposed for ES4 back in the day. before I wised up ;-). A couple of
points:

1. Perl 5 vs. 6 and Python 2 vs. 3 are not great precedents. I think they
are counterexamples even given the ability with Unix command line tools to
be installed and used on single systems or in cloud settings without the
huge coordination problem posed by the Web. Perl and Python have forked,
and split their communities between versions. The Python rift may heal, but
these forks have real and high costs. I know, we use Python at Brave in our
build system.

2. Opt-in versioning on the Web is an anti-pattern, as discussed at length
on es-discuss. The better way, dubbed 1JS, is to let old forms fall into
disuse while carefully extending the language with new syntax and semantics
that compose well with the existing surface language, using a kernel
semantics approach. This is still TC39's settled conviction as best foot
forward.

The track record of languages that never cleaned up isn't... great. You
> could consider things like RPG, Cobol, Fortran, etc. "alive" because
> they're still used. But in any other sense of the word they aren't.
>

Those languages forked and some modernized (I remember Fortran 77). Those
are all quite a bit older than JS. I would also suggest they are for the
most part stunning successes. We've learned a lot from them.

But the point of order here is whether JS can even be forked as Perl and
Python have been. Another point to discuss is what you mean by "isn't...
great." Aesthetics aside, keeping compatibility maximizes utility. There is
risk of "painting into a corner", making conflicts in the kernel semantics
or surface language over time, or just making a kitchen sink language.
These are not _malum in se_ but costs to be traded off for benefits.

If the aesthetic or Platonic ideal approach prevails, almost any successful
language is not "alive" because it is messy. But that's false: C is still
alive, C++ is quite alive, etc. I suggest being precise about costs vs.
benefits and avoiding vague or counterfactual metaphorical judgments
("isn't... great", not "alive").

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Bruno Jouhier]

> There are some features of x86 which where ditched. The more well known
example would be MMX (though the idea lives on in SSE/SIMD). But then
there's also ARM and its slow crawl to replace x86 ...

MMX was not in the original set and looks more like an abandoned experiment
(a bit like ES-4). But you are right, some obscure instructions got dropped

(like ES dropping arguments.caller). ARM would be more like Dart (with a
brighter future). Even if the analogy is not perfect, scale is the key
factor in these phenomena.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Florian Bösch]

On Wed, Jul 26, 2017 at 9:47 PM, Bruno Jouhier  wrote:

> JavaScript is often referred to as the "assembly language of the web". Did
> any instruction ever get removed from the x86 instruction set? Will this
> ever happen?
>

There are some features of x86 which where ditched. The more well known
example would be MMX (though the idea lives on in SSE/SIMD). But then
there's also ARM and its slow crawl to replace x86, mainly in areas x86
didn't have much luck in capturing (mobile), but which now is increasingly
making its way into nettops, and undoubdedly will eventually start to
tackle high-end personal computing. In other areas (such as GPUs), vendors
frequently toss support for features deemed obsolete (though many of them
remain support in drivers software paths, just don't use those features
cause the speed sucks).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Bruno Jouhier]

> But no other environment have a goal to be backward compatible *forever*

JavaScript is often referred to as the "assembly language of the web". Did
any instruction ever get removed from the x86 instruction set? Will this
ever happen?

Also, modern C compilers still compile C code written in the 70s, even if
they use obsolete syntax (pre-ansi K&R parameter declarations). Did
features get removed from C? (I don't know the answer - anyone ever used
trigraphs?). Is this a problem for C programmers?

There is an issue of scale here. You can impose an upgrade behind a
corporate firewall; much harder in the open.

Bruno
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[Florian Bösch]

On Wed, Jul 26, 2017 at 9:00 PM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:
>
> keeping it alive and healthy beyond its browser-limited existence.
>

Many languages (including Python and Perl)  concluded that at some point
things have to be "cleaned up". The track record of languages that never
cleaned up isn't... great. You could consider things like RPG, Cobol,
Fortran, etc. "alive" because they're still used. But in any other sense of
the word they aren't.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[Brendan Eich]

1. There's no evidence (I'm sitting in a TC39 meeting) other than grumping
from a few that we are near the point of JS painted into a corner by
backward compatibility.

2. WebAssembly is happening. Dynamic language support will  take a while.

Together these suggest JS evolution will continue. It shall continue.

/be

On Wed, Jul 26, 2017 at 11:37 AM Florian Bösch  wrote:

> On Tue, Jul 25, 2017 at 11:50 PM, Brendan Eich 
> wrote:
>>
>> 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.
>>
>
> There's a point at which you cannot add anything new meaningful because of
> the broken things. And you can't remove the broken things because you're
> committed to eternal backwards compatibility. And you can't add modes
> because nobody likes them. That's just planned obsolescence. This means JS
> is not a living language, or won't be much longer in any case. It's
> probably best if whatever you run on the web ships its own interpreter that
> runs on whatever flavor runtime (JS, asm.js or Web Assembly) is available.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[T.J. Crowder]

On Wed, Jul 26, 2017 at 7:37 PM, Florian Bösch  wrote:
> This means JS is not a living language, or won't be much longer in any
case.

"Much longer" is of course entirely subjective, but let's not be too
dramatic; I think we can count on JavaScript being a living language for
*at least* another 10 years, regardless of what happens with WebAssembly
and similar.

If WebAssembly (or similar) does stabilize, spread, and mature, that will
enable a thriving ecosystem of languages that compile to it, making
JavaScript only one of many (just as it is now outside of browsers). I love
the language, but I love the idea of it being one of many that can target
browsers even more.

And that will probably allow JavaScript itself more freedom at that point
in terms of evolution, keeping it alive and healthy beyond its
browser-limited existence.

-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Michał Wadas]

I know that's hard to remove features from the web. That's why I propose *clear
and well defined *route to clean up language.

Browsers already "broke" the web many times. Java Applets are dead. ActiveX
is dead (though some government websites still require it). Flash will be
dead in few years. And some sites stopped working because of this.

Backward compatibility is a great thing that made Web successful. But no
other environment have a goal to be backward compatible *forever*. Windows
98 .exe will probably not run on Windows 10. Old Android apps does not run
on new devices. Very old iOS apps does not run on new devices. Why would
anyone expect to run 20 years old code successfully on new browser? And why
we limit it only to JavaScript code, if other Web APIs and behaviours were
changed in past?


On Wed, Jul 26, 2017 at 5:52 PM, Brendan Eich 
wrote:

> On Wed, Jul 26, 2017 at 4:44 AM Michał Wadas 
> wrote:
>
>> Simple idea:
>>
>>- Add new Annex to language.
>>- Define operation EmitDeprecationWarning(code) - implementations MAY
>>show deprecation warning in implementation dependent way (it can depend on
>>runtime flag, dev tools, not minified code, etc.); otherwise operation
>>EmitDeprecationWarning is noop
>>
>>
> Who sees the warnings? Publishers hire contractors to build (re-build)
> site in year N, in year N+M when contractors are long gone, users visit
>  site and get unseen warnings in their unopened devtools. What upper bound
> can be put on M?
>
>>
>>- Define when implementations SHOULD emit deprecations warnings -
>>like using with statement, non-standard Reg-Exp properties, compile 
>> method,
>>assign to arguments, getYear etc.
>>
>>
> Who sees the warnings? Not the contractors, they are long gone by year
> N+1.
>
>>
>>- Language features can be removed after 10 (15?) years
>>
>>
> So M=10 might work (who knows?) but it's so long a time frame that no one
> will act on the remote threat of breakage. And yet at Y=N+M, there will be
> sites (not just web.archive.org) using the old feature, I would bet real
> money. We know this because from looking back at when the Web was smaller
> and easier to coordinate.
>
> Your model seems to assume a small-world-network coordination system.
> That's not the Web.
>
> I created JS in 1995. In 1996 I made a few incompatible changes to JS and
> got away with it, but not in 1997. ES3 was done in 1999 based on de-facto
> work in Netscape and IE that converged (mostly; a few edge cases) around
> the same time, but even by 1998 the only way to coordinate was via the
> ECMA-262 standards work, not just ES1 but the discussions about future work
> we were having in 1997.
>
> This kind of TC39 coordination helps for sure, don't get me wrong. But it
> does not solve the publisher/contractor division of labor leaving M
> effectively unbounded.
>
> For a language like Java or C# used server side, where the retrograde
> sites can stick to old tool/runtime versions as long as vendors support
> them, M can be a "Goldilocks" interval, not too big, not too small. The
> threat of vendors obsoleting old versions pushes most customers to upgrade
> in time, and the customers of size can push back and keep support going an
> extra year or three if need be.
>
> But that's not the Web. On the web, you don't just have the publishers and
> contractors, you have browser users also not coordinated except possibly by
> loose rules about supported browsers (banks try this and still get it
> wrong). Most sites do not want to turn away users based on detailed user
> agent version checks.
>
> Suppose TC39 said "with" was going away in 2027. Who among content owners,
> developers they hire sporadically, or browser users visiting their sites
> would do anything, and why would they do it? If a browser in 2027 ships
> without "with" support ahead of other major browsers, what happens to its
> support costs and market share?
>
> I hope this helps. It's very hard to remove things on the Web. That's the
> nature of the beast.
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[Florian Bösch]

On Tue, Jul 25, 2017 at 11:50 PM, Brendan Eich 
wrote:
>
> 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.
>

There's a point at which you cannot add anything new meaningful because of
the broken things. And you can't remove the broken things because you're
committed to eternal backwards compatibility. And you can't add modes
because nobody likes them. That's just planned obsolescence. This means JS
is not a living language, or won't be much longer in any case. It's
probably best if whatever you run on the web ships its own interpreter that
runs on whatever flavor runtime (JS, asm.js or Web Assembly) is available.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Mike Samuel]

On Wed, Jul 26, 2017 at 1:56 PM, Brendan Eich  wrote:
> Strict mode also made runtime-incompatible changes, e.g. arguments[i] not
> aliasing i'th formal parameter, which required two-way testing while strict
> mode adoption was nascent or partial (which of course many devs skipped).
>
> On Wed, Jul 26, 2017 at 9:53 AM Andreas Rossberg 
> wrote:
>>
>> The "ability to do sound static analysis" is not a binary characteristics.
>> You can do analysis on JS. With strict mode you have a couple more
>> invariants, so can do slightly better, but from my perspective it's not even
>> close to a game changer.
>
>
> Agreed (static analysis approximates runtime, so the ability to do it is of
> course not binary -- many trade-offs).

Of course, no static analysis can be complete for all programs in a
Turing complete language.

At the time it was being debated, we couldn't assume closure integrity
if a parameter could alias eval which made static analysis of even
simple programs really really hard.
It looks like both violations of closure integrity via indirect
aliasing of eval got rolled into non-strict mode though.  I was just
confused.


> From my memory of the meetings and online discussions, strict mode was not
> meant to make static analysis significantly easier. More important was
> enabling Caja (now SES) to "use strict" and do less work, static and at
> runtime. Implementation and legacy loopholes continue to confound such
> efforts :-).

Fair enough.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Allen Wirfs-Brock]

> On Jul 26, 2017, at 10:56 AM, Brendan Eich  wrote:
> 
> From my memory of the meetings and online discussions, strict mode was not 
> meant to make static analysis significantly easier. More important was 
> enabling Caja (now SES) to "use strict" and do less work, static and at 
> runtime. Implementation and legacy loopholes continue to confound such 
> efforts :-).

From my memory, static analysis of eval impact was definitely a motivator for 
the strict mode eval semantics. Similarly, it was part of the motivation for 
eliminating with. 

Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Brendan Eich]

Strict mode also made runtime-incompatible changes, e.g. arguments[i] not
aliasing i'th formal parameter, which required two-way testing while strict
mode adoption was nascent or partial (which of course many devs skipped).

On Wed, Jul 26, 2017 at 9:53 AM Andreas Rossberg 
wrote:

> The "ability to do sound static analysis" is not a binary characteristics.
> You can do analysis on JS. With strict mode you have a couple more
> invariants, so can do slightly better, but from my perspective it's not
> even close to a game changer.
>

Agreed (static analysis approximates runtime, so the ability to do it is of
course not binary -- many trade-offs).

>From my memory of the meetings and online discussions, strict mode was not
meant to make static analysis significantly easier. More important was
enabling Caja (now SES) to "use strict" and do less work, static and at
runtime. Implementation and legacy loopholes continue to confound such
efforts :-).

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Andreas Rossberg]

On 26 July 2017 at 18:10, Mike Samuel  wrote:

> On Wed, Jul 26, 2017 at 5:55 AM, Andreas Rossberg 
> wrote:
> > And clearly, modes or versions only make things worse in that regard.
> Strict
> > mode already is a pig when it comes to implementation complexity (in
> > retrospect, it does not carry its weight IMHO). ES6 made it worse. Our
>
> IIRC, the primary argument for strict mode wasn't implementation
> simplicity, but the ability to do sound static analysis.
>

Right, I was merely lumping a reply to two different suggestions into a
single reply.



> var x;
> function f(a, b) {
>   a(b);
>   return x;
> }
>
> isn't analyzable because f(eval, 'var x = 1;') could cause the
> returned x to refer to a local instead of the outer x but add "use
> strict" to either scope and suddenly it is statically analyzable.
>

Actually, it cannot. An indirect call to eval cannot inject anything into
the caller scope.

On the other hand, any use of indirect eval can inject something into the
global scope, whether the caller is in strict mode or not. Overall, I thus
don't think that strict mode makes JavaScript sufficiently better.



> When you say that strict mode "does not carry its weight," are you
> saying that that the ability to do sounds static analysis doesn't
> warrant the additional complexity or are you referring to a different
> bundle of benefits?
>

The "ability to do sound static analysis" is not a binary characteristics.
You can do analysis on JS. With strict mode you have a couple more
invariants, so can do slightly better, but from my perspective it's not
even close to a game changer.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Brendan Eich]

One thing that may not be obvious:

On Wed, Jul 26, 2017 at 8:52 AM Brendan Eich  wrote:

> I created JS in 1995. In 1996 I made a few incompatible changes to JS and
> got away with it, but not in 1997. ES3 was done in 1999 based on de-facto
> work in Netscape and IE that converged (mostly; a few edge cases) around
> the same time, but even by 1998 the only way to coordinate was via the
> ECMA-262 standards work, not just ES1 but the discussions about future work
> we were having in 1997.
>

Netscape had effective monopoly control of JS in 1995 and into 1996, but
was losing it by 1997 with IE4 coming out. No browser has it now, although
Chrome has the most market power.

Even monopolies cannot repeal price law -- they can only force deadweight
losses on customers up to a limit where the customer does without, or else
substitutes by going outside the monopoly system. With JS, there was risk
at the limit of users going without JS. There was risk too, small at first
but growing to large, of users substituting IE and even using VBScript
instead of JS.

Fortunately ;-), JS was first and good-enough, and standardized enough, to
head off the VBScript substitution.

So I couldn't just change JS any way I wanted based on market power. Nor
can Chrome now, or in a future where it got closer to IE's top (2004?)
share of 95% (per wikipedia).

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Mike Samuel]

On Wed, Jul 26, 2017 at 5:55 AM, Andreas Rossberg  wrote:
> And clearly, modes or versions only make things worse in that regard. Strict
> mode already is a pig when it comes to implementation complexity (in
> retrospect, it does not carry its weight IMHO). ES6 made it worse. Our

IIRC, the primary argument for strict mode wasn't implementation
simplicity, but the ability to do sound static analysis.

var x;
function f(a, b) {
  a(b);
  return x;
}

isn't analyzable because f(eval, 'var x = 1;') could cause the
returned x to refer to a local instead of the outer x but add "use
strict" to either scope and suddenly it is statically analyzable.

When you say that strict mode "does not carry its weight," are you
saying that that the ability to do sounds static analysis doesn't
warrant the additional complexity or are you referring to a different
bundle of benefits?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Brendan Eich]

On Wed, Jul 26, 2017 at 4:44 AM Michał Wadas  wrote:

> Simple idea:
>
>- Add new Annex to language.
>- Define operation EmitDeprecationWarning(code) - implementations MAY
>show deprecation warning in implementation dependent way (it can depend on
>runtime flag, dev tools, not minified code, etc.); otherwise operation
>EmitDeprecationWarning is noop
>
>
Who sees the warnings? Publishers hire contractors to build (re-build) site
in year N, in year N+M when contractors are long gone, users visit  site
and get unseen warnings in their unopened devtools. What upper bound can be
put on M?

>
>- Define when implementations SHOULD emit deprecations warnings - like
>using with statement, non-standard Reg-Exp properties, compile method,
>assign to arguments, getYear etc.
>
>
Who sees the warnings? Not the contractors, they are long gone by year N+1.


>
>- Language features can be removed after 10 (15?) years
>
>
So M=10 might work (who knows?) but it's so long a time frame that no one
will act on the remote threat of breakage. And yet at Y=N+M, there will be
sites (not just web.archive.org) using the old feature, I would bet real
money. We know this because from looking back at when the Web was smaller
and easier to coordinate.

Your model seems to assume a small-world-network coordination system.
That's not the Web.

I created JS in 1995. In 1996 I made a few incompatible changes to JS and
got away with it, but not in 1997. ES3 was done in 1999 based on de-facto
work in Netscape and IE that converged (mostly; a few edge cases) around
the same time, but even by 1998 the only way to coordinate was via the
ECMA-262 standards work, not just ES1 but the discussions about future work
we were having in 1997.

This kind of TC39 coordination helps for sure, don't get me wrong. But it
does not solve the publisher/contractor division of labor leaving M
effectively unbounded.

For a language like Java or C# used server side, where the retrograde sites
can stick to old tool/runtime versions as long as vendors support them, M
can be a "Goldilocks" interval, not too big, not too small. The threat of
vendors obsoleting old versions pushes most customers to upgrade in time,
and the customers of size can push back and keep support going an extra
year or three if need be.

But that's not the Web. On the web, you don't just have the publishers and
contractors, you have browser users also not coordinated except possibly by
loose rules about supported browsers (banks try this and still get it
wrong). Most sites do not want to turn away users based on detailed user
agent version checks.

Suppose TC39 said "with" was going away in 2027. Who among content owners,
developers they hire sporadically, or browser users visiting their sites
would do anything, and why would they do it? If a browser in 2027 ships
without "with" support ahead of other major browsers, what happens to its
support costs and market share?

I hope this helps. It's very hard to remove things on the Web. That's the
nature of the beast.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Andreas Rossberg]

On 26 July 2017 at 17:38, Brendan Eich  wrote:

> Hi Andreas, is this the best link to the Strong Mode post-mortem?
>
> https://groups.google.com/d/msg/strengthen-js/ojj3TDxbHpQ/5ENNAiUzEgAJ
>

Yup.


On Wed, Jul 26, 2017 at 2:56 AM Andreas Rossberg 
> wrote:
>
>> As for the reoccurring assumption that deprecation would help simplifying
>> JavaScript implementations: no, not to a relevant degree. 80+% of the
>> complexity in a JS VM comes from the plethora of (sometimes ridiculous)
>> edge cases in the core semantics of JavaScript, its object model, implicit
>> conversions, etc., and the desire to make all that fast in the common case
>> without breaking correctness of the million special cases. None of that can
>> be deprecated without creating a completely new language.
>>
>> And clearly, modes or versions only make things worse in that regard.
>> Strict mode already is a pig when it comes to implementation complexity (in
>> retrospect, it does not carry its weight IMHO). ES6 made it worse. Our
>> experiments with strong mode a while ago increased complexity even further,
>> so much that the urge to rip it out again overtook very quickly. I for one
>> am eternally healed of modes.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Brendan Eich]

Hi Andreas, is this the best link to the Strong Mode post-mortem?

https://groups.google.com/d/msg/strengthen-js/ojj3TDxbHpQ/5ENNAiUzEgAJ

/be

On Wed, Jul 26, 2017 at 2:56 AM Andreas Rossberg 
wrote:

> As for the reoccurring assumption that deprecation would help simplifying
> JavaScript implementations: no, not to a relevant degree. 80+% of the
> complexity in a JS VM comes from the plethora of (sometimes ridiculous)
> edge cases in the core semantics of JavaScript, its object model, implicit
> conversions, etc., and the desire to make all that fast in the common case
> without breaking correctness of the million special cases. None of that can
> be deprecated without creating a completely new language.
>
> And clearly, modes or versions only make things worse in that regard.
> Strict mode already is a pig when it comes to implementation complexity (in
> retrospect, it does not carry its weight IMHO). ES6 made it worse. Our
> experiments with strong mode a while ago increased complexity even further,
> so much that the urge to rip it out again overtook very quickly. I for one
> am eternally healed of modes.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Michał Wadas]

Simple idea:

   - Add new Annex to language.
   - Define operation EmitDeprecationWarning(code) - implementations MAY
   show deprecation warning in implementation dependent way (it can depend on
   runtime flag, dev tools, not minified code, etc.); otherwise operation
   EmitDeprecationWarning is noop
   - Define when implementations SHOULD emit deprecations warnings - like
   using with statement, non-standard Reg-Exp properties, compile method,
   assign to arguments, getYear etc.
   - Language features can be removed after 10 (15?) years


On Wed, Jul 26, 2017 at 11:55 AM, Andreas Rossberg 
wrote:

> As for the reoccurring assumption that deprecation would help simplifying
> JavaScript implementations: no, not to a relevant degree. 80+% of the
> complexity in a JS VM comes from the plethora of (sometimes ridiculous)
> edge cases in the core semantics of JavaScript, its object model, implicit
> conversions, etc., and the desire to make all that fast in the common case
> without breaking correctness of the million special cases. None of that can
> be deprecated without creating a completely new language.
>
> And clearly, modes or versions only make things worse in that regard.
> Strict mode already is a pig when it comes to implementation complexity (in
> retrospect, it does not carry its weight IMHO). ES6 made it worse. Our
> experiments with strong mode a while ago increased complexity even further,
> so much that the urge to rip it out again overtook very quickly. I for one
> am eternally healed of modes.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Andreas Rossberg]

As for the reoccurring assumption that deprecation would help simplifying
JavaScript implementations: no, not to a relevant degree. 80+% of the
complexity in a JS VM comes from the plethora of (sometimes ridiculous)
edge cases in the core semantics of JavaScript, its object model, implicit
conversions, etc., and the desire to make all that fast in the common case
without breaking correctness of the million special cases. None of that can
be deprecated without creating a completely new language.

And clearly, modes or versions only make things worse in that regard.
Strict mode already is a pig when it comes to implementation complexity (in
retrospect, it does not carry its weight IMHO). ES6 made it worse. Our
experiments with strong mode a while ago increased complexity even further,
so much that the urge to rip it out again overtook very quickly. I for one
am eternally healed of modes.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Mark]

I hope more people read and search https://esdiscuss.org/ and engage with
history instead of coming as if to a blank slate.

​
In all fairness, es-discuss is rather ancient in the way it works. I
personally would recommend es-discuss coming up with a better way to keep
track of its threads. The current setup is rather confusing, imo. FWIW, I
personally would recommend Discourse . I agree
with you on the same topics coming up constantly though.
​
​.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: FW: Removal of language features

[doodad-js Admin]

With something like Babel, we should be able to transpile from JS 2 to JS 1 for 
backward compatibility. We are already doing it from ES6/ES7 to ES5.

 

From: Alexander Craggs [mailto:alexan...@debenclipper.com] 
Sent: Tuesday, July 25, 2017 5:08 PM
To: doodad-js Admin ; es-discuss@mozilla.org
Subject: RE: FW: Removal of language features

 

I think version interoperability is a must in a world of Webpack & Browserify.

On 25/07/2017 21:12:58, doodad-js Admin 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:

 

...

 

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] 
Sent: Tuesday, July 25, 2017 3:54 PM
To: doodad-js Admin 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?

 


 
<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

RE: FW: Removal of language features

[doodad-js Admin]

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 ; doodad-js Admin 
; 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 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 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:

 

...

 

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 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_c

Re: Re: FW: Removal of language features

[Bruno Jouhier]

Reading this thread, it feels that cleaning the language raises more
problems than it solves. It is not even clear how versions should be
flagged.

TC39 has worked very hard to keep the language backward compatible and
avoid "breaking the web". So only a very strong motive would justify
removal of features. Security is one and that explains why arguments.callee
is going away, but I don't see others. Even performance isn't a strong
enough motive: libraries that don't perform because of inefficient language
features  (with, eval) will just die or be replaced. No need to be
proactive here, just let the Darwinian process take its course.

Language cleanup is the business of linters. They let you enforce modern
features within your teams/projects, without impacting others nor existing
libraries.

Derived languages and transpilers (TypeScript) are the perfect place to
experiment with new features. This is much better than taking chances with
JavaScript itself.

If it ain't broke, don't fix it.

Bruno
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[Brendan Eich]

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 
wrote:

> I think version interoperability is a must in a world of Webpack &
> Browserify.
>
> On 25/07/2017 21:12:58, doodad-js Admin  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:
>
>
>
> ...
>
>
>
> 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]
> *Sent:* Tuesday, July 25, 2017 3:54 PM
> *To:* doodad-js Admin ; 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
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: FW: Removal of language features

[Alexander Craggs]

I think version interoperability is a must in a world of Webpack & Browserify.
On 25/07/2017 21:12:58, doodad-js Admin  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:
 
...
 
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]
Sent: Tuesday, July 25, 2017 3:54 PM
To: doodad-js Admin ; 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
https://mail.mozilla.org/listinfo/es-discuss

RE: FW: Removal of language features

[doodad-js Admin]

*   How are you going to deal with scenarios that don't have extensions, 
e.g. REPL or inline JS.

 

For inline, that’ll be:

 

...

 

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] 
Sent: Tuesday, July 25, 2017 3:54 PM
To: doodad-js Admin ; 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
https://mail.mozilla.org/listinfo/es-discuss

RE: Removal of language features

[doodad-js Admin]

My apologizes, you still should set the “Content-Type” header from the server 
*as usual* if that’s not automatically done.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[Alexander Craggs]

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?
On 25/07/2017 20:41:33, doodad-js Admin  wrote:
*  1. In terms of including it in 

FW: Removal of language features

[doodad-js Admin]

*1. In terms of including it in 

Re: Removal of language features

[Alexander Craggs]

Some thoughts on using MIME types to distinguish between versions:

 1. In terms of including it in 

Re: Removal of language features

[Sebastian Zartner]

On 24 July 2017 at 10:47, Naveen Chawla  wrote:
> If reducing the available feature set would increase performance then a 
> declaration to the browser to ignore deprecated features should be enough to 
> get this optimization, but only for this reason.
>
> But do we even know that there is any performance gain for doing so?
>
> I'm not bothered about browser code complexity to support old features - I 
> don't see that code anyway. I don't know to what extent other javascript 
> developers are bothered about it either.

Well, JavaScript developers may not bother about the complexity of
browser code, though browser developers, or more generally spoken,
JavaScript engine developers should care about the complexity of their
code. Supporting old features may not only be a question of engine
performance but also memory consumption and (download) sizes of their
programs.
So, it should be in their interest to deprecate misfeatures, even when
it takes 5, 10, or 15 years until their usage drops enough so they can
actually be removed.

Sebastian
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Naveen Chawla]

Don't break the web.

Those who don't like old features just don't need to use them.

Applications that do use them would break!

If reducing the available feature set would increase performance then a
declaration to the browser to ignore deprecated features should be enough
to get this optimization, but only for this reason.

But do we even know that there is any performance gain for doing so?

I'm not bothered about browser code complexity to support old features - I
don't see that code anyway. I don't know to what extent other javascript
developers are bothered about it either.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Isiah Meadows]

Thought I'd clarify why I brought TypeScript in from:

- TypeScript in of itself is *not* a problem.
- Angular's use and embrace of TypeScript in of itself is *not* a problem.
- TypeScript was more of a tangentially related side detail.

I was only referring to Angular embracing a stage 2 proposal,
specifically decorators (with TypeScript extensions thereof), that had
become rather unstable a few months before they went beta with v2.0.
It's a technical risk taken by a framework with already very high
usage, one that introduced significant technical debt, and one I
questioned from the start.

(I could understand if it were stage 3, gaining browser support. But
to be clear, a year ago when they made the decision, it was a poor
choice, being relatively new and immature for a stage 2 proposal.)

-

Isiah Meadows
m...@isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[kdex]

This was kind of the original idea around Dart IIRC. It didn't see much 
traction though, and eventually got called off.

On Monday, July 24, 2017 1:56:53 AM CEST doodad-js Admin wrote:
> And more, engines could signal they support JS 2 just by the Accept header!
> 
> -Original Message-
> From: David White [mailto:david.rhys.wh...@icloud.com]
> Sent: Sunday, July 23, 2017 7:52 PM
> To: doodad-js Admin 
> Cc: es-discuss@mozilla.org
> Subject: Re: Removal of language features
> 
> Ooooh, a mime type based versioning would be very nice!
> 
> ``
> 
> For the most part you control your applications language decision and honour
> that with your bundle then load additional scripts you have little control
> over such as logging, monitoring, stats, etc in different runtimes perhaps.
> 
> It’s certainly cleaner than injecting a version into the top of your bundle
> and would allow 3rd party vendors to provide version specific bundles.
> 
> David
> 
> > On 24 Jul 2017, at 00:43, doodad-js Admin  wrote:
> > 
> > May I propose a new file extension and mime-type... "js2":
> > "application/javascript.2" ?
> > 
> > -Original Message-
> > From: David White [mailto:david.rhys.wh...@icloud.com]
> > Sent: Sunday, July 23, 2017 7:35 PM
> > To: doodad-js Admin 
> > Subject: Re: Removal of language features
> > 
> > That’s an interesting proposal but I’m struggling to think how that would
> > solve this same issue 2 or 3 or 5 years down the line? JavaScript and
> > browsers have a symmetry along with HTML, CSS... and given the disparity
> > of devices today alone, let alone tomorrow a new major version would
> > cause more harm than good. Ideally we would need a solution that works as
> > ES5 as standard, then have that semantic in later versions of the
> > language.
> > 
> > Perhaps this is not a problem for this community but something browser
> > providers should be providing / considering to allow developers to
> > specify their runtime in order to allow the language to progress more
> > natrurally?
> > 
> > David
> > 
> >> On 23 Jul 2017, at 23:38, doodad-js Admin  wrote:
> >> 
> >> Maybe that's time to start a new major version of JS?
> >> 
> >> -Original Message-
> >> From: David White [mailto:david.rhys.wh...@icloud.com]
> >> Sent: Sunday, July 23, 2017 5:54 PM
> >> To: es-discuss@mozilla.org
> >> Subject: Re: Re: Removal of language features
> >> 
> >> Lots of good thoughts and discussions here, and while it’s gone slightly
> >> off topic I’d love to discuss the possibilities of how we could get
> >> JavaScript to a point where we could actively remove features with every
> >> new specification.
> >> 
> >> I’m sure nobody would want to break the web, which would be very likely
> >> removing any parts of JavaScript, and certainly the biggest challenge,
> >> it does seem a shame that we can’t find an ulterior direction as it does
> >> seem allowing various features we consider bad practice today to still
> >> exist and the overhead that exists with them certainly hinders progress
> >> more than it helps.
> >> 
> >> Linting is certainly the fastest and easiest method, but to a certain
> >> extent I not really a solution in that we only lint our own code, and
> >> not the additional code that we rely upon. Ideally removal of features
> >> should mean more performance out of JavaScript, if engines have less
> >> constructs to deal with then there should be some beneficial performance
> >> related with that?
> >> 
> >> Given the lack of control over what browsers many users are using perhaps
> >> versioning could be a new semantic built into the language itself in the
> >> same way we have strict mode?
> >> 
> >> We could allow developers the option to specify the version they wish to
> >> use, avoiding unnecessary transpiration back to ES5 for applications
> >> confident enough to give their users the choice to upgrade if needed but
> >> also allow browsers to only run based on versions?
> >> 
> >> I'm sure it’s worth considering as removing features of a language /
> >> application is as important, if not more so, than adding features to a
> >> language or application.
> >> 
> >> David
> > 
> > ---
> > This email has been checked for viruses by AVG.
> > http://www.avg.com
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

signature.asc
Description: This is a digitally signed message part.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Owen]

It may be worth looking at Python 3 as a cautionary tail. For example, here
is a mailing list post from 2009 debating whether it is worth adding
features to 2.7 given that 3 is on the way:
https://mail.python.org/pipermail/python-dev/2009-October/093204.html .
Eight years later, Python 2.7 shows no signs of going  away, and the
language has become, at least for portable code, basically static since
then.

Of course, although the Python developers used an abundance of caution in
rolling out a major version, it remains an open question whether adoption
would have been smoother had the C API not changed. It may be that this
difficulty would not affect JavaScript, and a new major version would be
more feasible.

On Sun, Jul 23, 2017 at 7:57 PM doodad-js Admin  wrote:

> And more, engines could signal they support JS 2 just by the Accept header!
>
> -Original Message-
> From: David White [mailto:david.rhys.wh...@icloud.com]
> Sent: Sunday, July 23, 2017 7:52 PM
> To: doodad-js Admin 
> Cc: es-discuss@mozilla.org
> Subject: Re: Removal of language features
>
> Ooooh, a mime type based versioning would be very nice!
>
> ``
>
> For the most part you control your applications language decision and
> honour that with your bundle then load additional scripts you have little
> control over such as logging, monitoring, stats, etc in different runtimes
> perhaps.
>
> It’s certainly cleaner than injecting a version into the top of your
> bundle and would allow 3rd party vendors to provide version specific
> bundles.
>
> David
>
> > On 24 Jul 2017, at 00:43, doodad-js Admin  wrote:
> >
> > May I propose a new file extension and mime-type... "js2":
> "application/javascript.2" ?
> >
> > -Original Message-
> > From: David White [mailto:david.rhys.wh...@icloud.com]
> > Sent: Sunday, July 23, 2017 7:35 PM
> > To: doodad-js Admin 
> > Subject: Re: Removal of language features
> >
> > That’s an interesting proposal but I’m struggling to think how that
> would solve this same issue 2 or 3 or 5 years down the line? JavaScript and
> browsers have a symmetry along with HTML, CSS... and given the disparity of
> devices today alone, let alone tomorrow a new major version would cause
> more harm than good. Ideally we would need a solution that works as ES5 as
> standard, then have that semantic in later versions of the language.
> >
> > Perhaps this is not a problem for this community but something browser
> providers should be providing / considering to allow developers to specify
> their runtime in order to allow the language to progress more natrurally?
> >
> > David
> >
> >
> >> On 23 Jul 2017, at 23:38, doodad-js Admin  wrote:
> >>
> >> Maybe that's time to start a new major version of JS?
> >>
> >> -Original Message-
> >> From: David White [mailto:david.rhys.wh...@icloud.com]
> >> Sent: Sunday, July 23, 2017 5:54 PM
> >> To: es-discuss@mozilla.org
> >> Subject: Re: Re: Removal of language features
> >>
> >> Lots of good thoughts and discussions here, and while it’s gone
> slightly off topic I’d love to discuss the possibilities of how we could
> get JavaScript to a point where we could actively remove features with
> every new specification.
> >>
> >> I’m sure nobody would want to break the web, which would be very likely
> removing any parts of JavaScript, and certainly the biggest challenge, it
> does seem a shame that we can’t find an ulterior direction as it does seem
> allowing various features we consider bad practice today to still exist and
> the overhead that exists with them certainly hinders progress more than it
> helps.
> >>
> >> Linting is certainly the fastest and easiest method, but to a certain
> extent I not really a solution in that we only lint our own code, and not
> the additional code that we rely upon. Ideally removal of features should
> mean more performance out of JavaScript, if engines have less constructs to
> deal with then there should be some beneficial performance related with
> that?
> >>
> >> Given the lack of control over what browsers many users are using
> perhaps versioning could be a new semantic built into the language itself
> in the same way we have strict mode?
> >>
> >> We could allow developers the option to specify the version they wish
> to use, avoiding unnecessary transpiration back to ES5 for applications
> confident enough to give their users the choice to upgrade if needed but
> also allow browsers to only run based on versions?
> >>
> >> I'm sure it’s worth considering as removing fe

FW: Removal of language features

[doodad-js Admin]

I'm dealing with 4 emails, so sometimes I don't select the good one and get 
rejected by es-discuss :) This is my latest email...

Claude Petit

-Original Message-
From: Claude Petit [mailto:p...@webmail.us] 
Sent: Sunday, July 23, 2017 8:01 PM
To: 'doodad-js Admin' ; 'David White' 

Cc: es-discuss@mozilla.org
Subject: RE: Removal of language features

Sorry, I'm very sorry... I mean "clients", not "engines".

Claude Petit

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Removal of language features

[doodad-js Admin]

And more, engines could signal they support JS 2 just by the Accept header!

-Original Message-
From: David White [mailto:david.rhys.wh...@icloud.com] 
Sent: Sunday, July 23, 2017 7:52 PM
To: doodad-js Admin 
Cc: es-discuss@mozilla.org
Subject: Re: Removal of language features

Ooooh, a mime type based versioning would be very nice!

``

For the most part you control your applications language decision and honour 
that with your bundle then load additional scripts you have little control over 
such as logging, monitoring, stats, etc in different runtimes perhaps.

It’s certainly cleaner than injecting a version into the top of your bundle and 
would allow 3rd party vendors to provide version specific bundles.

David

> On 24 Jul 2017, at 00:43, doodad-js Admin  wrote:
> 
> May I propose a new file extension and mime-type... "js2": 
> "application/javascript.2" ?
> 
> -Original Message-
> From: David White [mailto:david.rhys.wh...@icloud.com] 
> Sent: Sunday, July 23, 2017 7:35 PM
> To: doodad-js Admin 
> Subject: Re: Removal of language features
> 
> That’s an interesting proposal but I’m struggling to think how that would 
> solve this same issue 2 or 3 or 5 years down the line? JavaScript and 
> browsers have a symmetry along with HTML, CSS... and given the disparity of 
> devices today alone, let alone tomorrow a new major version would cause more 
> harm than good. Ideally we would need a solution that works as ES5 as 
> standard, then have that semantic in later versions of the language.
> 
> Perhaps this is not a problem for this community but something browser 
> providers should be providing / considering to allow developers to specify 
> their runtime in order to allow the language to progress more natrurally?
> 
> David
> 
> 
>> On 23 Jul 2017, at 23:38, doodad-js Admin  wrote:
>> 
>> Maybe that's time to start a new major version of JS?
>> 
>> -Original Message-
>> From: David White [mailto:david.rhys.wh...@icloud.com] 
>> Sent: Sunday, July 23, 2017 5:54 PM
>> To: es-discuss@mozilla.org
>> Subject: Re: Re: Removal of language features
>> 
>> Lots of good thoughts and discussions here, and while it’s gone slightly off 
>> topic I’d love to discuss the possibilities of how we could get JavaScript 
>> to a point where we could actively remove features with every new 
>> specification.
>> 
>> I’m sure nobody would want to break the web, which would be very likely 
>> removing any parts of JavaScript, and certainly the biggest challenge, it 
>> does seem a shame that we can’t find an ulterior direction as it does seem 
>> allowing various features we consider bad practice today to still exist and 
>> the overhead that exists with them certainly hinders progress more than it 
>> helps.
>> 
>> Linting is certainly the fastest and easiest method, but to a certain extent 
>> I not really a solution in that we only lint our own code, and not the 
>> additional code that we rely upon. Ideally removal of features should mean 
>> more performance out of JavaScript, if engines have less constructs to deal 
>> with then there should be some beneficial performance related with that?
>> 
>> Given the lack of control over what browsers many users are using perhaps 
>> versioning could be a new semantic built into the language itself in the 
>> same way we have strict mode?
>> 
>> We could allow developers the option to specify the version they wish to 
>> use, avoiding unnecessary transpiration back to ES5 for applications 
>> confident enough to give their users the choice to upgrade if needed but 
>> also allow browsers to only run based on versions?
>> 
>> I'm sure it’s worth considering as removing features of a language / 
>> application is as important, if not more so, than adding features to a 
>> language or application.
>> 
>> David
>> 
> 
> 
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
> 
> 


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[David White]

Ooooh, a mime type based versioning would be very nice!

``

For the most part you control your applications language decision and honour 
that with your bundle then load additional scripts you have little control over 
such as logging, monitoring, stats, etc in different runtimes perhaps.

It’s certainly cleaner than injecting a version into the top of your bundle and 
would allow 3rd party vendors to provide version specific bundles.

David

> On 24 Jul 2017, at 00:43, doodad-js Admin  wrote:
> 
> May I propose a new file extension and mime-type... "js2": 
> "application/javascript.2" ?
> 
> -Original Message-
> From: David White [mailto:david.rhys.wh...@icloud.com] 
> Sent: Sunday, July 23, 2017 7:35 PM
> To: doodad-js Admin 
> Subject: Re: Removal of language features
> 
> That’s an interesting proposal but I’m struggling to think how that would 
> solve this same issue 2 or 3 or 5 years down the line? JavaScript and 
> browsers have a symmetry along with HTML, CSS... and given the disparity of 
> devices today alone, let alone tomorrow a new major version would cause more 
> harm than good. Ideally we would need a solution that works as ES5 as 
> standard, then have that semantic in later versions of the language.
> 
> Perhaps this is not a problem for this community but something browser 
> providers should be providing / considering to allow developers to specify 
> their runtime in order to allow the language to progress more natrurally?
> 
> David
> 
> 
>> On 23 Jul 2017, at 23:38, doodad-js Admin  wrote:
>> 
>> Maybe that's time to start a new major version of JS?
>> 
>> -Original Message-
>> From: David White [mailto:david.rhys.wh...@icloud.com] 
>> Sent: Sunday, July 23, 2017 5:54 PM
>> To: es-discuss@mozilla.org
>> Subject: Re: Re: Removal of language features
>> 
>> Lots of good thoughts and discussions here, and while it’s gone slightly off 
>> topic I’d love to discuss the possibilities of how we could get JavaScript 
>> to a point where we could actively remove features with every new 
>> specification.
>> 
>> I’m sure nobody would want to break the web, which would be very likely 
>> removing any parts of JavaScript, and certainly the biggest challenge, it 
>> does seem a shame that we can’t find an ulterior direction as it does seem 
>> allowing various features we consider bad practice today to still exist and 
>> the overhead that exists with them certainly hinders progress more than it 
>> helps.
>> 
>> Linting is certainly the fastest and easiest method, but to a certain extent 
>> I not really a solution in that we only lint our own code, and not the 
>> additional code that we rely upon. Ideally removal of features should mean 
>> more performance out of JavaScript, if engines have less constructs to deal 
>> with then there should be some beneficial performance related with that?
>> 
>> Given the lack of control over what browsers many users are using perhaps 
>> versioning could be a new semantic built into the language itself in the 
>> same way we have strict mode?
>> 
>> We could allow developers the option to specify the version they wish to 
>> use, avoiding unnecessary transpiration back to ES5 for applications 
>> confident enough to give their users the choice to upgrade if needed but 
>> also allow browsers to only run based on versions?
>> 
>> I'm sure it’s worth considering as removing features of a language / 
>> application is as important, if not more so, than adding features to a 
>> language or application.
>> 
>> David
>> 
> 
> 
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
> 
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[David White]

That’s an interesting proposal but I’m struggling to think how that would solve 
this same issue 2 or 3 or 5 years down the line? JavaScript and browsers have a 
symmetry along with HTML, CSS... and given the disparity of devices today 
alone, let alone tomorrow a new major version would cause more harm than good. 
Ideally we would need a solution that works as ES5 as standard, then have that 
semantic in later versions of the language.

Perhaps this is not a problem for this community but something browser 
providers should be providing / considering to allow developers to specify 
their runtime in order to allow the language to progress more natrurally?

> On 23 Jul 2017, at 23:38, doodad-js Admin  wrote:
> 
> Maybe that's time to start a new major version of JS?
> 
> -Original Message-
> From: David White [mailto:david.rhys.wh...@icloud.com] 
> Sent: Sunday, July 23, 2017 5:54 PM
> To: es-discuss@mozilla.org
> Subject: Re: Re: Removal of language features
> 
> Lots of good thoughts and discussions here, and while it’s gone slightly off 
> topic I’d love to discuss the possibilities of how we could get JavaScript to 
> a point where we could actively remove features with every new specification.
> 
> I’m sure nobody would want to break the web, which would be very likely 
> removing any parts of JavaScript, and certainly the biggest challenge, it 
> does seem a shame that we can’t find an ulterior direction as it does seem 
> allowing various features we consider bad practice today to still exist and 
> the overhead that exists with them certainly hinders progress more than it 
> helps.
> 
> Linting is certainly the fastest and easiest method, but to a certain extent 
> I not really a solution in that we only lint our own code, and not the 
> additional code that we rely upon. Ideally removal of features should mean 
> more performance out of JavaScript, if engines have less constructs to deal 
> with then there should be some beneficial performance related with that?
> 
> Given the lack of control over what browsers many users are using perhaps 
> versioning could be a new semantic built into the language itself in the same 
> way we have strict mode?
> 
> We could allow developers the option to specify the version they wish to use, 
> avoiding unnecessary transpiration back to ES5 for applications confident 
> enough to give their users the choice to upgrade if needed but also allow 
> browsers to only run based on versions?
> 
> I'm sure it’s worth considering as removing features of a language / 
> application is as important, if not more so, than adding features to a 
> language or application.
> 
> David
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Removal of language features

[doodad-js Admin]

To be honest, I started my own framework because of the lack of classical oop 
and a clear type system in JS. I know TypeScript, but that’s another language, 
not just a framework like mine. After that, ES6 classes has come to the 
surface, but they do not respond to my needs, and some choices on their 
behavior are not convenient. I’m waiting for new proposals like public/private 
fields and decorators, but just for the purpose of transpiling my classes to 
those of ES6 the most than possible for performance. I don’t think to have 
enough influence to get my classes system reflected in JS :)

 

From: kai zhu [mailto:kaizhu...@gmail.com] 
Sent: Sunday, July 23, 2017 6:36 PM
To: Vinnymac 
Cc: Jordan Harband ; Claude Petit ; 
es-discuss 
Subject: Re: Removal of language features

 

 

On Jul 23, 2017, at 10:58 AM, Vinnymac mailto:vinny...@gmail.com> > wrote:

 

Above Steve mentions that many people are mixing language additions with 
framework fatigue. I have to agree with him. In my case I am not overwhelmed by 
any of the additions TC39 has chosen to make to ECMA. In fact it is something I 
look forward to each year now that things seem to be iterating at a faster 
rate. 

 

-1

strongly disagree.  the explosion of different frameworks is encouraged by the 
current unstable nature of ecmascript.  the phenomenon wouldn't have been so 
severe if there wasn’t the mindset that ecmascript is undergoing a "language 
revolution", and everyone had to write their own framework to adapt to it.

 

It feels more mature, and we can already do so much more than we ever could 
just a couple of years ago.

 

-1

in the end-goal of browser UX capabilities, i feel the latest batch of 
frameworks don’t add anything more capable than the older simpler ones.  they 
simply employ more complicated procedures to achieve the final desired UX 
feature.

 

i feel the commercial web-industry is now more wanting on guidance to reliably 
ship and maintain products. the views of some people that ecmascript should 
further expand and develop new ideas, hardly helps in this regard.

 


 
<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

RE: Re: Removal of language features

[doodad-js Admin]

Maybe that's time to start a new major version of JS?

-Original Message-
From: David White [mailto:david.rhys.wh...@icloud.com] 
Sent: Sunday, July 23, 2017 5:54 PM
To: es-discuss@mozilla.org
Subject: Re: Re: Removal of language features

Lots of good thoughts and discussions here, and while it’s gone slightly off 
topic I’d love to discuss the possibilities of how we could get JavaScript to a 
point where we could actively remove features with every new specification.

I’m sure nobody would want to break the web, which would be very likely 
removing any parts of JavaScript, and certainly the biggest challenge, it does 
seem a shame that we can’t find an ulterior direction as it does seem allowing 
various features we consider bad practice today to still exist and the overhead 
that exists with them certainly hinders progress more than it helps.

Linting is certainly the fastest and easiest method, but to a certain extent I 
not really a solution in that we only lint our own code, and not the additional 
code that we rely upon. Ideally removal of features should mean more 
performance out of JavaScript, if engines have less constructs to deal with 
then there should be some beneficial performance related with that?

Given the lack of control over what browsers many users are using perhaps 
versioning could be a new semantic built into the language itself in the same 
way we have strict mode?

We could allow developers the option to specify the version they wish to use, 
avoiding unnecessary transpiration back to ES5 for applications confident 
enough to give their users the choice to upgrade if needed but also allow 
browsers to only run based on versions?

I'm sure it’s worth considering as removing features of a language / 
application is as important, if not more so, than adding features to a language 
or application.

David

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[kai zhu]

> On Jul 23, 2017, at 10:58 AM, Vinnymac  wrote:
> 
> Above Steve mentions that many people are mixing language additions with 
> framework fatigue. I have to agree with him. In my case I am not overwhelmed 
> by any of the additions TC39 has chosen to make to ECMA. In fact it is 
> something I look forward to each year now that things seem to be iterating at 
> a faster rate. 


-1
strongly disagree.  the explosion of different frameworks is encouraged by the 
current unstable nature of ecmascript.  the phenomenon wouldn't have been so 
severe if there wasn’t the mindset that ecmascript is undergoing a "language 
revolution", and everyone had to write their own framework to adapt to it.

> It feels more mature, and we can already do so much more than we ever could 
> just a couple of years ago.

-1
in the end-goal of browser UX capabilities, i feel the latest batch of 
frameworks don’t add anything more capable than the older simpler ones.  they 
simply employ more complicated procedures to achieve the final desired UX 
feature.

i feel the commercial web-industry is now more wanting on guidance to reliably 
ship and maintain products. the views of some people that ecmascript should 
further expand and develop new ideas, hardly helps in this regard.___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Removal of language features

[David White]

Lots of good thoughts and discussions here, and while it’s gone slightly off 
topic I’d love to discuss the possibilities of how we could get JavaScript to a 
point where we could actively remove features with every new specification.

I’m sure nobody would want to break the web, which would be very likely 
removing any parts of JavaScript, and certainly the biggest challenge, it does 
seem a shame that we can’t find an ulterior direction as it does seem allowing 
various features we consider bad practice today to still exist and the overhead 
that exists with them certainly hinders progress more than it helps.

Linting is certainly the fastest and easiest method, but to a certain extent I 
not really a solution in that we only lint our own code, and not the additional 
code that we rely upon. Ideally removal of features should mean more 
performance out of JavaScript, if engines have less constructs to deal with 
then there should be some beneficial performance related with that?

Given the lack of control over what browsers many users are using perhaps 
versioning could be a new semantic built into the language itself in the same 
way we have strict mode?

We could allow developers the option to specify the version they wish to use, 
avoiding unnecessary transpiration back to ES5 for applications confident 
enough to give their users the choice to upgrade if needed but also allow 
browsers to only run based on versions?

I'm sure it’s worth considering as removing features of a language / 
application is as important, if not more so, than adding features to a language 
or application.

David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Removal of language features

[Darien Valentine]

> But sure, perhaps a "guidelines for use in production" section would be
useful. [...] having them there makes it easier for people to point out to
them the dangers (or at least, considerations) of what they're doing,
backed by a link to the document [...]

In my own experience, that might have been a useful thing to have a few
times. A few years back I didn’t have the proper context for making
decisions about what the consequences of using stage 0-2 features might be
over time. I came to regret that. Later I had a better understanding of
this and had come to feel pretty strongly that it was unwise to use
anything less than stage 3 for projects that are expected to have a long
future. However it’s not always easy to convince people of this, especially
if they themselves can point to a lot of stuff that actually advises using
pre-stage 3 proposed features and non-standard extensions.

Being able to point to a formal statement about what the stages mean not
just from the point of view of TC39’s internal process, but also what they
imply for a consumer standpoint — chance of ultimate inclusion, overall
stability — would be helpful.

Would it actually lead to more careful decision making? I’m not sure, but
consider the mental health benefits: having linked to such an official doc
during a discussion of these concerns would mark a point after which one
might say to oneself: "okay... well, one _did try_". Then, rather than
continue such a discussion endlessly, one may instead grant oneself a few
moments to stare out a window wistfully, accept fate, sigh, and think about
ponies.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[T.J. Crowder]

Massive +1 on Jordan's call for increased civility and cleaner language.

On Sun, Jul 23, 2017 at 3:58 AM, Vinnymac  wrote:

> Above Steve mentions that many people are mixing language additions
> with framework fatigue. I have to agree with him. In my case I am not
> overwhelmed by any of the additions TC39 has chosen to make to ECMA.

Absolutely. Framework fatigue? Yes. Language change fatigue? Not at
all. The opposite, if anything -- eagerness to get to using the new
stuff.

> I don't think TC39 should need to babysit or have a special line of 
> communication with any specific libraries. Smells of lobbying and politics.

Yes indeed. Similarly:

On Sat, Jul 22, 2017 at 4:14 PM, Andrea Giammarchi
 wrote:

> TBH, I'd love to have an official review channel for hacky practices used on 
> frameworks, no matter how big is their company size, and flag officially as 
> TC39 friendly.

Same problem (lobbying and politics), as well as scope creep (that's
not their job) and limited resources (I'd rather they spent their TC39
time on the main mission: moving the language foward).

On Sat, Jul 22, 2017 at 6:44 PM, Andrea Giammarchi
 wrote
(replying to kai zhu ):

> > tc39 should be a bit more [expletive deleted] imo.
>
> No it shouldn't, it should be open minded and able to listen too.

Amen.

> However, when TC39 makes a decision the JS community follows quite 
> religiously that decision.
>
> If TC39 says everything is fine, you have today situation you describe.

I haven't seen any indiction from TC39 that using Stage 1 proposals in
production is "fine."

> If TC39 would give some little extra direction, you'd have people thinking 
> about what they're using daily, example:
>
> statement: TC39 considers Stage 1 unstable and it should never be used on 
> production.
>
> result: people using early transpilers cannot complain about anything about 
> it and it's their choice.
>
> statement: TC39 consider the usage of `eval` inappropriate for production
>
> result: people using any library fully based on eval or Function would start 
> looking for better options

I wouldn't have thought such statements were required, given the way
the stages are described in the [process
document](https://tc39.github.io/process-document/). Reading through
that, if you're relying on anything that isn't at least at Stage 4 or
*well* into Stage 3, you should know that it could change
significantly or go away entirely, and be prepared for that. Caveat
usor.

But sure, perhaps a "guidelines for use in production" section would
be useful. The people who are relying on Stage 1 stuff presumably
haven't read the process document anyway and so won't see the
guidelines, but having them there makes it easier for people to point
out to them the dangers (or at least, considerations) of what they're
doing, backed by a link to the document. E.g., that if they want to
use X, that's their choice, but they should be aware they'll probably
have to refactor at some point, perhaps repeatedly, as it evolves into
something stable.

-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Vinnymac]

ingly.
>>>
>>> Typescript developers shouldn't be unprepared, and ES can continue on
>>> its path.
>>>
>>> None of this makes Typescript "bad". Developers can keep using their
>>> existing version of Typescript and its transpiler if they don't want to
>>> risk disruption.
>>>
>>> So this kind of works for everybody: those who want bleeding edge ideas
>>> implemented and are prepared to update in the face of breaking changes can
>>> use e.g. Typescript and keep updating its version; those who want current
>>> bleeding edge ideas implemented but not risk breaking changes can use e.g.
>>> Typescript but stick to the same version; those who want to use the latest
>>> features of ES can do so directly; those who want old ES code to continue
>>> to work can have that. So it seems all of these cases are serviced OK.
>>>
>>> I'm not sure it's TC39's job to mark the implementation of preliminary
>>> ideas as "unfriendly". If anything such implementations could expose any
>>> weaknesses of these ideas such that they can be improved upon, or if not,
>>> exposed as required as-is, potentially more clearly than a hypothetical
>>> discussion on them, and that would carry value in of itself.
>>>
>>> So Javascript and Typescript serve different purposes. Typescript, being
>>> as it is transpiled to Javascript, has the luxury of not having to be
>>> backwards compatible, whereas because Javascript is run directly on
>>> browsers, it has to be.
>>>
>>> On Sat, 22 Jul 2017 at 23:26 Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
>>>> CSP to name one, but you picked 1% of my reply.
>>>>
>>>> On Sat, 22 Jul 2017 at 19:52, Claude Petit  wrote:
>>>>
>>>>> “TC39 consider the usage of `eval` inappropriate for production”
>>>>>
>>>>>
>>>>>
>>>>> And what about dynamic code, expressions evaluation, ...? Who has wake
>>>>> up one day and decided that nobody should use “eval” ?
>>>>>
>>>>>
>>>>>
>>>>> *From:* Andrea Giammarchi [mailto:andrea.giammar...@gmail.com]
>>>>> *Sent:* Saturday, July 22, 2017 1:44 PM
>>>>> *To:* kai zhu 
>>>>> *Cc:* es-discuss 
>>>>> *Subject:* Re: Removal of language features
>>>>>
>>>>
>>>>>
>>>>> answering to all questions here:
>>>>>
>>>>
>>>>>
>>>>> > What problems would this address?
>>>>>
>>>>>
>>>>>
>>>>> It will give developers a clear indication of what's good and future
>>>>> proof and what's not so cool.
>>>>>
>>>>>
>>>>>
>>>>> MooTools and Prototype extending natives in all ways didn't translate
>>>>> into "cool, people like these methods, let's put them on specs" ... we all
>>>>> know the story.
>>>>>
>>>>>
>>>>>
>>>>> Having bad practices promoted as "cool stuff" is not a great way to
>>>>> move the web forward, which AFAIK is part of the manifesto too.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> > In general, the committee sees any tool with significant adoption as
>>>>> an opportunity to learn/draw ideas from, not a plague.
>>>>>
>>>>>
>>>>>
>>>>> That's the ideal situation, reality is that there are so many Stage 0
>>>>> proposals instantly adopted by many that have been discarded by TC39.
>>>>>
>>>>>
>>>>>
>>>>> This spans to other standards like W3C or WHATWG, see Custom Elements
>>>>> builtin extends as clear example of what I mean.
>>>>>
>>>>>
>>>>>
>>>>> Committee might have the *right* opinion even about proposed
>>>>> standards, not even developers experimenting, so as much I believe what 
>>>>> you
>>>>> stated is true, I'm not sure that's actually what happens. There are more
>>>>> things to consider than hype, and thanks gosh it's like that.
>>>>>
>>>>>
>>>>>
>>>>>
&

Re: Removal of language features

[Jordan Harband]

ause Javascript is run directly on
>> browsers, it has to be.
>>
>> On Sat, 22 Jul 2017 at 23:26 Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> CSP to name one, but you picked 1% of my reply.
>>>
>>> On Sat, 22 Jul 2017 at 19:52, Claude Petit  wrote:
>>>
>>>> “TC39 consider the usage of `eval` inappropriate for production”
>>>>
>>>>
>>>>
>>>> And what about dynamic code, expressions evaluation, ...? Who has wake
>>>> up one day and decided that nobody should use “eval” ?
>>>>
>>>>
>>>>
>>>> *From:* Andrea Giammarchi [mailto:andrea.giammar...@gmail.com]
>>>> *Sent:* Saturday, July 22, 2017 1:44 PM
>>>> *To:* kai zhu 
>>>> *Cc:* es-discuss 
>>>> *Subject:* Re: Removal of language features
>>>>
>>>
>>>>
>>>> answering to all questions here:
>>>>
>>>
>>>>
>>>> > What problems would this address?
>>>>
>>>>
>>>>
>>>> It will give developers a clear indication of what's good and future
>>>> proof and what's not so cool.
>>>>
>>>>
>>>>
>>>> MooTools and Prototype extending natives in all ways didn't translate
>>>> into "cool, people like these methods, let's put them on specs" ... we all
>>>> know the story.
>>>>
>>>>
>>>>
>>>> Having bad practices promoted as "cool stuff" is not a great way to
>>>> move the web forward, which AFAIK is part of the manifesto too.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> > In general, the committee sees any tool with significant adoption as
>>>> an opportunity to learn/draw ideas from, not a plague.
>>>>
>>>>
>>>>
>>>> That's the ideal situation, reality is that there are so many Stage 0
>>>> proposals instantly adopted by many that have been discarded by TC39.
>>>>
>>>>
>>>>
>>>> This spans to other standards like W3C or WHATWG, see Custom Elements
>>>> builtin extends as clear example of what I mean.
>>>>
>>>>
>>>>
>>>> Committee might have the *right* opinion even about proposed standards,
>>>> not even developers experimenting, so as much I believe what you stated is
>>>> true, I'm not sure that's actually what happens. There are more things to
>>>> consider than hype, and thanks gosh it's like that.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> > you wouldn't see any interest in policing libraries and frameworks
>>>> from the committee
>>>>
>>>>
>>>>
>>>> agreed, because policing is a strong term. "TC39 friendly" is what I
>>>> was thinking of, something like any other GitHub badge when it comes to
>>>> code coverage, coding style, or target engines.
>>>>
>>>>
>>>>
>>>> I'm a pioneer of any sort of hacks myself, but I know that if my new
>>>> library is fully implemented thanks to eval and global prototype pollution,
>>>> through transpiled code that uses reserved words, probably nobody beside me
>>>> inside my crazy-lab should use my own code, no matter how much I promote 
>>>> it.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> > This is in conflict with the extensible web manifesto
>>>>
>>>>
>>>>
>>>> The situation I've just described would be indeed against the web
>>>> manifesto, wouldn't it?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> > tc39 should be a bit more assholish imo.
>>>>
>>>>
>>>>
>>>> No it shouldn't, it should be open minded and able to listen too.
>>>> However, when TC39 makes a decision the JS community follows quite
>>>> religiously that decision.
>>>>
>>>>
>>>>
>>>> If TC39 says everything is fine, you have today situation you describe.
>>>>
>>>>
>>>>
>>>> If TC39 would give some little extra direction, you'd have people
>>>> thinking about what they're using daily, example:
>>>>
>>>>
>>>>
>>>> statement: TC39 considers Stage 1 unstable and it should never be used
>>>> on production.
>>>>
>>>> result: people using early transpilers cannot complain about anything
>>>> about it and it's their choice.
>>>>
>>>>
>>>>
>>>> statement: TC39 consider the usage of `eval` inappropriate for
>>>> production
>>>>
>>>> result: people using any library fully based on eval or Function would
>>>> start looking for better options
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> And so on, I hope my previous email is now cleared a little bit, I'm a
>>>> JS developer myself and I promote both poly and
>>>> libraries/frameworks/utilities since ever.
>>>>
>>>>
>>>>
>>>> If anyone from TC39 would tell me: "dude, this is bad because not
>>>> future friendly" I'd either put that info on the README of the GitHub repo
>>>> or tell people about it even if it's my lib.
>>>>
>>>>
>>>>
>>>> Best Regards
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Bob Myers]

Some comments on various posts in this thread:

1. Asia has more than four billion people. Can we please avoid making
generalizations about the level of competence of engineering managers in
that region to make risk/benefit trade-offs?

2. I don't understand the TC39 process, but I am guessing they are not
authorized to make pronouncements about framework friendliness. Given the
overall level of bureaucracy, it would probably take one year, if that, to
even amend the charter to include the ability to issue such moral judgments
in their mission. Then each individual judgment would take months at best
to be approved. Then such judgments, once issued sometime in 2019, would be
widely ignored by the community.

3. If someone is worried about the rogue designers on the TypeScript team
hijacking the `enum` keyword, why not just adopt it as is? The design is
fine as it stands.

4. I cannot but read some of the comments in this thread as amounting to
saying that no-one should be allowed to innovate outside the TC39
framework, and no-one should be allowed to adopt such innovations. As an
unabashed TypeScript fan, this puzzles me. At our company, we are not only
using TypeScript for all front-end work, but also for node.js back-ends.
The decision to do so was made by the consensus of a number of
knowledgeable managers who are fully cognizant of the risk/reward equation.
There is an undeniable, demonstrable improvement in programming
productivity and code quality. While TC39 was bike-shedding about
exponentiation precedence, or adding `padLeft`, the TypeScript team was
making real, meaningful, useful, real-world improvements.

5. I think there is a tendency to underestimate the level of engineering
excellence embodied in TypeScript, and their self-understanding of where
they fit in the JS ecosystem. Personally, I have a great deal of confidence
in their ability to adapt to and maintain compatibility with evolving TC39
standards. As Maggie wisely points out, we should learn from them, not piss
on them.

Bob




On Sun, Jul 23, 2017 at 12:05 AM, Naveen Chawla 
wrote:

> Typescript allows breaking changes, ES doesn't.
>
> Hence it would be an acceptable decision for ES to clash with an existing
> Typescript keyword and force Typescript to update accordingly.
>
> Typescript developers shouldn't be unprepared, and ES can continue on its
> path.
>
> None of this makes Typescript "bad". Developers can keep using their
> existing version of Typescript and its transpiler if they don't want to
> risk disruption.
>
> So this kind of works for everybody: those who want bleeding edge ideas
> implemented and are prepared to update in the face of breaking changes can
> use e.g. Typescript and keep updating its version; those who want current
> bleeding edge ideas implemented but not risk breaking changes can use e.g.
> Typescript but stick to the same version; those who want to use the latest
> features of ES can do so directly; those who want old ES code to continue
> to work can have that. So it seems all of these cases are serviced OK.
>
> I'm not sure it's TC39's job to mark the implementation of preliminary
> ideas as "unfriendly". If anything such implementations could expose any
> weaknesses of these ideas such that they can be improved upon, or if not,
> exposed as required as-is, potentially more clearly than a hypothetical
> discussion on them, and that would carry value in of itself.
>
> So Javascript and Typescript serve different purposes. Typescript, being
> as it is transpiled to Javascript, has the luxury of not having to be
> backwards compatible, whereas because Javascript is run directly on
> browsers, it has to be.
>
> On Sat, 22 Jul 2017 at 23:26 Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> CSP to name one, but you picked 1% of my reply.
>>
>> On Sat, 22 Jul 2017 at 19:52, Claude Petit  wrote:
>>
>>> “TC39 consider the usage of `eval` inappropriate for production”
>>>
>>>
>>>
>>> And what about dynamic code, expressions evaluation, ...? Who has wake
>>> up one day and decided that nobody should use “eval” ?
>>>
>>>
>>>
>>> *From:* Andrea Giammarchi [mailto:andrea.giammar...@gmail.com]
>>> *Sent:* Saturday, July 22, 2017 1:44 PM
>>> *To:* kai zhu 
>>> *Cc:* es-discuss 
>>> *Subject:* Re: Removal of language features
>>>
>>
>>>
>>> answering to all questions here:
>>>
>>
>>>
>>> > What problems would this address?
>>>
>>>
>>>
>>> It will give developers a clear indication of what's good and future
>>> proof and what's not so cool.
>>>
>>>
>>

Re: Removal of language features

[Steve Fink]

This makes sense to me. Though I kind of feel like the discussion has 
veered off on a less useful direction because of reactions to words like 
"policing" or "gatekeeping". It may be more productive to consider 
whether it might be useful to have a mechanism whereby frameworks could 
leverage the expertise of people close to tc39. If I were a framework 
author (and I'm not), I would appreciate having the ability to say "hey, 
I'm thinking of doing X. What current or potential problems could X run 
into with respect to ES?" The expectation is that I would take the 
feedback into account (so tc39 people wouldn't feel like they were 
shouting into the void, or participating in a meaningless feel-good 
opportunity.) TC39 would benefit by having some degree of influence (not 
control!) over the more unfortunate directions of frameworks, as well as 
getting more exposure to the sorts of problems people are running into.


Anyway, I don't have a dog in any of these races. (Hell, I'm more of a 
cat person to begin with.) I just see the conversation taking a less 
than useful path, and wanted to point it out.


On 07/22/2017 11:35 AM, Naveen Chawla wrote:

Typescript allows breaking changes, ES doesn't.

Hence it would be an acceptable decision for ES to clash with an 
existing Typescript keyword and force Typescript to update accordingly.


Typescript developers shouldn't be unprepared, and ES can continue on 
its path.


None of this makes Typescript "bad". Developers can keep using their 
existing version of Typescript and its transpiler if they don't want 
to risk disruption.


So this kind of works for everybody: those who want bleeding edge 
ideas implemented and are prepared to update in the face of breaking 
changes can use e.g. Typescript and keep updating its version; those 
who want current bleeding edge ideas implemented but not risk breaking 
changes can use e.g. Typescript but stick to the same version; those 
who want to use the latest features of ES can do so directly; those 
who want old ES code to continue to work can have that. So it seems 
all of these cases are serviced OK.


I'm not sure it's TC39's job to mark the implementation of preliminary 
ideas as "unfriendly". If anything such implementations could expose 
any weaknesses of these ideas such that they can be improved upon, or 
if not, exposed as required as-is, potentially more clearly than a 
hypothetical discussion on them, and that would carry value in of itself.


So Javascript and Typescript serve different purposes. Typescript, 
being as it is transpiled to Javascript, has the luxury of not having 
to be backwards compatible, whereas because Javascript is run directly 
on browsers, it has to be.


On Sat, 22 Jul 2017 at 23:26 Andrea Giammarchi 
mailto:andrea.giammar...@gmail.com>> wrote:


CSP to name one, but you picked 1% of my reply.

On Sat, 22 Jul 2017 at 19:52, Claude Petit mailto:p...@webmail.us>> wrote:

“TC39 consider the usage of `eval` inappropriate for production”

And what about dynamic code, expressions evaluation, ...? Who
has wake up one day and decided that nobody should use “eval” ?

*From:* Andrea Giammarchi [mailto:andrea.giammar...@gmail.com
<mailto:andrea.giammar...@gmail.com>]
*Sent:* Saturday, July 22, 2017 1:44 PM
*To:* kai zhu mailto:kaizhu...@gmail.com>>
*Cc:* es-discuss mailto:es-discuss@mozilla.org>>
*Subject:* Re: Removal of language features

answering to all questions here:

> What problems would this address?

It will give developers a clear indication of what's good and
future proof and what's not so cool.

MooTools and Prototype extending natives in all ways didn't
translate into "cool, people like these methods, let's put
them on specs" ... we all know the story.

Having bad practices promoted as "cool stuff" is not a great
way to move the web forward, which AFAIK is part of the
manifesto too.

> In general, the committee sees any tool with significant adoption as 
an
opportunity to learn/draw ideas from, not a plague.

That's the ideal situation, reality is that there are so many
Stage 0 proposals instantly adopted by many that have been
discarded by TC39.

This spans to other standards like W3C or WHATWG, see Custom
Elements builtin extends as clear example of what I mean.

Committee might have the *right* opinion even about proposed
standards, not even developers experimenting, so as much I
believe what you stated is true, I'm not sure that's actually
what happens. There are more things to consider than hype, and
thanks gosh it's like 

Re: Removal of language features

[Steve Fink]

On 07/21/2017 03:00 PM, kai zhu wrote:
Can you produce any data at all to back that up? I've never seen any 
appetite in that regard at all.
no hard data admittedly.  i regularly attend tech meetups in hong 
kong.  at these gatherings, the general sentiment from frontend 
developers is that creating webapps has gotten considerably more 
difficult with the newish technologies.  even the local presenters for 
react and angular2+ at these talks can’t hide their lack of enthusiasm 
for these frameworks (like they’re doing it mainly to hustle more 
side-business for themselves).  on-the-job, we all generally try to 
avoid taking on such technical risks, until we are inevitably asked to 
by our manager.  the ones i see who are enthusiastic are typically 
non-frontend-engineers who write mostly backend nodejs code, that 
isn’t all that more scalable or interesting with what you can do in 
java/c#/ruby.


I think this is mixing up frameworks with the language. There is indeed 
extreme framework fatigue, and has been for quite some time. Language 
changes have been much slower and mind-bending, and it is my 
(uninformed) impression that people generally haven't had too much 
difficulty incorporating them. Or at least, not nearly as much as 
learning the mindset of eg React or Flux or Angular or whatever. And 
there seems to usually be a sense of relief when something gets added to 
the language that removes the need for the workarounds that the 
libraries and frameworks have been using for some time.


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Naveen Chawla]

Typescript allows breaking changes, ES doesn't.

Hence it would be an acceptable decision for ES to clash with an existing
Typescript keyword and force Typescript to update accordingly.

Typescript developers shouldn't be unprepared, and ES can continue on its
path.

None of this makes Typescript "bad". Developers can keep using their
existing version of Typescript and its transpiler if they don't want to
risk disruption.

So this kind of works for everybody: those who want bleeding edge ideas
implemented and are prepared to update in the face of breaking changes can
use e.g. Typescript and keep updating its version; those who want current
bleeding edge ideas implemented but not risk breaking changes can use e.g.
Typescript but stick to the same version; those who want to use the latest
features of ES can do so directly; those who want old ES code to continue
to work can have that. So it seems all of these cases are serviced OK.

I'm not sure it's TC39's job to mark the implementation of preliminary
ideas as "unfriendly". If anything such implementations could expose any
weaknesses of these ideas such that they can be improved upon, or if not,
exposed as required as-is, potentially more clearly than a hypothetical
discussion on them, and that would carry value in of itself.

So Javascript and Typescript serve different purposes. Typescript, being as
it is transpiled to Javascript, has the luxury of not having to be
backwards compatible, whereas because Javascript is run directly on
browsers, it has to be.

On Sat, 22 Jul 2017 at 23:26 Andrea Giammarchi 
wrote:

> CSP to name one, but you picked 1% of my reply.
>
> On Sat, 22 Jul 2017 at 19:52, Claude Petit  wrote:
>
>> “TC39 consider the usage of `eval` inappropriate for production”
>>
>>
>>
>> And what about dynamic code, expressions evaluation, ...? Who has wake up
>> one day and decided that nobody should use “eval” ?
>>
>>
>>
>> *From:* Andrea Giammarchi [mailto:andrea.giammar...@gmail.com]
>> *Sent:* Saturday, July 22, 2017 1:44 PM
>> *To:* kai zhu 
>> *Cc:* es-discuss 
>> *Subject:* Re: Removal of language features
>>
>
>>
>> answering to all questions here:
>>
>
>>
>> > What problems would this address?
>>
>>
>>
>> It will give developers a clear indication of what's good and future
>> proof and what's not so cool.
>>
>>
>>
>> MooTools and Prototype extending natives in all ways didn't translate
>> into "cool, people like these methods, let's put them on specs" ... we all
>> know the story.
>>
>>
>>
>> Having bad practices promoted as "cool stuff" is not a great way to move
>> the web forward, which AFAIK is part of the manifesto too.
>>
>>
>>
>>
>>
>> > In general, the committee sees any tool with significant adoption as an
>> opportunity to learn/draw ideas from, not a plague.
>>
>>
>>
>> That's the ideal situation, reality is that there are so many Stage 0
>> proposals instantly adopted by many that have been discarded by TC39.
>>
>>
>>
>> This spans to other standards like W3C or WHATWG, see Custom Elements
>> builtin extends as clear example of what I mean.
>>
>>
>>
>> Committee might have the *right* opinion even about proposed standards,
>> not even developers experimenting, so as much I believe what you stated is
>> true, I'm not sure that's actually what happens. There are more things to
>> consider than hype, and thanks gosh it's like that.
>>
>>
>>
>>
>>
>> > you wouldn't see any interest in policing libraries and frameworks from
>> the committee
>>
>>
>>
>> agreed, because policing is a strong term. "TC39 friendly" is what I was
>> thinking of, something like any other GitHub badge when it comes to code
>> coverage, coding style, or target engines.
>>
>>
>>
>> I'm a pioneer of any sort of hacks myself, but I know that if my new
>> library is fully implemented thanks to eval and global prototype pollution,
>> through transpiled code that uses reserved words, probably nobody beside me
>> inside my crazy-lab should use my own code, no matter how much I promote it.
>>
>>
>>
>>
>>
>> > This is in conflict with the extensible web manifesto
>>
>>
>>
>> The situation I've just described would be indeed against the web
>> manifesto, wouldn't it?
>>
>>
>>
>>
>>
>> > tc39 should be a bit more assholish im

Re: Removal of language features

[Andrea Giammarchi]

CSP to name one, but you picked 1% of my reply.

On Sat, 22 Jul 2017 at 19:52, Claude Petit  wrote:

> “TC39 consider the usage of `eval` inappropriate for production”
>
>
>
> And what about dynamic code, expressions evaluation, ...? Who has wake up
> one day and decided that nobody should use “eval” ?
>
>
>
> *From:* Andrea Giammarchi [mailto:andrea.giammar...@gmail.com]
> *Sent:* Saturday, July 22, 2017 1:44 PM
> *To:* kai zhu 
> *Cc:* es-discuss 
> *Subject:* Re: Removal of language features
>
>
>
> answering to all questions here:
>
>
>
> > What problems would this address?
>
>
>
> It will give developers a clear indication of what's good and future proof
> and what's not so cool.
>
>
>
> MooTools and Prototype extending natives in all ways didn't translate into
> "cool, people like these methods, let's put them on specs" ... we all know
> the story.
>
>
>
> Having bad practices promoted as "cool stuff" is not a great way to move
> the web forward, which AFAIK is part of the manifesto too.
>
>
>
>
>
> > In general, the committee sees any tool with significant adoption as an
> opportunity to learn/draw ideas from, not a plague.
>
>
>
> That's the ideal situation, reality is that there are so many Stage 0
> proposals instantly adopted by many that have been discarded by TC39.
>
>
>
> This spans to other standards like W3C or WHATWG, see Custom Elements
> builtin extends as clear example of what I mean.
>
>
>
> Committee might have the *right* opinion even about proposed standards,
> not even developers experimenting, so as much I believe what you stated is
> true, I'm not sure that's actually what happens. There are more things to
> consider than hype, and thanks gosh it's like that.
>
>
>
>
>
> > you wouldn't see any interest in policing libraries and frameworks from
> the committee
>
>
>
> agreed, because policing is a strong term. "TC39 friendly" is what I was
> thinking of, something like any other GitHub badge when it comes to code
> coverage, coding style, or target engines.
>
>
>
> I'm a pioneer of any sort of hacks myself, but I know that if my new
> library is fully implemented thanks to eval and global prototype pollution,
> through transpiled code that uses reserved words, probably nobody beside me
> inside my crazy-lab should use my own code, no matter how much I promote it.
>
>
>
>
>
> > This is in conflict with the extensible web manifesto
>
>
>
> The situation I've just described would be indeed against the web
> manifesto, wouldn't it?
>
>
>
>
>
> > tc39 should be a bit more assholish imo.
>
>
>
> No it shouldn't, it should be open minded and able to listen too. However,
> when TC39 makes a decision the JS community follows quite religiously that
> decision.
>
>
>
> If TC39 says everything is fine, you have today situation you describe.
>
>
>
> If TC39 would give some little extra direction, you'd have people thinking
> about what they're using daily, example:
>
>
>
> statement: TC39 considers Stage 1 unstable and it should never be used on
> production.
>
> result: people using early transpilers cannot complain about anything
> about it and it's their choice.
>
>
>
> statement: TC39 consider the usage of `eval` inappropriate for production
>
> result: people using any library fully based on eval or Function would
> start looking for better options
>
>
>
>
>
> And so on, I hope my previous email is now cleared a little bit, I'm a JS
> developer myself and I promote both poly and libraries/frameworks/utilities
> since ever.
>
>
>
> If anyone from TC39 would tell me: "dude, this is bad because not future
> friendly" I'd either put that info on the README of the GitHub repo or tell
> people about it even if it's my lib.
>
>
>
> Best Regards
>
>
>
>
>
>
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

FW: Removal of language features

[doodad-js Admin]

“TC39 consider the usage of `eval` inappropriate for production”

 

And what about dynamic code, expressions evaluation, ...? Who has wake up one 
day and decided that nobody should use “eval” ?

 

From: Andrea Giammarchi [mailto:andrea.giammar...@gmail.com] 
Sent: Saturday, July 22, 2017 1:44 PM
To: kai zhu mailto:kaizhu...@gmail.com> >
Cc: es-discuss mailto:es-discuss@mozilla.org> >
Subject: Re: Removal of language features

 

answering to all questions here:

 

> What problems would this address?

 

It will give developers a clear indication of what's good and future proof and 
what's not so cool.

 

MooTools and Prototype extending natives in all ways didn't translate into 
"cool, people like these methods, let's put them on specs" ... we all know the 
story.

 

Having bad practices promoted as "cool stuff" is not a great way to move the 
web forward, which AFAIK is part of the manifesto too.

 

 

> In general, the committee sees any tool with significant adoption as an 
> opportunity to learn/draw ideas from, not a plague.

 

That's the ideal situation, reality is that there are so many Stage 0 proposals 
instantly adopted by many that have been discarded by TC39.

 

This spans to other standards like W3C or WHATWG, see Custom Elements builtin 
extends as clear example of what I mean.

 

Committee might have the *right* opinion even about proposed standards, not 
even developers experimenting, so as much I believe what you stated is true, 
I'm not sure that's actually what happens. There are more things to consider 
than hype, and thanks gosh it's like that.

 

 

> you wouldn't see any interest in policing libraries and frameworks from the 
> committee

 

agreed, because policing is a strong term. "TC39 friendly" is what I was 
thinking of, something like any other GitHub badge when it comes to code 
coverage, coding style, or target engines.

 

I'm a pioneer of any sort of hacks myself, but I know that if my new library is 
fully implemented thanks to eval and global prototype pollution, through 
transpiled code that uses reserved words, probably nobody beside me inside my 
crazy-lab should use my own code, no matter how much I promote it.

 

 

> This is in conflict with the extensible web manifesto

 

The situation I've just described would be indeed against the web manifesto, 
wouldn't it?

 

 

> tc39 should be a bit more assholish imo.

 

No it shouldn't, it should be open minded and able to listen too. However, when 
TC39 makes a decision the JS community follows quite religiously that decision.

 

If TC39 says everything is fine, you have today situation you describe.

 

If TC39 would give some little extra direction, you'd have people thinking 
about what they're using daily, example:

 

statement: TC39 considers Stage 1 unstable and it should never be used on 
production.

result: people using early transpilers cannot complain about anything about it 
and it's their choice.

 

statement: TC39 consider the usage of `eval` inappropriate for production

result: people using any library fully based on eval or Function would start 
looking for better options

 

 

And so on, I hope my previous email is now cleared a little bit, I'm a JS 
developer myself and I promote both poly and libraries/frameworks/utilities 
since ever.

 

If anyone from TC39 would tell me: "dude, this is bad because not future 
friendly" I'd either put that info on the README of the GitHub repo or tell 
people about it even if it's my lib.

 

Best Regards

 

 

 

 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Andrea Giammarchi]

answering to all questions here:

> What problems would this address?

It will give developers a clear indication of what's good and future proof
and what's not so cool.

MooTools and Prototype extending natives in all ways didn't translate into
"cool, people like these methods, let's put them on specs" ... we all know
the story.

Having bad practices promoted as "cool stuff" is not a great way to move
the web forward, which AFAIK is part of the manifesto too.


> In general, the committee sees any tool with significant adoption as an
opportunity to learn/draw ideas from, not a plague.

That's the ideal situation, reality is that there are so many Stage 0
proposals instantly adopted by many that have been discarded by TC39.

This spans to other standards like W3C or WHATWG, see Custom Elements
builtin extends as clear example of what I mean.

Committee might have the *right* opinion even about proposed standards, not
even developers experimenting, so as much I believe what you stated is
true, I'm not sure that's actually what happens. There are more things to
consider than hype, and thanks gosh it's like that.


> you wouldn't see any interest in policing libraries and frameworks from
the committee

agreed, because policing is a strong term. "TC39 friendly" is what I was
thinking of, something like any other GitHub badge when it comes to code
coverage, coding style, or target engines.

I'm a pioneer of any sort of hacks myself, but I know that if my new
library is fully implemented thanks to eval and global prototype pollution,
through transpiled code that uses reserved words, probably nobody beside me
inside my crazy-lab should use my own code, no matter how much I promote it.


> This is in conflict with the extensible web manifesto

The situation I've just described would be indeed against the web
manifesto, wouldn't it?


> tc39 should be a bit more assholish imo.

No it shouldn't, it should be open minded and able to listen too. However,
when TC39 makes a decision the JS community follows quite religiously that
decision.

If TC39 says everything is fine, you have today situation you describe.

If TC39 would give some little extra direction, you'd have people thinking
about what they're using daily, example:

statement: TC39 considers Stage 1 unstable and it should never be used on
production.
result: people using early transpilers cannot complain about anything about
it and it's their choice.

statement: TC39 consider the usage of `eval` inappropriate for production
result: people using any library fully based on eval or Function would
start looking for better options


And so on, I hope my previous email is now cleared a little bit, I'm a JS
developer myself and I promote both poly and libraries/frameworks/utilities
since ever.

If anyone from TC39 would tell me: "dude, this is bad because not future
friendly" I'd either put that info on the README of the GitHub repo or tell
people about it even if it's my lib.

Best Regards
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[kai zhu]

> On Jul 22, 2017, at 11:37 PM, Maggie Pint  wrote:

> 
> Having been a delegate to tc39 from the JS foundation for only about six 
> months, I can't claim authority to speak to all of the history here. That 
> said, I can very assuredly tell you there is a significant amount of respect 
> for every technology that has been mentioned in this thread from most of the 
> committee. In general, the committee sees any tool with significant adoption 
> as an opportunity to learn/draw ideas from, not a plague.

tc39 should be a bit more assholish imo.  frontend-development (at least in 
asia) is in a zombie-state with few really understanding the technical-risks of 
the latest technologies and practices.  this mess is partly due to no-one in 
the committee having the foresight and courage to gatekeep es6 to a manageable 
number of features.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Maggie Pint]

Having been a delegate to tc39 from the JS foundation for only about six
months, I can't claim authority to speak to all of the history here. That
said, I can very assuredly tell you there is a significant amount of
respect for every technology that has been mentioned in this thread from
most of the committee. In general, the committee sees any tool with
significant adoption as an opportunity to learn/draw ideas from, not a
plague.

Certainly, all delegates have their own opinions on various things. That
said, IMO you wouldn't see any interest in policing libraries and
frameworks from the committee. This is in conflict with the extensible web
manifesto that most of the committee holds quite dear.

On Jul 22, 2017 8:22 AM, "Mike Samuel"  wrote:

>
>
> On Jul 22, 2017 11:14 AM, "Andrea Giammarchi" 
> wrote:
>
>
> About frameworks or Angular, version 1 was based on eval and I think
> frameworks should have an OK from TC39 before being considered influential .
>
>
> What problems would this address?  I would prefer almost any other
> solution to taking "official" positions on frameworks or libraries.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Mike Samuel]

On Jul 22, 2017 11:14 AM, "Andrea Giammarchi" 
wrote:


About frameworks or Angular, version 1 was based on eval and I think
frameworks should have an OK from TC39 before being considered influential .


What problems would this address?  I would prefer almost any other solution
to taking "official" positions on frameworks or libraries.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Andrea Giammarchi]

My point was that ES classes work as spec'd TypeScript classes are broken
without warning.

It's also not a matter of smelly instanceof, the problem is that if you add
a method to that list class it won't be there. The returned instance/object
won't have anything to do with the List class so classes in the well
defined TypeScript language are not even close to native JS.

Babel bug is well known and I've proposed already a fix and I've also
opened the currently opened bug about it.

Although Babel doesn't claim to be a well defined language, it's just a
transpiler, hence my nitpick on the TS description.

About frameworks or Angular, version 1 was based on eval and I think
frameworks should have an OK from TC39 before being considered influential .

TBH, I'd love to have an official review channel for hacky practices used
on frameworks, no matter how big is their company size, and flag officially
as TC39 friendly.

No idea if there are resources to do that, though, so I'm just speaking out
loudly.

Regards

On Sat, 22 Jul 2017 at 16:48, T.J. Crowder 
wrote:

> On Sat, Jul 22, 2017 at 3:17 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> ```js
>> class List extends Array { }
>>
>> console.log(new List instanceof List);
>> // false .. seriously
>> ```
>>
>> Try it yourself. [1]
>>
>
> I don't have a horse in the TypeScript race, but that example is unfair:
> The playground targets ES5 by default. As you know, you can't correctly
> subclass Array with ES5 features. To get the expected `instanceof` result
> from that code in ES5-land, TypeScript would have to replace uses of
> `instanceof` with something of its own, sacrificing efficiency for a
> questionable gain (`instanceof` usually smells anyway). (It *is*
> unfortunate that http://www.typescriptlang.org/docs/handbook/classes.html
> doesn't mention this.)
>
> But ES5 output is just an option; if you tell TypeScript to output ES2015
> code instead (`tsc --target ES2015 example.ts`), you get the expected
> result. Note that Babel targeting ES5 output also outputs "false":
> https://goo.gl/aJuQjV (that's just a shortened version of the Babel link
> resulting from pasting the code above into https://babeljs.io/repl)
>
> If necessary, let's have a reasonable discussion of whether TypeScript's
> co-opting of keywords and syntax has a negative effect on the evolution of
> JavaScript (if that's a useful conversation to have), but let's not blame
> TypeScript for ES5's deficiencies, particularly not ones that were fixed
> more than two years ago.
>
>
> -- T.J. Crowder
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[T.J. Crowder]

On Sat, Jul 22, 2017 at 3:17 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> ```js
> class List extends Array { }
>
> console.log(new List instanceof List);
> // false .. seriously
> ```
>
> Try it yourself. [1]
>

I don't have a horse in the TypeScript race, but that example is unfair:
The playground targets ES5 by default. As you know, you can't correctly
subclass Array with ES5 features. To get the expected `instanceof` result
from that code in ES5-land, TypeScript would have to replace uses of
`instanceof` with something of its own, sacrificing efficiency for a
questionable gain (`instanceof` usually smells anyway). (It *is*
unfortunate that http://www.typescriptlang.org/docs/handbook/classes.html
doesn't mention this.)

But ES5 output is just an option; if you tell TypeScript to output ES2015
code instead (`tsc --target ES2015 example.ts`), you get the expected
result. Note that Babel targeting ES5 output also outputs "false":
https://goo.gl/aJuQjV (that's just a shortened version of the Babel link
resulting from pasting the code above into https://babeljs.io/repl)

If necessary, let's have a reasonable discussion of whether TypeScript's
co-opting of keywords and syntax has a negative effect on the evolution of
JavaScript (if that's a useful conversation to have), but let's not blame
TypeScript for ES5's deficiencies, particularly not ones that were fixed
more than two years ago.

-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Andrea Giammarchi]

My 2 cents

> TypeScript, which like it or not is a perfectly well-defined language.

TS these days is a broken, diverging, branch of latest ECMAScript features,
IMO.

```js
class List extends Array { }

console.log(new List instanceof List);
// false .. seriously
```

Try it yourself. [1]

You can also argue that type, enum, interface, and private are also not
aligned with ECMAScript so as much as "well-defined language" as it is, it
shouldn't compromise any future development of an already "well-defined
language" too which is JavaScript.

Best Regards

[1]
http://www.typescriptlang.org/play/#src=class%20List%20extends%20Array%20%7B%20%7D%0D%0A%0D%0Aconsole.log(new%20List%20instanceof%20List)%3B%20%2F%2F%20false
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[kdex]

Inline.

On Saturday, July 22, 2017 7:47:32 AM CEST Bob Myers wrote:
> Let me weigh in as an Angular programmer.
> 
> Angular does not "encourage use of non-standard and/or unstable language
> features". It encourages (indeed for all practical purposes mandates) the
> use of TypeScript, which like it or not is a perfectly well-defined
> language.
> 
> The TypeScript designers walk a fine line between providing features that
> the user base needs and wants, and getting too far out on the cutting edge.
> IMHO, they have done a very good job threading this needle. They
> religiously avoid adding features which are unstable or perceived as likely
> to change. The TS discussion list is replete with requests for adding this
> that or the other stage-0 feature, but such requests are invariably
> rejected.

With regard to non-standard and/or unstable features:

Examples for cases where TypeScript has actively harmed the ECMAScript 
ecosystem would be every instance where it was decided to mess with reserved 
words. `enum` and `interface` would be just two such examples.

In fact, this has recently come up in the ecmascript-interfaces-proposal [1], 
which led to the (IMHO absurd) idea of introducing `interface` under the 
keyword `protocol`, just so that ECMAScript and TypeScript play nice together.

Compatibility is nice, but ECMAScript can not be holding the bag for every 
"compiles to ES" type of language out there, especially if those languages 
decide to gamble with syntax and semantics when it comes to reserved words. 
That's really their own fault.

CoffeeScript didn't make the mistake of claiming to be a superset of 
ECMAScript at any time. TypeScript did. Consequently, there must either 
incompatibilities between the two languages, or TypeScript will have to be 
versioned and made backwards-incompatible to follow ECMAScript. Both of which 
is equally horrendous and far from what I would still call "perfectly well-
defined".

[1] https://github.com/michaelficarra/ecmascript-interfaces-proposal/issues/3

> 
> I unfortunately sometimes get the impressions that the TC39 school views
> the TypeScript guys as the crazy uncle beating off over in the corner,
> while they define the "real" language at their own pace. Meanwhile,
> thousands of applications involving millions of lines of code are being
> developed in TS at high productivity levels, thanks not only to the
> language features but the extraordinarily good tooling and ecosystem. It
> would be a huge mistake to think that TypeScript is merely the CoffeeScript
> of our time.
> 
> With regard to the questionable comments in the post to which Isiah was
> responding, no, platform and toolchain decisions are not made by ignorant,
> copy-cat Asians. Nor are they usually made by non-technical PMs or other
> people in suits, other than in the form of approving recommendations made
> by forward-looking engineering management at the software or product
> company which is outsourcing its development. If you are losing mind-share
> with those folks, it's not their problem, it's your problem. Our
> engineering managers have been through countless iterations of the platform
> wars over the years, and usually have a finely honed sense of risk/benefit.
> The risk/benefit equation for TypeScript is overwhelmingly positive.
> 
> My two cents.
> 
> Bob
> 
> On Sat, Jul 22, 2017 at 4:31 AM, Isiah Meadows 
> 
> wrote:
> > Most of these flashy frameworks (e.g. Angular, React, and Aurelia)
> > encourage use of non-standard and/or unstable language features, even
> > though they shouldn't, and it's a horrible idea to even recommend
> > anything not at least stage 3 for general framework usage. (Note: I'm
> > an active core developer for Mithril, a front-end framework whose
> > community generally rejects the idea of embracing the latest and
> > greatest without good pragmatic reason.) Decorators are stage 2, and
> > the runtime API is still very much under flux. JSX is non-standard and
> > Facebook has stated they don't intend on promoting it to become
> > standard in any way.
> > 
> > Conversely, a large number of TC39 people have to deal with large
> > legacy projects and older browsers, and most of them work in large
> > companies with very large, brittle code bases where introducing a new
> > tool is often extremely costly, no matter what it is. Babel isn't an
> > option for many of them, and even Rollup (ES modules) and Bublé
> > (majority of useful ES6 language features) are difficult to introduce.
> > 
> > To draw a comparison, consider the structure of ESLint (100k+ lines of
> > pure, unprocessed ES6 minus modules) vs Babel (100k+ lines of Flow +
> > JS with numerous transforms applied) and Angular (100k+ lines of
> > TypeScript with some unstable features enabled). One is built from
> > pure JS and has had no issues with language stability, the second with
> > several non-standard additions and has had multiple wide-reaching
> > refactorizations, and the third using dec

Re: Removal of language features

[Bob Myers]

Let me weigh in as an Angular programmer.

Angular does not "encourage use of non-standard and/or unstable language
features". It encourages (indeed for all practical purposes mandates) the
use of TypeScript, which like it or not is a perfectly well-defined
language.

The TypeScript designers walk a fine line between providing features that
the user base needs and wants, and getting too far out on the cutting edge.
IMHO, they have done a very good job threading this needle. They
religiously avoid adding features which are unstable or perceived as likely
to change. The TS discussion list is replete with requests for adding this
that or the other stage-0 feature, but such requests are invariably
rejected.

I unfortunately sometimes get the impressions that the TC39 school views
the TypeScript guys as the crazy uncle beating off over in the corner,
while they define the "real" language at their own pace. Meanwhile,
thousands of applications involving millions of lines of code are being
developed in TS at high productivity levels, thanks not only to the
language features but the extraordinarily good tooling and ecosystem. It
would be a huge mistake to think that TypeScript is merely the CoffeeScript
of our time.

With regard to the questionable comments in the post to which Isiah was
responding, no, platform and toolchain decisions are not made by ignorant,
copy-cat Asians. Nor are they usually made by non-technical PMs or other
people in suits, other than in the form of approving recommendations made
by forward-looking engineering management at the software or product
company which is outsourcing its development. If you are losing mind-share
with those folks, it's not their problem, it's your problem. Our
engineering managers have been through countless iterations of the platform
wars over the years, and usually have a finely honed sense of risk/benefit.
The risk/benefit equation for TypeScript is overwhelmingly positive.

My two cents.

Bob

On Sat, Jul 22, 2017 at 4:31 AM, Isiah Meadows 
wrote:

>
> Most of these flashy frameworks (e.g. Angular, React, and Aurelia)
> encourage use of non-standard and/or unstable language features, even
> though they shouldn't, and it's a horrible idea to even recommend
> anything not at least stage 3 for general framework usage. (Note: I'm
> an active core developer for Mithril, a front-end framework whose
> community generally rejects the idea of embracing the latest and
> greatest without good pragmatic reason.) Decorators are stage 2, and
> the runtime API is still very much under flux. JSX is non-standard and
> Facebook has stated they don't intend on promoting it to become
> standard in any way.
>
> Conversely, a large number of TC39 people have to deal with large
> legacy projects and older browsers, and most of them work in large
> companies with very large, brittle code bases where introducing a new
> tool is often extremely costly, no matter what it is. Babel isn't an
> option for many of them, and even Rollup (ES modules) and Bublé
> (majority of useful ES6 language features) are difficult to introduce.
>
> To draw a comparison, consider the structure of ESLint (100k+ lines of
> pure, unprocessed ES6 minus modules) vs Babel (100k+ lines of Flow +
> JS with numerous transforms applied) and Angular (100k+ lines of
> TypeScript with some unstable features enabled). One is built from
> pure JS and has had no issues with language stability, the second with
> several non-standard additions and has had multiple wide-reaching
> refactorizations, and the third using decorators in both its API and
> implementation, whose spec's API went into significant flux around the
> time it was ready to go stable. (And BTW, Babel itself pulled
> decorator support because of the feature's instability.)
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Isiah Meadows]

Inline.

On Fri, Jul 21, 2017 at 6:00 PM, kai zhu  wrote:
> > Can you produce any data at all to back that up? I've never seen any
> appetite in that regard at all.
>
> no hard data admittedly.  i regularly attend tech meetups in hong kong.  at
> these gatherings, the general sentiment from frontend developers is that
> creating webapps has gotten considerably more difficult with the newish
> technologies.  even the local presenters for react and angular2+ at these
> talks can’t hide their lack of enthusiasm for these frameworks (like they’re
> doing it mainly to hustle more side-business for themselves).  on-the-job,
> we all generally try to avoid taking on such technical risks, until we are
> inevitably asked to by our manager.  the ones i see who are enthusiastic are
> typically non-frontend-engineers who write mostly backend nodejs code, that
> isn’t all that more scalable or interesting with what you can do in
> java/c#/ruby.
>
> > Don't like `const`? Don't use it. Don't like arrow functions? Don't use
> > them. Don't like `async`/`await`? (You guessed it.) Don't use them. Nothing
> > other than unspecified behavior is any different unless you use it. (And
> > even in regard to unspecified behavior [I'm thinking function declarations
> > in blocks here], the committee has bent over backward to do their best to
> > avoid imposing changes on it.)
>
> this brings up the point that frontend developers have no say in these
> matters when a less-than-technical pm asks them to use frameworks that all
> but uses these features.  there are many of these managers in asia who copy
> whatever they perceive is trending in silicon valley, with very little care
> about the technical-risks they bring to projects.

Most of these flashy frameworks (e.g. Angular, React, and Aurelia)
encourage use of non-standard and/or unstable language features, even
though they shouldn't, and it's a horrible idea to even recommend
anything not at least stage 3 for general framework usage. (Note: I'm
an active core developer for Mithril, a front-end framework whose
community generally rejects the idea of embracing the latest and
greatest without good pragmatic reason.) Decorators are stage 2, and
the runtime API is still very much under flux. JSX is non-standard and
Facebook has stated they don't intend on promoting it to become
standard in any way.

Conversely, a large number of TC39 people have to deal with large
legacy projects and older browsers, and most of them work in large
companies with very large, brittle code bases where introducing a new
tool is often extremely costly, no matter what it is. Babel isn't an
option for many of them, and even Rollup (ES modules) and Bublé
(majority of useful ES6 language features) are difficult to introduce.

To draw a comparison, consider the structure of ESLint (100k+ lines of
pure, unprocessed ES6 minus modules) vs Babel (100k+ lines of Flow +
JS with numerous transforms applied) and Angular (100k+ lines of
TypeScript with some unstable features enabled). One is built from
pure JS and has had no issues with language stability, the second with
several non-standard additions and has had multiple wide-reaching
refactorizations, and the third using decorators in both its API and
implementation, whose spec's API went into significant flux around the
time it was ready to go stable. (And BTW, Babel itself pulled
decorator support because of the feature's instability.)

-

Isiah Meadows
m...@isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[kai zhu]

> Can you produce any data at all to back that up? I've never seen any appetite 
> in that regard at all.
no hard data admittedly.  i regularly attend tech meetups in hong kong.  at 
these gatherings, the general sentiment from frontend developers is that 
creating webapps has gotten considerably more difficult with the newish 
technologies.  even the local presenters for react and angular2+ at these talks 
can’t hide their lack of enthusiasm for these frameworks (like they’re doing it 
mainly to hustle more side-business for themselves).  on-the-job, we all 
generally try to avoid taking on such technical risks, until we are inevitably 
asked to by our manager.  the ones i see who are enthusiastic are typically 
non-frontend-engineers who write mostly backend nodejs code, that isn’t all 
that more scalable or interesting with what you can do in java/c#/ruby.

> Don't like `const`? Don't use it. Don't like arrow functions? Don't use them. 
> Don't like `async`/`await`? (You guessed it.) Don't use them. Nothing other 
> than unspecified behavior is any different unless you use it. (And even in 
> regard to unspecified behavior [I'm thinking function declarations in blocks 
> here], the committee has bent over backward to do their best to avoid 
> imposing changes on it.)

this brings up the point that frontend developers have no say in these matters 
when a less-than-technical pm asks them to use frameworks that all but uses 
these features.  there are many of these managers in asia who copy whatever 
they perceive is trending in silicon valley, with very little care about the 
technical-risks they bring to projects.

> On Jul 22, 2017, at 5:14 AM, T.J. Crowder  
> wrote:
> 
> On Fri, Jul 21, 2017 at 9:37 PM, kai zhu  > wrote:
> 
> > that being said, es6 is such a different beast from es5, that i
> > think a backwards-compatible “use es5” text pragma would be
> > appreciated by the significant number of veteran frontend-
> > programmers and established companies who still prefer
> > writing and maintaining code in the “legacy” language-style
> 
> Can you produce any data at all to back that up? I've never seen any appetite 
> in that regard at all.
> 
> You do realize, presumably, that there is *nothing* preventing you from 
> writing ES5 code and running it on current engines -- since ES2015, ES2016, 
> and ES2017 are all backward-compatible with ES5. By design.
> 
> Don't like `const`? Don't use it. Don't like arrow functions? Don't use them. 
> Don't like `async`/`await`? (You guessed it.) Don't use them. Nothing other 
> than unspecified behavior is any different unless you use it. (And even in 
> regard to unspecified behavior [I'm thinking function declarations in blocks 
> here], the committee has bent over backward to do their best to avoid 
> imposing changes on it.)
> 
> -- T.J. Crowder

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[T.J. Crowder]

On Fri, Jul 21, 2017 at 9:37 PM, kai zhu  wrote:

> that being said, es6 is such a different beast from es5, that i
> think a backwards-compatible “use es5” text pragma would be
> appreciated by the significant number of veteran frontend-
> programmers and established companies who still prefer
> writing and maintaining code in the “legacy” language-style

Can you produce any data at all to back that up? I've never seen any
appetite in that regard at all.

You do realize, presumably, that there is *nothing* preventing you from
writing ES5 code and running it on current engines -- since ES2015, ES2016,
and ES2017 are all backward-compatible with ES5. By design.

Don't like `const`? Don't use it. Don't like arrow functions? Don't use
them. Don't like `async`/`await`? (You guessed it.) Don't use them. Nothing
other than unspecified behavior is any different unless you use it. (And
even in regard to unspecified behavior [I'm thinking function declarations
in blocks here], the committee has bent over backward to do their best to
avoid imposing changes on it.)

-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[kai zhu]

pragmas although not great and should be used sparingly, are still the most 
feasible way forward to limiting excessive features.  that being said, es6 is 
such a different beast from es5, that i think a backwards-compatible “use es5” 
text pragma would be appreciated by the significant number of veteran 
frontend-programmers and established companies who still prefer writing and 
maintaining code in the “legacy” language-style.

this would effectively be a one-off pragma, as its unlikely future es versions 
would have language changes of such magnitude to warrant it.

> On Jul 22, 2017, at 3:19 AM, Steve Fink  wrote:
> 
> On 07/20/2017 03:08 AM, Alexander Jones wrote:
>> Removing things also frees up syntax and names for future extensions. Never 
>> removing features is simply unscalable, and it's only going to accelerate 
>> JS's demise!
>> 
>> I still think version pragmas are probably worth exploring to mitigate this, 
>> while not 'breaking the web' is a stated goal.
> 
> Not breaking the web is a stated goal.
> 
> A non-web embedding is free to remove whatever is unwanted, but the vast 
> majority of resources are put into JS engines that run the web, so in 
> practice you're going to run on engines that implement the whole spec and are 
> not at all eager to pay for testing or maintenance overhead for non-web 
> configurations.
> 
> Features can sometimes be usefully deprecated by not implementing them in 
> optimizing JITs. (For example, 'with'.) Whatever invariants the features 
> break must still be handled by the overall engine, but it's usually much 
> easier to only handle things on slow paths.
> 
> Version pragmas have been explored and found to be a bad idea. See 
> http://exploringjs.com/es6/ch_one-javascript.html for a far better 
> description than I would be able to produce.
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Steve Fink]

On 07/20/2017 03:08 AM, Alexander Jones wrote:
Removing things also frees up syntax and names for future extensions. 
Never removing features is simply unscalable, and it's only going to 
accelerate JS's demise!


I still think version pragmas are probably worth exploring to mitigate 
this, while not 'breaking the web' is a stated goal.


Not breaking the web is a stated goal.

A non-web embedding is free to remove whatever is unwanted, but the vast 
majority of resources are put into JS engines that run the web, so in 
practice you're going to run on engines that implement the whole spec 
and are not at all eager to pay for testing or maintenance overhead for 
non-web configurations.


Features can sometimes be usefully deprecated by not implementing them 
in optimizing JITs. (For example, 'with'.) Whatever invariants the 
features break must still be handled by the overall engine, but it's 
usually much easier to only handle things on slow paths.


Version pragmas have been explored and found to be a bad idea. See 
http://exploringjs.com/es6/ch_one-javascript.html for a far better 
description than I would be able to produce.


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Mike Samuel]

On Thu, Jul 20, 2017 at 2:13 AM, Michael Kriegel
 wrote:
> Removing language features will introduce breaking changes. Removal is more
> like an agreement, not to use certain features, so it is the task of a
> Linter, which can check, that you do not use "bad things". Strict mode is
> another way, which disables a certain set of features, such that it becomes
> an error, when you use them. However, it is not very fine granular.

Linters help guide good-faith developers towards the good parts(tm) of
the language.
Keeping all the bad parts of the language around does impose an
ongoing cost though.

Obscure implementation-specific extensions and ancient rarely used
features can still be rediscovered and used to break out of sandboxes.
It's also the old, irregularly maintained code paths that are most
likely to allow an attacker
to attack underlying layers -- buffer overflows against C code via
neglected IDL binding
code.

As someone who has to keep current on the bad parts, I would
appreciate if there were
fewer of them.
Old code that has legitimate reasons to use ancient features was also
written and tested
when machines (modulo battery-constrained devices) were slower.
If old misfeatures can't be eliminated, I would prefer that old
features be reimplemented
in terms of newer features where possible even if that imposes a
significant performance
penalty since that results in fewer code paths close to the metal that
are rarely tested
openly.



> Maybe ES should introduce something like a configuration object, in which
> developers can enable / disable or in general configure features for their
> module in a fine granular way. Of course all features which exist at the
> time of introducing such a mechanism would have to be enabled by default...

This could reduce the attack surface for code injection attacks like XSS if done
at the realm level.  Expanding the configuration space also has
security consequences
though since you now have to test against all possible configurations or make
assumptions about likely or supported configurations.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Alexander Jones]

Removing things also frees up syntax and names for future extensions. Never
removing features is simply unscalable, and it's only going to accelerate
JS's demise!

I still think version pragmas are probably worth exploring to mitigate
this, while not 'breaking the web' is a stated goal.

Alex

On Thu, 20 Jul 2017 at 07:53, T.J. Crowder 
wrote:

> On Thu, Jul 20, 2017 at 7:13 AM, Michael Kriegel <
> michael.krie...@actifsource.com> wrote:
>
>> Maybe ES should introduce something like a configuration object, in which
>> developers can enable / disable or in general configure features for their
>> module in a fine granular way. Of course all features which exist at the
>> time of introducing such a mechanism would have to be enabled by default...
>>
> As you say, this is more a job for linters / code analysis / code quality
> tools. The only time it's relevant to the JavaScript engine itself is where
> the elimination of a feature allows the engine to do a better/faster
> optimization job (for instance in strict mode, `with`, the link between
> `arguments` and named parameters, ...) or where only the engine can know
> about something problematic (viz. automatic globals). Those are relatively
> rare.
>
> I can't recall details, but I seem to recall an indication on the list at
> some stage that there's little-to-no appetite for further `"use
> strict"`-like directives. It's a big hammer, used once so far to fix some
> long-standing performance and correctness pain-points. Maybe TC-39 will use
> it again, but the indication was, not any time soon, and certainly not just
> to turn off features people don't like.
>
> -- T.J. Crowder
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[T.J. Crowder]

On Thu, Jul 20, 2017 at 7:13 AM, Michael Kriegel <
michael.krie...@actifsource.com> wrote:

> Maybe ES should introduce something like a configuration object, in which
> developers can enable / disable or in general configure features for their
> module in a fine granular way. Of course all features which exist at the
> time of introducing such a mechanism would have to be enabled by default...
>
As you say, this is more a job for linters / code analysis / code quality
tools. The only time it's relevant to the JavaScript engine itself is where
the elimination of a feature allows the engine to do a better/faster
optimization job (for instance in strict mode, `with`, the link between
`arguments` and named parameters, ...) or where only the engine can know
about something problematic (viz. automatic globals). Those are relatively
rare.

I can't recall details, but I seem to recall an indication on the list at
some stage that there's little-to-no appetite for further `"use
strict"`-like directives. It's a big hammer, used once so far to fix some
long-standing performance and correctness pain-points. Maybe TC-39 will use
it again, but the indication was, not any time soon, and certainly not just
to turn off features people don't like.

-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Michael Kriegel]

Removing language features will introduce breaking changes. Removal is 
more like an agreement, not to use certain features, so it is the task 
of a Linter, which can check, that you do not use "bad things". Strict 
mode is another way, which disables a certain set of features, such that 
it becomes an error, when you use them. However, it is not very fine 
granular.


Maybe ES should introduce something like a configuration object, in 
which developers can enable / disable or in general configure features 
for their module in a fine granular way. Of course all features which 
exist at the time of introducing such a mechanism would have to be 
enabled by default...



On 20.07.2017 01:16, Andrea Giammarchi wrote:
FWIW I can tell you already removing `RegExp.$1`, `RegExp.global`, and 
friends will break a lot of things.


Testing a `RegExp` to instantly using its matches via `$1` and friends 
has been used in many scripts.


Regards

On Thu, Jul 20, 2017 at 1:11 AM, Isiah Meadows > wrote:


It's mostly a TC39 process, where they have to go through a very
pain-staking process to ensure it breaks virtually nothing in real
world code, one that takes several years. So far, the only
language feature successfully removed is `arguments.caller`. There
are a few others deprecated for future removal:

- `Function.prototype.caller`
- `arguments.callee`
- `RegExp.$1`, `RegExp.global`, and friends
- Most everything banned from strict mode.
- And likely others.

On Wed, Jul 19, 2017, 18:36 David White
mailto:david.rhys.wh...@icloud.com>>
wrote:

Hi,

I’m just curious as there are a lot of proposals for the
addition of features to the ES specification, is there any
scope for requests to remove language features? Going via the
same means of writing a proposition that would attempt to
support the removal of a feature, ultimately simplifying the
specification and language?

David
___
es-discuss mailing list
es-discuss@mozilla.org 
https://mail.mozilla.org/listinfo/es-discuss



___
es-discuss mailing list
es-discuss@mozilla.org 
https://mail.mozilla.org/listinfo/es-discuss





___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


--
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar 
• www.actifsource.com • +41 56 250 40 02

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Andrea Giammarchi]

FWIW I can tell you already removing `RegExp.$1`, `RegExp.global`, and
friends will break a lot of things.

Testing a `RegExp` to instantly using its matches via `$1` and friends has
been used in many scripts.

Regards

On Thu, Jul 20, 2017 at 1:11 AM, Isiah Meadows 
wrote:

> It's mostly a TC39 process, where they have to go through a very
> pain-staking process to ensure it breaks virtually nothing in real world
> code, one that takes several years. So far, the only language feature
> successfully removed is `arguments.caller`. There are a few others
> deprecated for future removal:
>
> - `Function.prototype.caller`
> - `arguments.callee`
> - `RegExp.$1`, `RegExp.global`, and friends
> - Most everything banned from strict mode.
> - And likely others.
>
> On Wed, Jul 19, 2017, 18:36 David White 
> wrote:
>
>> Hi,
>>
>> I’m just curious as there are a lot of proposals for the addition of
>> features to the ES specification, is there any scope for requests to remove
>> language features? Going via the same means of writing a proposition that
>> would attempt to support the removal of a feature, ultimately simplifying
>> the specification and language?
>>
>> David
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Isiah Meadows]

It's mostly a TC39 process, where they have to go through a very
pain-staking process to ensure it breaks virtually nothing in real world
code, one that takes several years. So far, the only language feature
successfully removed is `arguments.caller`. There are a few others
deprecated for future removal:

- `Function.prototype.caller`
- `arguments.callee`
- `RegExp.$1`, `RegExp.global`, and friends
- Most everything banned from strict mode.
- And likely others.

On Wed, Jul 19, 2017, 18:36 David White  wrote:

> Hi,
>
> I’m just curious as there are a lot of proposals for the addition of
> features to the ES specification, is there any scope for requests to remove
> language features? Going via the same means of writing a proposition that
> would attempt to support the removal of a feature, ultimately simplifying
> the specification and language?
>
> David
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[kai zhu]

+1
On Jul 20, 2017 6:36 AM, "David White"  wrote:

> Hi,
>
> I’m just curious as there are a lot of proposals for the addition of
> features to the ES specification, is there any scope for requests to remove
> language features? Going via the same means of writing a proposition that
> would attempt to support the removal of a feature, ultimately simplifying
> the specification and language?
>
> David
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Removal of language features

[David White]

Hi, 

I’m just curious as there are a lot of proposals for the addition of features 
to the ES specification, is there any scope for requests to remove language 
features? Going via the same means of writing a proposition that would attempt 
to support the removal of a feature, ultimately simplifying the specification 
and language?

David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss