• TheCee@programming.dev
    link
    fedilink
    English
    arrow-up
    4
    ·
    1 year ago

    That’s not a positive, though.

    Depending on how it pans out, it’s either not useful enough. Who the hell doesn’t use namespaces or enums. Or - as

    These constructs are not in the scope of this proposal, but could be added by separate TC39 proposals.

    implies - a door opener to outsource TypeScripts problem unto other peoples and not to investing into improving WebAssembly. That’s just MS being lazy and making their problems other peoples problems.

    I feel like this would be the ideal scenario: things working right out of the box without needing a compile step or additional tooling.

    It’s just annotations. No proposed semantics of a type system which your browser could check on its own.

    • Phen@lemmy.eco.br
      link
      fedilink
      arrow-up
      3
      ·
      edit-2
      1 year ago

      Who the hell doesn’t use namespaces or enums

      Uhhh, typescript devs? Enums were useful once, but typescript evolved everything else around it and these days using direct values is actually far better.

      And I don’t think anyone uses Namespaces other than for defining external modules.

      • TheCee@programming.dev
        link
        fedilink
        English
        arrow-up
        1
        arrow-down
        1
        ·
        edit-2
        1 year ago

        My bad, I’m not deep enough into our frontend stack to realize Hjeilsberg already did what he does best - ruining enums. (I guess he is not to blame for global imports in c#, so i can not add ‘questionable import module/namespace ideas’.)

        And it seems like this proposal contains type declarations (in order to compensate for their enums), among other typescript specific things. So, guess it is option B, then.

    • fidodo@lemm.ee
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      I don’t see any practical use case for it as is as anyone wanting to use them would want the full TS feature set anyways, but I could see it being a good step forward for more meaningful features to be added in the future.

      • TheCee@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        but I could see it being a good step forward for more meaningful features to be added in the future.

        I think you are right. And that is unfortunate.

    • rockstarpirate@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      Yeah it’s interesting because JS is interpreted, not compiled. The proposal allows for type annotations in the syntax but no actual interpreter consequences. On the one hand that makes sense because otherwise you’re in the territory of runtime type-checking which would be a huge performance hit and would sort of defeat the purpose of static types anyway. But that means you still have to rely on your IDE or a linter for this to be useful.