11 ms·

TypeScript Won

121 points by SanderMak 10y ago

hiou 10y ago
If you like typescript so much you might as well stop pretending you write JavaScript and just write in C# like you really want to. http://bridge.net http://bridge.net If typescript was simply type safety that would be one thing. It's definitely a lot, lot more than that. Typescript is to .NET as Coffeescript was to Ruby. A bunch of developers who didn't know JavaScript and wanted to find the closest thing they could to what they already knew. And who really uses Coffeescript anymore? Stick with esnext to babel and the bright future JavaScript has ahead.
- coroutines 10y ago
  I say again: Javascript can learn many things more from Coffeescript. Coffeescript's future is diminished, presently (hah) - but ES6 only picked up a handful of magical features.
coroutines 10y ago
TypeScript "won" because certain folks will happily trade some coherency for more complexity. Types (can) be helpful.
antjanus 10y ago
One thing that makes a huge difference is the plugin ecosystem. TypeScript, as far as I know, doesn't have any while Babel has a whole myriad of them by various people. I recently built a Babel plugin that solves a lot of my module import pathing issues (namely the `../../` hell) https://github.com/AntJanus/babel-plugin-namespaces https://github.com/AntJanus/babel-plugin-namespaces This and other plugins are just not possible on TS. The best way to look at Babel vs TypeScript is to realize they do different things. As far as Babel ES2015 transpiling vs TypeScript, maybe TS wins out. But Babel is a whole platform for transpiling. In fact, you can use both Babel and TypeScript together!
gcb0 10y ago
... won the disposable syntax sugar of the month. next month people will want memory protection in JavaScript and JavaScript developers being JavaScript developers will create a new project from scratch with new syntax, just like Babel did from coffee and like typescript did from Babel. meh. this is all needed because you have a team that doesn't know how to agree on coding style or something. yes, it would be nice to have type errors detected before runtime. but we have responsive devs so we never had those errors to begin with. and we're way past 80k lines. adding a transpiler would be more annoying than helpful.
- woah 10y ago
  Babel is a program which compiles a newer version of JS into an older version, so that you can use the new version on platforms that don't support it yet. I can't tell if you're aware of what it is.
koolba 10y ago
Does anyone here have bad things to say about TypeScript? I haven't used it for any large projects yet (couple toy ones) but seems pretty legit. Based on my anecdata, people who have used it at scale seems to like it. I can't tell if that's because they're still in the honeymoon phase or if it really is a step forward for the long term.
- akavi 10y ago
  The ability to programmatically generate methods/classes can be really powerful and, as far as I can tell, impossible with Typescript (and most statically typed languages). Back in my Backbone + CoffeeScript days, I reimplemented Rails style has_many/belongs_to "class methods" on Backbone.Model, and it was incredibly useful. But would've been doubly so if I could have had it statically checked somehow.
  - mordocai 10y ago
    I don't know if it is possible in any practically used statically typed languages, but I can think of nothing that would prevent you from doing metaprogramming in a statically typed language on a theoretical basis. It might be a bit hard to implement, but I think it should be perfectly possible.
- saosebastiao 10y ago
  In terms of Javascript targeting languages, Typescript has been the only one that hasn't made me want to murder a thousand baby seals. The build system is fast and easily understood, the typing makes refactoring so much easier, and in probably its biggest win, I can read a Javascript tutorial and trivially write the same thing in Typescript. As a language, though, it still leaves a lot to be desired. Things like type guards and null annotations are like the methadone to the vastly more addictive pattern matching and options that I can no longer live without, and promises/callbacks are vastly inferior to futures. I would rather use Scala.js or Elm, but the ecosystems pale in comparison and trying to work in what is effectively an abstraction layer (and leaky at that) makes life really difficult. So I stick with Typescript.
superskierpat 10y ago
On the topic of typescript vs purescript and similar projects, I believe these projects are more for people who want to stay in the same mindset across the whole stack. So haskell with ghjs or purescript and scala with scalajs... I dont think they are really in competition with typescript.
- benjaminjackman 10y ago
  This reflects my use case. I was just writing Scala code that compiles to both the JVM and JS. The requirements for the code in terms of performance for the JVM side are very intense which ruled out using Typescript there. I am using the browser for visualizations / UI where I have used Typescript in the past, between using Vanilla Javascript and then Coffeescript and before Scala.js was available. I continue to watch Typescript because I think it has its place and certainly is worth knowing / using in certain projects. I really appreciate the .d.ts/DefinitelyTyped (files which provide Typescript static types for javascript libraries) that are available, I am able to mostly convert them to ScalaJS facades programatically which gives me nice code complete in ScalaJS. One area I think Typescript outshines ScalaJS is if you have a large existing Javascript codebase, or are a Javascript programmer looking to incrementally improve your codebase / language knowledge Typescript is the best step in that direction. However if you are going `full stack`, with high performance requirements on one side, and a browser on the other, right now I think Scala is the best option. That opinion might change in the future with web-assembly (then perhaps back again e.g. scala.native ).
gkilmain 10y ago
What have they won? Why all of the f'ing if you choose A you're awesome if you choose B you've lost? Articles like this give me anxiety.
- sbarre 10y ago
  "Won" may be click-bait a little bit here, but I think the overall message is that if you are starting from scratch and deciding on which toolchain or approach to pick from, Typescript may be your best choice (but obviously not the only choice, since you may have specific requirements that affect this generic recommendation).
- corysama 10y ago
  The article presents measurements indicating that Typescript has won greater mindshare compared to similar JavaScript transpilers.
  - gkilmain 10y ago
    TypeScript is a transpiler + type checker. If you just need a transpiler the author makes no recommendation between Babel and TypeScript
shrugger 10y ago
I love the piegonhole arguments that always 'exclude' Dart from these types of discussions. Class-based vs prototype-based, classes will always win. JS is terrible, TypeScript is only very slightly better. Dart's core team is absolutely world class, and the language is already highly capable.
- nathancahill 10y ago
  JS has classes.
  - shrugger 10y ago
    JS has a syntactic sugar keyword class. Objects are still prototypes.
deforciant 10y ago
javascript and "win" must not be in the same sentence
- bazqux2 10y ago
  except that one
jwineman 10y ago
Interesting he omits Flow from his very carefully chosen "Typescript won" arguments.
- shrugger 10y ago
  I didn't even think about that, but yeah he totally did. This whole article has a very "Wow, all other languages except for the one I've invested time in really suck!" feel to it. The arguments presented are shallow at best, rely on short-term data, mostly just popular trends of what people are talking about/searching for. There's not any empirical evidence that I've seen in this article that suggests any language is better than any other language.
- spankalee 10y ago
  Does anyone actually use Flow? I see TypeScript all over the place.
  - k__ 10y ago
    I do, in production. But yeah, it seems Flow needs more marketing. TypeScript seems to be rather big for MS. But FB mostly pumps money in Babel and React at the moment...
- spion 10y ago
  Last time I checked, its not available on Windows. That automatically limits its market.
JustSomeNobody 10y ago
I hate these stupid "X Won" posts.
knowtheory 10y ago
I could quibble with the conflation of correlation w/ causation for a lot of the comments this post makes about es6/babel or coffeescript. But each time i re-read this post, the cohesive point that pops out most is that this post is basically a Donald Trump speech about Typescript. The claim is that it's bigger, it's better, and everyone else is a bit sad. It disingenuously claims that it's not about about competition and then literally ends with "Typescript Won". So, lemme offer some rhetorical advice: 1) pick to a POV & stick to it. It's a competition or it's not. You either think it's worth highlighting how much better Typescript is over other technologies, or you don't. 2) Most of the points made in the post aren't assertions about the benefits of Typescript or the decisions it makes. Not everyone agrees that the existence of a static type checker is an unqualified benefit (and there are many dimensions to that conversation). If you want to make the assertion that Typescript makes your life easier/better because it has a type checker, assert the benefits of having a type checker (and the decision making for AngularJS's adoption of Typescript on the basis of having a type checker could use a citation). 3) Related to 1., this post comes off as MEGA passive-aggressive because you keep on mentioning how much you also love other technologies at the same time talking about how they are inferior to Typescript on a variety of shifting bases. Because of that you're not telling a cohesive story about Typescript. You're just talking about how you think other technologies are bad.
- mordocai 10y ago
  On point 2, I don't think an optional type checker has any real downsides that I can think of (optional because with typescript you don't have to add type annotations to your code). It helps with debugging and possibly performance but you can choose not to use it. The rest of your comment I agree with.
  - doodpants 10y ago
    I have no experience with TypeScript, but in general the downside of optional language features is when you're working with a team, and different people end up using different dialects of the language.
yesimahuman 10y ago
No need to say TypeScript "won," we're all pushing JS forward and TS is just another tool in the toolbox. However, I'm glad to see it doing well especially since it felt like a big risk for us at Ionic to pick TypeScript (along with ng2). I've been happy with how positively received TS has been, which has been a bit of a surprise to me, honestly.
symlinkk 10y ago
I bet we'll be seeing a lot more of Typescript in the next few years, seeing as it's the default language that is suggested in Angular 2's documentation. I find it odd that Dart wasn't the default language of choice for Angular 2 (although it is fully supported) seeing as Google is behind both projects. I think it really boils down to what the author wrote here: "Dart is not JavaScript. TypeScript is." At the end of the day more people are going to want to use what they are already more familiar with, and it's really not necessary to throw out years and years of progress we have made on JS.
- pjmlp 10y ago
  For me it was a clear message to the outside world, how little backing Dart has inside Google, if their management allows for choosing a programming language designed by the competition instead of their own one, for their own products.
  - LukeB_UK 10y ago
    Or it shows that they see that there's already an established base of people using TypeScript, more than Dart, and choosing to follow where the community exists. Throughout the development of Angular 2 the team also talked with the developers of other frameworks, libraries and tools, which shows that they believe in the community more than trying to push their own agenda.
  - spankalee 10y ago
    You saw "allowed" like it's a bad or unusual thing. Allowing is the way Google works.
tptacek 10y ago
Is Typescript/Babel an either/or choice? ES6 is non-negotiable. I understand the basic premise behind Typescript. Would I "switch" from Babel to Typescript and get arrow functions and string interpolation through Typescript somehow?
- eloisant 10y ago
  Yes, because Typescripts is 2 things: * A language, superset of ES6 that adds optional types * A compiler (like Babel) that will take your Typescript code, check if the types are correct, remove them, and transpile the non-ES5 parts of into ES5 (just like Babel). So if you want to use Typescript-the-langage, you need Typescript-the-compiler and you will no longer need Babel.
  - thejameskyle 10y ago
    Many people choose to use both. TypeScript for type-checking and stripping types, and Babel for compiling down ES2015 code. Babel follows the spec for that much closer than TypeScript does and has hundreds of plugins that allow you to do even more.
- Keats 10y ago
  You can use both, I do TS -> Babel to get hot reload in react (if you know a way to do that without Babel, please let me know). If you don't care about that, it's pretty much the same except async/await are not there yet. In Babel you could also use ESX features before any kind of approval while TypeScript only implements features approved (afaik).
drinchev 10y ago
Wow this is such a strong title. There's no winning. Use the right tool for the right job. Although every big project I take these days I prefer to write in TypeScript, I would honestly not use it if I have a small static landing page with an AJAX ticker or something. It would be overkill.
davidhyde 10y ago
TypeScript on JavaScript is like c# on CIL (.net common intermediate language). You are free to modernize the language as much as you want without breaking backwards compatibility. Not surprising Anders Hejlsberg is heavily involved in both. Great language.
PSeitz 10y ago
Once ES6 is widely supported, and a transpiler is not necessary anymore, people will switch to pure ES6.
intrasight 10y ago
JavaScript as an intermediate language is a fail, therefore TypeScript is a fail.
LukeB_UK 10y ago
I think the end result is actually that JavaScript wins. If it turns out that a lot of people think that JavaScript needs a type system, one will be proposed and rolled into the language.
draw_down 10y ago
I'll keep writing in the language it compiles down to. Which would be JavaScript, of course. But keep telling yourselves that if you must...
thejameskyle 10y ago
It's frustrating that the only reason thats really given for TypeScript being "better" than Babel is that it has more downloads, using incorrect charts to prove it. Here's the actual download charts if you are interested: https://twitter.com/thejameskyle/status/725344218411986946 https://twitter.com/thejameskyle/status/725344218411986946 Source: - babel-core: http://npm-stat.com/charts.html?package=babel-core&author=&from=2015-04-28&to=2016-04-27 http://npm-stat.com/charts.html?package=babel-core&author=&f... - typescript: http://npm-stat.com/charts.html?package=typescript&author=&from=2015-04-28&to=2016-04-27 http://npm-stat.com/charts.html?package=typescript&author=&f... Also if you want types with Babel, use Flow– which is arguably a much better type system anyways.
- avolcano 10y ago
  fwiw, TypeScript -> Babel is doable, if painful. I have it set up in my repo here: https://github.com/thomasboyt/manygolf https://github.com/thomasboyt/manygolf I agree that Flow currently the superior type system (and, unlike TypeScript, not a complete nightmare to set up if you're wanting to use Babel/Webpack instead of manually running file builds through your editor like it's 2002), but TypeScript has significantly more momentum behind it making it a much more practical solution for basically anyone who doesn't currently work at Facebook. There are also several exciting new features coming to the type system that brings it closer to parity with Flow: Non-nullable types: https://github.com/Microsoft/TypeScript/pull/7140 https://github.com/Microsoft/TypeScript/pull/7140 Control flow type analysis: https://github.com/Microsoft/TypeScript/pull/8010 https://github.com/Microsoft/TypeScript/pull/8010 I wish TypeScript tried to better-integrate with the greater JavaScript ecosystem and stop acting as a language of its own. Thankfully, the "es6" target gets it pretty close (I think it still compiles some es7 features, meaning you can't have Babel handle everything yet), and the non-standard module syntax seems to be a thing of the past. I hope the gap can be bridged between the TypeScript and Babel communities, so that TypeScript can one day be shipped as a Babel transform, same as Flow.
  - thejameskyle 10y ago
    There's not really a gap between them. I've spoken to people on the TypeScript team a number of times. Jonathan Turner and I talked about sharing ASTs once, and I gave an internal presentation about Babel at Microsoft last year. Also, there's tons of people that use TypeScript for type-checking and stripping types and then use Babel for compiling down ES2015 code since Babel follows the spec closer.
rhinoceraptor 10y ago
Or it could be that Babel downloads are declining because it's becoming less necessary as Node and the major browsers implement ES6. The whole point of Babel is to be a stopgap, so it's not surprising that its usage is declining. Babel is not a language.
noahlt 10y ago
What about Flow?
quangv 10y ago
Doesn't matter, it maybe more popular, but it no one died. http://zenoverflow.com/2016/04/27/platform-of-the-browser/ http://zenoverflow.com/2016/04/27/platform-of-the-browser/ - my response to TypeScript Winning
Touche 10y ago
Weird comparisons. People who like Elm aren't going to switch to TypeScript because it's more popular. They are fundamental disagreements that can't be dismissed with a Google Trend chart. TypeScript is currently popular but popularity in JavaScript never last long. The cycle is: * A library that comes out that solves a problem with the previous iteration. * The new popular library has some different problem but people ignore it because the new cool thing is still fresh in their minds. * People become annoyed with the popular library and someone makes a new library that fixes the problem with the popular library. It looks a lot like the original library that popular library replaced. * Cycle repeats itself.
- nathancahill 10y ago
  The difference is that Typescript isn't someone's side project where they accidentally typed `npm publish` when they should have typed `rm -r ./` It's backed by M$ and the Github repo is super active, especially in langauge proposals. This will be around for a while.
  - Touche 10y ago
    Sure and Traceur was backed by Google but that didn't stop it from losing the hype train to Babel (which was someone's side project). The JavaScript hype cycle has no escape hatch. All that go up, must come down. Some things just last a little longer than others.
    - nathancahill 10y ago
      > Backed by Google Exactly the problem. Like all other Google projects, they bailed on it.
      - Touche 10y ago
        No they didn't, it's still under active development, last release 4 days ago. Ditto for Closure which is actively developed (and is among the best libraries in ES6 features) but also lost the hype cycle to Uglify.
untog 10y ago
Choosing a winner based on Google Trends? Hmm. Pointing out that CoffeeScript is on the decline because Google Trends for it once peaked and has since declined? Hmm. Failing to consider that TypeScript might be at a similar peak and is due a similar decline? Hmm.
- nathancahill 10y ago
  Posting pointless comments? Hmm.
  - untog 10y ago
    What exactly is pointless about what I said? The article presents no good data to back up its assertion, and even raises a potential issue then doesn't address it.
kowdermeister 10y ago
If I absolutely must choose a "winner" (what does that even mean?) then I would give the golden medal to the one that has a standard behind it. I think it's a very pointless thing to pick a winner. It's not a popularity contest. You will be able to tell that some technology is "lost" or is over, when the popularity will be declined to the 0.0.1 alpha release state.
- nathancahill 10y ago
  The standard doesn't keep up fast enough with the pace of development in the JS ecosystem. That's why Babel's plugin architecture is so great. It allows super fast paced experimentation with new language features, without having to get buy-in from browser vendors or even JS family languages.
  - kowdermeister 10y ago
    That's true and experimentation is good thing, just look at CoffeeScript, although I never liked it. However I always bet on technologies that are standardized rather than maintained by a company. Not a fail safe approach, I know, but that's the way I minimize risk.

121 points by SanderMak 10y ago

hiou 10y ago

If you like typescript so much you might as well stop pretending you write JavaScript and just write in C# like you really want to. http://bridge.net http://bridge.net If typescript was simply type safety that would be one thing. It's definitely a lot, lot more than that. Typescript is to .NET as Coffeescript was to Ruby. A bunch of developers who didn't know JavaScript and wanted to find the closest thing they could to what they already knew. And who really uses Coffeescript anymore? Stick with esnext to babel and the bright future JavaScript has ahead.

coroutines 10y ago
I say again: Javascript can learn many things more from Coffeescript. Coffeescript's future is diminished, presently (hah) - but ES6 only picked up a handful of magical features.

coroutines 10y ago

TypeScript "won" because certain folks will happily trade some coherency for more complexity. Types (can) be helpful.

antjanus 10y ago

One thing that makes a huge difference is the plugin ecosystem. TypeScript, as far as I know, doesn't have any while Babel has a whole myriad of them by various people. I recently built a Babel plugin that solves a lot of my module import pathing issues (namely the `../../` hell) https://github.com/AntJanus/babel-plugin-namespaces https://github.com/AntJanus/babel-plugin-namespaces This and other plugins are just not possible on TS. The best way to look at Babel vs TypeScript is to realize they do different things. As far as Babel ES2015 transpiling vs TypeScript, maybe TS wins out. But Babel is a whole platform for transpiling. In fact, you can use both Babel and TypeScript together!

gcb0 10y ago

... won the disposable syntax sugar of the month. next month people will want memory protection in JavaScript and JavaScript developers being JavaScript developers will create a new project from scratch with new syntax, just like Babel did from coffee and like typescript did from Babel. meh. this is all needed because you have a team that doesn't know how to agree on coding style or something. yes, it would be nice to have type errors detected before runtime. but we have responsive devs so we never had those errors to begin with. and we're way past 80k lines. adding a transpiler would be more annoying than helpful.

woah 10y ago
Babel is a program which compiles a newer version of JS into an older version, so that you can use the new version on platforms that don't support it yet. I can't tell if you're aware of what it is.

koolba 10y ago

Does anyone here have bad things to say about TypeScript? I haven't used it for any large projects yet (couple toy ones) but seems pretty legit. Based on my anecdata, people who have used it at scale seems to like it. I can't tell if that's because they're still in the honeymoon phase or if it really is a step forward for the long term.

akavi 10y ago
The ability to programmatically generate methods/classes can be really powerful and, as far as I can tell, impossible with Typescript (and most statically typed languages). Back in my Backbone + CoffeeScript days, I reimplemented Rails style has_many/belongs_to "class methods" on Backbone.Model, and it was incredibly useful. But would've been doubly so if I could have had it statically checked somehow.
- mordocai 10y ago
  I don't know if it is possible in any practically used statically typed languages, but I can think of nothing that would prevent you from doing metaprogramming in a statically typed language on a theoretical basis. It might be a bit hard to implement, but I think it should be perfectly possible.
saosebastiao 10y ago
In terms of Javascript targeting languages, Typescript has been the only one that hasn't made me want to murder a thousand baby seals. The build system is fast and easily understood, the typing makes refactoring so much easier, and in probably its biggest win, I can read a Javascript tutorial and trivially write the same thing in Typescript. As a language, though, it still leaves a lot to be desired. Things like type guards and null annotations are like the methadone to the vastly more addictive pattern matching and options that I can no longer live without, and promises/callbacks are vastly inferior to futures. I would rather use Scala.js or Elm, but the ecosystems pale in comparison and trying to work in what is effectively an abstraction layer (and leaky at that) makes life really difficult. So I stick with Typescript.

superskierpat 10y ago

On the topic of typescript vs purescript and similar projects, I believe these projects are more for people who want to stay in the same mindset across the whole stack. So haskell with ghjs or purescript and scala with scalajs... I dont think they are really in competition with typescript.

benjaminjackman 10y ago
This reflects my use case. I was just writing Scala code that compiles to both the JVM and JS. The requirements for the code in terms of performance for the JVM side are very intense which ruled out using Typescript there. I am using the browser for visualizations / UI where I have used Typescript in the past, between using Vanilla Javascript and then Coffeescript and before Scala.js was available. I continue to watch Typescript because I think it has its place and certainly is worth knowing / using in certain projects. I really appreciate the .d.ts/DefinitelyTyped (files which provide Typescript static types for javascript libraries) that are available, I am able to mostly convert them to ScalaJS facades programatically which gives me nice code complete in ScalaJS. One area I think Typescript outshines ScalaJS is if you have a large existing Javascript codebase, or are a Javascript programmer looking to incrementally improve your codebase / language knowledge Typescript is the best step in that direction. However if you are going `full stack`, with high performance requirements on one side, and a browser on the other, right now I think Scala is the best option. That opinion might change in the future with web-assembly (then perhaps back again e.g. scala.native ).

gkilmain 10y ago

What have they won? Why all of the f'ing if you choose A you're awesome if you choose B you've lost? Articles like this give me anxiety.

sbarre 10y ago
"Won" may be click-bait a little bit here, but I think the overall message is that if you are starting from scratch and deciding on which toolchain or approach to pick from, Typescript may be your best choice (but obviously not the only choice, since you may have specific requirements that affect this generic recommendation).
corysama 10y ago
The article presents measurements indicating that Typescript has won greater mindshare compared to similar JavaScript transpilers.
- gkilmain 10y ago
  TypeScript is a transpiler + type checker. If you just need a transpiler the author makes no recommendation between Babel and TypeScript

shrugger 10y ago

I love the piegonhole arguments that always 'exclude' Dart from these types of discussions. Class-based vs prototype-based, classes will always win. JS is terrible, TypeScript is only very slightly better. Dart's core team is absolutely world class, and the language is already highly capable.

nathancahill 10y ago
JS has classes.
- shrugger 10y ago
  JS has a syntactic sugar keyword class. Objects are still prototypes.

deforciant 10y ago

javascript and "win" must not be in the same sentence

bazqux2 10y ago
except that one

jwineman 10y ago

Interesting he omits Flow from his very carefully chosen "Typescript won" arguments.

shrugger 10y ago
I didn't even think about that, but yeah he totally did. This whole article has a very "Wow, all other languages except for the one I've invested time in really suck!" feel to it. The arguments presented are shallow at best, rely on short-term data, mostly just popular trends of what people are talking about/searching for. There's not any empirical evidence that I've seen in this article that suggests any language is better than any other language.
spankalee 10y ago
Does anyone actually use Flow? I see TypeScript all over the place.
- k__ 10y ago
  I do, in production. But yeah, it seems Flow needs more marketing. TypeScript seems to be rather big for MS. But FB mostly pumps money in Babel and React at the moment...
spion 10y ago
Last time I checked, its not available on Windows. That automatically limits its market.

JustSomeNobody 10y ago

I hate these stupid "X Won" posts.

knowtheory 10y ago

I could quibble with the conflation of correlation w/ causation for a lot of the comments this post makes about es6/babel or coffeescript. But each time i re-read this post, the cohesive point that pops out most is that this post is basically a Donald Trump speech about Typescript. The claim is that it's bigger, it's better, and everyone else is a bit sad. It disingenuously claims that it's not about about competition and then literally ends with "Typescript Won". So, lemme offer some rhetorical advice: 1) pick to a POV & stick to it. It's a competition or it's not. You either think it's worth highlighting how much better Typescript is over other technologies, or you don't. 2) Most of the points made in the post aren't assertions about the benefits of Typescript or the decisions it makes. Not everyone agrees that the existence of a static type checker is an unqualified benefit (and there are many dimensions to that conversation). If you want to make the assertion that Typescript makes your life easier/better because it has a type checker, assert the benefits of having a type checker (and the decision making for AngularJS's adoption of Typescript on the basis of having a type checker could use a citation). 3) Related to 1., this post comes off as MEGA passive-aggressive because you keep on mentioning how much you also love other technologies at the same time talking about how they are inferior to Typescript on a variety of shifting bases. Because of that you're not telling a cohesive story about Typescript. You're just talking about how you think other technologies are bad.

mordocai 10y ago
On point 2, I don't think an optional type checker has any real downsides that I can think of (optional because with typescript you don't have to add type annotations to your code). It helps with debugging and possibly performance but you can choose not to use it. The rest of your comment I agree with.
- doodpants 10y ago
  I have no experience with TypeScript, but in general the downside of optional language features is when you're working with a team, and different people end up using different dialects of the language.

yesimahuman 10y ago

No need to say TypeScript "won," we're all pushing JS forward and TS is just another tool in the toolbox. However, I'm glad to see it doing well especially since it felt like a big risk for us at Ionic to pick TypeScript (along with ng2). I've been happy with how positively received TS has been, which has been a bit of a surprise to me, honestly.

symlinkk 10y ago

I bet we'll be seeing a lot more of Typescript in the next few years, seeing as it's the default language that is suggested in Angular 2's documentation. I find it odd that Dart wasn't the default language of choice for Angular 2 (although it is fully supported) seeing as Google is behind both projects. I think it really boils down to what the author wrote here: "Dart is not JavaScript. TypeScript is." At the end of the day more people are going to want to use what they are already more familiar with, and it's really not necessary to throw out years and years of progress we have made on JS.

pjmlp 10y ago
For me it was a clear message to the outside world, how little backing Dart has inside Google, if their management allows for choosing a programming language designed by the competition instead of their own one, for their own products.
- LukeB_UK 10y ago
  Or it shows that they see that there's already an established base of people using TypeScript, more than Dart, and choosing to follow where the community exists. Throughout the development of Angular 2 the team also talked with the developers of other frameworks, libraries and tools, which shows that they believe in the community more than trying to push their own agenda.
- spankalee 10y ago
  You saw "allowed" like it's a bad or unusual thing. Allowing is the way Google works.

tptacek 10y ago

Is Typescript/Babel an either/or choice? ES6 is non-negotiable. I understand the basic premise behind Typescript. Would I "switch" from Babel to Typescript and get arrow functions and string interpolation through Typescript somehow?

eloisant 10y ago
Yes, because Typescripts is 2 things: * A language, superset of ES6 that adds optional types * A compiler (like Babel) that will take your Typescript code, check if the types are correct, remove them, and transpile the non-ES5 parts of into ES5 (just like Babel). So if you want to use Typescript-the-langage, you need Typescript-the-compiler and you will no longer need Babel.
- thejameskyle 10y ago
  Many people choose to use both. TypeScript for type-checking and stripping types, and Babel for compiling down ES2015 code. Babel follows the spec for that much closer than TypeScript does and has hundreds of plugins that allow you to do even more.
Keats 10y ago
You can use both, I do TS -> Babel to get hot reload in react (if you know a way to do that without Babel, please let me know). If you don't care about that, it's pretty much the same except async/await are not there yet. In Babel you could also use ESX features before any kind of approval while TypeScript only implements features approved (afaik).

drinchev 10y ago

Wow this is such a strong title. There's no winning. Use the right tool for the right job. Although every big project I take these days I prefer to write in TypeScript, I would honestly not use it if I have a small static landing page with an AJAX ticker or something. It would be overkill.

davidhyde 10y ago

TypeScript on JavaScript is like c# on CIL (.net common intermediate language). You are free to modernize the language as much as you want without breaking backwards compatibility. Not surprising Anders Hejlsberg is heavily involved in both. Great language.

PSeitz 10y ago

Once ES6 is widely supported, and a transpiler is not necessary anymore, people will switch to pure ES6.

intrasight 10y ago

JavaScript as an intermediate language is a fail, therefore TypeScript is a fail.

LukeB_UK 10y ago

I think the end result is actually that JavaScript wins. If it turns out that a lot of people think that JavaScript needs a type system, one will be proposed and rolled into the language.

draw_down 10y ago

I'll keep writing in the language it compiles down to. Which would be JavaScript, of course. But keep telling yourselves that if you must...

thejameskyle 10y ago

It's frustrating that the only reason thats really given for TypeScript being "better" than Babel is that it has more downloads, using incorrect charts to prove it. Here's the actual download charts if you are interested: https://twitter.com/thejameskyle/status/725344218411986946 https://twitter.com/thejameskyle/status/725344218411986946 Source: - babel-core: http://npm-stat.com/charts.html?package=babel-core&author=&from=2015-04-28&to=2016-04-27 http://npm-stat.com/charts.html?package=babel-core&author=&f... - typescript: http://npm-stat.com/charts.html?package=typescript&author=&from=2015-04-28&to=2016-04-27 http://npm-stat.com/charts.html?package=typescript&author=&f... Also if you want types with Babel, use Flow– which is arguably a much better type system anyways.

avolcano 10y ago
fwiw, TypeScript -> Babel is doable, if painful. I have it set up in my repo here: https://github.com/thomasboyt/manygolf https://github.com/thomasboyt/manygolf I agree that Flow currently the superior type system (and, unlike TypeScript, not a complete nightmare to set up if you're wanting to use Babel/Webpack instead of manually running file builds through your editor like it's 2002), but TypeScript has significantly more momentum behind it making it a much more practical solution for basically anyone who doesn't currently work at Facebook. There are also several exciting new features coming to the type system that brings it closer to parity with Flow: Non-nullable types: https://github.com/Microsoft/TypeScript/pull/7140 https://github.com/Microsoft/TypeScript/pull/7140 Control flow type analysis: https://github.com/Microsoft/TypeScript/pull/8010 https://github.com/Microsoft/TypeScript/pull/8010 I wish TypeScript tried to better-integrate with the greater JavaScript ecosystem and stop acting as a language of its own. Thankfully, the "es6" target gets it pretty close (I think it still compiles some es7 features, meaning you can't have Babel handle everything yet), and the non-standard module syntax seems to be a thing of the past. I hope the gap can be bridged between the TypeScript and Babel communities, so that TypeScript can one day be shipped as a Babel transform, same as Flow.
- thejameskyle 10y ago
  There's not really a gap between them. I've spoken to people on the TypeScript team a number of times. Jonathan Turner and I talked about sharing ASTs once, and I gave an internal presentation about Babel at Microsoft last year. Also, there's tons of people that use TypeScript for type-checking and stripping types and then use Babel for compiling down ES2015 code since Babel follows the spec closer.

rhinoceraptor 10y ago

Or it could be that Babel downloads are declining because it's becoming less necessary as Node and the major browsers implement ES6. The whole point of Babel is to be a stopgap, so it's not surprising that its usage is declining. Babel is not a language.

noahlt 10y ago

What about Flow?

quangv 10y ago

Doesn't matter, it maybe more popular, but it no one died. http://zenoverflow.com/2016/04/27/platform-of-the-browser/ http://zenoverflow.com/2016/04/27/platform-of-the-browser/ - my response to TypeScript Winning

Touche 10y ago

Weird comparisons. People who like Elm aren't going to switch to TypeScript because it's more popular. They are fundamental disagreements that can't be dismissed with a Google Trend chart. TypeScript is currently popular but popularity in JavaScript never last long. The cycle is: * A library that comes out that solves a problem with the previous iteration. * The new popular library has some different problem but people ignore it because the new cool thing is still fresh in their minds. * People become annoyed with the popular library and someone makes a new library that fixes the problem with the popular library. It looks a lot like the original library that popular library replaced. * Cycle repeats itself.

nathancahill 10y ago
The difference is that Typescript isn't someone's side project where they accidentally typed `npm publish` when they should have typed `rm -r ./` It's backed by M$ and the Github repo is super active, especially in langauge proposals. This will be around for a while.
- Touche 10y ago
  Sure and Traceur was backed by Google but that didn't stop it from losing the hype train to Babel (which was someone's side project). The JavaScript hype cycle has no escape hatch. All that go up, must come down. Some things just last a little longer than others.
  - nathancahill 10y ago
    > Backed by Google Exactly the problem. Like all other Google projects, they bailed on it.
    - Touche 10y ago
      No they didn't, it's still under active development, last release 4 days ago. Ditto for Closure which is actively developed (and is among the best libraries in ES6 features) but also lost the hype cycle to Uglify.

untog 10y ago

Choosing a winner based on Google Trends? Hmm. Pointing out that CoffeeScript is on the decline because Google Trends for it once peaked and has since declined? Hmm. Failing to consider that TypeScript might be at a similar peak and is due a similar decline? Hmm.

nathancahill 10y ago
Posting pointless comments? Hmm.
- untog 10y ago
  What exactly is pointless about what I said? The article presents no good data to back up its assertion, and even raises a potential issue then doesn't address it.

kowdermeister 10y ago

If I absolutely must choose a "winner" (what does that even mean?) then I would give the golden medal to the one that has a standard behind it. I think it's a very pointless thing to pick a winner. It's not a popularity contest. You will be able to tell that some technology is "lost" or is over, when the popularity will be declined to the 0.0.1 alpha release state.

nathancahill 10y ago
The standard doesn't keep up fast enough with the pace of development in the JS ecosystem. That's why Babel's plugin architecture is so great. It allows super fast paced experimentation with new language features, without having to get buy-in from browser vendors or even JS family languages.
- kowdermeister 10y ago
  That's true and experimentation is good thing, just look at CoffeeScript, although I never liked it. However I always bet on technologies that are standardized rather than maintained by a company. Not a fail safe approach, I know, but that's the way I minimize risk.