4 ms·

Is TypeScript really future proof? I mean unless types, exactly implemented as they are in TypeScript, will become part of the spec, we can't really call it fut

by Hurtak 11y ago

Is TypeScript really future proof? I mean unless types, exactly implemented as they are in TypeScript, will become part of the spec, we can't really call it future proof. Also how is it compatible with anything, JavaScript is compatible with TypeScript, since TypeScript is superset of JS, but it is not compatible the other way around.

nothrabannosir 11y ago
Yes, it is. Compiling TS just removes type annotations; the compilation output (.js) is as readable as your original .ts. It has the same structure, same indentation, same variable names, same whitespace, same comments, same everything. This also makes debugging the code in the browser very easy. TS does not add any semantic features, it only adds type annotations. Which it checks at compile time, and then removes. That's it. Want to switch away from TS? Compile all your .ts files, save the .js, check that into your repo and continue from there. (As other commenters sort-of pointed out: you will need to keep Babel in your pipeline.)
- agumonkey 11y ago
  Interesting, I never 'considered' that. It's basically a thin typechecker linguistic layer. A variant of gradual typing.
- Roboprog 11y ago
  Thanks for the concrete description. Can I still use dynamic constructs such as string subscripts to associative arrays and code generation via eval()?
  - nothrabannosir 11y ago
    You mean in TS? Yes. ∀ x: I can do x in JS → I can do x in TS But, let's assume for a second that you couldn't: this thread is about TS being future-proof. I.e.: ∃ x: I can do x in TS & I cannot do x in JS? No, false. This implies TS = JS. And that's the point: semantically, TS = JS.
    - Roboprog 11y ago
      OK, that's a good start. Is there a tool analogous to JSDoc for TypeScript that gathers the same docs without repeating the type info already in the code?
      - elisee 11y ago
        http://typedoc.io/ http://typedoc.io/ might be what you're looking for.
        Roboprog 11y ago
        Thanks. Also, some informative samples of what TypeScript itself looks like. https://github.com/sebastian-lenz/typedoc/blob/master/src/lib/application.ts https://github.com/sebastian-lenz/typedoc/blob/master/src/li...
minionslave 11y ago
It is, you just need to define a d.ts file. I was able to use plain jquery with typescript. Check out DefinitelyTyped. It's a project that makes it easy.
Eridrus 11y ago
Sort of. I don't recall the details from the top of my head and can't easily seem to find details, but I think we're seeing some divergence between Typescript's classes and es6 classes, though I think it's mostly syntactic. Your code will keep working, but it may diverge a bit from standard JS; however everything will keep working, and I'm sure the expectation would be to move over the es6's syntax unless there were semantic reasons not to. The Typescript authors are involved in the ECMAScript process, so I'm pretty sure that there won't be any surprising huge rifts at least.
- chadaustin 11y ago
  I don't know why you're being downvoted. You're exactly right - there are a few tiny divergences between ES6 and TypeScript. In particular, try compiling some classes with Babel's strict compatibility mode and compare the output to TypeScript's output. There are several small semantic differences. Also, there a few constructs in TypeScript that generate JavaScript code, like enum and module. THAT SAID, TypeScript is basically ES6 + type annotations, and can certainly be used as such.
- SiVal 11y ago
  I'm hoping that Typescript will be willing to break backward compatibility when necessary to maintain its core advantage of being an assisted version of the standard rather than just another non-standard language. If Typescript gets out ahead of the ES standard and adopts a feature that is presumably coming in ES, but ES changes course and doesn't follow, TS will no longer be annotated, standard ES. In this case, I'm hoping TS will just make the breaking change and go back to being pure, standard ES plus optional type annotations. Developers who use it would just accept that from time to time, this could happen, but it could probably be made a non-issue if MS just wrote another transpiler: oldTS -> newTS, for people whose choice of Typescript meant they had committed from the start to a system that would ALWAYS require transpiling.

by Hurtak 11y ago

nothrabannosir 11y ago

Yes, it is. Compiling TS just removes type annotations; the compilation output (.js) is as readable as your original .ts. It has the same structure, same indentation, same variable names, same whitespace, same comments, same everything. This also makes debugging the code in the browser very easy. TS does not add any semantic features, it only adds type annotations. Which it checks at compile time, and then removes. That's it. Want to switch away from TS? Compile all your .ts files, save the .js, check that into your repo and continue from there. (As other commenters sort-of pointed out: you will need to keep Babel in your pipeline.)

agumonkey 11y ago
Interesting, I never 'considered' that. It's basically a thin typechecker linguistic layer. A variant of gradual typing.
Roboprog 11y ago
Thanks for the concrete description. Can I still use dynamic constructs such as string subscripts to associative arrays and code generation via eval()?
- nothrabannosir 11y ago
  You mean in TS? Yes. ∀ x: I can do x in JS → I can do x in TS But, let's assume for a second that you couldn't: this thread is about TS being future-proof. I.e.: ∃ x: I can do x in TS & I cannot do x in JS? No, false. This implies TS = JS. And that's the point: semantically, TS = JS.
  - Roboprog 11y ago
    OK, that's a good start. Is there a tool analogous to JSDoc for TypeScript that gathers the same docs without repeating the type info already in the code?
    - elisee 11y ago
      http://typedoc.io/ http://typedoc.io/ might be what you're looking for.
      - Roboprog 11y ago
        Thanks. Also, some informative samples of what TypeScript itself looks like. https://github.com/sebastian-lenz/typedoc/blob/master/src/lib/application.ts https://github.com/sebastian-lenz/typedoc/blob/master/src/li...

minionslave 11y ago

It is, you just need to define a d.ts file. I was able to use plain jquery with typescript. Check out DefinitelyTyped. It's a project that makes it easy.

Eridrus 11y ago

Sort of. I don't recall the details from the top of my head and can't easily seem to find details, but I think we're seeing some divergence between Typescript's classes and es6 classes, though I think it's mostly syntactic. Your code will keep working, but it may diverge a bit from standard JS; however everything will keep working, and I'm sure the expectation would be to move over the es6's syntax unless there were semantic reasons not to. The Typescript authors are involved in the ECMAScript process, so I'm pretty sure that there won't be any surprising huge rifts at least.

chadaustin 11y ago
I don't know why you're being downvoted. You're exactly right - there are a few tiny divergences between ES6 and TypeScript. In particular, try compiling some classes with Babel's strict compatibility mode and compare the output to TypeScript's output. There are several small semantic differences. Also, there a few constructs in TypeScript that generate JavaScript code, like enum and module. THAT SAID, TypeScript is basically ES6 + type annotations, and can certainly be used as such.
SiVal 11y ago
I'm hoping that Typescript will be willing to break backward compatibility when necessary to maintain its core advantage of being an assisted version of the standard rather than just another non-standard language. If Typescript gets out ahead of the ES standard and adopts a feature that is presumably coming in ES, but ES changes course and doesn't follow, TS will no longer be annotated, standard ES. In this case, I'm hoping TS will just make the breaking change and go back to being pure, standard ES plus optional type annotations. Developers who use it would just accept that from time to time, this could happen, but it could probably be made a non-issue if MS just wrote another transpiler: oldTS -> newTS, for people whose choice of Typescript meant they had committed from the start to a system that would ALWAYS require transpiling.