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 <[email protected]> wrote: > 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 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
