4 ms·

The reasoning behind most of this, that the output JS is not a strict subset of the input is silly and imho represent a misunderstanding of what Typescript is g

by donatj 5y ago

The reasoning behind most of this, that the output JS is not a strict subset of the input is silly and imho represent a misunderstanding of what Typescript is going for. It’s a full fledged language that compiles to readable JS, not just annotated JavaScript. There are many features in Typescript where it simply isn’t just outputting a subset of the input, and many of them are the best parts of Typescript. If you just want JavaScript with types, there are other languages that do that, but Typescript offers so much more.

Vinnl 5y ago
> imho represent a misunderstanding of what Typescript is going for. It's pretty what TypeScript's going for though: > Avoid adding expression-level syntax. https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...
- donatj 5y ago
  I’m curious what they mean by “expression-level syntax” specifically, because they certainly added a lot of syntax that isn’t ECMA and aren’t just Babel, backporting future ECMA features.
  - Vinnl 5y ago
    As long as it's stage 3 EcmaScript, I (and the TS team, AFAIK) wouldn't count that as TS syntax - that's actual ES for all intents and purposes. Other than that it's mostly syntax that affects how your code runs - i.e. if you were to remove all syntax that TS adds, the code should still run without further modifications in any interpreter that understands ES. (And features like enums don't satisfy this condition, hence why they don't match TS's design goals.)
Zababa 5y ago
> It’s a full fledged language that compiles to readable JS Compiling to readable JS is not one of TS's goals. For example: https://www.typescriptlang.org/play?noImplicitAny=false&target=1&jsx=0&ssl=10&ssc=2&pln=1&pc=1#code/MYewdgzgLgBAtgTwBLgCYEMYF4YG9QA2IATgFwwDkxApqhQDQwDuAFtdQROQCyPVgBzAJZhq5fAgIjU1Ylxi8YEIQC8xMAEwA6DQF9dAbgCwAKFOnQkEAWpaiAgBSIUYDAH4t-YaI-BJ02QgASmMzE0toGHRiYmwYAG0ARkYNRgBmRkUAVkYANkYAdkYADkYATkZEgAYAXVDTADMSGAcI2A4YEAaomKC8UxgYCOtbewcOENNdIA https://www.typescriptlang.org/play?noImplicitAny=false&targ...
- donatj 5y ago
  That seems very readable, especially in comparison to something like Dart or Elm’s output, both of which can output thousands of lines from something as simple as your example. From the language goals > 4. Emit clean, idiomatic, recognizable JavaScript code. https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...
  - mhoad 5y ago
    I don’t really see the value proposition of having a compilation step that also prioritises readability when you have source maps. I love Dart personally and I mostly see it’s compile to nonsense looking code as a feature not a bug because it’s an ACTUAL compilation step worked on by ex Chrome team members who understand V8 internals not just code splitting and running terser over it and calling it a day. Want to get the same compilation optimisations that Google uses to run all of their multi billion dollar ad business? Cool, that’s enabled by default out of the box. [1] The part where Dart on the web falls over for me is that they have shitty support right now for modern web APIs. They are building against some ancient version of Chrome’s WebIDL files so you can totally forget about things like web components for example. So in that sense it doesn’t feel like a sensible choice in 2022 for basic web development which is a shame because it’s otherwise probably the best developer experience I’ve ever seen. [1] I say this somewhat theoretically, I don’t know that Dart is in anyway an obvious thing to point to in terms of web performance from what I had seen casually. I think their goal there you can write huge business critical applications with stupidly large code bases and still get good performance. But nobody’s experience after using Google Ads is to talk about how snappy it was.
    - Zababa 5y ago
      > I don’t really see the value proposition of having a compilation step that also prioritises readability when you have source maps. It's to increase adoption. Some people still remember migrating to coffeescript and away from it. It's in line with tsc accepting regular JS files, the degrees of strictness, things like that. Typescript is optimized to be adopted by the maximum number of people, which in turn increases its usefulness, the feedback they can get, their influence on JS. People are going to write bindings for popular libraries, even migrate them. Some other people (like at my job) have some people use typescript, and others the generated code. It makes debugging and reasoning about code easier. As for Dart, I'm not really convinced. The language seems to have the same philosophy as Go (incremental improvement over old technologies), and while for Go it works because Go is relatively "low level" (lower than Dart), for Dart it's just weird.

by donatj 5y ago

Vinnl 5y ago

> imho represent a misunderstanding of what Typescript is going for. It's pretty what TypeScript's going for though: > Avoid adding expression-level syntax. https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

donatj 5y ago
I’m curious what they mean by “expression-level syntax” specifically, because they certainly added a lot of syntax that isn’t ECMA and aren’t just Babel, backporting future ECMA features.
- Vinnl 5y ago
  As long as it's stage 3 EcmaScript, I (and the TS team, AFAIK) wouldn't count that as TS syntax - that's actual ES for all intents and purposes. Other than that it's mostly syntax that affects how your code runs - i.e. if you were to remove all syntax that TS adds, the code should still run without further modifications in any interpreter that understands ES. (And features like enums don't satisfy this condition, hence why they don't match TS's design goals.)

Zababa 5y ago

> It’s a full fledged language that compiles to readable JS Compiling to readable JS is not one of TS's goals. For example: https://www.typescriptlang.org/play?noImplicitAny=false&target=1&jsx=0&ssl=10&ssc=2&pln=1&pc=1#code/MYewdgzgLgBAtgTwBLgCYEMYF4YG9QA2IATgFwwDkxApqhQDQwDuAFtdQROQCyPVgBzAJZhq5fAgIjU1Ylxi8YEIQC8xMAEwA6DQF9dAbgCwAKFOnQkEAWpaiAgBSIUYDAH4t-YaI-BJ02QgASmMzE0toGHRiYmwYAG0ARkYNRgBmRkUAVkYANkYAdkYADkYATkZEgAYAXVDTADMSGAcI2A4YEAaomKC8UxgYCOtbewcOENNdIA https://www.typescriptlang.org/play?noImplicitAny=false&targ...

donatj 5y ago
That seems very readable, especially in comparison to something like Dart or Elm’s output, both of which can output thousands of lines from something as simple as your example. From the language goals > 4. Emit clean, idiomatic, recognizable JavaScript code. https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...
- mhoad 5y ago
  I don’t really see the value proposition of having a compilation step that also prioritises readability when you have source maps. I love Dart personally and I mostly see it’s compile to nonsense looking code as a feature not a bug because it’s an ACTUAL compilation step worked on by ex Chrome team members who understand V8 internals not just code splitting and running terser over it and calling it a day. Want to get the same compilation optimisations that Google uses to run all of their multi billion dollar ad business? Cool, that’s enabled by default out of the box. [1] The part where Dart on the web falls over for me is that they have shitty support right now for modern web APIs. They are building against some ancient version of Chrome’s WebIDL files so you can totally forget about things like web components for example. So in that sense it doesn’t feel like a sensible choice in 2022 for basic web development which is a shame because it’s otherwise probably the best developer experience I’ve ever seen. [1] I say this somewhat theoretically, I don’t know that Dart is in anyway an obvious thing to point to in terms of web performance from what I had seen casually. I think their goal there you can write huge business critical applications with stupidly large code bases and still get good performance. But nobody’s experience after using Google Ads is to talk about how snappy it was.
  - Zababa 5y ago
    > I don’t really see the value proposition of having a compilation step that also prioritises readability when you have source maps. It's to increase adoption. Some people still remember migrating to coffeescript and away from it. It's in line with tsc accepting regular JS files, the degrees of strictness, things like that. Typescript is optimized to be adopted by the maximum number of people, which in turn increases its usefulness, the feedback they can get, their influence on JS. People are going to write bindings for popular libraries, even migrate them. Some other people (like at my job) have some people use typescript, and others the generated code. It makes debugging and reasoning about code easier. As for Dart, I'm not really convinced. The language seems to have the same philosophy as Go (incremental improvement over old technologies), and while for Go it works because Go is relatively "low level" (lower than Dart), for Dart it's just weird.