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.
mobx seem to be one year old, that not enough.
I'm not sure what you mean, given the mobx project has existed as mobservable for quite some time.
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 obj…
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.
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.
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.
Your view seems to be from someone who hasn't used Dart extensively, because no one who had would minimize its advantages this way. Being different from JS is the whole point. Dart introduces all the advantages of TS and more, while leaving the baggage and bullshit of JS behind.
Dart has gradual typing > working with existing build tools and module systems I'd say they replaced it with a better tool, pub. The one good argument you have there is .d.ts files. Dart lacks them, but there are tools to generate js bindings from those same .d.ts files. https://github.com/jirkadanek/definitely_typed I haven't used it though, so I can't say if it works as advertised.
> I'd say they replaced it with a better tool, pub. Right but that route ends in forcing people to leap to a whole different ecosystem before they can even try your thing. Whereas with typescript you could put a single .ts file in your existing project without messing with anything else.
I consider the small hop to TS its greatest disadvantage, personally. JS's ecosystem is a horribly broken mess, and any sane person would welcome a leap to another, better designed one. Dart has JS-interoperability for those times when you just can't get away, but TS is like an anchor holding you down in the mire of the JS world.
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.
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.
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 :)
But Flow still needs to be able to parse the JS. If it thinks your JS is invalid, you'all get an error.
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.
Things like babel-core are still a must though.
They are? I haven't run into any problems with the latest typescript@next.
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 :)
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.
But The TS parser will see object spread as a syntax error.
Sorry for my ignorance, but does that amount to loading a library on demand? If so, yes, Dart can do this: import 'package:deferred/hello.dart' deferred as hello; // When you need the library, invoke loadLibrary() using the library’s identifier. greet() async { await hello.loadLibrary(); hello.printGreeting(); }
That does indeed work. I just tried it, and it works beautifully. The only problem is that the main output js file is still 107kb, quite large.
When I test this out, I get a 94KB file. That's reasonable depending on what you're doing.
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.
Dart is a special cookie. You can't use dart with all of Javascript's ecosystem.