Removal of language features

classic Classic list List threaded Threaded
99 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Removal of language features

kai zhu

+1

On Jul 20, 2017 6:36 AM, "David White" <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Removal of language features

Isiah Meadows-2
In reply to this post by David White
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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Removal of language features

Andrea Giammarchi-2
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




_______________________________________________
es-discuss mailing list
[hidden email]
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Removal of language features

T.J. Crowder-2
On Thu, Jul 20, 2017 at 7:13 AM, Michael Kriegel <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:
On Thu, Jul 20, 2017 at 7:13 AM, Michael Kriegel <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Removal of language features

Mike Samuel
In reply to this post by Michael Kriegel
On Thu, Jul 20, 2017 at 2:13 AM, Michael Kriegel
<[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Removal of language features

Steve Fink
In reply to this post by Alexander Jones
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Removal of language features

T.J. Crowder-2
On Fri, Jul 21, 2017 at 9:37 PM, kai zhu <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:

On Fri, Jul 21, 2017 at 9:37 PM, kai zhu <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Removal of language features

Isiah Meadows-2
Inline.

On Fri, Jul 21, 2017 at 6:00 PM, kai zhu <[hidden email]> 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
[hidden email]

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Removal of language features

Bob Myers
In reply to this post by David White
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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
>
> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removal of language features

Andrea Giammarchi-2
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


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Removal of language features

T.J. Crowder-2
On Sat, Jul 22, 2017 at 3:17 PM, Andrea Giammarchi <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Removal of language features

Andrea Giammarchi-2
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 <[hidden email]> wrote:
On Sat, Jul 22, 2017 at 3:17 PM, Andrea Giammarchi <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Removal of language features

Mike Samuel


On Jul 22, 2017 11:14 AM, "Andrea Giammarchi" <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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" <[hidden email]> wrote:


On Jul 22, 2017 11:14 AM, "Andrea Giammarchi" <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12345