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.
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.
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.
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 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.
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.
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.)
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.
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.
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.
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 ).
"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).
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.
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.
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.
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
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.
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...
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.
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 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.
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?
* 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.
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.
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)
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!
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.
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.
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.
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:
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.
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.
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.
127 comments
[ 3.5 ms ] story [ 198 ms ] threadI 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.
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.
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-...
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
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.
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.
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.
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!
Arrays are no longer bivariant, and haven't been for at least a year. They are still covariant unfortunately.
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.
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.
Other than those nuisances, I've grown to like using TypeScript a lot.
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.
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.
https://blogs.msdn.microsoft.com/typescript/2015/01/16/annou...
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.
Thank you for correcting me.
(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.)
I prefer the idea of Flow as well but tooling and community is not there yet
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.
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.
Consider being in the situation of being in charge of a large coffeescript codebase, today. No thank you.
In particular I like how readable and clean CoffeeScript is when you have a long series of callbacks.
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 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 ).
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.
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.
TypeScript seems to be rather big for MS. But FB mostly pumps money in Babel and React at the moment...
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.
The rest of your comment I agree with.
Comparing TypeScript to transpilers in the same space, like Flow and Dart makes sense. They're trying to accomplish similar goals at least.
[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...
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.
After modules there's async/await and after that there's plenty more future to discover...
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.
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.
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?
* 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.
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).
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.
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!
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.
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.
Coffeescript's future is diminished, presently (hah) - but ES6 only picked up a handful of magical features.
Types (can) be helpful.
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.
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.
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.
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.
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.
http://zenoverflow.com/2016/04/27/platform-of-the-browser/ - my response to TypeScript Winning