So, with TSX support in TypeScript, node and react-native, its now possible to write end-to-end type checked web and mobile applications (from database to templates). With full language service support (refactoring, intelligent navigation etc) that is also exposed via a standalone language service distributed with the compiler relatively easy to integrate with any editor. All that while seamlessly leveraging the entire node (and JS) ecosystem (just add a few definition files). And there even is a free, cross-platform editor that packages it all into one neat package: https://code.visualstudio.com/
Seriously, how cool is that? (Even though admittedly there are soundness issues with TypeScript, its still pretty damn amazing)
I have been experimenting with React development with TSX and I must say I finally feel like I can do web development in a way that isn't just trial and error. The soundness issues with TypeScript do crop up, but they happen at certain boundaries that if you're use to them, you'll scrutinize them harder. Mind you, this is the same scrutiny you are used to doing in plain Javascript.
A key benefit to TypeScript over Flow is the very deep amount of IntelliSense and IDE support you get from it up front in your development process. It's very nice to have things like auto-completion and API documentation at your fingertips as you work.
Also, TypeScript has a fairly strong transpilation engine and can be a one-stop shop for most of your transpilation needs (contrasting to also needing something Babel or Traceur in your build and/or runtime stack, for instance, because you can just transpile ES6-like TypeScript directly to ES5).
I don't know much about type theory, so I suspect that my intuition is wrong, but the phrase "intersection type" violates my intuition.
If I have Printable and Drawable interfaces, which each describe a set of behaviors, then I would expect the "intersection" of Printable and Drawable to be the intersection of those sets of behaviors — which, here, is likely the empty set.
Is there another way of understanding types that makes the word "intersection" make more sense here? Or is it just to say that "where union types say OR, intersection types say AND"?
---
...ya know what? By typing it out, I think I get it now.
The set that we're talking about isn't the set of Printable's behaviors; it's the set of things that implement Printable. `Printable & Drawable` is the intersection of the set of types that implement Printable with the set of types that implement Drawable. Got it. Thanks for rubber-ducking for me, HN!
Objects whose type is a subtype of "Printable | Drawable" (union) are those that implement either interface. For "Printable & Drawable" (intersection), you have objects that implement both interfaces. Meaning, those objects that have both .print() and .draw() (or similar).
You're not taking the intersection of the interfaces, but of the sets of objects that implement them.
It is referring to mathematical sets, but at the categorization of types level rather than the "shape" of types.
If you think of Set X consisting of all the objects that could possibly be built as Class X and Set Y as all the objects that could possibly be built as Class Y, then the union of those sets is all of the Class X derived objects and all of the Class Y derived objects, whereas the intersection of those sets are whatever objects manage to implement or derive from both Class X and Class Y.
The Roadmap [0] has long seen async/await as the defining feature for the TypeScript 2.0 milestone, from what I recall. From what I've read in the blog posts the team wants to prioritize ES6 (ES2015) features first, particularly as async/await is potentially on the standards agenda as early as ES2016 or ES2017...
The surprise in TypeScript 1.6 is that experimental support for async/await is actually included, with the caveats that you have to explicitly opt in to the experimental feature with a compiler flag and that it only works when outputting ES6 code (it fails for ES3 and ES5). Some details are at the bottom of the issue 1664.
Also, I think the new typing capabilities are hugely sexy if you've ever had to write .d.ts files for wild JS. Generic type aliases and intersection types will solve a lot of things that were much harder to do in definition files previously.
Also, the support for expressions in class extends clauses makes it a lot easier to use the nicer class syntax when operating with JS libraries that use a custom object factory. (Given the long history of JS OO, there are a lot of weird custom object factories out there in wild JS code.) This is also good catchup with ES6 class syntax; it's always sexy when TS works to keep its "pure superset" goals.
JSX support is a big feature, albeit controversial and not for everyone. Notice Rob Eisenberg's first comment on the blog:
"I do have one concern with this release. Back in the day, Anders was extremely adamant about not including XML in C#. At the time, XML was extremely popular, but today it is much less so. It was a wise decision. Today, I see a release that ties TypeScript to JSX, which seems to fly in the face of the previous language design principle. But furthermore, it is a long held principle that one should not embed JavaScript in HTML. So, why are we so quick to embed HTML in JavaScript? JSX has always seemed like a phenomenally bad idea and one that is certain to be short lived. Can you elaborate on the nature of the JSX integration? I'd like to know that it's not going to affect TS in the long-term. I'd also like to know what type of compiler output it produces. Does it produce React code? or does it produce some sort of string concatenation expression in the end? Did the TS compiler just get tied to the React library's implementation details?"
I like Typescript, however it leads to that "Enterprise Javascript" coding style I really hate, pushing OOP Java style over simple functional programming.
But I admit that being able to read type signatures in the source code makes understanding a code base way easier, it's just that people tend to be more verbose going full OOP , even when it is not necessary. But kudos for Microsoft, if only they would have accepted ES4 8 years ago, TS would not have been needed.
And by the way Microsoft, why not make Jscript.net cool again ?
The great thing about multi-paradigm languages is that you and I can write very functional code one day and lend a hand in a heavily OOP codebase the next.
Even "Enterprise JavaScript" is a step up from the hodge podge "no paradigm" JS that has classically littered the web. It's nice seeing actual architecture and planning in JS codebases these days, with and without the big rigid frameworks. Sure, a lot of it is more verbose than it needs to be and over-architecture is an easy over correction to make, but typically I'll take over-architecture over no-architecture any day of the week. (Even if most of the joy I get from over-architecture is taking sledge hammers to it and reducing it down to a tighter core. Net negative lines of code refactors are a wonderful thing.)
It helps people who don't know JS code for JS. And it helps people like c# / java devs just writing code without learning more that typescript. This is very powerful but it also can lead to Enterprise-like code writing.
You can say that the library is of "any" type and the compiler will accept all method calls on it.
However it should be fairly easy to write a .d.ts file for it. You don't even have to cover the entire library - its enough to specify the types of the parts you use.
Yes, but that's a good thing. .d.ts files are reasonably straightforward to write (the external vs internal module thing is the exception), and easy to share on DefinitelyTyped. But that only happened because TypeScript requires .d.ts files - the requirement pushes the community forward, with benefits for all.
and TSD to copy into your directory from DT (it's like a package manager for definitions). Not ideal but that's the practice. Doesn't cover your simple-oauth2 example though, but its not that bad adding the individual methods you need on demand (easier if you have the definatelyTyped examples to follow).
I was just playing with this today. I didn't realize it was so new! I filed a bug about the extension with the related emacs mode and it's already fixed: https://github.com/fxbois/web-mode/issues/585
Seriously, how cool is that? (Even though admittedly there are soundness issues with TypeScript, its still pretty damn amazing)