2020-12-09 06:22

Sound wrong to me

I'm a big user of typescript and I'm not convinced at all by this proposal:

1) Types require a lot of new syntax which evolves contently, and require hundred of developers to maintain/develop. And a lot of experimental features, something that should not be integrated into the TC39 pipeline... (ts specs: https://github.com/Microsoft/TypeScript/blob/master/doc/spec.md) 2) Type transpilers add more than just types. Typescript add enum, class private, public, protected, build to different target, etc... 3) If transpilers exist and work perfectly, why re-inventing the wheel ? Basically this proposal looks like: let's put typescript directly into the TC39. When everybody can already install and use ts in 10s...

It start with a good idea: "everybody should be able to use types". But in reality, it's already the case... (except its not native, but the transpilers add far more than just types...).

PS: I really encourage people to use typed js with a good IDE which helps A LOT debugging, maintaining, avoid a lot of errors, and provide powerful auto-completion. But I would not see this natively in JS.


  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答


  • weixin_39942400 weixin_39942400 5月前

    I think the idea of this proposal is to standardize type syntax. similar to how python has types but the interpreter just ignores them https://docs.python.org/3/library/typing.html

    given that flow and ts already share very similar type syntax (constname:TypeName= new TypeName()) a standard might make sense

    点赞 评论 复制链接分享
  • weixin_39833469 weixin_39833469 5月前

    Sounds perfectly reasonable to me!

    JavaScript already ships with types! Few people notice: String, Boolean, Number, Promise, etc.

    TC39 is all about JavaScript standards, if we are talking about the possibilities outside JavaScript, it's off topic in TC39 IMHO.

    Precisely! There is no need for JavaScript to reinvent the wheel, take clues from how Python does it, stand on the shoulders of giants!

    I think creating a bridge to fill the gap is genius engineering, well done 🎉 I do however think that there is another missing piece in this puzzle, like Python, JavaScript needs a global Type object that other global types inherit from.

    REPL examples:

    const obj = 1.42;
    // Number()

    Just musing, though one can then even have a union type and other TypeScript goodies:

    new Type(Number | Promise)
    // UnionType(Number, Promise)
    点赞 评论 复制链接分享
  • weixin_39942400 weixin_39942400 5月前

    -m-sadeghi what do you mean by

    JavaScript needs a global Type object that other global types inherit from

    everything in JS aready inherits from Object by default. Maybe I'm missing something here

    点赞 评论 复制链接分享
  • weixin_39833469 weixin_39833469 5月前

    JavaScript doesn't have an equivalent of type() in Python. I was trying to describe the same effect with the Type global that I made up. We have the typeof operator, though due to being an old design, it evaluates to a string:

    typeof 1.42
    // "number"
    typeof new Promise(resolve => {})
    // "object"

    In fact, now that you brought it to my attention, Object might be a more ergonomic candidate for implementing a python type() analogous mechanism (from a JavaScript developer's point of view, since we are already familiar with the likes of Object.assign). Here's how it'd look:

    // Number()
    Object.type(new Promise(resolve => {}))
    // Promise()

    The difference here is that an Object.type call returns the actual type, instead of a string.

    By acknowledging that JavaScript already has types, we can proceed to type annotations:

    function aFunction(aNumber: Number, unknown: Object): Promise {
        // function body
    点赞 评论 复制链接分享
  • weixin_39668890 weixin_39668890 5月前


    JavaScript already ships with types! Few people notice: String, Boolean, Number, Promise, etc

    Wow, wow, wow, Number, String or Promise are not types ! They are functions/classes which allow to create instances or cast a type to another. Moreover using new Number() to create a number is a bad practice, but using it to cast a value to a number is fine (const value = Number(stringValue)). To detect a primitive type, typeofshould be used, and to detect if a variable is an instance of a class instanceof is used for (or compare constructor directly if you don't want a super class).

    Notice than 1 instanceof Number evals to false, so Object.type(1.42) => Number() lacks of sense. ⚠️ A "number" is not a "Number" You may know python's type, but all of this is possible in js. The syntax is just different.

    What i'm pointing in my top first argument, is that types for javascript are far far more complicated than you could imagine due to the versatility of javascript, no spec sheet would be able to cover it a the first round, probably hundreds will be needed. Typescript add an huge amount of improvements for each of its releases which appends frequently. Integrating types at the level of TC39, would be really longer and error/regression prone. Some types are pretty hardcore, as an example: Array.flatMap (due to its type's recursivity)

    点赞 评论 复制链接分享
  • weixin_39833469 weixin_39833469 5月前

    It's arrogant that you assume others are not aware of how to do simple things in JavaScript. No worries though, I personally like arrogance! (So long as it doesn't become ignorance)

    Now that we're at it, give this a try:

    typeof (new Number(2) + new Number(3))

    You have decided to call it a bad practice, it's perfectly valid JavaScript.

    Historically, JavaScript incrementally integrated concepts like classes, generators and Promises. Along the way TC39 invented things like Symbol.iterator and whatnot. TC39 is still well capable of inventing new stuff. To incrementally integrate a mechanism like Python's type(), TC39 can invent things like Symbol.type and assign it even to a function such as Promise.

    instanceof operator can coexist alongside something like Object.type, you can then decide to do things the old way or the new way. Just like you can decide to implement a class by prototype or the class keyword (which again, TC39 has invented).

    note Substitute "standardized" for "invented" , since that's what's really happened

    About your note on hardcore types, you are absolutely right. Even Promise<T> is a hardcore type. That's why I think the solution proposed by is genius. JavaScript built-in types can only go so far, competition in types is well ahead just like you mentioned. However, something along the line of Object.type might go a long way for many simple use cases. For complex ones, this proposal is my personal favorite (as a library author who needs to accommodate both TypeScript and JavaScript).

    点赞 评论 复制链接分享