CSP to name one, but you picked 1% of my reply. On Sat, 22 Jul 2017 at 19:52, Claude Petit <[email protected]> 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:[email protected]] > *Sent:* Saturday, July 22, 2017 1:44 PM > *To:* kai zhu <[email protected]> > *Cc:* es-discuss <[email protected]> > *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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
