3 ms·

I honestly wish Microsoft and TypeScript enthusiasts would transform it into an official standalone language and stop polluting the JavaScript ecosystem. Like

I honestly wish Microsoft and TypeScript enthusiasts would transform it into an official standalone language and stop polluting the JavaScript ecosystem. Like C++, it could be a true superset of JS, importing JS code freely into TypeScript projects. It would also allow TypeScript to do whatever it wanted and not have to worry about transpilation. If it needs to work in the browser, it can be bundled into web assembly.

wrs 1y ago
This is a mischaracterization of TypeScript. Unlike the relationship of C++ to C, TS is explicitly not a separate language from JS, and introduces no new capabilities. There’s no engine that executes TypeScript. It doesn’t do anything (*) that JavaScript doesn’t do. It just layers a type system onto JavaScript so you can tell when your JS code doesn’t make sense. (*) with small exceptions like enums, which some think were a mistake for that reason
- winrid 1y ago
  Yeah but it could be, as the runtime could take advantage of the type defs.
  - wrs 1y ago
    So much of the TS type system is just there to capture all the weird things you can do in JS. If you just wanted a new strongly typed dynamic language, I don't think TS is what you'd come up with. It is designed for a very large, but unique, niche domain, and that domain already has some incredibly optimized runtimes.
    - winrid 1y ago
      I wouldn't come up with a new language. I would use TS and use the types to optimize runtime decisions like using numbers to index arrays, without having to carry extra info about the number, and so on. I would change nothing except the runtime. Are you somehow arguing that's bad?
      - wrs 1y ago
        TS complains if it sees you trying to index a T[] with a non-integer. But there's nothing in the JS language that represents that T[] type annotation. So there's no way for the runtime to do that check. If you want to make that work, you'll have to invent a bunch of runtime type machinery and define it. The resulting combination of a subset of JS, TS, and whatever you had to invent to glue it together at runtime will be neither JS nor TS, it will be a new language (with, certainly, a family history). Also, every high-performance JS runtime already knows that you're only indexing that object with integers and already optimizes it without you telling it to.
Sacro 1y ago
C++ isn't a superset of JS, nor is it a superset of C
jasonthorsness 1y ago
How does it pollute? Hasn't the presence of TypeScript pushed a lot of awesome features back into the later versions of JavaScript?
- owebmaster 1y ago
  As far as I know, this still amounts to zero. It got many features from coffeescript
jinushaun 1y ago
There is no pollution. Typescript is a strict super set. I always joke that Typescript is JavaScript code mixed with compiler instructions. The type annotations are not code.

wrs 1y ago

This is a mischaracterization of TypeScript. Unlike the relationship of C++ to C, TS is explicitly not a separate language from JS, and introduces no new capabilities. There’s no engine that executes TypeScript. It doesn’t do anything (*) that JavaScript doesn’t do. It just layers a type system onto JavaScript so you can tell when your JS code doesn’t make sense. (*) with small exceptions like enums, which some think were a mistake for that reason

winrid 1y ago
Yeah but it could be, as the runtime could take advantage of the type defs.
- wrs 1y ago
  So much of the TS type system is just there to capture all the weird things you can do in JS. If you just wanted a new strongly typed dynamic language, I don't think TS is what you'd come up with. It is designed for a very large, but unique, niche domain, and that domain already has some incredibly optimized runtimes.
  - winrid 1y ago
    I wouldn't come up with a new language. I would use TS and use the types to optimize runtime decisions like using numbers to index arrays, without having to carry extra info about the number, and so on. I would change nothing except the runtime. Are you somehow arguing that's bad?
    - wrs 1y ago
      TS complains if it sees you trying to index a T[] with a non-integer. But there's nothing in the JS language that represents that T[] type annotation. So there's no way for the runtime to do that check. If you want to make that work, you'll have to invent a bunch of runtime type machinery and define it. The resulting combination of a subset of JS, TS, and whatever you had to invent to glue it together at runtime will be neither JS nor TS, it will be a new language (with, certainly, a family history). Also, every high-performance JS runtime already knows that you're only indexing that object with integers and already optimizes it without you telling it to.

Sacro 1y ago

C++ isn't a superset of JS, nor is it a superset of C

jasonthorsness 1y ago

How does it pollute? Hasn't the presence of TypeScript pushed a lot of awesome features back into the later versions of JavaScript?

owebmaster 1y ago
As far as I know, this still amounts to zero. It got many features from coffeescript

jinushaun 1y ago

There is no pollution. Typescript is a strict super set. I always joke that Typescript is JavaScript code mixed with compiler instructions. The type annotations are not code.