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
<[email protected] <mailto:[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]
<mailto:[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]
<mailto:[email protected]>]
*Sent:* Saturday, July 22, 2017 1:44 PM
*To:* kai zhu <[email protected] <mailto:[email protected]>>
*Cc:* es-discuss <[email protected]
<mailto:[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] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
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
