Hacker News Reader

Comment by joostdevries | Hacker News Reader

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.... [2] 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.

View on HN

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.

If that first feature is true, it will bring me back to TypeScript. Honestly, my major deterrence of TypeScript was managing both 3rd party libraries and typing files.

Could you give links about moving types to npm? Are there any issues in a tracker or a blog?

Posted today https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-f...

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/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.

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)

TypeScript 1.8x already looks for "typings" in package.json

see https://github.com/Microsoft/TypeScript/issues/8275

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

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.

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.

IIRC there is no ergonomic way to define typed records for Immutable.js ?

If I recall correctly, you still can't type Immutable.js nicely with Flow, let alone Typescript, so I'm not surprised tbh

I've been playing with https://github.com/danielearwicker/doop

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).

> As a Scala developer

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

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.

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.

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.

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++.

So it sounds like everything worked out.

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.

The advantage is it gives you an escape route if Typescript ends up dying. I worked on a project that had to do a giant dead language -> Java conversion, and it was extremely painful.

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.

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.

I wonder is it some black humour to choose padLeft as an example source code. :)

Thanks for the links, future looks promising indeed.

Reply on news.ycombinator.com