5 ms·

With the arrival of TS 2.0 this month (hopefully) we'll have some cool features: a union types [1] b type guards to work with them [1] c nonullable types [2]

With the arrival of TS 2.0 this month (hopefully) we'll have some cool features: a union types [1] b type guards to work with them [1] c nonullable types [2] [1] https://www.typescriptlang.org/docs/handbook/advanced-types.html https://www.typescriptlang.org/docs/handbook/advanced-types.... [2] https://github.com/Microsoft/TypeScript/pull/7140 https://github.com/Microsoft/TypeScript/pull/7140 As a Scala developer I like Typescript a lot. Which is a first for me in browser development. But I'm not so fond of webpack et al. So I created a sbt-typescript plugin. And now I have incremental compilation of NG2 - Play apps for both the browser side and the server side. In a single build definition. It's a nice experience.

Tx3 10y ago
I wonder is it some black humour to choose padLeft as an example source code. :) Thanks for the links, future looks promising indeed.
virtualwhys 10y ago
> As a Scala developer Interesting, choosing TypeScript over Scala.js; what does TS offer vs. working directly in Scala across the board?
- kodablah 10y ago
  I am in the same boat as the poster. The main reasons I use typescript instead of scala.js are the vast amount of definition files already made (the scala.js translator of these leaves a lot to be desired), and the fact that it's closer to the es6 community which makes maintenance, contributions, and adoption much more likely. So basically because you stay closer to the JS world. The only downside is lack of "isomorphic" code reuse which I gladly accept anyways because I rarely see server and client side code reuse as beneficial beyond simple models and validation.
- joostdevries 10y ago
  As codablah said: the availability of type definitions is a major difference in ease of use. The other reason is that I can add a specialised frontend dev to the team and reasonably expect them to be able to work in Typescript.
  - k__ 10y ago
    Also, TypeScript uses a structural type system, which feels very dynamic most of the time. I could imagine, that most JavaScript developers prefer this over nominative systems.
- choward 10y ago
  I think the biggest advantage is that typescript emits code that is good JavaScript. This means if I decide to stop using typescript, I can just use the generated JavaScript. It also means that there transpiled file is smaller. Using scala.js for a small project wouldn't make sense if you cared about file size at all. It could be worth it more as your project grows, but your then you are that much more commited. There's no exit strategy like with typescript.
  - shados 10y ago
    I'm always curious where that came from. TypeScript does not emit good JS. It's pretty garbage and not reasonably usable by humans. TS supports ES6 target, where it more or less just strips TS-specific features, but that's only useful if you target a very small subset of browsers and limit what you use. Even "6to5" (previous name for Babel), which originally had as a design goal that it would emit good JS (and back then, it did!) quickly lost that when they tried to aim for spec correctness. TypeScript actually punts on the standard in some cases (eg: TypeScript classes are not ES6 compliant) to generate more readable code, but it's still not "good" code and I certainly would never consider working with that.
  - intrasight 10y ago
    I remember hearing the same argument in the early 80s for the benefit of C vs Assembly. And it actually was a good argument. A lot of people, myself included, learned "real programming" (ie assembly) by using C as training wheels. But a funny thing happened on the way to the forum - C became real programming and nobody remembered or learned assembly - myself included. Then the same thing happened ten years later with the transition from C to C++.
    - choward 10y ago
      So it sounds like everything worked out.
      - intrasight 10y ago
        It did, and it will. My point is that just like with these "legacy" languages, the next generation of TypeScript developers are no more likely to "drop down into JavaScript" as a C developer is to "drop down into assembly". So our development tools and debuggers must be really solid at the language level that we code in. And just like I skipped the "transpiling" phase of C++, I'll probably skip the transpiling phase of TypeScript, and wait for the tooling and runtime to be more mature.
samps 10y ago
TypeScript 1.8 already has unions and custom type guards! You can use them today. Woohoo! (Looking forward to those non-nullable types, though.)
- shuzchen 10y ago
  I was just about to complain how TS fails totally for typechecking backbone models or immutablejs datastructures: both situations where obj.get("foo") and obj.get("bar") return a particular type but there's no way of having TS handle that except defining them as any. But it turns out string literal types in 1.8 will make that work. And this was out since February! I should reevaluate TS for my omniscient project.
  - rubber_duck 10y ago
    IIRC there is no ergonomic way to define typed records for Immutable.js ?
    - girvo 10y ago
      If I recall correctly, you still can't type Immutable.js nicely with Flow, let alone Typescript, so I'm not surprised tbh
    - danielearwicker 10y ago
      I've been playing with https://github.com/danielearwicker/doop https://github.com/danielearwicker/doop
  - danielearwicker 10y ago
    The example you give has been supported since day 1. Example: document.createElement("canvas") returns HTMLCanvasElement. A limited form of string literal types has always been supported specifically for overloading return types. The newer support added in 1.8 is a way more powerful generalisation.
  - nidu 10y ago
    It could also benefit from constant propagation (iirc the term) where you could write obj.get(Item.name) and both get type check and stay refactoring friendly (though with cost of some more typing).
robwormald 10y ago
The two things coming in 2.0 that most excite me are - moving types to npm (despite the great work of Blake on typings, managing type definitions is still out of band) - npm install @types/somelib will be great. - AST transforms, which will open up some interesting options for bundling and optimizations, sort of like babel's plugin ecosystem.
- solomatov 10y ago
  Could you give links about moving types to npm? Are there any issues in a tracker or a blog?
  - ihsw 10y ago
    I don't know about moving all of the current typings to beneath an NPM org, but TypeScript can look for the `typings` field in a package's package.json file. https://github.com/ihsw/toxiproxy-node-client/blob/master/package.json#L6 https://github.com/ihsw/toxiproxy-node-client/blob/master/pa... An NPM package will be typed and you won't have to download typings separately. It may be improper to publish typings with your code instead of letting the user install them separately, but at that point it ceases being clean. In this case, my `toxiproxy-node-client` package is written in TypeScript and the typings are published alongside the built package files. Compatibility between ES6 and TS is maintained.
    - camwest 10y ago
      TypeScript 1.8x already looks for "typings" in package.json
    - robwormald 10y ago
      yep, this method works great for libraries authored in typescript (and/or those that take the time to provide external module-style typedef files), but the @typings would be for what tsd/typings does today (mostly ambient)
  - robwormald 10y ago
    see https://github.com/Microsoft/TypeScript/issues/8275 https://github.com/Microsoft/TypeScript/issues/8275

Tx3 10y ago

I wonder is it some black humour to choose padLeft as an example source code. :) Thanks for the links, future looks promising indeed.

virtualwhys 10y ago

> As a Scala developer Interesting, choosing TypeScript over Scala.js; what does TS offer vs. working directly in Scala across the board?

kodablah 10y ago
I am in the same boat as the poster. The main reasons I use typescript instead of scala.js are the vast amount of definition files already made (the scala.js translator of these leaves a lot to be desired), and the fact that it's closer to the es6 community which makes maintenance, contributions, and adoption much more likely. So basically because you stay closer to the JS world. The only downside is lack of "isomorphic" code reuse which I gladly accept anyways because I rarely see server and client side code reuse as beneficial beyond simple models and validation.
joostdevries 10y ago
As codablah said: the availability of type definitions is a major difference in ease of use. The other reason is that I can add a specialised frontend dev to the team and reasonably expect them to be able to work in Typescript.
- k__ 10y ago
  Also, TypeScript uses a structural type system, which feels very dynamic most of the time. I could imagine, that most JavaScript developers prefer this over nominative systems.
choward 10y ago
I think the biggest advantage is that typescript emits code that is good JavaScript. This means if I decide to stop using typescript, I can just use the generated JavaScript. It also means that there transpiled file is smaller. Using scala.js for a small project wouldn't make sense if you cared about file size at all. It could be worth it more as your project grows, but your then you are that much more commited. There's no exit strategy like with typescript.
- shados 10y ago
  I'm always curious where that came from. TypeScript does not emit good JS. It's pretty garbage and not reasonably usable by humans. TS supports ES6 target, where it more or less just strips TS-specific features, but that's only useful if you target a very small subset of browsers and limit what you use. Even "6to5" (previous name for Babel), which originally had as a design goal that it would emit good JS (and back then, it did!) quickly lost that when they tried to aim for spec correctness. TypeScript actually punts on the standard in some cases (eg: TypeScript classes are not ES6 compliant) to generate more readable code, but it's still not "good" code and I certainly would never consider working with that.
- intrasight 10y ago
  I remember hearing the same argument in the early 80s for the benefit of C vs Assembly. And it actually was a good argument. A lot of people, myself included, learned "real programming" (ie assembly) by using C as training wheels. But a funny thing happened on the way to the forum - C became real programming and nobody remembered or learned assembly - myself included. Then the same thing happened ten years later with the transition from C to C++.
  - choward 10y ago
    So it sounds like everything worked out.
    - intrasight 10y ago
      It did, and it will. My point is that just like with these "legacy" languages, the next generation of TypeScript developers are no more likely to "drop down into JavaScript" as a C developer is to "drop down into assembly". So our development tools and debuggers must be really solid at the language level that we code in. And just like I skipped the "transpiling" phase of C++, I'll probably skip the transpiling phase of TypeScript, and wait for the tooling and runtime to be more mature.

samps 10y ago

TypeScript 1.8 already has unions and custom type guards! You can use them today. Woohoo! (Looking forward to those non-nullable types, though.)

shuzchen 10y ago
I was just about to complain how TS fails totally for typechecking backbone models or immutablejs datastructures: both situations where obj.get("foo") and obj.get("bar") return a particular type but there's no way of having TS handle that except defining them as any. But it turns out string literal types in 1.8 will make that work. And this was out since February! I should reevaluate TS for my omniscient project.
- rubber_duck 10y ago
  IIRC there is no ergonomic way to define typed records for Immutable.js ?
  - girvo 10y ago
    If I recall correctly, you still can't type Immutable.js nicely with Flow, let alone Typescript, so I'm not surprised tbh
  - danielearwicker 10y ago
    I've been playing with https://github.com/danielearwicker/doop https://github.com/danielearwicker/doop
- danielearwicker 10y ago
  The example you give has been supported since day 1. Example: document.createElement("canvas") returns HTMLCanvasElement. A limited form of string literal types has always been supported specifically for overloading return types. The newer support added in 1.8 is a way more powerful generalisation.
- nidu 10y ago
  It could also benefit from constant propagation (iirc the term) where you could write obj.get(Item.name) and both get type check and stay refactoring friendly (though with cost of some more typing).

robwormald 10y ago

The two things coming in 2.0 that most excite me are - moving types to npm (despite the great work of Blake on typings, managing type definitions is still out of band) - npm install @types/somelib will be great. - AST transforms, which will open up some interesting options for bundling and optimizations, sort of like babel's plugin ecosystem.

solomatov 10y ago
Could you give links about moving types to npm? Are there any issues in a tracker or a blog?
- ihsw 10y ago
  I don't know about moving all of the current typings to beneath an NPM org, but TypeScript can look for the `typings` field in a package's package.json file. https://github.com/ihsw/toxiproxy-node-client/blob/master/package.json#L6 https://github.com/ihsw/toxiproxy-node-client/blob/master/pa... An NPM package will be typed and you won't have to download typings separately. It may be improper to publish typings with your code instead of letting the user install them separately, but at that point it ceases being clean. In this case, my `toxiproxy-node-client` package is written in TypeScript and the typings are published alongside the built package files. Compatibility between ES6 and TS is maintained.
  - camwest 10y ago
    TypeScript 1.8x already looks for "typings" in package.json
  - robwormald 10y ago
    yep, this method works great for libraries authored in typescript (and/or those that take the time to provide external module-style typedef files), but the @typings would be for what tsd/typings does today (mostly ambient)
- robwormald 10y ago
  see https://github.com/Microsoft/TypeScript/issues/8275 https://github.com/Microsoft/TypeScript/issues/8275