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

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

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.

Gulp is the source of so much pain for people and yet so much of the ecosystem keeps suggesting that more gulp is the answer to their gulp problems.

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

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.

More people should consider using Angular 2 for some kinds of projects.

Now, I have professional projects in both Angular 2 and React/Redux ecosystems, and frankly I enjoy using React a lot more in projects where I can focus on the frontend. I moved some projects to isomorphic React (ie, render using React on backend) in Node.js and Rails apps, and thoroughly enjoyed that experience. I keep on top of Elm and omnext and so forth, and I have personal projects built with those, and I do experiments with completely unidirectional dataflow in Elm using an Elixir backend ...

However.

Twice recently, when I had a full-stack project with a relatively short timeline, I made a conscious decision to keep the frontend from getting too uppity and absorbing too much of my mental energy.

In those cases, I used Angular 2, generated from the ng2 CLI.

It's worked pretty well. Well, the first one had some dependency issues from time to time, which is understandable because of the beta -> rc1 -> rcX -> Angular2 release process that was happening.

Why ng2? Well ... not because I'm convinced that it's "the best" in any particular dimension. Its special sauce is supposed to be Zones, which make knowing when side-effects have occurred less something that we have to track and manage manually, but there's other work in that problem space!

I used it because it's an opinionated stack that already has the important pieces in place (router, DI, build/minify, type checking, components), and more importantly, because I can be fairly confident that another dev could get up to speed quickly due to decent docs and guides ... and it's less easy for someone to "paint themselves into a corner" by doing things really wrong.

On a side note, I had submitted this to HN but somehow my submissions are visible only to me and doesn't appear when I checked the newest tab after logging out.

[1]: https://youtu.be/OcUzuQ_31co?t=34m5s (the relevant part in the EmberCamp keynote by Yehuda Katz and Tom Dale)

In my work I deal with a legacy system with an ExtJS GUI. The two ways that ExtJS fails to be opinionated are perpetual pain points for me and my team! One is: every component has a million optional configurations, not to mention all of the events you can listen on. For the most part this is great, but there was never any systematic separation for "here are the absolutely-required things, there are the things which are optional but must be configured together, and over yonder are the things which are totally optional." Then you could require that the required-configs were, say, statically known when you were deriving a concrete class from an abstract one. Instead ExtJS wanted to accept doing all of this stuff at runtime, so because it failed to take a strong stand on its required configs, when you inevitably forget to configure some of them, you get an error puked out from somewhere very deep in the framework, where the call-stack and error messages show nothing related to your class at all, just "TypeError: SomethingYouNeverCaredAbout is null." It would have all been saved if `Ext.define` looked for some "abstractProperties" array, and made sure that every new `Ext.define` either set abstract properties or propagated them, finally checking that whichever ones are still present in the `Ext.create` call are filled in. Simple descriptive error messages are then available when you forget a required config.

The other way ExtJS violates the principle is... God help you if you ever have to figure out how the underlying form submits and grid reloads actually work. You'd think with something so critical, it would be clear... it's not.

"My grid refreshes automatically when the underlying store loads. Great! The underlying store can be loaded or reloaded with the .load() method, which accepts a callback. Wonderful!" It starts off very promising. But then you dig deeper and find that the .load() method packages the params and the callback into some object and then calls some .read() method which doesn't exist on the class you're looking at (inheritance! go up to the superclass!). Once you've traced that down the actual .read() bounces to some .doAction() which repackages these into some `Operation{type: 'readAction'}` or whatever... and then this gets handed up to some Proxy object which then stores it in some meaningless array, because of course these things get batched together... if you're not sick yet you find out that the Proxy needs to push the stuff to some Reader and Writer, just in case you wanted to communicate with the server via XML instead of JSON, or wanted to store the resulting array under a key not named 'results'. But you don't want to do any of this because the query finally gets XMLHttpRequested somehow (God knows how) to some `router.php` which we stole from IBM[1] a long time ago, which finally took a stand, "I will accept these two inputs, send them to the backend this way, and emit one of two corresponding outputs." (Except for that then you open that and it contains code for some sort of `doAroundCalls` because apparently the original author[2] decided to vacillate on what they'd accept, trying to also allow you to bookend one RPC service with two other RPC services, which never happens because Ext.JS never does it!) It gets a little more complicated because there is one rather significant bug which nobody has ever fixed in IBM's router.php, which is that formHandler services get the $_POST params (an associative array) as their first argument whereas XMLHttpRequests get the `json_decode($HTTP_RAW_POST_DATA)` (a StdClass object) as their first argument, so there's no interoperability on the frontend or the backend. Happy debugging, you. It's all one big mess.

You begin to wish ExtJS had done what they eventually ended up doing[3], and just told people, "here is how you're going to do this thing. We have a Java router, a PHP router, here is how you set up your backend on these platforms..." That would have been very bold since ExtJS was originally just a set of helper classes to help automate GUI stuff with YUI, so I understand that the history made them feel a bit shaky about doing that, but... I really don't value that there's 10 layers of abstraction just in case I want to transmit the same stuff over-the-wire in XML rather than JSON.

If any developers of toolkits are reading this: please, please consider very firm protocols: "here is what you're going to send me, and here's what I'm going to respond with." Because, half of programming anyways is translating outputs to inputs; we all know how to write the adapters which connect the two. Please make your life really simple by not supporting a million different ways to do the thing. I promise, you're also making my life simple because even though I will grumble about spending a half-day writing that adapter, I will then save untold dozens of half-days because the overall architecture is modularized, "oh there's a bug in the adapter, my bad, but it's only a 5 minute fix." My communication with you must pass through a gateway; please limit me to only a very small choice of inputs which you are going to tolerate, and break very loudly at the gateway when I forget some of those. It's far better than having a nigh-undebuggable error somewhere in the middle of your framework code that I never want to read.

[1] http://www.ibm.com/developerworks/library/wa-aj-streamline/

[2] This could be Dan Dallala of Microsoft? His Gist appears to be an older version of the file and is one of the top results when googling strings out of the source file...

[3] It's not complete as to how the backend should be set up, but at least there is now a documented interface for this Ext.Direct communication. https://docs.sencha.com/extjs/6.0.1/guides/backend_connector...

Javascript is a language and an ecosystem I really disliked until React and TypeScript came around and changed everything. We're making extensive use of JSX in our React app (https://github.com/hearthsim/joust / https://hsreplay.net/replay/ZXKe5VoqTzknRJNcPdTnYa) and it's really wonderful to both read and write.

If anyone is interested, I have a working boiler plate with React Server rendering using TypeScript[2].

[1]: https://github.com/styfle/typed-tmpl [2]: https://github.com/styfle/react-server-example-tsx

Agreed. Here's an example of JSX in TypeScript that has nothing to do with React. UI Builder is a templating library, just like Mustache, but much better because you get full intellisense and compile-time checking for the template:

https://github.com/wisercoder/uibuilder

Practially not, but it's a bit of a hassle. either you leave the JSX be and parse it with Babel or you need some wrappers for you VDOM lib, because tsc assumes a namespace, while most not-React-vdom libs just deliver a function out of the box.

i suspect a great many typescript users are not open source.

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.

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.

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... [1] https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...

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

Agreed! There's an open issue that addresses that scenario (and a ton of others):

https://github.com/Microsoft/TypeScript/issues/6606

No need to use the RC any more. 2.0 is out!

https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...

[1]: https://www.npmjs.com/package/typescript

[2]: https://github.com/Microsoft/TypeScript/releases

Example:

  const INCREMENT: "increment" = "increment";
  const DECREMENT: "decrement" = "decrement";

  interface Increment {
      type: typeof INCREMENT;
      payload: {
          inc: number;
      };
  }

   interface Decrement {
      type: typeof DECREMENT;
      payload: {
          dec: number;
      };
  }

  interface State { 
      count: number; 
  }

  type Actions = Increment | Decrement;

  function reducer(state: State, action: Actions) {
     switch (action.type) {
        case INCREMENT: {
             const { inc } = action.payload;
             return { count: state.count + inc };
         }
         case DECREMENT: {
             const { dec } = action.payload;
             return { count: state.count + dec };
         }
         default:
             return state;
     }
  }

That's one of the reasons why I miss possibility to tell what is the type of the object that function returns. So I could do something like this (hypothetical syntax)

    const INCREMENT: "increment" = "increment";
    const DECREMENT: "decrement" = "decrement";

    function increment(inc: number) {
        return {
            type: INCREMENT,
            inc
        };
    }

    function decrement(dec: number) {
        return {
            type: DECREMENT,
            dec
        };
    }

    type Actions =
        returntypeof increment
        | returntypeof decrement;

https://npm-stat.com/charts.html?package=babel&package=types...

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

https://npm-stat.com/charts.html?package=babel-core&package=...

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.

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.

esproposal.class_instance_fields=enable

but it chokes on ones it doesn't understand. I tried using Flow and RxJS in the same codebase. RxJS makes heavy use of the pipeline operator:

stream::map(thing) vs map.call(stream, thing)

Flow will stop checking types as soon as it sees ::. Babel parses it, but Flow runs in parallel, so it needs to be able to walk the AST itself.

That's the problem I have with the Babel-everything mentality of a lot of developers, they don't realize that they are essentially created their own quasi-language that they'll have to support on their own.

Many React projects use JSX, decorators and class properties to the max, so they needed babel in the first place.

Now if you want to add types, Flow is easier to integrate than switching to another compiler.

For example, if you desired to implement a plugin for "thin arrows", and a plugin for JSX, how would you parse this?

const x = <foo x = {y -> <y/> } />

You'd have to have the JSX parser know to invoke the thin arrow parser, then the thin arrow parser has to know how to invoke the JSX parser, then when you emit, you have to do the whole dance over again.

If you're willing to take some trade-offs in the parsing phase, it's OK. But the emit is where you get killed - either every plugin has to be written generically and correctly enough to deal with any arbitrary nesting of syntaxes (including the cases where the semantics of nesting aren't even clear, like where a 'fat' arrow here would capture 'this' from), or you do one tree pass per transformer, which gets very expensive.

There's a reason you don't usually see architectures like that live very long.

Maybe the specific example you give can be solved in a very hacky way with something like a priority system but I can see how messy it can get even when tokenizing the possible expressions for such an open "playground", let alone transforming in the correct sequence.

Thank you, Ryan.

edit: Oh you are the person who implemented JSX support for Typescript! How do we buy you a beer, or in this case a six-pack?

That said, if you look at TS as a superset of Babel plugins, there's actually not much to TS that is TS-specific. Adding that to Babel would be relatively simple.

You seem to be arguing it's a slippery slope. We're not talking about arbitrary syntax. We're talking about a fairly well-established syntax extension backed by Google and Microsoft. It doesn't have to perfectly universal and generic to support TS.

EDIT: If you were specifically addressing the parent: yes, if every syntax extension was created as a parser plugin, getting them to work together would be messy, but that's basically what we have in PostCSS isn't it? Plugins explicitly instructing users "this conflicts with X, please add it after Y but before Z" -- which is fine IMO as you only need to care about the most popular ones and everybody else knows their stack is experimental.

Actually kind of the opposite - babel used to use the common ESTree AST format, but they've moved away to something similar but incompatible.

Babel itself demonstrates the truth of this. If you look at the source code for any of Babel's syntax plugins, they are literally only a few lines long, because all they do is activate a feature that is actually part of the parser core.

It seems like Perl 6 is trying to implement pluggable grammars that work like that. Can anyone here familiar with the Perl 6 ecosystem comment on how it's going over there? Can you feasibly write a module with 5 or 6 different grammar extensions? What's it like? My understanding of the situation has matched what RyanCavanaugh expressed here for a while, and I'm curious if people's experiences match it or not.

Then we'll have the Babel problem. E.g. how they handled 2 to 3 transition doesn't inspire confidence.

> If you work outside the San Francisco bubble and are stuck on Windows, Flow isn't really an option at the moment.

> A big factor in my company recently switching to TypeScript was Windows performance, even with the recent massive advancements for Flow on Windows it's still painful to use and the tooling is miles behind.

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

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.

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.

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

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:

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

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

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.

Elaborate then. Because one's major advantages can be another's (and sometimes, objective) trivialities...

No, he means that the Dart team was supposed to solicitate opinions on how to build Dart and what the best objectives for it would be, but instead they showcased it in "almost done" form, and only then tried to attract a community.

The other big problem was that it was done with the VM being a major part of the project with the intent of getting it into Chrome, obviously without having talked that much with several of the people who have significant influence over such things in (then) WebKit, even those within Google. That the VM was going to be outright objected was entirely predictable.

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

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.

You can't just pull your package from pub (leftpad).

Extremely trivial, but I prefer yaml to json, :)

https://www.dartlang.org/tools/pub

I did use CoffeeScript after that, a beautiful little language, but only suitable for smallish projects. I need static typing for large projects.

After that, I learned Dart, and coming from C/C++, Java, AS3, it was a breeze. I find there are no quirks, everything behaves as you'd expect. Other team members were productive in Dart in about a week, without having seen a line of Dart code.

I mostly write HTML5 games and server-side with Dart, so I can't really talk too much about any client-side frameworks.

As for Dart cons, I guess one would be you have to use a different browser for web dev, but it's not really a big deal, I'm kinda reaching here. There aren't as many 3rd party libraries as some other languages. Depending on what you want, you might have to get your hands dirty and issue some pull requests for features/bug fixes for those libs. JS interop can still be a bit tricky too, depending on what you're doing.

Any specific questions, I'd be happy to answer. Also, there's a great slack channel for Dart: https://dartlang-slack.herokuapp.com/

I haven't touched Dart for over a year, but the Flutter page seems like it is on HTML, not native, and it only specifies Linux or OS X dev machine.

https://docs.google.com/presentation/d/1cw7A4HbvM_Abv320rVgP...

I'm going to try it on my Linux box. The only disadvantage I can see for my eventual needs after a second reading is the lack of 3D support. I can get by with 2D for most of my stuff, but for games, I need the 3D hook.

I'll have to see how easy it is to customize the Dart-provided widgets. Might be easier than creating them from scratch in OpenGL via the NDK.

What about using a combination of StageXL and ThreeJS? Then use Cordova to package your HTML5-based app?

http://www.stagexl.org/ http://threejs.org/ https://cordova.apache.org/

Dart is a different language so it's a different path. It's no different than, say, using C# or Java or C or whatever language that can be transpiled to JavaScript.

[1] https://flutter.io/faq/ [2] https://github.com/dart-lang/dev_compiler

  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();
  }

The only problem is that the main output js file is still 107kb, quite large.

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.

really? I'm assuming you never refactor anything.

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

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

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.

grumble grumble grumble

(Of course if yc ever decides to fund our small startup it should know that we are a team of forward thinking progressive individuals who will use the best and most robust tools available to us, who's views i do not necessarily represent)

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

Classic troll magnet :)

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

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

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.

Even the ECMAScript feature table (https://kangax.github.io/compat-table/es6/) uses Babel and TS with core-js when comparing features, otherwise it'd be heavily browser dependent.

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

For a decent sized TypeScript + React code-base checkout 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

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

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

A nice typescript-friendly alternative to redux+immutablejs is MobX (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

Though I find that Ramda's curried style isn't that useful now that we have arrow 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.

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

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

And yes, actually I am using MobX, too, it's really a good choice for React. Although I miss redux-saga sometimes.

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.

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.

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.

I also moved most of the components that had state to use observable variables and it's been working well.

I cannot really speak in term of maintenance or architecture quality yet. But it works.

Go all in with purescript[0] :D

Simple, elegant, strong typed and compiles to JS.

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

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

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.

[0] https://github.com/purescript/purescript/wiki/Differences-fr...

https://swlaschin.gitbooks.io/fsharpforfunandprofit/content/...

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?

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.

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

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

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

Aside: I tend to do much more with higher order functions than with classes, so Typescript and the like really don't excite me very much. I'm happier to skip the whole transpile and source-map shuffle. Also, I tend to put at least partial JSDoc comments on just about everything, so that an open documentation panel explains things as I move the cursor down the file. Any type annotation is also shown on the function names/params in the structure tree browser.

Finally, autocomplete is not as useful when not using "Enterprise" style naming conventions. E.g. - "inv_acct.load()" vs "checkoutInvoicePayableAccount.asynchronousLazyLoadFromRemoteServer()". Hopefully, between context and comments, such ridiculous names aren't really necesary - like, how many "account" type values do you have floating around in the current scope/context???

[0]: http://ternjs.net/

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

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.

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

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

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

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

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 only see advantages for static typing for a small cost of time: you prevent most of Type Error from happening, you get automatic auto-completion, refactoring errors are easier to catch and feel safer. Either way, you need to specify the type of the arguments in the documentation of your function (I can sometimes even find the C# LINQ's function I'm looking for just by looking at the return type of the list of function).

You could even use Flow and Typescript to catch

Aside from the proprietary reasons (which I believe are unfounded since the whole Typescript ecosystem is opensource), why do you think static typing doesn't belong in Javascript ?

https://github.com/Microsoft/TypeScript is uh... right there. Check the license. Visual Studio code runs Textmate snippets and has a very sublime-like extension system.

There is no vendor lock in.

What do you think is the advantage of such a thing? IME they tend to end up as an ad hoc, informally-specified, bug-ridden, slow implementation of half of a type system.