17 ms·

Announcing TypeScript 3.0

367 points by DanRosenwasser 8y ago

plurby 8y ago
“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-and-Lars-Bak-TypeScript-JavaScript-and-Dart https://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-...
jhabdas 8y ago
Still haven't even used Typescript. What's the draw?
- bradenb 8y ago
  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 8y ago
    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.
    - albertgoeswoof 8y ago
      It’s faster to write typescript than JavaScript. Because a) you get properties and type definitions popping up in your text editor as you write code and b) you eliminate a tonne of run time bugs There’s basically no extra effort to using typescript if you already have a build pipeline running. It’s not like using Java or Haskell where you’re drowning in type definitions.
    - aoeusnth1 8y ago
      Are you aware that some people build projects with JavaScript that aren't intended to be thrown away quickly? TypeScript makes writing frontends easier and it makes writing Node-JS apps easier. It makes it easier to both read and write code.
    - coldtea 8y ago
      The draw is for people who aren't building for "throwawayability"...
    - steego 8y ago
      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.
- roryisok 8y ago
  Static typing, compile time type checking. Those are the big ones.
  - DCoder 8y ago
    Worth noting that this is not just for your actual code. You can also typecheck (and, just as importantly, refactor) JSX-based views like React's. You can't do that on stringly-typed templates like jQuery.tmpl, Knockout templates, or similar. If you've ever had to debug a misbehaving Knockout template just to find it was referencing a misspelled object property, you can appreciate how much cleaner TSX templating is.
ComputerGuru 8y ago
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.
- always_good 8y ago
  FWIW, the Redditism of pointing out that you're not in fact a die-hard supporter of something doesn't make your praise any stronger. It always feels like cheap rhetoric since you can prefix anything you say about anything with that, as many people do.
  - sremani 8y ago
    The only thing that feels cheap here is your unnecessary contextual annotation without adding any proper value.
- GordonS 8y ago
  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 8y ago
    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.
Legogris 8y ago
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
fabian2k 8y ago
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 8y ago
  This is a great update! It often feels impossible to decipher the wall-of-text error messages in TypeScript.
bradenb 8y ago
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.
coldtea 8y ago
>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???!!!
- GordonS 8y ago
  It most certainly did, I've been using async/await in Typescript for well over a year. From memory, it arrived in something like v2.2?
- stupidcar 8y ago
  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-december-2016 https://github.com/Microsoft/TypeScript/wiki/Roadmap#21-dece...
- TomMarius 8y ago
  These are JavaScript features, they're saying "what we've done apart from adding support for this"
isuckatcoding 8y ago
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.
- nicoburns 8y ago
  It has support for external type definitions, which can be installed from NPM like any other package. These are only necessary for packages which don't support typescript themselves. But it can definitely be an issue for smaller, less well supported packages where you can be left with a choice of writing type definitions yourself or turning off type safety for that library (using the `any` type).
  - stupidcar 8y ago
    I don't see that as much of an issue though. You wouldn't get any type-checking if you weren't using TypeScript, so it's still a net gain even if a few packages are `any`.
- kageneko 8y ago
  A lot of packages have types built into them. Others have types available in "@types/<package>". For everything else, I create a "types.d.ts" file that just has a bunch of stuff like: declare module 'twilio'; declare module 'bitly'; declare module 'cloudinary'; declare module 'tmp-promise'; declare module 'dialogflow'; declare module 'fuel-rest'; And then those modules get set to the "any" type.
- udp 8y ago
  You can use any regular JS library from typescript. You just won't get type checking in calls to it.
- minimidge 8y ago
  That's true, but typings exist for most of the common packages: npm i express @types/express It usually "just works", but it really depends on how obscure the packages you're using are. 4,720 type definition files at the moment: https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types https://github.com/DefinitelyTyped/DefinitelyTyped/tree/mast...
euroclydon 8y ago
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/lib.d.ts.html#polyfill-for-old-javascript-engines https://basarat.gitbooks.io/typescript/content/docs/types/li... More on Target: https://basarat.gitbooks.io/typescript/content/docs/types/lib.d.ts.html#compiler-target-effect-on-libdts https://basarat.gitbooks.io/typescript/content/docs/types/li...
- recursive 8y ago
  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 8y ago
    Specifically, TS has polyfills for language features (eg iterators), not library features (eg `Array.prototype[Symbol.iterator]`).
    - johnny_reilly 8y ago
      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.
  - deleted 8y ago
    [deleted]
- 8y ago
danenania 8y ago
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
- jhasse 8y ago
  > Am I missing out by not switching to VSCode? I would say yes! VSCode also has many other things to offer over ST3 besides IntelliSense btw.
  - danenania 8y ago
    Yeah? Would you mind giving a quick overview?
    - jhasse 8y ago
      The biggest three advantages I can think of right now: * Git integration: You can directly edit in diffs, commit from the sidebar, see your submodules and commit in them, ... * Integrated terminal which can also run tasks, so colors and input will work * Much better debugging support (AFAIK ST3 has none out-of-the-box) It's been a while since I've seriously used Sublime Text though.
      - noir_lord 8y ago
sbjs 8y ago
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.
- maxwell 8y ago
  Their strategy seems focused on increasing Azure market share.
  - sbjs 8y ago
    Oh! Duh! How could I have forgotten Azure! Yes, that's definitely where all this is headed. They could be trying to position TypeScript as a secret weapon that gives Azure an edge over AWS. Especially if they're planning on using the type information, once it's universally near-100%, to build a blazingly fast platform using a new compiler and runtime that make use of TypeScript's unique features suited toward compiler optimizations. Especially considering Hejlsberg is behind TypeScript (see my other comment in this thread).
  - SpaceGorilla 8y ago
    This seems like the most logical. Growing azure meant MS had to pivot. They finally embraced Linux/open source because without them azure would be doomed. I really hope they continue doing so and it's not just an attempt to take over a market then lock it down how they want. What's the term? Embrace, take over, discontinue?
pjmlp 8y ago
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.
- sridca 8y ago
  Yup, with https://webassembly.org/ https://webassembly.org/ Not only TypeScript, one day we would be able to compile Haskell as well: https://github.com/WebGHC https://github.com/WebGHC
- tomjen3 8y ago
  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.
- plexicle 8y ago
  As much as I love the idea of letting the browser do some crazy optimization with native types -- I don't think it will ever happen. Or perhaps maybe it shouldn't happen. The only reason TS is able to iterate so quickly is because of the compilation cycle. Without it, progress forward would probably come to a screeching halt.
mcraiha 8y ago
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?
- vbezhenar 8y ago
  Very clear for me. What's horrible about it?
- baq 8y ago
  Any notation you're not familiar with looks horrible.
- brainzap 8y ago
  yes it seems a bit much at first glance, I hope the learning curve for beginners is not too steep.
- tomjen3 8y ago
  It should be formatted better, but other than that, I don't see the problem; yes it is hard to parse, but that is because a lot is going on.
- dested 8y ago
  I imagine most code bases will contain a very small number (probably zero) type definitions with a spread tuple type. There are only so many ways to solve being type safe in a language that is so permissive, and sometimes it causes the result to look ugly. Ideally 95% of end users will never need to type this, only rely on it.
- brlewis 8y ago
  "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 8y ago
hateful 8y ago
Upvoted because they mentioned Vue.
Slackwise 8y ago
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?
- samirm 8y ago
  It's popular because OOP is the only thing most people know and understand better than any other paradigm and has been a staple of "reliable software" in big business.
  - joshuacc 8y ago
    TypeScript supports both FP and OOP styles of programming. And it doesn't add any new OOP features on top of JavaScript.
    - andyfleming 8y ago
      One might argue that interfaces are an OOP feature that TypeScript adds. That said, you aren't forced to use them.
      - steve_adams_86 8y ago
        Interfaces are excellent for defining structures in both FP and OOP paradigms in my opinion. They simply describe the shape of data. This is useful in most situations I can think of at compile time.
- brlewis 8y ago
  There are various options for trading away backward compatibility to gain protection from the usual JS pitfalls. Search for "strict" on https://www.typescriptlang.org/docs/handbook/compiler-options.html https://www.typescriptlang.org/docs/handbook/compiler-option...
andrewstuart 8y ago
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.
- wereHamster 8y ago
  Can you give an example?
- johnny_reilly 8y ago
  Parameter destructuring works. `funcName({ param1, param2 }: { param1: number; param2: string; }) { ... }`
- joshuacc 8y ago
  What problem? TypeScript has supported param destructuring for a while.
ggregoire 8y ago
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.
- sbjs 8y ago
  I tried Flow and TypeScript for the first time a few months ago. Flow is absolutely abandoned and dying. TypeScript is taking over where Flow left off, and is far ahead of the game by now. I use TypeScript with create-react-app in my client work and it is invaluable and a wonderful experience, with no downsides as far as I can see.
- plexicle 8y ago
  Honestly they're not even close. TS has been eating Flow's lunch pretty much all year. It won't be long now.
- mikewhy 8y ago
  Once I heard about ReasonML I figured that was the end of Flow. And re: create-react-app, have you tried react-scripts-ts? I've been using it all year with no real issues.
- flanbiscuit 8y ago
  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/
polskibus 8y ago
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 8y ago
  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
- ryanworl 8y ago
  Literally every release I check the notes, the roadmap, and the nearly 4 year old issue filed for runtime type information and every release I am disappointed. All the TypeScript dependency injection libraries rely on decorators or something else requiring modifying the classes being injected. It makes the code look terrible and this is really my only complaint about TypeScript which is otherwise fantastic. I basically only do DI by hand because of it.
- steve_adams_86 8y ago
  I use ajv's schema-based validation at all entry points to my application (user input from forms, urls, whatever comes back from an API, etc) and find I can very safely assume all data after that point is totally safe, so I'm using TypeScript to ensure _I'm_ not doing anything stupid. Hopefully that makes sense. Runtime type checking would be neat for sure, but I'm mostly worried about the dumb things I'll do. It's not too hard to strictly and cleanly validate foreign data at runtime, but it's historically very easy to shoot yourself in the foot with JavaScript. So I'm very happy.
Jedi72 8y ago
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!

“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-and-Lars-Bak-TypeScript-JavaScript-and-Dart https://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-...

jhabdas 8y ago

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

bradenb 8y ago
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 8y ago
  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.
  - albertgoeswoof 8y ago
    It’s faster to write typescript than JavaScript. Because a) you get properties and type definitions popping up in your text editor as you write code and b) you eliminate a tonne of run time bugs There’s basically no extra effort to using typescript if you already have a build pipeline running. It’s not like using Java or Haskell where you’re drowning in type definitions.
  - aoeusnth1 8y ago
    Are you aware that some people build projects with JavaScript that aren't intended to be thrown away quickly? TypeScript makes writing frontends easier and it makes writing Node-JS apps easier. It makes it easier to both read and write code.
  - coldtea 8y ago
    The draw is for people who aren't building for "throwawayability"...
  - steego 8y ago
    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.
roryisok 8y ago
Static typing, compile time type checking. Those are the big ones.
- DCoder 8y ago
  Worth noting that this is not just for your actual code. You can also typecheck (and, just as importantly, refactor) JSX-based views like React's. You can't do that on stringly-typed templates like jQuery.tmpl, Knockout templates, or similar. If you've ever had to debug a misbehaving Knockout template just to find it was referencing a misspelled object property, you can appreciate how much cleaner TSX templating is.

ComputerGuru 8y ago

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.

always_good 8y ago
FWIW, the Redditism of pointing out that you're not in fact a die-hard supporter of something doesn't make your praise any stronger. It always feels like cheap rhetoric since you can prefix anything you say about anything with that, as many people do.
- sremani 8y ago
  The only thing that feels cheap here is your unnecessary contextual annotation without adding any proper value.
GordonS 8y ago
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 8y ago
  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.

Legogris 8y ago

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

fabian2k 8y ago

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 8y ago
This is a great update! It often feels impossible to decipher the wall-of-text error messages in TypeScript.

bradenb 8y ago

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.

coldtea 8y ago

>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???!!!

GordonS 8y ago
It most certainly did, I've been using async/await in Typescript for well over a year. From memory, it arrived in something like v2.2?
stupidcar 8y ago
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-december-2016 https://github.com/Microsoft/TypeScript/wiki/Roadmap#21-dece...
TomMarius 8y ago
These are JavaScript features, they're saying "what we've done apart from adding support for this"

isuckatcoding 8y ago

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.

nicoburns 8y ago
It has support for external type definitions, which can be installed from NPM like any other package. These are only necessary for packages which don't support typescript themselves. But it can definitely be an issue for smaller, less well supported packages where you can be left with a choice of writing type definitions yourself or turning off type safety for that library (using the `any` type).
- stupidcar 8y ago
  I don't see that as much of an issue though. You wouldn't get any type-checking if you weren't using TypeScript, so it's still a net gain even if a few packages are `any`.
kageneko 8y ago
A lot of packages have types built into them. Others have types available in "@types/<package>". For everything else, I create a "types.d.ts" file that just has a bunch of stuff like: declare module 'twilio'; declare module 'bitly'; declare module 'cloudinary'; declare module 'tmp-promise'; declare module 'dialogflow'; declare module 'fuel-rest'; And then those modules get set to the "any" type.
udp 8y ago
You can use any regular JS library from typescript. You just won't get type checking in calls to it.
minimidge 8y ago
That's true, but typings exist for most of the common packages: npm i express @types/express It usually "just works", but it really depends on how obscure the packages you're using are. 4,720 type definition files at the moment: https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types https://github.com/DefinitelyTyped/DefinitelyTyped/tree/mast...

euroclydon 8y ago

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/lib.d.ts.html#polyfill-for-old-javascript-engines https://basarat.gitbooks.io/typescript/content/docs/types/li... More on Target: https://basarat.gitbooks.io/typescript/content/docs/types/lib.d.ts.html#compiler-target-effect-on-libdts https://basarat.gitbooks.io/typescript/content/docs/types/li...

recursive 8y ago
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 8y ago
  Specifically, TS has polyfills for language features (eg iterators), not library features (eg `Array.prototype[Symbol.iterator]`).
  - johnny_reilly 8y ago
    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.
- deleted 8y ago
  [deleted]
8y ago

danenania 8y ago

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

jhasse 8y ago
> Am I missing out by not switching to VSCode? I would say yes! VSCode also has many other things to offer over ST3 besides IntelliSense btw.
- danenania 8y ago
  Yeah? Would you mind giving a quick overview?
  - jhasse 8y ago
    The biggest three advantages I can think of right now: * Git integration: You can directly edit in diffs, commit from the sidebar, see your submodules and commit in them, ... * Integrated terminal which can also run tasks, so colors and input will work * Much better debugging support (AFAIK ST3 has none out-of-the-box) It's been a while since I've seriously used Sublime Text though.
    - noir_lord 8y ago

sbjs 8y ago

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.

maxwell 8y ago
Their strategy seems focused on increasing Azure market share.
- sbjs 8y ago
  Oh! Duh! How could I have forgotten Azure! Yes, that's definitely where all this is headed. They could be trying to position TypeScript as a secret weapon that gives Azure an edge over AWS. Especially if they're planning on using the type information, once it's universally near-100%, to build a blazingly fast platform using a new compiler and runtime that make use of TypeScript's unique features suited toward compiler optimizations. Especially considering Hejlsberg is behind TypeScript (see my other comment in this thread).
- SpaceGorilla 8y ago
  This seems like the most logical. Growing azure meant MS had to pivot. They finally embraced Linux/open source because without them azure would be doomed. I really hope they continue doing so and it's not just an attempt to take over a market then lock it down how they want. What's the term? Embrace, take over, discontinue?

pjmlp 8y ago

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.

sridca 8y ago
Yup, with https://webassembly.org/ https://webassembly.org/ Not only TypeScript, one day we would be able to compile Haskell as well: https://github.com/WebGHC https://github.com/WebGHC
tomjen3 8y ago
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.
plexicle 8y ago
As much as I love the idea of letting the browser do some crazy optimization with native types -- I don't think it will ever happen. Or perhaps maybe it shouldn't happen. The only reason TS is able to iterate so quickly is because of the compilation cycle. Without it, progress forward would probably come to a screeching halt.

mcraiha 8y ago

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?

vbezhenar 8y ago
Very clear for me. What's horrible about it?
baq 8y ago
Any notation you're not familiar with looks horrible.
brainzap 8y ago
yes it seems a bit much at first glance, I hope the learning curve for beginners is not too steep.
tomjen3 8y ago
It should be formatted better, but other than that, I don't see the problem; yes it is hard to parse, but that is because a lot is going on.
dested 8y ago
I imagine most code bases will contain a very small number (probably zero) type definitions with a spread tuple type. There are only so many ways to solve being type safe in a language that is so permissive, and sometimes it causes the result to look ugly. Ideally 95% of end users will never need to type this, only rely on it.
brlewis 8y ago
"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 8y ago

hateful 8y ago

Upvoted because they mentioned Vue.

Slackwise 8y ago

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?

samirm 8y ago
It's popular because OOP is the only thing most people know and understand better than any other paradigm and has been a staple of "reliable software" in big business.
- joshuacc 8y ago
  TypeScript supports both FP and OOP styles of programming. And it doesn't add any new OOP features on top of JavaScript.
  - andyfleming 8y ago
    One might argue that interfaces are an OOP feature that TypeScript adds. That said, you aren't forced to use them.
    - steve_adams_86 8y ago
      Interfaces are excellent for defining structures in both FP and OOP paradigms in my opinion. They simply describe the shape of data. This is useful in most situations I can think of at compile time.
brlewis 8y ago
There are various options for trading away backward compatibility to gain protection from the usual JS pitfalls. Search for "strict" on https://www.typescriptlang.org/docs/handbook/compiler-options.html https://www.typescriptlang.org/docs/handbook/compiler-option...

andrewstuart 8y ago

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.

wereHamster 8y ago
Can you give an example?
johnny_reilly 8y ago
Parameter destructuring works. `funcName({ param1, param2 }: { param1: number; param2: string; }) { ... }`
joshuacc 8y ago
What problem? TypeScript has supported param destructuring for a while.

ggregoire 8y ago

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.

sbjs 8y ago
I tried Flow and TypeScript for the first time a few months ago. Flow is absolutely abandoned and dying. TypeScript is taking over where Flow left off, and is far ahead of the game by now. I use TypeScript with create-react-app in my client work and it is invaluable and a wonderful experience, with no downsides as far as I can see.
plexicle 8y ago
Honestly they're not even close. TS has been eating Flow's lunch pretty much all year. It won't be long now.
mikewhy 8y ago
Once I heard about ReasonML I figured that was the end of Flow. And re: create-react-app, have you tried react-scripts-ts? I've been using it all year with no real issues.
flanbiscuit 8y ago
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/

polskibus 8y ago

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 8y ago
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
ryanworl 8y ago
Literally every release I check the notes, the roadmap, and the nearly 4 year old issue filed for runtime type information and every release I am disappointed. All the TypeScript dependency injection libraries rely on decorators or something else requiring modifying the classes being injected. It makes the code look terrible and this is really my only complaint about TypeScript which is otherwise fantastic. I basically only do DI by hand because of it.
steve_adams_86 8y ago
I use ajv's schema-based validation at all entry points to my application (user input from forms, urls, whatever comes back from an API, etc) and find I can very safely assume all data after that point is totally safe, so I'm using TypeScript to ensure _I'm_ not doing anything stupid. Hopefully that makes sense. Runtime type checking would be neat for sure, but I'm mostly worried about the dumb things I'll do. It's not too hard to strictly and cleanly validate foreign data at runtime, but it's historically very easy to shoot yourself in the foot with JavaScript. So I'm very happy.

Jedi72 8y ago

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!