Speaking as the person who implemented JSX support for TypeScript, I question the premise! JSX support (and implementation of React semantics for typechecking that JSX) was a very popular feature request. I can tell you just from how quickly people notice when something JSX-related changes in the nightly build that there are a lot of people using TypeScript with React.<p>Also, since this seem to be a popular misconception, JSX support in TypeScript is <i>not</i> wedded to React. The default JSX target is React, but you can set JSX to "preserve" and get very vanilla semantics as well as keeping the JSX in the emitted code so you can pipe it through a custom transformer.<p>The question also points out that the reader is looking at lots of tutorials -- it should be unsurprising that these don't use TypeScript as it's an optional thing that would only increase the concept count in an educational setting where you want to only show the thing you're trying to explain.<p>If you need a notable React + TypeScript project, see the Delve team's write-up of their use of TypeScript - <a href="https://medium.com/@delveeng/why-we-love-typescript-bec2df88d6c2#.uvwtenu64" rel="nofollow">https://medium.com/@delveeng/why-we-love-typescript-bec2df88...</a>
Anecdotally, at Bloomberg we're in the middle of ramping up TypeScript support in our core server-side stack. Our custom IDE is Windows based, so it was very straightforward to integrate the tserver into the workflow to give developers the choice of writing vanilla JS or TS with additional annotations we send down to the IDE for the core stack. We have the largest single collection of JS I'm aware of and we're eager to see TS take off as we iron out a few corner cases and really get 2,000+ devs using it daily. This isn't the web or Node, so make of it what you will -- but the tserver integration and ease of layering on top of the existing vanilla JS in a progressive manner made it a simple decision.
I don't feel the posts answer the question, they are more ads to Typescript or Flow. Unsurprisingly the people who answer are the one who use TS or Flow.<p>So I tried a little to convert a big React project to Flow or Typescript. The Flow was a non-starter because of the absence of Windows support at the time, and we use like 40 (non dev) dependencies, and Typescript has a way better support for typings, I tried Flow on a mac it was chocking on the size of the node_modules or couldn't find the app modules because we use a webpack root dir (i don't tried hard to make it work).<p>When the app was started Typescript didn't support React so it wasn't written in a "static" way, and accumulated a lot of dynamic idioms, also the backbone of the app is a dynamically generated schema based on XSD and that would be hard to make it compatible with TS type system, also React ecosystem doesn't really use it, leading to a chicken/egg problem, and React.PropTypes is already a form of type checking (but dynamic) so it probably lessen the feeling of a need of static typing in React ecosystem.
I've been using React + Redux + Typescript stack and I've been quite happy with it (It's hard for me to image how you could do big refactoring without TS).<p>The fact that components props are verified by compiler instantly when I type is a big win. I believe with PropTypes you can't specifically describe what is the shape of your data, for example object with property of such name and the value of this property is object with other concrete properties. Or array of objects with specific property. In pure react you only have "React.PropTypes.object" and "React.PropTypes.array" in TypeScript you can say "{ foo: string, bar : { fieldNum : number}}" or "{foo: string}[]".<p>Some other observations:<p>- I use Typescript 2.0 RC, because it has union types [0] and it works great with Redux reducers. It's super cool!<p>- I don't miss spread object operator that much, it would be nice but I'm fine with some utils function that can even verify that I "override" property that exist is source object[1] (I mean creating new object with changed properties)<p>- What I really miss is the ability to say that what is the return type of the method. There is "typeof" operator in typescript for telling what is the type of particular object, I would like something like "returntypeof". Because now I always need to write the type of an action and very often it could be inferred from action creator function. Or I need to write type to describe what will be returned by Redux's "mapStateToProps" function, and sometimes this object can be big.<p>[0] <a href="https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#tagged-union-types" rel="nofollow">https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...</a>
[1] <a href="https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#example-21" rel="nofollow">https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...</a>
Edit: Misleading charts, figures and conclusions ahead, see @nathancahill's reply<p><a href="https://npm-stat.com/charts.html?package=babel&package=typescript&package=flow-bin&from=2013-09-19&to=2016-09-19" rel="nofollow">https://npm-stat.com/charts.html?package=babel&package=types...</a><p>Babel has faltered since the V6 release, TypeScript is still growing fast, so I'd expect the React world to follow suite, even if Facebook itself pushes Flow...<p>NPM downloads in August (rounded):<p><pre><code> typescript: 2,000,000
babel: 620,000 (down from 890,000 in November 2015)
flow-bin: 120,000</code></pre>
TypeScript works very well with React, less so with Redux/ImmutableJS.<p>We just moved our app from Redux and ImmutableJS to mobx and it's been a treat: we now get full typing and it's much less verbose. We don't need to repeat the payload definition at every point, we have a store where we call a method and that's it. Highly recommend checking out mobx if you use TS.
Because a lot of notable ReactJS projects are irritatingly enamored with all the latest ES6/ES7/ESCloudCuckooLand features, not all of which are supported by TypeScript.<p>I've noticed this a lot in the Redux realm. For every possible problem there seems to be a solution that harnesses one particular new/proposed bell & whistle.
I've been very happy using Typescript with React, and have found the productivity and code quality gains to be remarkable compared to the relatively small amount of change required to use it vs. plain JS.<p>Indeed there are some pain points as mentioned in the article, e.g. typing Redux actions can be a bit boilerplatey, and there's currently no object spread operator; but I feel it's worth the trade off - you can always opt out of typing something (e.g. with the "any" type), but I've always found that the places where you do this are the places where the bugs creep in!<p>Obligatory plug for my Typescript 1.9 + React project set up guide - I need to update this for v2.0, but I think it should pretty much work as is: <a href="http://blog.tomduncalf.com/posts/setting-up-typescript-and-react/" rel="nofollow">http://blog.tomduncalf.com/posts/setting-up-typescript-and-r...</a><p>I actually prefer Flow's approach of being just annotations which can be stripped out, rather than a new language (albeit a superset of Javascript) with its own features and compiler - for one, I find this makes it an easier sell to teams worried about "lock in". However, there is a bit of FUD around this IMO, as you can use just the subset of Typescript which adds types to JS and avoid stuff like "enum" and the "class" enhancements - in my experience, TS's types can be stripped by Babel in the same way as it strips Flow's, so actually if you ignore the `.ts` extension, there's not such a big difference.<p>The problem is that every time I've tried Flow (including very recently spending several days trying to convert an existing medium size React project to it), I've hit so many random undocumented issues, and ended up feeling that the benefits of it were outweighed by the amount of effort required to get it working properly. This is especially true because the editor experience offered by Nuclide is (again, in my experience) sub-par and buggy compared to VS Code (or the Typescript Sublime plugin), and I've always felt the editor support is actually one of the big selling points of working with "typed JS".<p>I am really looking forward to seeing how Flow progresses, as in an ideal world it is what I would use, but for now (in a commercial situation especially), I have to go with what I feel brings the biggest productivity/code quality benefits and the best developer experience for the team, and for now I still think that is Typescript by a fair distance.
I was always wondering why HN crowd is ok with TS and so prejudiced against Dart - Dart has NG2, await async in older browsers and good tooling (webstorm, vscode) and much saner package system. When doing lot of small web apps - it's easier to mantain.
I do TypeScript every day for work, and honestly I don't see the point of it. I'm also of the opinion that the iterator pattern nonsense has ruined generated code quality for ES6 transpilers, and that ES5 getters and setters have made it considerably harder for JS engines to do high level optimizations (dead store elimination, invariant hoisting, load merging, etc.).<p>The sky is falling.<p>Anyway, you're not going to dissuade anyone. TypeScript looks visually similar to Java and C# enough that managers will think they can adapt Java and C# teams to it in a couple of days; and they won't know how wrong they are until a month or two have passed.
From personal experience, you probably want Babel anyway even with TS to deal with some weird edge cases.<p>I think this has been fixed now. But a couple of weeks ago, I had a case where TS compiler output has to be ES6 (since the code base were using something like constructor.name which isn't in ES5), but then Jest (the test framework) doesn't like ES6 syntax, so Babel is needed to compile whatever Jest didn't like down to just ES5 syntax.
I'm not sure if this not a sophisticated trolling :) Imagine the question with random technologies:<p>If ___________ is so great, how come all notable ________ projects use __________?<p>Classic troll magnet :)
The main reason for using Babel was async/await. However, the lastest TypeScript verion (typescript@next) can compile async/await for older browsers, so there is no reason for me to use Babel anymore.
TypeScript with JSPM and VS.NET works great, IMO even better than Babel since it doesn't require additional configuration for Babel or managing a separate watcher process since VS.NET compiles on save - providing an optimal dev experience. The additional complexity TypeScript requires is typings for each library which is designed to add value over time through typing feedback, but sometimes the typings can deviate from the implementation which is currently the only friction I hit when using TypeScript.<p>If you're interested in this combination, I've published a step-by-step guide showing how all pieces fit together in:<p><a href="https://github.com/ServiceStackApps/typescript-redux" rel="nofollow">https://github.com/ServiceStackApps/typescript-redux</a><p>For a decent sized TypeScript + React code-base checkout <a href="https://github.com/ServiceStack/Gistlyn" rel="nofollow">https://github.com/ServiceStack/Gistlyn</a> - a C# Gist IDE written in TypeScript + React and Redux - a large enough project that would've been painful to write without React or TypeScript. A Live demo is available at: <a href="http://gistlyn.com" rel="nofollow">http://gistlyn.com</a>
TypeScript is a PITA when working with typed immutable records, I don't think there will be a happy solution to that. React stack encourages stuff like immutable.js. In general TS React feels bolted on rather than designed with TS in mind like Angular 2.<p>I love TS and using ng2 at work. If I was using React I would probably also skip on TS.
I am using TypeScript in a middle sized app (around 200 react components) and its help is invaluable for collaborating and sharing APIs.<p>Currently it is based on redux, but I have a feeling I have to write too much code, I am looking into MobX as an alternative.<p>I think TypeScript is the best thing that happened to the JS community in a long time.
Why waste your time with half-baked type systems that try to achieve some compromise over JS idiosyncrasies.<p>Go all in with purescript[0] :D<p>Simple, elegant, strong typed and compiles to JS.<p>[0]: <a href="http://www.purescript.org/" rel="nofollow">http://www.purescript.org/</a>
I like to use TypeScript with ReactJS.
And I was surprised to see some mainstream libraries using it: mobx, apollo stack.
And it is also a surprise to see really well updated typings for a lot of things in the react world.
I got a link to these articles from HN a couple of weeks ago.<p><a href="https://swlaschin.gitbooks.io/fsharpforfunandprofit/content/posts/designing-for-correctness.html" rel="nofollow">https://swlaschin.gitbooks.io/fsharpforfunandprofit/content/...</a><p>What I loved about them is they show how a different type system and language design can massively reduce code size and errors.<p>After reading them I felt frustrated back in JavaScript or C# or any other language I use regularly.<p>Are Typescript and Flow missing the forest for the trees?
Why not both? I just installed flow and checked the JavaScript output of my TypeScript project (~2000 lines) and was a little disappointed it didn't turn up any errors.
Isn't a large part of the win for typescript the tooling? Specifically the auto completion and documentation that pops up in various typescript enabled editors.<p>Does such a thing exist for Flow? Could it? If it did that would go a lot further to push me to flow than that it just catches more errors. I get huge productivity gains from my editor helping me with API completions etc...
The ceaseless drumbeat of "why do I have to correct every breaking error in my code just to try it" just... Don't people realize how old and flawed this argument is?<p>And it's even stranger applied to Typescript, which is a fairly good implementation of a real-world gradual typing system.<p>Most modern type systems are quite good at giving you info about problems, blocking errors about the outright incorrect stuff, and otherwise get out of your way. Typescript is no different in this.<p>But many people (including the top reply) argue like secretly it's 2007 and we're talking about inscrutable C++ compiler errors from the last generation g++ compiler. We're not. Typescript is not only fast and friendly, but it's a heck of a lot more "batteries included" than Babel.<p>The funniest part is that ultimately flow desires to asymptotically approach what TypeScript already (for the most part) _is_ today.
I found the comment about soundness in the linked post to be kind of an odd remark.<p>It didn't take me long after reading that to come up with an invalid program that is accepted by Flow's type checker. (The typechecker normally rejects doing math against strings, but accepts this.)<p><pre><code> let array = [1,2];
array.pop();
array.push('hello');
console.log(array[1] - 3);
</code></pre>
To be clear, being completely sound is hard! There's a lot of space in type systems and Flow must make some hard decisions itself; whether it's "sound" or not is kinda orthogonal to whether it's useful or not. And I'm sure Flow is useful. So let's not talk about soundness.<p>(Disclaimer: I work with TypeScript and am pretty fond of it.)
In my team we use both approaches depending on the size of the project, an inconvenience we ran into using typescript is the typings definitions, some are out of date or don't work at all, that and the fact that typing dependency management is not yet fully integrated means that you have to keep track of 2 set of dependencies.
This is a bit of a false dichotomy, I use TypeScript + Babel to get full ES6 + TypeScript features - they work so seamlessly I forget that I have a Babel layer in there.
I do not believe compilation nor a type system belong in JavaScript. It's better to have something like "Flow" that does static analysis of the code as you write.<p>I might even go as far as putting on a "tin foil hat" and state that Typescript is a trick to lock you into their proprietary ecosystem of expensive tools that everyone have to buy into just to communicate with you once you are locked in.
I would have switched to typescript but I had to rename EVERYTHING from something to something else in order to use TypeScript. If that's how "compatible" starts, well, no thanks cause clearly that's just the start of the pain.<p>Compatible should be same files, new compiler = "just works".