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 <andrea.giammar...@gmail.com <mailto: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
    <mailto: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
        <mailto:andrea.giammar...@gmail.com>]
        *Sent:* Saturday, July 22, 2017 1:44 PM
        *To:* kai zhu <kaizhu...@gmail.com <mailto:kaizhu...@gmail.com>>
        *Cc:* es-discuss <es-discuss@mozilla.org
        <mailto: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 <mailto: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

Reply via email to