
If TypeScript is so great, how come all notable ReactJS projects use Babel? - stuartmemo
https://discuss.reactjs.org/t/if-typescript-is-so-great-how-come-all-notable-reactjs-projects-use-babel/4887/2?u=spicyj
======
RyanCavanaugh
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.

Also, since this seem to be a popular misconception, JSX support in TypeScript
is _not_ 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.

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.

If you need a notable React + TypeScript project, see the Delve team's write-
up of their use of TypeScript - [https://medium.com/@delveeng/why-we-love-
typescript-bec2df88...](https://medium.com/@delveeng/why-we-love-typescript-
bec2df88d6c2#.uvwtenu64)

~~~
afarrell
> It would only increase the concept count in an educational setting where you
> want to only show the thing you're trying to explain.

As someone who has written a long tutorial, this makes total sense. When I was
first looking at the react ecosystem, it was very frustrating because of the
high cost of picking pieces to work together. I really liked
[http://teropa.info/blog/2015/09/10/full-stack-redux-
tutorial...](http://teropa.info/blog/2015/09/10/full-stack-redux-
tutorial.html) because it showed how to use mocha _in the context_ of we
webpack and react and redux.

It would be nice to see more tutorials for curated toolchains, but they take a
lot of work.

~~~
emodendroket
This is basically my frustration with the whole trend toward smaller pieces
over big monoliths. I don't need a best-in-class every tiny little thing; I
just want reasonable tools I can expect to work together well.

~~~
saosebastiao
The JS build system ecosystem could definitely use some help along the whole
"reasonable tools I can expect to work together well" front. I swear, 30% of
my time is spent fighting the build systems and their plugins that hate each
other.

EDIT: to add, I think the TS team has done such a bangup job on Typescript
that I would love it if they could create a build system as well. Some things
that would be nice to have:

* Build-time loading of static resources (.json into js objects, html into strings, etc.)

* File watching and processing for more than just .ts/.js files

* Optimization. Not just tree-shaking and minification, but you could actually get a little more advanced due to the static types and ES6 modules.

* Environment-dependent compilation (compile _these_ files in _this_ way, inserting _these_ static values where ENV variables are used in the source, etc.)

* Target capabilities analysis (ie. for this set of browsers and versions, what is the Lowest Common Denominator for browser capabilities, and ergo, what babel transforms and browser shims should be included?)

* Integrated contracts testing with test elision (ie. run these tests in these (karma? selenium?) environments and if failing, throw a compilation error or warning, and if passing, strip the tests from the compiled source).

* Source packaging (gzipping, etc.), and deployment plugins (ie. deploy compiled assets to S3, package for NPM, etc.).

All of these are pain points in Typescript projects, and all of them touch TS
projects in such a way that it makes it even more painful in existing build
systems.

~~~
neilellis
I find webpack to be quite a 'holistic' solution I got pretty much everything
out of the box or with minimal googling.

I agree though over-fragmentation is a huge problem for JS, we need the big
players (either foundations or companies) to put their weight behind one or
two solutions and just get on with it :-)

~~~
rpeden
Google sort of already has one, and has for a long time.

Now that their Closure Compiler supports ES6 quite well, I've had a decent
amount of success writing my app using straightforward ES6 and referencing the
extensive Closure Library for functionality I would've previously pulled in
npm packages for.

And the nice thing is that the whole library is written in such a way that all
of the compiler's advanced optimizations and branch pruning, and dead code
elimination work nicely on it so your compiled JS ends up containing only the
code you need, and none of the code your don't need. If you want to use JSX in
React projects, you can still zip the code through Babel or Typescript before
feeding it to Closure.

It certainly won't work for every project, but it's one way to write modern JS
without having to deal with the node/npm ecosystem too much...at least until
things settle down a bit.

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

~~~
oblio
That sounds really interesting. Could you give more details about your
adoption plan? Which version of TS are you using? Are you planning to migrate
to TS 2.0, when it comes out? In your experience so far, have the conversion
done until now caught any bugs?

~~~
apaprocki
If I'm remembering correctly it first went live to some early adopters with
1.6.1 and it is using 1.8 now. We obviously want to track the latest releases
as fast as we can because they bring new features we're interested in.

I would need to ask some of the teams that tried converting larger projects
specifically what they found that they felt was important. I'm certain TS
would find _some_ bugs in any sufficiently large project, but I'd have to go
dig up data to know roughly how many or how serious they were. Just because
there was a technical quality issue with the code doesn't mean that the
vanilla JS version of it wasn't producing the actual desired result. It's hard
to gather numbers for that type of thing. It's very similar to the let-down a
lot of people feel with using static analyzers on mature, battle-tested C++
code for the first time. It will certainly find some nits, but most likely
they were not that important to begin with.

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

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

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.

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

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}[]".

Some other observations:

\- I use Typescript 2.0 RC, because it has union types [0] and it works great
with Redux reducers. It's super cool!

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

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

[0] [https://github.com/Microsoft/TypeScript/wiki/What's-new-
in-T...](https://github.com/Microsoft/TypeScript/wiki/What's-new-in-
TypeScript#tagged-union-types) [1]
[https://github.com/Microsoft/TypeScript/wiki/What's-new-
in-T...](https://github.com/Microsoft/TypeScript/wiki/What's-new-in-
TypeScript#example-21)

~~~
berfarah
Don't you have

    
    
      React.PropTypes.shape({
        foo: React.PropTypes.string,
        bar: React.PropTypes.shape({
          fieldNum: React.PropTypes.number
        })
      })
    

? I'm not saying it isn't verbose, but I'm pretty sure that as of a few months
ago, this existed in React natively.

~~~
sync
PropType support is pretty iffy, see e.g.
[https://github.com/facebook/react/issues/1833#issuecomment-1...](https://github.com/facebook/react/issues/1833#issuecomment-148297807)

------
pygy_
Edit: Misleading charts, figures and conclusions ahead, see @nathancahill's
reply

[https://npm-stat.com/charts.html?package=babel&package=types...](https://npm-
stat.com/charts.html?package=babel&package=typescript&package=flow-
bin&from=2013-09-19&to=2016-09-19)

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

NPM downloads in August (rounded):

    
    
        typescript: 2,000,000
    
        babel:        620,000 (down from 890,000 in November 2015)
    
        flow-bin:     120,000

~~~
nathancahill
Well, the V6 release made babel modular, so the babel package is no longer the
right one to compare against. Look at babel-runtime: 4,600,000 or babel-core:
4,300,000 vs typescript: 2,100,000.

~~~
vcarl
Good call, that's a very different chart.

[https://npm-stat.com/charts.html?package=babel-core&package=...](https://npm-
stat.com/charts.html?package=babel-core&package=typescript&package=flow-
bin&from=2013-09-19&to=2016-09-19)

~~~
nathancahill
It's irrationally irritating that September's incomplete stats are graphed
incorrectly. Guess I need more coffee before dealing with JS in the morning.

------
Keats
TypeScript works very well with React, less so with Redux/ImmutableJS.

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.

~~~
cloverich
I've been using Typescript, React, and mobx and absolutely in love with how
they all work together. For me the high-level summary is that the vast
majority of my logic is moved out of React views and into stores / controllers
/ whatever, with almost no boilerplate to make them play nicely together. The
way its coming along reminds me of Ember quite a bit, but I get to use React
and POJO's.

~~~
iamcasen
I definitely want to look into mobx now. Just thought I would throw out there
that I've been using Nuclear-js/Immutable.js and it has a lot of the benefits
you mentioned. All the data manipulation logic is encapsulated nicely, and
merely appears as state to your components. You can observe memoized
transforms in your components so that they only need to listen for the data
they need, rather than a single change event on an entire store.

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

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.

~~~
dangoor
As far as I've seen, it's really only Object spread (likely ES2017 feature)
that's commonly used that is not yet supported by TypeScript. Microsoft has
promised support for it in TS 2.1, and generally stays on top of ECMAScript
proposals that have gained enough traction that they seem likely to ship.

~~~
vcarl
On the other hand, Flow is removed from the code transformation, so it doesn't
have to bother with keeping up with the spec. That's a pretty strong point in
Flow's favor in my opinion, single responsibility principle and all that :)

~~~
spankalee
You can do that in TypeScript too: just target ES6, use all the features like
spread/rest and async/await, then compile the result with Babel.

~~~
dangoor
But The TS parser will see object spread as a syntax error.

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

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!

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:
[http://blog.tomduncalf.com/posts/setting-up-typescript-
and-r...](http://blog.tomduncalf.com/posts/setting-up-typescript-and-react/)

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.

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

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.

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

~~~
gsnedders
At least in my view, there's a couple of big things: Dart doesn't introduce
that many advantages over JS for all of its differences, and TS introduces
many of them with a smaller diff; there's also the presentation of it—Dart was
originally presented as a wholesale replacement of Dart, to ship in all
browsers, the language more or less as a fait accompli, which rubs plenty of
people the wrong way.

~~~
markdog12
> Dart doesn't introduce that many advantages over JS for all of its
> differences

As someone with experience in both languages, I could not disagree more.

> Dart was originally presented as a wholesale replacement of Dart

I think you meant replacement of JS here. I guess it depends entirely on what
you think of JS as a language. I, for one, would rather a language that fixes
core issues with JS, instead of just being a superset of JS.

~~~
gsnedders
> I think you meant replacement of JS here. I guess it depends entirely on
> what you think of JS as a language. I, for one, would rather a language that
> fixes core issues with JS, instead of just being a superset of JS.

If I were aiming to replace JS, I'd fix what Dart does, but I wouldn't stop
with merely fixing what Dart does.

Dart, despite being an entirely new language, has a less expressive type
system than TS. It's transpiler (and it's VM) also does no optimisation based
on the type system, instead heavily relying on the JIT to infer what the types
already imply (e.g., it would be nice to do things like LICM at compile-time).

~~~
markdog12
> has a less expressive type system than TS

Care to elaborate on that?

As for the rest of your comment, I'm with ya. I guess they're reasoning behind
that was they thought a lot of development would start out untyped with
additional types added as development progressed. I think that assumption
didn't pan out, at least that's not how I do it.

Official answer from
[https://www.dartlang.org/faq](https://www.dartlang.org/faq):

"Q. But don’t you need sound typing information to get high performance?

Sound types can help with performance but aren’t essential. What we need are
uniform, simple semantics. Modern VMs can use actual runtime behavior as a
valuable signal for optimizations."

~~~
logicchains
>Care to elaborate on that?

I'm not the OP, but TypeScript supports union types (A | B ; a type that can
be either type A or type B) and intersection types (A & B ; a type that is
both A and B), while Dart doesn't.
[https://www.typescriptlang.org/docs/handbook/advanced-
types....](https://www.typescriptlang.org/docs/handbook/advanced-types.html)

Typescript also has structural types, like Go and OCaml, which many people
find nicer than nominal types. Structural types mean if I have an interface
Blaz with two methods Foo and Bar, if I have an object MyObject with Foo and
Bar methods of the same types then my object counts as a Blaz, while nominal
types mean I have to write something like MyObject extends Blaz.

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

The sky is falling.

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.

~~~
icholy
> I do TypeScript every day for work, and honestly I don't see the point of
> it.

really? I'm assuming you never refactor anything.

~~~
Roboprog
Perhaps menu-driven refactoring is overrated?

(much like IDE generated getter/setter code, which is solving the wrong
problem)

~~~
choward
What do you mean? It's the typescript compiler that catches your errors. The
IDE stuff is nice to have, but it's not the main benefit typescript adds to
refactoring. Typescript doesn't rely on an IDE.

~~~
Roboprog
Apologies, as I am going to make a few assumptions.

If you write fewer classes and class hierarchies, and use higher order
functions (see also - partial function application), you will have much less
"refactoring" to do - often, simply small changes such as to increase the
visible scope of a function you now want to reuse elsewhere, or to "pre bind"
another argument to a function so the caller(s) don't need to know a
particular detail.

This probably has a lot to do with why the static OOP people think the dynamic
FP people are insane: they have no idea how we really work.

We have garbage collectors and closures now. Stop writing code as if in some
crippled version of Simula 67 :-)

------
NhanH
From personal experience, you probably want Babel anyway even with TS to deal
with some weird edge cases.

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.

~~~
baq
webassembly can't come soon enough. as a developer who doesn't deal with
browser frontends what i read in this thread is madness. (3 comments at the
time of writing this...)

~~~
spankalee
WASM doesn't have DOM access or GC. It's not the answer.

~~~
SiVal
Is that correct? WASM has no DOM access? (I'm asking, not advocating
anything.) How does code that runs in a browser do UI I/O without DOM access?
Is the intent that you go on writing all of your I/O and DOM-manipulating code
with JavaScript and call WASM-implemented helper functions from JS code?

~~~
markdog12
No DOM access for the MVP. They do plan on eventually supporting it though:
[https://github.com/WebAssembly/design/blob/master/FutureFeat...](https://github.com/WebAssembly/design/blob/master/FutureFeatures.md)

~~~
themihai
I think we can hack a reverse js proxy before it gets native DOM access.

------
kowdermeister
I'm not sure if this not a sophisticated trolling :) Imagine the question with
random technologies:

If ___________ is so great, how come all notable ________ projects use
__________?

Classic troll magnet :)

~~~
paulddraper
If Apache Spark is so great, how come do all notable JS projects use jQuery?

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

~~~
k__
OT: When will 2.0 finally released?

I saw that they have a completed 2.0.3 milestone in Github, but just a RC
release at the moment.

~~~
denisanerson
No, I mean nightly build 2.1.0: npm install typescript@next

~~~
k__
I know.

I just wanted to know when 2.0 will be officially released and it seems like
never, since they already at 2.1, lol

~~~
moogly
They might be waiting for VS2015 tooling support, because VS2015 support for
TypeScript is still hilariously atrocious.

It feels like the TypeScript team and VS team do not communicate and are set
on completely different workflows.

The VS Code team gets it though, but that's probably because they use TS to
write their very product.

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

If you're interested in this combination, I've published a step-by-step guide
showing how all pieces fit together in:

[https://github.com/ServiceStackApps/typescript-
redux](https://github.com/ServiceStackApps/typescript-redux)

For a decent sized TypeScript + React code-base checkout
[https://github.com/ServiceStack/Gistlyn](https://github.com/ServiceStack/Gistlyn)
\- 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: [http://gistlyn.com](http://gistlyn.com)

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

I love TS and using ng2 at work. If I was using React I would probably also
skip on TS.

~~~
renke1
I recently started using TypeScript for my React projects and I am actually
pretty happy.

I am not actually sure what you mean by typed immutable records in this
context, can you explain in more detail?

~~~
spion
Immutable.js ([https://facebook.github.io/immutable-
js/](https://facebook.github.io/immutable-js/)) doesn't have the greatest
typescript type annotations. Due to limitations of TypeScript, there is no way
to write types for immutable.js heterogenous maps (homogenous Maps and Vectors
are fine though). Since immutable.js collections are recommended to be used
with redux, and no one wants to bother using IMJS records instead of just
maps, the types end up being kinda useless.

A nice typescript-friendly alternative to redux+immutablejs is MobX
([https://mobxjs.github.io/mobx/getting-
started.html](https://mobxjs.github.io/mobx/getting-started.html)). It does go
a bit against the latest cool and hip trends (immutability, functional
programming), but IMO its quite brilliant

~~~
Bahamut
I feel like TypeScript needs some work in areas around typing methods - for
example, I ran into type issues when trying to go more functional via ramda.js
([http://ramdajs.com/](http://ramdajs.com/)) using stuff like compose, and
ultimately it felt like a limitation of TypeScript.

~~~
spion
To properly type Ramda, you need higher kinded types, which are not yet a
feature of TypeScript.

Though I find that Ramda's curried style isn't that useful now that we have
arrow functions...

~~~
Roboprog
Hmm. I find that classes and subclasses aren't all that useful, now that I can
use higher order functions :-)

(I still use classes/objects for services with multiple related operations or
polymorphism, but not for one trick pony "Executioners" for which Java would
use a lambda -- which is what ES6 arrow funcs look like)

I wish I could vote the grandparent post up more.

~~~
spion
What I meant is that pointfree style (which is what Ramda implements) isn't
that great in JS:

* JavaScript is not suited for it (no composition operator, no interop with existing multi-argument functions)

* It doesn't improve readability over arrow syntax.
    
    
      compose(f, flip(g)(y), h)
    

vs

    
    
      x => f(g(h(x), y))

------
kuon
I am using TypeScript in a middle sized app (around 200 react components) and
its help is invaluable for collaborating and sharing APIs.

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.

I think TypeScript is the best thing that happened to the JS community in a
long time.

~~~
saosebastiao
Don't hesitate to jump ship to Mobx. No regrets at all, it was like trading in
a Lada for a Toyota. And being written in typescript, the TS support is
impeccable.

~~~
kuon
I wonder if such comments:
[http://disq.us/p/1bpl2ua](http://disq.us/p/1bpl2ua) are actually based on
reality or just a plain rant.

I worked with SproutCore, Angular and others that tried to be "smart", and
while it was awesome at first, in the long run it was hard to maintain.

~~~
spion
In this video:

[https://www.youtube.com/watch?v=TfxfRkNCnmk](https://www.youtube.com/watch?v=TfxfRkNCnmk)

The author of MobX explains how MobX works and implements a 50 line version of
it (a fast and functional one too, except without the sugary decorator syntax)

You can see the presentation and decide for yourself.

------
HugoDaniel
Why waste your time with half-baked type systems that try to achieve some
compromise over JS idiosyncrasies.

Go all in with purescript[0] :D

Simple, elegant, strong typed and compiles to JS.

[0]: [http://www.purescript.org/](http://www.purescript.org/)

~~~
computerex
Because freedom? Typescript is a superset of JavaScript, which means all
JavaScript is valid typescript. So you're never faced with the difficult
choice of locking yourself to one language/platform. JavaScript is awesome, it
just doesn't scale to large projects because you cannot efficiently refactor
it. Typescript solves this problem beautifully. You can easily add whatever
type information you need to effectively work with the codebase, whilst being
compatible with all JavaScript libraries and the ecosystem.

~~~
HugoDaniel
Does that include ES6 ? What parts of JS do they consider a subset of
typescript ? Can i keep my type declarations in a different file than my .js
code like flow does ? (thus ensuring compatibility while keeping the
functionality of typescript)

How far can i go with typescript until i need to use babel ?

~~~
pitaj
> Does that include ES6 ?

Yes.

> What parts of JS do they consider a subset of typescript ?

Everything that's standardized.

> Can i keep my type declarations in a different file than my .js code like
> flow does ?

Yes.

> How far can i go with typescript until i need to use babel ?

Pretty much as far as you want, although you may have to wait a little bit
longer.

BTW, stop inserting spaces before your punctuation. It's super aggravating.

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

------
greggman
I got a link to these articles from HN a couple of weeks ago.

[https://swlaschin.gitbooks.io/fsharpforfunandprofit/content/...](https://swlaschin.gitbooks.io/fsharpforfunandprofit/content/posts/designing-
for-correctness.html)

What I loved about them is they show how a different type system and language
design can massively reduce code size and errors.

After reading them I felt frustrated back in JavaScript or C# or any other
language I use regularly.

Are Typescript and Flow missing the forest for the trees?

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

~~~
AgentME
Flow only type-checks files that have opted into it with the //@flow comment.
It will have some trouble dealing with the compiled output of another tool
like Typescript. For example, it probably wouldn't understand that output of
how Typescript compiles classes into ES5 represents a class.

Even if using both of them on the same code worked, Flow and Typescript are
both a bit anal about certain dynamic javascript patterns, and I think any
possible extra gains from having both check your code would be canceled out by
having to write your code in ways to please both type-systems.

~~~
labrador
I made the necessary mods (flow doc is not very clear by the way) and thought
it was funny flow complained about TypeScript emitting this:

var live_items = new Array(); ^^^^^^^^^^^ Use array literal instead of new
Array(..)

------
cpdean
"If we descended from monkeys, how come there's still monkeys?"

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

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

~~~
Ezku
Our team is using Flow, and most devs use Nuclide[1] for the autocompletion
and type hint popups. I can't compare it to any TS IDE, I'm afraid, but I can
attest it's way more comfortable than doing without.

[1]:
[https://nuclide.io/docs/languages/flow/](https://nuclide.io/docs/languages/flow/)

------
amelius
OT: is it me or is Babel incredibly slow in translating ES6 to regular JS?

~~~
cprecioso
It is. Try enabling the `compact` option or using something like Buble [1].

[1]: [https://buble.surge.sh](https://buble.surge.sh)

~~~
werkinprogress
I use buble. It transpiles ES6 to ES5 2.5 times faster than babel on average.
But be aware that buble is still a work in progress and only supports a subset
of ES6 features. A very usable subset, but a subset nonetheless.

~~~
hokkos
And has it progress it will be slower to handle the most complex cases and
follow the spec, than they will use a plugin architecture to let users develop
their own language extension and modularize it, than they will only have to
rename it to Babel because it won't be different.

~~~
werkinprogress
The buble project wouldn't exist if babel ran faster and worked out of the box
without setting up confusing config files. It fills a need.

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

And it's even stranger applied to Typescript, which is a fairly good
implementation of a real-world gradual typing system.

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.

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.

The funniest part is that ultimately flow desires to asymptotically approach
what TypeScript already (for the most part) _is_ today.

------
evmar
I found the comment about soundness in the linked post to be kind of an odd
remark.

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

    
    
        let array = [1,2];
        array.pop();
        array.push('hello');
        console.log(array[1] - 3);
    

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.

(Disclaimer: I work with TypeScript and am pretty fond of it.)

~~~
recursive
I guess they fixed it. Try it yourself.
[http://www.typescriptlang.org/play/](http://www.typescriptlang.org/play/)

Argument of type 'string' is not assignable to parameter of type 'number' on
line 3.

~~~
evmar
Sorry for the confusing comment -- I updated it. I was saying that it is
strange for the linked post to talk about soundness being important when it's
trivial to find an unsound Flow program. (This particular program is properly
rejected by TypeScript but TypeScript is also unsound so there are plenty of
other invalid programs that it accepts.)

~~~
recursive
I think it's a lot harder to get past TypeScript's type checker. It's probably
possible, but I can't think of a way to do it off the top of my head without
casting to any. It's a lot easier to show correctly executing javascript
programs that would be rejected by the type checker.

~~~
evmar
Here's one that TypeScript gets wrong. It's kind of a canonical example of a
program that is difficult to get right in a type system. (It's how I found the
Flow example linked upthread.)

    
    
        let x: number[] = [];
        let y: Object[] = x;
        y.push('a');
        let bad = x.pop();
        // bad has type number but is actually a string.

------
nbevans
Since when are "all notable ReactJS projects" the authority on greatness?

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

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

------
intrasight
All this JS and TS churn and stress makes me want to just stick to HTML

------
ZLeviathan
because Facebook doesn't want M wins?

------
hmans
Because the masses will always gravitate towards inferior options.

~~~
douchescript
Maybe "the masses" can code without struts.

------
douchescript
Typescript is a pile of crap that's why.

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

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.

~~~
lsadam0
My team is 'locked' into TS on a large project. We have yet to purchase any TS
related tooling, and have no plans or need to do so. Given that TS transpiles
to JS, I'm unsure as to how any project can be truly 'locked' into the
ecosystem. I'm really unsure what you are basing your fears upon.

~~~
DrJokepu
It's not just that it transpiles into JS, if you target ES6 pretty much all
tsc does besides validation is stripping type information, access modifiers
etc. while basically preserving the code structure, including whitespace.
Which means that if you ever want to migrate away from TypeScript you simply
run tsc one last time and then you'll have a fairly usable JS codebase.

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

Compatible should be same files, new compiler = "just works".

~~~
whatever_dude
I have not encountered this problem. Can you provide an example?

~~~
Bahamut
I'm guessing he/she is referring to using .ts instead of .js

