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 <naveen.c...@gmail.com> wrote: > Typescript allows breaking changes, ES doesn't. > > Hence it would be an acceptable decision for ES to clash with an existing > Typescript keyword and force Typescript to update accordingly. > > Typescript developers shouldn't be unprepared, and ES can continue on its > path. > > None of this makes Typescript "bad". Developers can keep using their > existing version of Typescript and its transpiler if they don't want to > risk disruption. > > So this kind of works for everybody: those who want bleeding edge ideas > implemented and are prepared to update in the face of breaking changes can > use e.g. Typescript and keep updating its version; those who want current > bleeding edge ideas implemented but not risk breaking changes can use e.g. > Typescript but stick to the same version; those who want to use the latest > features of ES can do so directly; those who want old ES code to continue > to work can have that. So it seems all of these cases are serviced OK. > > I'm not sure it's TC39's job to mark the implementation of preliminary > ideas as "unfriendly". If anything such implementations could expose any > weaknesses of these ideas such that they can be improved upon, or if not, > exposed as required as-is, potentially more clearly than a hypothetical > discussion on them, and that would carry value in of itself. > > So Javascript and Typescript serve different purposes. Typescript, being > as it is transpiled to Javascript, has the luxury of not having to be > backwards compatible, whereas because Javascript is run directly on > browsers, it has to be. > > On Sat, 22 Jul 2017 at 23:26 Andrea Giammarchi < > andrea.giammar...@gmail.com> wrote: > >> CSP to name one, but you picked 1% of my reply. >> >> On Sat, 22 Jul 2017 at 19:52, Claude Petit <p...@webmail.us> wrote: >> >>> “TC39 consider the usage of `eval` inappropriate for production” >>> >>> >>> >>> And what about dynamic code, expressions evaluation, ...? Who has wake >>> up one day and decided that nobody should use “eval” ? >>> >>> >>> >>> *From:* Andrea Giammarchi [mailto:andrea.giammar...@gmail.com] >>> *Sent:* Saturday, July 22, 2017 1:44 PM >>> *To:* kai zhu <kaizhu...@gmail.com> >>> *Cc:* es-discuss <es-discuss@mozilla.org> >>> *Subject:* Re: Removal of language features >>> >> >>> >>> answering to all questions here: >>> >> >>> >>> > What problems would this address? >>> >>> >>> >>> It will give developers a clear indication of what's good and future >>> proof and what's not so cool. >>> >>> >>> >>> MooTools and Prototype extending natives in all ways didn't translate >>> into "cool, people like these methods, let's put them on specs" ... we all >>> know the story. >>> >>> >>> >>> Having bad practices promoted as "cool stuff" is not a great way to move >>> the web forward, which AFAIK is part of the manifesto too. >>> >>> >>> >>> >>> >>> > In general, the committee sees any tool with significant adoption as >>> an opportunity to learn/draw ideas from, not a plague. >>> >>> >>> >>> That's the ideal situation, reality is that there are so many Stage 0 >>> proposals instantly adopted by many that have been discarded by TC39. >>> >>> >>> >>> This spans to other standards like W3C or WHATWG, see Custom Elements >>> builtin extends as clear example of what I mean. >>> >>> >>> >>> Committee might have the *right* opinion even about proposed standards, >>> not even developers experimenting, so as much I believe what you stated is >>> true, I'm not sure that's actually what happens. There are more things to >>> consider than hype, and thanks gosh it's like that. >>> >>> >>> >>> >>> >>> > you wouldn't see any interest in policing libraries and frameworks >>> from the committee >>> >>> >>> >>> agreed, because policing is a strong term. "TC39 friendly" is what I was >>> thinking of, something like any other GitHub badge when it comes to code >>> coverage, coding style, or target engines. >>> >>> >>> >>> I'm a pioneer of any sort of hacks myself, but I know that if my new >>> library is fully implemented thanks to eval and global prototype pollution, >>> through transpiled code that uses reserved words, probably nobody beside me >>> inside my crazy-lab should use my own code, no matter how much I promote it. >>> >>> >>> >>> >>> >>> > This is in conflict with the extensible web manifesto >>> >>> >>> >>> The situation I've just described would be indeed against the web >>> manifesto, wouldn't it? >>> >>> >>> >>> >>> >>> > tc39 should be a bit more assholish imo. >>> >>> >>> >>> No it shouldn't, it should be open minded and able to listen too. >>> However, when TC39 makes a decision the JS community follows quite >>> religiously that decision. >>> >>> >>> >>> If TC39 says everything is fine, you have today situation you describe. >>> >>> >>> >>> If TC39 would give some little extra direction, you'd have people >>> thinking about what they're using daily, example: >>> >>> >>> >>> statement: TC39 considers Stage 1 unstable and it should never be used >>> on production. >>> >>> result: people using early transpilers cannot complain about anything >>> about it and it's their choice. >>> >>> >>> >>> statement: TC39 consider the usage of `eval` inappropriate for production >>> >>> result: people using any library fully based on eval or Function would >>> start looking for better options >>> >>> >>> >>> >>> >>> And so on, I hope my previous email is now cleared a little bit, I'm a >>> JS developer myself and I promote both poly and >>> libraries/frameworks/utilities since ever. >>> >>> >>> >>> If anyone from TC39 would tell me: "dude, this is bad because not future >>> friendly" I'd either put that info on the README of the GitHub repo or tell >>> people about it even if it's my lib. >>> >>> >>> >>> Best Regards >>> >>> >>> >>> >>> >>> >>> >>> >>> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
