
Announcing TypeScript 3.0 - DanRosenwasser
https://blogs.msdn.microsoft.com/typescript/2018/07/30/announcing-typescript-3-0/
======
sbjs
More and more projects are adding TypeScript definition files for us, and many
are even being written (or rewritten) using TypeScript directly! I honestly
think TypeScript is the future of JavaScript. In fact, I can't help but wonder
what Microsoft's long term goal is with TS. They're making such _blazingly
fast_ progress with it, that I can't help but wonder if this is the
"incubation" period of the language, and when it's finally "ready to hatch",
they're going to do something big. Almost like this phase of TypeScript's life
would traditionally be done inside MS privately, but they wanted to benefit
from giving back to the community, from trust building within the community,
and from being able to say "we provided the most advances to the JavaScript
language out of any contributors by far" and somehow use that as leverage.
Maybe they'll make an official TC39 proposal that TypeScript syntax be
integrated into JavaScript, complete with a de facto free and open source
implementation that browsers and Node.js are free to use to strip types live
at compile-time. I just don't get it. They made VS Code, they bought Github,
they made TypeScript... where are they going with this? I honestly wonder.

~~~
mattferderer
Microsoft wants "Developers, Developers, Developers!"

TypeScript makes JavaScript easier & less buggy IMO. The more people
developing with TypeScript, the better chance they use Microsoft's other
tools. Some of those tools cost money. Some also make deploying with Azure
really easy & enjoyable. Azure is their big cash cow.

The more MS tools you use & the better perception of the company you have, the
easier it is to find yourself just wanting to stay in their ecosystem.

~~~
sbjs
That doesn't seem right. I don't know anyone who uses Azure outside of a .NET-
centric programming job. Azure always seemed to be like "hey if you heard good
things about AWS and need a place to deploy your code but you've never touched
anything outside the Microsoft ecosystem, come try Azure!" I've seen it
advertised on Stack Overflow a lot, but I have never even thought of looking
into it, for the same reason I have no reason to install Visual Studio.

~~~
TomMarius
Enterprise doesn't care about this. Enterprise cares about prices.

~~~
mattferderer
In my experience, enterprises care less about price & more about support,
perceived reliability & how they calculate value. I typically see them pay
through the nose for inferior products, that are over priced but offer support
packages & are billed as an enterprise company. Ironically, the support
usually leaves them frustrated as good support is hard to find.

------
ComputerGuru
I’m not a huge JavaScript developer as I prefer to code things in native
languages wherever possible but TypeScript is amazing and has brought much-
needed sanity to the world of interpreted scripting languages. With Hejlsberg
at the helm it has gained some incredible type-related features that even
traditional strongly-typed dynamically inferred languages haven’t been able to
find elegant syntax for.

It started off taking language queues and inspirations from C# and other
languages and is now at the point where _they_ are the ones copying back.
Impressive stuff, and it’s really come a long way since 1.0 which was so much
more awkward to use.

~~~
GordonS
I'm mainly a C# guy, and have never been a fan of JavaScript (although I
concede it has improved dramatically over the last few years).

I've never liked front-end development, but my first Typescript project was
something of a revelation for me - a familiar syntax, static types,
async/await, automatic fields via some ctor sugar, and a great type system! I
really like the way it blends aspects of C# with JavaScript and F# - if you
didn't known it had Hejlsberg at the helm, you could easily guess.

~~~
sbjs
I think you just solved the mystery I was wondering about... I bet Microsoft's
endgame here is to create a new platform. Think about it, they're actually
succeeding in getting types added to every single JS package out there, slowly
but surely. Eventually, there'll be no more need for the `any` and `unknown`
types, which I bet are just transitional. Once all JS in the world is
_completely and fully typed_ , they will have enough type information to
create a _blazingly fast_ alternative compiler and (minimal) runtime, even
faster than C#, maybe even rivaling C or C++. I mean they literally put the
guy who made C# in charge of TypeScript and had him working on this language
for several years now. I have no idea how they'll avoid the same mistakes they
made with UWP, but I honestly bet they're making a new platform even right now
as we speak, and that they're going to unveil it in a year or two.

~~~
Nelkins
Aha! A new platform, brilliant! And better yet, it could be a common runtime,
for different languages to inter-operate!

But what would they call it?!

;)

~~~
copperx
Dot jNet.

------
ggregoire
It's kind of crazy that Facebook has let TypeScript takes so much market
share.

I've been using Flow for so long now. The techno is good, the integration with
the code editors is good too, but Flow has a lot of small-but-really-annoying
bugs (2235 issues on GitHub right now), the type definitions for third-party
libs are meh (you often have to update/fix the definitions by yourself), the
team seems extraordinarily unstaffed for such an important project, they don't
share the roadmap at all, the priorities are clearly internal first (like
improving the performances instead of fixing the bugs) and they don't seem to
do much marketing or communication about it.

I wonder what's the future of Flow at this point.

And I'm seriously thinking to move to TS (for pro and personal projects) once
create-react-app will work perfectly out-of-the-box with TS.

~~~
flanbiscuit
Interesting. I was considering Flow and was going to begin using it by
sprinkling it in using their Comment Types[1]. I wanted something that I could
use but also make it optional for the other devs. Only because I was just
wanted to test it out and not fully commit to making the team use it right
away.

[1]
[https://flow.org/en/docs/types/comments/](https://flow.org/en/docs/types/comments/)

~~~
dinja15
Typescript also supports comment typing via JSDoc. I write complex types in a
definition file and use them in JSDoc. Works great.
[https://github.com/Microsoft/TypeScript/wiki/JSDoc-
support-i...](https://github.com/Microsoft/TypeScript/wiki/JSDoc-support-in-
JavaScript)

~~~
flanbiscuit
Hold on, TS can typecheck your code just by using your jsdoc annotations?!
That's a game changer for me!

~~~
egeozcan
Yes and it works quite well. Sometimes JSDoc fails to provide enough info
about the types though.

------
euroclydon
I've been using TypeScript for a while, and one thing I keep wondering about
is which polyfills are baked into the compiler. I don't know how I've been
able to get this far without understanding it.

Turns out there are none. You have two compiler flags: Target and Lib. Lib
determines the syntax and objects/apis you can use: ES2015, 2016, '17, etc,
and Target determines which platform it will run on.

But as far as I can tell, setting target does nothing to materially change the
output code. It doesn't polyfill. Rather it just causes additional
configurations to feed into the Lib compiler argument.

How to Polyfill with Typescript:
[https://basarat.gitbooks.io/typescript/content/docs/types/li...](https://basarat.gitbooks.io/typescript/content/docs/types/lib.d.ts.html#polyfill-
for-old-javascript-engines)

More on Target:
[https://basarat.gitbooks.io/typescript/content/docs/types/li...](https://basarat.gitbooks.io/typescript/content/docs/types/lib.d.ts.html#compiler-
target-effect-on-libdts)

~~~
recursive
Typescript _does_ have built-in polyfills. See for yourself.

1\. Goto
[http://www.typescriptlang.org/play/](http://www.typescriptlang.org/play/)

2\. Enter the code `function* gen() { yield "foo"; }`

3\. Behold the mighty state machine in the compiled output.

~~~
Arnavion
Specifically, TS has polyfills for _language_ features (eg iterators), not
_library_ features (eg `Array.prototype[Symbol.iterator]`).

~~~
johnny_reilly
Exactly what Arnavion said. So if you want to write es-latest with TypeScript
but support es5 simply set your target to be es5, import core-js for API
polyfills and set lib to your desired es version.

------
fabian2k
The improved error messages look very nice. Typescript can produce some rather
large error messages, and picking out the relevant type mismatch instead of
hitting the user with a wall of text is a vast improvement.

~~~
andyfleming
This is a great update! It often feels impossible to decipher the wall-of-text
error messages in TypeScript.

------
Slackwise
If I'm going to "upgrade" from JavaScript, why would I specifically choose
TypeScript?

Yes, it gives some compile-time-only type safety in certain places, but it
doesn't provide _state safety_ like ClojureScript. I'm more worried about
state/reference-based bugs creeping into my code versus type related issues,
which I'll be checking via unit tests anyway. On top of that, it doesn't
protect you from the usual JavaScript pitfalls since it's backwards
compatible, including the bad parts.

Or am I missing something here? Is it popular because it lets you directly
upgrade existing JavaScript files? I can see that being a big draw. Small and
gradual improvement, yeah?

~~~
always_good
What do you mean by "state safety" in ClojureScript?

For example, it couldn't mean atoms/CAS because it's already single-threaded.

Also, you'd consider upgrading to Typescript because static-typing was on your
wishlist. ClojureScript isn't really a competitor.

In fact, I ultimately found that "I still want a dynamically-typed language
but with some technical improvements" is the weakest reasoning for switching
away from Javascript which is why I ended up dropping ClojureScript. Meanwhile
I've found something like Elm goes far enough to make the switch more
worthwhile (static typing, built-in front-end architecture, etc).

~~~
iLemming
You left it too soon. Clojure.spec brings much more than most of the other
type systems could deliver.

------
mcraiha
Am I the only one that thinks "function call<TS extends any[], R>(fn:
(...args: TS) => R, ...args: TS): R { return fn(...args); }" looks horrible?

~~~
brlewis
"For this function named `call`, the first argument must be a function `fn`,
and subsequent arguments must be the type of arguments that `fn` expects. The
return value of `call` is the same type as the return value of `fn`."

How would you recommend communicating all that in an extended version of
ECMAscript?

~~~
frankpf
I like TypeScript's syntax, but I think the way function types are declared is
ugly.

If you have a function from A to B, you have to declare its type as

    
    
        type MyFunction = (arg1: A) => B
    

instead of

    
    
        type MyFunction = A => B
    

Here's that syntax applied to the example from GP:

    
    
        function call<TS extends any[], R>(fn: (...args: TS) => R, ...args: TS): R { return fn(...args); }
    

vs.

    
    
        function call<TS extends any[], R>(fn: ...TS => R, ...args: TS): R { return fn(...args); }

~~~
eppsilon
The syntax is probably meant to differentiate between a function expression
and a function type declaration.

------
plurby
“The question is not whether JavaScript is broken. The question is whether it
is broken enough to merit being replaced by something else.” ~ Anders
Hejlsberg

“Big JavaScript codebases tend to become read-only.” ~ Anders Hejlsberg

Anders Hejlsberg and Lars Bak: TypeScript, JavaScript, and Dart
[https://channel9.msdn.com/Shows/Going+Deep/Anders-
Hejlsberg-...](https://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-
and-Lars-Bak-TypeScript-JavaScript-and-Dart)

------
polskibus
It would be great if there was a way to use the type information from within
the code, ie. without type erasure.

Often we find that we create a nice model in TS, only to handle a lot of
switching on types in the runtime. This is sometimes a smell but sometimes
unavoidable, unless type information can be present in the runtime.

~~~
Stoids
That's probably unlikely to happen, as it falls out of line with the design
goals of TS, but check out io-ts[0] for a library approach to this problem.

[0] [https://github.com/gcanti/io-ts](https://github.com/gcanti/io-ts)

------
Legogris
While I have already encountered scenarios where the "Extracting and spreading
parameter lists with tuples" would have been helpful, this feels more like a
duct-tape hack instead of properly tackling overloads. I can see arguments
against TS doing that much magic, but the current situation when dealing with
overloaded functions (which you can do just fine in vanilla JS) is also not
really approachable.

Also, unknown is a great addition.

EDIT: Just checked out their roadmap and while not exactly what I had in mind,
Variadic Kinds is there and way more interesting:
[https://github.com/Microsoft/TypeScript/issues/5453](https://github.com/Microsoft/TypeScript/issues/5453)

------
bradenb
I'm particularly excited about project references. We have quite a few small
web apps that use the client/server/shared structure and the default Angular
webpack configuration does not like relative references (i.e. referencing
../shared from client). I'm hoping this resolves the issue of having to
install the shared project as a module or ejecting the webpack configuration.

------
danenania
We're working on converting EnvKey’s[1] babel/ES6 codebase to TypeScript. It
has been a true pleasure so far and has already brought gains in safety and
productivity. I've never worked with a type system that is so intuitive and so
rarely violates the principle of least surprise. It's amazingly easy to pick
up, and also easy to gradually introduce it to existing js code in an
iterative fashion. Color me impressed!

A few questions for TS veterans:

\- With babel, we used the module-resolver plugin to set a custom root for
absolute imports. In TS, it seems relative imports (import x from
'../../../i-hate-life') are the norm, which turns ugly fast. How are folks
dealing with this? Or aren’t they?

\- Our codebase uses Ramda heavily for FP, and it can be hard to get TS to
play nicely sometimes. Any tips on how to most effectively do Ramda/FP in TS?

\- Am I missing out by not switching to VSCode? I’m using ST3 currently and it
works, but there’s no fancy intellisense. Are the benefits worth picking up a
new editor for?

1 - [https://www.envkey.com](https://www.envkey.com)

~~~
michaeldwan
The best option right now for keeping relative imports clean is using the
`paths` compiler option to create aliases. This works most of the time but in
some cases typescript won't rewrite paths in the javascript output so modules
can't be resolved at runtime, so you'll need to use webpack or another tool in
your build script to rewrite them.

See: [https://decembersoft.com/posts/say-goodbye-to-relative-
paths...](https://decembersoft.com/posts/say-goodbye-to-relative-paths-in-
typescript-imports/)

~~~
danenania
Cool, that looks like it could work for client-side code that gets run through
webpack, but what about for a node-friendly library?

~~~
frankpf
I use tsconfig's `paths` in combination with the `require-rewrite` npm module
([https://github.com/IUnknown68/require-
rewrite](https://github.com/IUnknown68/require-rewrite)).

Here's an example:

    
    
        // tsconfig.json
        ...
        "paths": {
            "#src/*": ["src/*"],
        }
        ...
    
        // package.json
        ...
        "requireRewrite": {
            "map": [
                 [
                    "#src/",
                    "dist/src/"
                 ],
            ]
        }
        ...
       
        // src/path1/x.ts
        import { X } from '#src/path2/y.ts`

------
isuckatcoding
How well does Typescript play with existing node packages? Last I checked you
need to do some work extra work (typings?) to get it working. That's the
biggest reason I've not yet switched over to typescript.

~~~
_hardwaregeek
It's not the best. I had to trawl through a bunch of documentation and filter
out old info (modules became namespaces? I think?), and try different formats
for the typings file. Tbh there should be a FAQ that is just: Help, the
compiler is complaining about a package, how do I fix it? Also, why do I need
to clone the DefinitelyTyped repo and make a PR to add a typing file? Why
can't I just make an NPM package?

These are all nitpicks in light of the amazing achievement that is
typechecking JavaScript. But I wouldn't mind a little more ergonomics for
package typing.

~~~
WorldMaker
It's hopefully getting easier. Many libraries increasingly just pack their own
definitions, which really is the best case. `npm install package` and done.

Writing a temporary definition file to just make something work is as easy as
a one-liner in most cases now (make a .d.ts file somewhere in your project and
add: `declare module 'module-name'` and/or `declare module 'module-name/*'`,
depending on how the module is supposed to be used).

> Also, why do I need to clone the DefinitelyTyped repo and make a PR to add a
> typing file? Why can't I just make an NPM package?

It is possible. DefinitelyTyped is a publishing infrastructure bottleneck for
sure. But it's a useful infrastructure bottleneck in doing somewhat minimal
gatekeeping of the `@types` namespace on NPM and keeping it from filling with
garbage. (I was a somewhat vocal critic of it before NPM @types, but I've
mellowed again on it, partly because it is shrinking slowly in some areas as
more NPM libraries adopt types directly. Some of my favorite contributions are
PRs to remove types in DT because a library added their own directly to their
NPM packages.)

Though a baked-in default in Typescript, @types is only semi-magic. The
configuration knob is called typeRoots [1]. You can't configure a recursive
search path like `@types` with it, but you can use it for experimenting with
non-DefinitelyTyped types packages. (DT itself uses typeRoots internally for
all of its testing.)

[1] [https://www.typescriptlang.org/docs/handbook/tsconfig-
json.h...](https://www.typescriptlang.org/docs/handbook/tsconfig-json.html)

------
pjmlp
Looking forward to the day that TypeScript no longer needs to compile into
JavaScript, and is natively supported by all major browsers.

A bit like Objective-C and C++ got free of their initial compilation model.

~~~
tomjen3
That would suck, because then we would be forever forced to use ancient
versions, because 2% of our customers are on Windows 95.

A much better model would be a progressive enhancement, where we can deliver
optional types that browsers can then use if they understand them. That way
there will also be a reason to upgrade for users.

------
andrewstuart
I've been waiting for TypeScript to solve the problem of param destructuring,
but surely this is not it?

Param destructuring is one of the absolute best features of ES2015. TypeScript
breaks it.

Reading this page I can't actually tell if param destructuring is even being
addressed but I can see alot of at first glance weird and obtuse looking code.

Not an obvious up front win.

~~~
johnny_reilly
Parameter destructuring works. `funcName({ param1, param2 }: { param1: number;
param2: string; }) { ... }`

------
coldtea
> _So what have we done since? What, apart from new ECMAScript features like
> the long-await-ed async /await, generators, and object rest/spread brought
> us to TypeScript 3.0?_

Wait, Typescript didn't have async/await and generators until this
release???!!!

~~~
stupidcar
They're talking about all the releases they've done since 2.0. Await/async
support was added in v2.1:
[https://github.com/Microsoft/TypeScript/wiki/Roadmap#21-dece...](https://github.com/Microsoft/TypeScript/wiki/Roadmap#21-december-2016)

------
Jedi72
I would like to thank the Javascript community for finally clearing up the
whole "JS is not Java" debacle by just throwing in the towel and becoming
Java, even if they call it Typescript now. JS sure is such a modern language,
you can tell because its always changing. Time to go build me some applets,
sorry, SPAs!

------
jhabdas
Still haven't even used Typescript. What's the draw?

~~~
bradenb
Most people that care about Typescript are JavaScript developers who desire
more structure and safety. It can't do anything that JavaScript itself can't
do. The article itself has a great description of the benefits in the first
paragraph.

~~~
jhabdas
I'm familiar with it and have used FlowType which I believe has similar
qualities. Just didn't feel worth the effort if you're building for
throwawayability. So I'm still left wondering what's the draw.

~~~
steego
If you're familiar with it, you might want to consider sharing your thoughts
on it rather having people waste their time explaining something to you that
you're already familiar with. Otherwise, your inquiry doesn't come off as
genuine.

> Just didn't feel worth the effort if you're building for throwawayability.

Now that's a legitimate point. If you're building for throwawayability, then
TypeScript and FlowType are probably not worth _your_ effort. For other
people, modeling things with types helps them move faster even for
throwawayability.

Personally, I tend to code first, use type inferencing first, and then
annotate later. However, I also tend to use a lot of reflection as well to
help me prototype things quicker. If I've found the types I've wanted after
I've explored the domain space, I'll then annotate afterward to lock them in.

As with anything, YMMV.

------
hateful
Upvoted because they mentioned Vue.

