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
