TypeScript Won | Hacker News Reader

TypeScript Won

medium.com

121 pointsSanderMak127 comments

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.

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.

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.

That doesn't really apply here, because type annotations have no runtime effect. They're effectively comments.

you could say that about any high level language. i.e. that it's effectively metadata few levels above metal ignored at runtime. But it is relevant here because the relevant part is working with application code within a team half of which may choose to use optional features

The content of comments isn't enforced by the compiler, so I would say they are not very comment-like.

It's just weird to compare philosophically different languages. ClojureScript fans are never going to switch to TypeScript. So saying TypeScript has won the transpiler wars is hilariously wrong.

Comparing TypeScript to transpilers in the same space, like Flow and Dart makes sense. They're trying to accomplish similar goals at least.

A downside is everyone on your team has to learn how to use it.

I don't know what any of this has anything to do with Trump.

Donald Trump, well aside from the content of his speeches, has been noted for his rhetorical style. As i stated, this bears some resemblance.

> this post is basically a Donald Trump speech about Typescript.

Low energy.

I can't think of any downsides of an optional type checker. Can you? Just curious if there's an argument I hadn't heard before.

If it's TypeScript versus pure JavaScript (not versus Babel), there's a transpile time hit you must consider.

Pure (vanilla) JavaScript will remain a bit of a rare unicorn in large projects, though, at least until HTTP/2 and maybe even after HTTP/2 for whatever other reasons [1]. Just about every large project has a bundler and/or minifier step and the Typescript transpilation fits right in there, instead of in the browser.

[1] People will always still want to shave bandwidth, and the new hotness is Tree Shakers which shave bandwidth and computation/JIT time for the browser...

Just about every large project has a bundler step for production. Many have for dev as well, but this is unequivocally an undesirable thing. You can't beat Refresh for dev workflows.

In dev workflows you can deal with the extra few milliseconds of transpilation time just like you deal with the extra few milliseconds of overhead from any of your other dev tools.

Plus, even a bunch of dev workflows are increasingly using tools like gulp-watch in the background of their refresh cycle (for whatever reasons), and Typescript's watch support has gotten very good.

You can "deal with" a lot of things, but that doesn't make them desirable. It's not like the community has evolved towards build scripts because build scripts are great, it evolved in that direction because the ecosystem has changed faster than the web has been able to keep up. Once the web catches up on the module front you'll definitely see the refresh workflow regain some lost popularity.

Maybe? There's always an "ES Next" in the evergreen world. There's always some feature you might want to use today that a build tool makes accessible that otherwise you'd wait months/years for browser support to "catch up". The goal posts will keep moving, especially now that TC39 is working on an "agile" yearly spec release cycle.

After modules there's async/await and after that there's plenty more future to discover...

I'd say live reload beats refresh for dev workflows (when it works).

Same problems with linters: people write weird code and/or introduce unnecessary changes to correct code that doesn't pass the check.

Also, optional type checkers throw away a lot of the upsides of type systems (safe refactoring, type-aware optimizations, useful generics) so they're kind of a worst-of-both-worlds solution.

> Same problems with linters: people write weird code and/or introduce unnecessary changes to correct code that doesn't pass the check.

Having just converted a bunch of pure Javascript to Typescript, and writing new code in Typescript, this hasn't been an issue.

> Also, optional type checkers throw away a lot of the upsides of type systems (safe refactoring, type-aware optimizations, useful generics) so they're kind of a worst-of-both-worlds solution.

I'm not sure what you mean by "throwing away safe refactoring" but yeah, you don't get the performance benefits or reified generics (not that it's particularly useful). That said, it's not like you derive any performance benefit from Java generics either.

But that's kind of what the article is about, isn't it? TypeScript is a way of having types and yet existing in a typeless world.

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

Source: - babel-core: http://npm-stat.com/charts.html?package=babel-core&author=&f... - typescript: 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.

fwiw, TypeScript -> Babel is doable, if painful. I have it set up in my repo here: 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

Control flow type analysis: 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.

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.

Not to mention that currently Typescript doesn't emit certain types of polyfills so it can be handy to let Babel manage that.

What makes you say flow is a better type system?

> Also if you want types with Babel, use Flow– which is arguably a much better type system anyways.

Why? Besides, kinda ironic you point out the lack of reasoning in the article, then making a bold claim on your own providing no arguments.

I've given up on trying to have serious discussions about these things on Hacker News. It's a really bad community for that sort of thing. Find me elsewhere if you want to have that discussion.

Ever wondered if it's exactly because of people discussing like this?

I don't particularly care what it is. This is the discussion forum where I've been told that Babel single-handedly has "destroyed the web platform" and all sorts of just senseless attacks, including ones that get way too personal.

No, if this community wants to act like a bunch of 12 year olds then that is their prerogative, but I'm not going to be part of it.

Again, I'm more than happy to talk about this anywhere else.

So you're taking your ball and going home? LOL. Nana nana boo boo!

The charts are not to say the TypeScript is better then Babel, it's to show that 'it has won'

these are just npm stats. this ignores nuget (visual studio equivalent) and other ways it can be installed including direct download

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

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!

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.

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.

Have you tried a async/await?

async/await isn't in TypeScript yet, if that's what you were implying. It will be though (and obviously is part of babel if you choose the right pieces).

async/await has been in TypeScript for a while, but currently depend on generators, so don't down-level to <= ES5 emit (that work is in progress).

With the latest Node releases and modern browsers supporting generators today, you can target ES6 and use async/await today if you can target those environments.

https://blogs.msdn.microsoft.com/typescript/2015/11/03/what-...

Top-level types can be permanently shadowed. For instance, if I name a type "Date" within a namespace, then every file within that namespace or a sub-namespace will no longer be able to access the JavaScript native Date type. This also apparently isn't something they're inclined to fix. [0]

The tsconfig.json file does not allow for glob-type inclusion of files, or even inclusion of directories. However, you can exclude entire directories. So if I want to simply compile everything in the "src" directory, my best option is to exclude every other directory.

[0] https://github.com/Microsoft/TypeScript/issues/983

Isn't this kind of inherent to the JS model? I mean I guess you could rewrite the names of types at compilation but that would create other problems

Typescript's job is to add safeties to a lot of the JS footguns, but there are a lot of them if you are not careful, and also, even with a safety in place, some people just want to shoot themselves in the foot.

No, because I'm shadowing the type, not overwriting it.

JS doesn't have namespace scoping, and therefore everything has to be explicitly scoped. So if I create `my.awesome.Date`, just `Date` means JavaScript's `Date`, and I have to put `my.awesome.Date` to get the new type. Typescript adds namespaces and scoping rules, so that anything in the `my.awesome` namespace or any namespace below it will see `Date` as `my.awesome.Date`. And there's no way to explicitly reference the global scope, so within those namespaces the new type completely and irrevocably shadows the original JavaScript type.

Also in JavaScript, unless I overwrite the original `Date` type, I can always explicitly scope it by saying `window.Date`. But TypeScript doesn't define `Date` within the `window` type, so I can't use that out either.

Typescript's following the usual JS scope closure rules: the namespace syntax is sugar for the usual sort of JS "IIFE" object pattern, which you should be able to plainly see in the transpiled output.

Because Date is a data type, not every browser may attach `Date` to the global `window` object. I can't think of one that does not, but it's one of those cases where JS has always been ambiguous.

That said, Typescript is more than happy to let you `(<any>window).Date` assert your way to that global. Or if you feel particularly strongly about this, you could in increasing order of strength of opinion: 1) add .d.ts file somewhere augment window yourself with Date, 2) fork the lib.d.ts and use your own instead of the default, 3) send a PR to Typescript adding it to the default lib.d.ts and see if they have a stronger reason for it not being there beyond it just being ambiguous in the JS language/spec/library.

> Typescript's following the usual JS scope closure rules: the namespace syntax is sugar for the usual sort of JS "IIFE" object pattern, which you should be able to plainly see in the transpiled output.

Yes, and in the transpiled output I will see `Date` turned into `my.awesome.Date` for files within the namespace scope. As I said, JavaScript is always explicitly scoped, so unless you shadow it with a local variable or overwrite the original, you can always access it. So I could easily write `my.awesome.Date` in JavaScript without shadowing the native `Date`, but I cannot do that in TypeScript because of the namespace scoping rules it adds. Which, pains of using TypeScript being the original prompt, seemed quite relevant.

The only complaint I've heard is that TS makes JS feel more like C#. Lots of people would say that's a good thing. But, some people really appreciate the dynamic nature of JS.

In typescript the types are optional, so if you omit types it'll look very much like ES6.

You can mix and match dynamic stuff with Typescript, depending on your compiler options, it'll treat non-typed things as if you were writing regular JS.

I always turned on 'do not allow 'any' types' because I wanted everything typed.

As far as C#... there are enough minor differences for it to be rather annoying if you have to jump back and forth every second day. C# is vastly more powerful and convenient as a language to Typescript, though. I'd write C# in the browser if it were a de-facto option, and I used to write and love Ruby. C# has all the functional stuff I doted over in Ruby, and it's all typesafe!

Furthermore you can give Typescript the allowJS: true compiler option in recent versions and literally mix and match pure JS files and Typescript files in the same "project".

Structural is worse than nominal. The types are unsound even without "any" because arrays are bivariant. There are no HKTs.

Structural is not worse than nominal. Nominal types are mostly a lie, and in the case of JS and package managers / module systems like npm / node's, they are a non-starter.

Arrays are no longer bivariant, and haven't been for at least a year. They are still covariant unfortunately.

I used it very heavily and exclusively for about 3 months. I'm not writing it day to day now but it was like having super powers in comparison to writing JS or Coffee.

I was using Visual Studio Community so I had all the benefits of intellisense (which is a big benefit), and I was able to manage a fairly complicated bespoke canvas thingo that suffered a few major refactorings - which I was able to perform with confidence due to the type checker.

The massive list of bundled typings and 3rd party typings makes it much quicker to pick up a new API or remind yourself of one you haven't used for a while.

I now write C# day to day and I find I don't spend the majority of my day alt-tabbing to and from documentation web pages as a result.

So... any bad things to say? None at all off the top of my head. I'm a huge convert, and not because 'it's nice' or 'it's pretty' but because it's like wearing the Iron Man suit when it comes to programming. It's helped me be more productive on non-trivial projects.

I love TypeScript, and after spending a few years writing JavaScript and CoffeeScript, I've switched to using TypeScript whenever I possibly can. The only bad thing that I can say about it is that the management of type definition (.d.ts) files for external libraries can be a bit of a pain, even using tsd. That's less an indictment of the way TS works, and more of the tooling around it.

It has a terrible type system

The things missing for me are:

1. partial application (bind is typed as 'any')

2. sum type destructuring

3. issues with recursive type definitions

But the Typescript team add new features very quickly so I wouldn't be surprised if these issues are solved in the future.

The type definitions for some libraries aren't super fleshed out, which prevents you from doing some of the optimal styles possible with those libraries. I ran into problems with both lodash and ramda with TypeScript so far.

Other than those nuisances, I've grown to like using TypeScript a lot.

The type system is not that great and inference is quite limited. Definitions are not always existent or up to date and a single repo like definitelytyped is a terrible way to manage all the definitions.

The above sounds negative but TS is still the best bet right now imo. Some people will prefer Elm or Purescript for better type systems but I like staying close to JS.

Personally, I'm more excited about Flow because it introduces a modern type system into ES6/ESNext without me having to sacrifice Babel.

With regards to types: TypeScript has only recently added support for any kind of Algebraic Data Types whereas Flow was built upon Unions and Intersections from day one. That to me speaks to their priorities.

Unions were added in TS 1.4, over a year ago.

https://blogs.msdn.microsoft.com/typescript/2015/01/16/annou...

Also, Intersections were added in TS 1.6, last year:

https://blogs.msdn.microsoft.com/typescript/2015/09/16/annou...

They seem to be moving at a decent, agile pace to improving/expanding upon the algebraic sides of the type system.

Yup, I was definitely wrong on that one. Sorry about that.

Thank you for correcting me.

Next up on the roadmap, Typescript is working to add opt-in strict null and undefined checking which is probably the last area where Flow's type system is particularly better than Typescript's.

(It will be opt-in as Typescript follows a rule of increasing strictness via compile options to support the spectrum of JS needs, but also as it will not be entirely backward compatible with existing type definition files and will need some effort among typings authors.)

The fact that Flow doesn't work on Windows is a big limitation.

I prefer the idea of Flow as well but tooling and community is not there yet

There are occasionally Windows builds by the OCamlPro people popping up.

The fact that last time I checked, it wasn't able to consume TSD signatures from third-party libraries (or offer an equivalent system with a significant amount of libraries) is a much bigger issue IMHO.

Not terribly related but I am starting to see this as a pattern on the internet:

When I bring up the latest and greatest (eg. Flow) it doesn't actually work on Windows because Windows is as I see it an after-thought for a lot of the Open Source world.

But I've brought up this exact problem (the lag in tooling) to .Net/Windows devs before and they've told me I'm wrong and that they've got all the latest and greatest dev tooling like everyone else.

Typings uses an actual package management approach to type definition management and makes it easier to support repositories specific to a package definition and versioning typing definitions in synchronization with their upstream packages. Typings is particularly great for projects using NPM and/or JSPM packages. It's definitely time to move beyond DefinitelyTyped as the single point of failure and giant repo of doom.

Like other compile-to-JS languages such as coffeescript, I don't think it has enough to offer over plain JS to justify its existence. Coffeescript was great because it drove a bunch of language features into consideration for ES6, but actually writing in it seemed like more pain than it was worth.

Consider being in the situation of being in charge of a large coffeescript codebase, today. No thank you.

Funny, I feel the exact opposite about CoffeeScript, but maybe I'm not using enough advanced features.

In particular I like how readable and clean CoffeeScript is when you have a long series of callbacks.

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.

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.

TypeScript's type system is "occasionally typed". E.g. in trivial, C#/Java-style code it works well. And even there it falls back to `any` way too often (and it can become hard to find out way). Flow's type system is designed with modern, more functional style in mind and didn't fail me yet.

Suggestion that solves your problem: don't use TypeScript without "noImplicitAny"

For small projects with little client-side code it's more trouble than it's worth. But no, if you're doing serious JS development I think it's worth seriously considering.

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.

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.

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.

You saw "allowed" like it's a bad or unusual thing. Allowing is the way Google works.

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

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.

Does anyone actually use Flow? I see TypeScript all over the place.

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

Last time I checked, its not available on Windows. That automatically limits its market.

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.

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

The article presents measurements indicating that Typescript has won greater mindshare compared to similar JavaScript transpilers.

TypeScript is a transpiler + type checker. If you just need a transpiler the author makes no recommendation between Babel and TypeScript

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.

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

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.

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.

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?

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.

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.

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

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.

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.

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

I hate these stupid "X Won" posts.

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.

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.

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.

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.

> Backed by Google

Exactly the problem. Like all other Google projects, they bailed on it.

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.

Uglify? Webpack would have been the better comparison if we're talking straight hype factor.

You must be young. There was a time when Closure was the most used library for minification. Before that it was the YUI Compressor. Anyways, Node came out and Uglify worked with Node and Closure didn't and even though Closure had some benefits like dead code elimination (which was eventually added to Uglify but not sure if as good or not - regardless it wasn't there at first) Uglify still won out.

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.

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.

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.

Doesn't matter, it maybe more popular, but it no one died.

http://zenoverflow.com/2016/04/27/platform-of-the-browser/ - my response to TypeScript Winning

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.

JS has classes.

JS has a syntactic sugar keyword class. Objects are still prototypes.

What about Flow?

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.

Posting pointless comments?

Hmm.

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.

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

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.

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

TypeScript "won" because certain folks will happily trade some coherency for more complexity.

Types (can) be helpful.

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

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

except that one

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

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.

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.

Reply on news.ycombinator.com