8 ms·

TypeScript 3.4

180 points by traderjane 8y ago

scanr 8y ago
Excited about “Higher order type inference from generic functions”. Great for libraries like RxJS, Ramda and axax.
mark_l_watson 8y ago
The type inference looks good. Pardon a question here: Will ES6 Code ‘just Run’ under TypeScript? I think the answer is yes for ES5, but I don’t know about ES6. Thanks.
- lachenmayer 8y ago
  Generally that depends on how many 'strict' compiler options you enable -- and whether you consider legitimate type errors a reasonable reason to not 'just run' your code :) An example would be that classes that don't explicitly declare their fields will throw a type error when their fields are mutated (eg. `this.foo = 123`).
- jtreminio 8y ago
  I believe Typescript is an extension of ES6. TS is ES6 + types (and other things).
- stareatgoats 8y ago
  Not sure what you mean by running ES6 code under Typescript. It is my understanding that Typescript 'transpiles' to whatever flavor of Javascript you need, and then the code is executed as Javascript. If your question is whether you can just change the file extension of a working ES6 file to .ts without Typescript complaining then answer is 'yes', you should be able to do that no problem. Edit: of course there is little sense in doing nothing more than that, but it is a good starting point for decorating existing Javascript with TS features.
  - Someone1234 8y ago
    The biggest pain-point with renaming a ES6 file to *.TS is that TypeScript will flag every library or browser specific object you reference as missing. That isn't wrong behavior on TS's part, just getting started with TypeScript is very configuration heavy, particularly for targeting browsers.
    - jahewson 8y ago
      You can use the ‘allowJs’ flag to have the compiler accept unmodied JavaScript and for untyped modules you can use shorthand ambient module declarations so they use the ‘any’ type, with one line of code.
  - superpermutat0r 8y ago
    If your target is ES5 you will have to provide polyfills. Typescript will unfortunately typecheck even if you don't have polyfills and you'll get runtime errors with your ES5 target. They specifically said they won't provide polyfills and they Will continue to typecheck even if your target does not support the standard function.
- nikeee 8y ago
  If you use classes, the compiler may complain because the class has no declared fields. The compiler will emit JS anyway.
  - vimslayer 8y ago
    Class field declarations are a stage 3 proposal for EcmaScript, btw, and already supported in Chrome. So class Foo { foo; constructor() { this.foo = 42 } } Will be both valid ES2019 or ES2020 and TypeScript.
ng12 8y ago
Wow. The const assertion is huge. My codebases are littered with things that I, the developer, know are constant but TypeScript does not and it often takes extra work to get type safety because of it. Can't wait to start using it.
- coldtea 8y ago
  Now following their examples clearly. Why not just make that "let x" a "const x" which JS already allows?
  - kentor 8y ago
    "const a = {}" disallows reassignment to "a" but still allows you to mutate the object e.g. "a.b = 1". The const context does not allow you to mutate the object.
    - coldtea 8y ago
      OK, the example with the "hello" literal string they have is quite bad then.
      - karanlyons 8y ago
        `as const` is useful there as well, as TypeScript’s type inference only narrows as far as the type and not the literal value. `let z = {text: "hello"}` has the shape `{text: string}`, with `as const` it has the shape `{text: "hello"}`.
        coldtea 8y ago
        Yeah, but shouldn't it use: const z = 'hello' and then get the shape {text: 'hello'} automatically? Why use "let" along with "as const" instead of mere "const x = 'hello'" for that?
        karanlyons 8y ago
cryptica 8y ago
There has never been a worse time to be a software developer. Practically all of the most popular tools encourage anti-patterns, add unnecessary complexity or solve superficial problems instead of focusing on critical problems that exist in today's software projects. Some examples: - TypeScript: Unfortunately, we cannot reduce a language's complexity by adding extra complexity on top. The complexity will keep rearing its ugly head no matter how much we try to hide it. The TypeScript project has had over 20K issues raised and 9K pull requests (that's not even mentioning the DefinitelyTyped repo)... To put it into perspective, the Linux project has only had about 380 PRs on GitHub. But how much value does TypeScript add? All evidence points to the fact that TypeScript does not have any positive effect on bug density. Its value is purely subjective and speculative. If humanity had invested a quarter of that time and energy towards coming up with and documenting proper JavaScript design patterns and architectures, TypeScript would have been completely redundant to begin with. - NestJS: Makes heavy use of decorators; these aim to allow developers to handle cross-cutting concerns within their code. Unfortunately, cross-cutting concerns are an anti-pattern because they imply a violation of the principle of separation of concerns between components. It takes a bit of thinking and discipline to come up with components which have clear and distinct concerns/responsibilities, but this is not a problem that can simply be ignored by injecting decorators all over your code. - InversifyJS: Dependency injection is a failed concept. It's been proven over and over. Angular 1 provided us with plenty of evidence for why we should avoid dependency injection (e.g. it's impossible to find stuff and you end up with a pseudo-global scope for everything which is as bad as simply using global variables). Again, dependency management is not a solution which can be automated away; it requires developers to make careful design decisions. - Code coverage tools like Istanbul and others add very little value to projects. 100% coverage is not a useful goal to have, in fact it's counterproductive. When it comes to test coverage, quality of that coverage is WAY more important than quantity (this cannot be over-emphasized). Did you test all the right inputs? Do the tests focus on the most important code paths (and those which are more complex and therefore more likely to fail)? I'd rather have 10% quality coverage of the right parts of the code than 100% poor quality coverage. Also, you need to take into account that the more unit test coverage you have, the harder it is to make changes to your code. - Linting tools such as ESLint/TSLint: These tools can be very nice if used correctly and not treated as a silver bullet for all programming problems. We should never forget that linters can only detect superficial problems. If your code passes all the most strict linting rules, it still says almost nothing about your project's code quality. I'd MUCH rather have code that fails ALL linting rules possible but has good architecture and good separation of concerns between components; at least the linting is easy to fix. Linting does not prevent architectural mistakes AT ALL; it only prevents superficial mistakes which are usually easy to identify anyway (if you have half-decent testing). I hope that over the next decade, the masses of new developers will develop their critical thinking skills and that they will be able to see value beyond the hype which is always being shoved into their faces by various misguided organizations. It's particularly difficult for me to see what has happened to software development because 10 years ago, I used to roll my eyes when I read comments like this from older and more experienced developers. New developers are often attracted to complexity like moths to a flame, but eventually we all learn that complexity is a silent killer - It's the ultimate enemy. Complexity is always trying to quietly sneak its way into your code (and I do mean ALWAYS; no matter how good your code is at any given point) and you must identify and stop every single attempt. It takes most developers at least a decade or two of coding to really appreciate this. For me, starting a TypeScript project is like accepting unnecessary complexity from the beginning of the project. It's a bad start, a slippery slope.
tombert 8y ago
I haven't written anything in TypeScript, though I have some friends that love the language; I got annoyed at having to supply bindings for obscure languages. If you can get past the initial hurdle, is TypeScript worth it for Node.JS stuff?
- gmac 8y ago
  YES. I would never go back. Types, combined with a great IDE in VS Code, make for a so much less frustrating experience.
- dpacmittal 8y ago
  Typescript is a godsend. Once you get comfortable with TS, you just can't go back to normal JS.
- pas 8y ago
  what does bindings for obscure languages mean in this context? does TS count as obscure?
  - skybrian 8y ago
    I'm guessing it's a typo for "libraries".
    - tombert 8y ago
      You guessed correctly.
- klodolph 8y ago
  TypeScript doesn't require bindings to call JavaScript libraries. This includes writing code to run in the browser and writing Node.js code. Instead, what you want are type definitions for the library you use. These are optional, but make using a library with TypeScript a much better experience. It is very common for these definitions be available already, whether the library is written in TypeScript or something else. Years ago I remember having to manage these type definitions, these days I don't really have to think about it much. There's not much of an initial hurdle, to be honest. You're mostly adding annotations to your JavaScript code. It does influence the structure of your code but not as much as you might think, at least in my experience.
deleted 8y ago
[deleted]
jasonhansel 8y ago
Just waiting until TypeScript's type system becomes so powerful that inference accidentally becomes Turing-complete.
- mickael 8y ago
  Apparently, Typescript type system is already Turing-complete: https://github.com/Microsoft/TypeScript/issues/14833 https://github.com/Microsoft/TypeScript/issues/14833
truth_seeker 8y ago
Oh dear, look at those features. Typescript is becoming the big valley of types and syntax overheads. In order to be productive, as a developer I should learn or know almost all the distinct syntax rules and tons of best practices. An ideal (or close to it) typed language will have only few type rules and better way to compose them. I prefer either ReasonML or PureScript ReasonML is great if you are looking lightweight alternative for compatibility with existing JS libraries. It has relatively far less type syntax than TypeScript. I find PureScript (which also compiles to JS) to be more succinct and solving the right problems for the developer. Although you need to spend some time writing monadic adapter layer over existing JS library API interface if you want to use them but given the confidence and safety provided by PS compiler, I think it's worth the time. https://blog.functorial.com/posts/2017-08-09-Why-You-Should-Use-PureScript.html https://blog.functorial.com/posts/2017-08-09-Why-You-Should-...

180 points by traderjane 8y ago

Excited about “Higher order type inference from generic functions”. Great for libraries like RxJS, Ramda and axax.

The type inference looks good. Pardon a question here: Will ES6 Code ‘just Run’ under TypeScript? I think the answer is yes for ES5, but I don’t know about ES6. Thanks.

lachenmayer 8y ago
Generally that depends on how many 'strict' compiler options you enable -- and whether you consider legitimate type errors a reasonable reason to not 'just run' your code :) An example would be that classes that don't explicitly declare their fields will throw a type error when their fields are mutated (eg. `this.foo = 123`).
jtreminio 8y ago
I believe Typescript is an extension of ES6. TS is ES6 + types (and other things).
stareatgoats 8y ago
Not sure what you mean by running ES6 code under Typescript. It is my understanding that Typescript 'transpiles' to whatever flavor of Javascript you need, and then the code is executed as Javascript. If your question is whether you can just change the file extension of a working ES6 file to .ts without Typescript complaining then answer is 'yes', you should be able to do that no problem. Edit: of course there is little sense in doing nothing more than that, but it is a good starting point for decorating existing Javascript with TS features.
- Someone1234 8y ago
  The biggest pain-point with renaming a ES6 file to *.TS is that TypeScript will flag every library or browser specific object you reference as missing. That isn't wrong behavior on TS's part, just getting started with TypeScript is very configuration heavy, particularly for targeting browsers.
  - jahewson 8y ago
    You can use the ‘allowJs’ flag to have the compiler accept unmodied JavaScript and for untyped modules you can use shorthand ambient module declarations so they use the ‘any’ type, with one line of code.
- superpermutat0r 8y ago
  If your target is ES5 you will have to provide polyfills. Typescript will unfortunately typecheck even if you don't have polyfills and you'll get runtime errors with your ES5 target. They specifically said they won't provide polyfills and they Will continue to typecheck even if your target does not support the standard function.
nikeee 8y ago
If you use classes, the compiler may complain because the class has no declared fields. The compiler will emit JS anyway.
- vimslayer 8y ago
  Class field declarations are a stage 3 proposal for EcmaScript, btw, and already supported in Chrome. So class Foo { foo; constructor() { this.foo = 42 } } Will be both valid ES2019 or ES2020 and TypeScript.

ng12 8y ago

Wow. The const assertion is huge. My codebases are littered with things that I, the developer, know are constant but TypeScript does not and it often takes extra work to get type safety because of it. Can't wait to start using it.

coldtea 8y ago
Now following their examples clearly. Why not just make that "let x" a "const x" which JS already allows?
- kentor 8y ago
  "const a = {}" disallows reassignment to "a" but still allows you to mutate the object e.g. "a.b = 1". The const context does not allow you to mutate the object.
  - coldtea 8y ago
    OK, the example with the "hello" literal string they have is quite bad then.
    - karanlyons 8y ago
      `as const` is useful there as well, as TypeScript’s type inference only narrows as far as the type and not the literal value. `let z = {text: "hello"}` has the shape `{text: string}`, with `as const` it has the shape `{text: "hello"}`.
      - coldtea 8y ago
        Yeah, but shouldn't it use: const z = 'hello' and then get the shape {text: 'hello'} automatically? Why use "let" along with "as const" instead of mere "const x = 'hello'" for that?
        karanlyons 8y ago

cryptica 8y ago

There has never been a worse time to be a software developer. Practically all of the most popular tools encourage anti-patterns, add unnecessary complexity or solve superficial problems instead of focusing on critical problems that exist in today's software projects. Some examples: - TypeScript: Unfortunately, we cannot reduce a language's complexity by adding extra complexity on top. The complexity will keep rearing its ugly head no matter how much we try to hide it. The TypeScript project has had over 20K issues raised and 9K pull requests (that's not even mentioning the DefinitelyTyped repo)... To put it into perspective, the Linux project has only had about 380 PRs on GitHub. But how much value does TypeScript add? All evidence points to the fact that TypeScript does not have any positive effect on bug density. Its value is purely subjective and speculative. If humanity had invested a quarter of that time and energy towards coming up with and documenting proper JavaScript design patterns and architectures, TypeScript would have been completely redundant to begin with. - NestJS: Makes heavy use of decorators; these aim to allow developers to handle cross-cutting concerns within their code. Unfortunately, cross-cutting concerns are an anti-pattern because they imply a violation of the principle of separation of concerns between components. It takes a bit of thinking and discipline to come up with components which have clear and distinct concerns/responsibilities, but this is not a problem that can simply be ignored by injecting decorators all over your code. - InversifyJS: Dependency injection is a failed concept. It's been proven over and over. Angular 1 provided us with plenty of evidence for why we should avoid dependency injection (e.g. it's impossible to find stuff and you end up with a pseudo-global scope for everything which is as bad as simply using global variables). Again, dependency management is not a solution which can be automated away; it requires developers to make careful design decisions. - Code coverage tools like Istanbul and others add very little value to projects. 100% coverage is not a useful goal to have, in fact it's counterproductive. When it comes to test coverage, quality of that coverage is WAY more important than quantity (this cannot be over-emphasized). Did you test all the right inputs? Do the tests focus on the most important code paths (and those which are more complex and therefore more likely to fail)? I'd rather have 10% quality coverage of the right parts of the code than 100% poor quality coverage. Also, you need to take into account that the more unit test coverage you have, the harder it is to make changes to your code. - Linting tools such as ESLint/TSLint: These tools can be very nice if used correctly and not treated as a silver bullet for all programming problems. We should never forget that linters can only detect superficial problems. If your code passes all the most strict linting rules, it still says almost nothing about your project's code quality. I'd MUCH rather have code that fails ALL linting rules possible but has good architecture and good separation of concerns between components; at least the linting is easy to fix. Linting does not prevent architectural mistakes AT ALL; it only prevents superficial mistakes which are usually easy to identify anyway (if you have half-decent testing). I hope that over the next decade, the masses of new developers will develop their critical thinking skills and that they will be able to see value beyond the hype which is always being shoved into their faces by various misguided organizations. It's particularly difficult for me to see what has happened to software development because 10 years ago, I used to roll my eyes when I read comments like this from older and more experienced developers. New developers are often attracted to complexity like moths to a flame, but eventually we all learn that complexity is a silent killer - It's the ultimate enemy. Complexity is always trying to quietly sneak its way into your code (and I do mean ALWAYS; no matter how good your code is at any given point) and you must identify and stop every single attempt. It takes most developers at least a decade or two of coding to really appreciate this. For me, starting a TypeScript project is like accepting unnecessary complexity from the beginning of the project. It's a bad start, a slippery slope.

tombert 8y ago

I haven't written anything in TypeScript, though I have some friends that love the language; I got annoyed at having to supply bindings for obscure languages. If you can get past the initial hurdle, is TypeScript worth it for Node.JS stuff?

gmac 8y ago
YES. I would never go back. Types, combined with a great IDE in VS Code, make for a so much less frustrating experience.
dpacmittal 8y ago
Typescript is a godsend. Once you get comfortable with TS, you just can't go back to normal JS.
pas 8y ago
what does bindings for obscure languages mean in this context? does TS count as obscure?
- skybrian 8y ago
  I'm guessing it's a typo for "libraries".
  - tombert 8y ago
    You guessed correctly.
klodolph 8y ago
TypeScript doesn't require bindings to call JavaScript libraries. This includes writing code to run in the browser and writing Node.js code. Instead, what you want are type definitions for the library you use. These are optional, but make using a library with TypeScript a much better experience. It is very common for these definitions be available already, whether the library is written in TypeScript or something else. Years ago I remember having to manage these type definitions, these days I don't really have to think about it much. There's not much of an initial hurdle, to be honest. You're mostly adding annotations to your JavaScript code. It does influence the structure of your code but not as much as you might think, at least in my experience.

deleted 8y ago

[deleted]

jasonhansel 8y ago

Just waiting until TypeScript's type system becomes so powerful that inference accidentally becomes Turing-complete.

mickael 8y ago
Apparently, Typescript type system is already Turing-complete: https://github.com/Microsoft/TypeScript/issues/14833 https://github.com/Microsoft/TypeScript/issues/14833

truth_seeker 8y ago

Oh dear, look at those features. Typescript is becoming the big valley of types and syntax overheads. In order to be productive, as a developer I should learn or know almost all the distinct syntax rules and tons of best practices. An ideal (or close to it) typed language will have only few type rules and better way to compose them. I prefer either ReasonML or PureScript ReasonML is great if you are looking lightweight alternative for compatibility with existing JS libraries. It has relatively far less type syntax than TypeScript. I find PureScript (which also compiles to JS) to be more succinct and solving the right problems for the developer. Although you need to spend some time writing monadic adapter layer over existing JS library API interface if you want to use them but given the confidence and safety provided by PS compiler, I think it's worth the time. https://blog.functorial.com/posts/2017-08-09-Why-You-Should-Use-PureScript.html https://blog.functorial.com/posts/2017-08-09-Why-You-Should-...