Removal of language features

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

Re: Removal of language features

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

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 [[hidden email]]
Sent: Saturday, July 22, 2017 1:44 PM
To: kai zhu <[hidden email]>
Cc: es-discuss <[hidden email]>
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
[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
In reply to this post by Andrea Giammarchi-2
CSP to name one, but you picked 1% of my reply.

On Sat, 22 Jul 2017 at 19:52, Claude Petit <[hidden email]> 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:[hidden email]]
Sent: Saturday, July 22, 2017 1:44 PM
To: kai zhu <[hidden email]>
Cc: es-discuss <[hidden email]>
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:
CSP to name one, but you picked 1% of my reply.

On Sat, 22 Jul 2017 at 19:52, Claude Petit <[hidden email]> 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:[hidden email]]
Sent: Saturday, July 22, 2017 1:44 PM
To: kai zhu <[hidden email]>
Cc: es-discuss <[hidden email]>
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
[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

Steve Fink
In reply to this post by kai zhu
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
[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 Naveen Chawla
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 <[hidden email]> wrote:
CSP to name one, but you picked 1% of my reply.

On Sat, 22 Jul 2017 at 19:52, Claude Petit <[hidden email]> 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:[hidden email]]
Sent: Saturday, July 22, 2017 1:44 PM
To: kai zhu <[hidden email]>
Cc: es-discuss <[hidden email]>
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
[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

Bob Myers
In reply to this post by Naveen Chawla
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 <[hidden email]> 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 <[hidden email]> wrote:
CSP to name one, but you picked 1% of my reply.

On Sat, 22 Jul 2017 at 19:52, Claude Petit <[hidden email]> 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:[hidden email]]
Sent: Saturday, July 22, 2017 1:44 PM
To: kai zhu <[hidden email]>
Cc: es-discuss <[hidden email]>
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
[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

Jordan Harband
Please note, "piss on them" is certainly achieved by your antagonistic comments about TC39's "bikeshedding" on two valuable recent proposals, which do solve real-world problems - even if they aren't your own.

I'll withhold comment on the rest of the thread beyond a general comment to everyone (*every*one, to be clear, not just the person my previous comment is in reply to): please behave in a professional manner; please refrain from making *any kind* of sexual references; please do not generalize about any groups of people, be they TypeScript users, TC39 members, people who live in Asia, etc. My personal suspicion is that people who are unable to have self-control in these matters will find themselves losing the ability to comment further on es-discuss, but either way, let's be courteous.

Thanks!


;

On Sat, Jul 22, 2017 at 12:40 PM, Bob Myers <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> wrote:
CSP to name one, but you picked 1% of my reply.

On Sat, 22 Jul 2017 at 19:52, Claude Petit <[hidden email]> 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:[hidden email]]
Sent: Saturday, July 22, 2017 1:44 PM
To: kai zhu <[hidden email]>
Cc: es-discuss <[hidden email]>
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
[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



_______________________________________________
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

Vinnymac
Jordan is right about this needing to be a more civil discussion. The hostile environment prevents people from even wanting to participate in the conversation, including myself.

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. It feels more mature, and we can already do so much more than we ever could just a couple of years ago.

I feel the language shouldn't need to remove a feature unless it is really absolutely necessary. New and abundant proposals are a good thing. It means we have a lot of requests to make the language fit all of the use cases and needs that exist. TC39 has a pretty great proposal process [1], and I imagine that in and of itself will help protect from proposals unnecessarily entering into the language.

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.


On Jul 22, 2017 9:56 PM, "Jordan Harband" <[hidden email]> wrote:
Please note, "piss on them" is certainly achieved by your antagonistic comments about TC39's "bikeshedding" on two valuable recent proposals, which do solve real-world problems - even if they aren't your own.

I'll withhold comment on the rest of the thread beyond a general comment to everyone (*every*one, to be clear, not just the person my previous comment is in reply to): please behave in a professional manner; please refrain from making *any kind* of sexual references; please do not generalize about any groups of people, be they TypeScript users, TC39 members, people who live in Asia, etc. My personal suspicion is that people who are unable to have self-control in these matters will find themselves losing the ability to comment further on es-discuss, but either way, let's be courteous.

Thanks!


;

On Sat, Jul 22, 2017 at 12:40 PM, Bob Myers <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> wrote:
CSP to name one, but you picked 1% of my reply.

On Sat, 22 Jul 2017 at 19:52, Claude Petit <[hidden email]> 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:[hidden email]]
Sent: Saturday, July 22, 2017 1:44 PM
To: kai zhu <[hidden email]>
Cc: es-discuss <[hidden email]>
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
[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



_______________________________________________
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
Massive +1 on Jordan's call for increased civility and cleaner language.

On Sun, Jul 23, 2017 at 3:58 AM, Vinnymac <[hidden email]> 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
<[hidden email]> 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
<[hidden email]> wrote
(replying to kai zhu <[hidden email]>):

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

Re: Re: Removal of language features

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

Re: Re: Removal of language features

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

Re: Removal of language features

kai zhu
In reply to this post by Vinnymac

On Jul 23, 2017, at 10:58 AM, Vinnymac <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Re: Removal of language features

doodad-js Admin
In reply to this post by David White
Maybe that's time to start a new major version of JS?

-----Original Message-----
From: David White [mailto:[hidden email]]
Sent: Sunday, July 23, 2017 5:54 PM
To: [hidden email]
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Removal of language features

doodad-js Admin
In reply to this post by kai zhu

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:[hidden email]]
Sent: Sunday, July 23, 2017 6:36 PM
To: Vinnymac <[hidden email]>
Cc: Jordan Harband <[hidden email]>; Claude Petit <[hidden email]>; es-discuss <[hidden email]>
Subject: Re: Removal of language features

 

 

On Jul 23, 2017, at 10:58 AM, Vinnymac <[hidden email]> 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.

 

Virus-free. www.avg.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

David White
In reply to this post by doodad-js Admin
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 <[hidden email]> wrote:
>
> Maybe that's time to start a new major version of JS?
>
> -----Original Message-----
> From: David White [mailto:[hidden email]]
> Sent: Sunday, July 23, 2017 5:54 PM
> To: [hidden email]
> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Removal of language features

David White
In reply to this post by doodad-js Admin
Ooooh, a mime type based versioning would be very nice!

`<script src=“/myapp.js” type=“application/javascript.2”></script>`

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 <[hidden email]> wrote:
>
> May I propose a new file extension and mime-type... "js2": "application/javascript.2" ?
>
> -----Original Message-----
> From: David White [mailto:[hidden email]]
> Sent: Sunday, July 23, 2017 7:35 PM
> To: doodad-js Admin <[hidden email]>
> 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 <[hidden email]> wrote:
>>
>> Maybe that's time to start a new major version of JS?
>>
>> -----Original Message-----
>> From: David White [mailto:[hidden email]]
>> Sent: Sunday, July 23, 2017 5:54 PM
>> To: [hidden email]
>> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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:[hidden email]]
Sent: Sunday, July 23, 2017 7:52 PM
To: doodad-js Admin <[hidden email]>
Cc: [hidden email]
Subject: Re: Removal of language features

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

`<script src=“/myapp.js” type=“application/javascript.2”></script>`

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 <[hidden email]> wrote:
>
> May I propose a new file extension and mime-type... "js2": "application/javascript.2" ?
>
> -----Original Message-----
> From: David White [mailto:[hidden email]]
> Sent: Sunday, July 23, 2017 7:35 PM
> To: doodad-js Admin <[hidden email]>
> 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 <[hidden email]> wrote:
>>
>> Maybe that's time to start a new major version of JS?
>>
>> -----Original Message-----
>> From: David White [mailto:[hidden email]]
>> Sent: Sunday, July 23, 2017 5:54 PM
>> To: [hidden email]
>> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

FW: Removal of language features

doodad-js Admin
In reply to this post by David White
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:[hidden email]]
Sent: Sunday, July 23, 2017 8:01 PM
To: 'doodad-js Admin' <[hidden email]>; 'David White' <[hidden email]>
Cc: [hidden email]
Subject: RE: Removal of language features

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

Claude Petit

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