I wish the same. Unfortunately not many devs are trying out TypeScript.

I've used React+TS for a year now. It works perfectly. The decorators in TS are great to use with the react-redux implementations - makes the code look less verbose

The only problems I have faced is when type definitions are not available for certain libs. The workaround is simple - using "require(...)" instead of "import .. from ..." statements

With type definitions available from npm and @types, its pretty easy compared to the TSD and Typings I had to use earlier.

TypeScript is the 9th most used language on the StackOverflow survey - ahead of languages like Ruby, Swift, and Objective-C - so I wouldn't say that "not many devs" are trying it out. :)

> Unfortunately not many devs are trying out TypeScript.

Really? I've seen so much hype for typescript (though not as much recently). How much is enough?

You should try the "allowJs" tsconfig option, it should allow to use the JS libraries without types with normal syntax (if you do that already with require trick, you are basically doing that anyhow).

Yeah, using Flow with React is painful. Which is weird, considering they're both from Facebook. Want to add a propType for 'children'? Sorry, nope. Want to use the equivalent of PropTypes.node? Good luck with that.

The biggest thing that I see as a barrier to entry for TS (and someone please correct me if this is no longer a problem) is integration with build tools from the rest of the ecosystem. Webpack with fancy loaders, third party language tools (linters, etc.), top-tier non-VS Code editor support, and so on.

TypeScript's strong part is the IDE support. It worked great with Eclipse years ago (using the same language server), it worked with Atom years ago. It has Sublime plugin that also uses the language server (not tried this myself). This is because the whole language is build with IDE tooling in mind. It's also approachable, as more language servers are being built the same way, like the PHP language server that is now gathering steam and will be used in several IDE's also besides VS Code.

Webpack and fancy loaders could be issue if you want type checking on really fancy syntax plugins. (Not sure what they are, since JSX is part of TS) These days you need one Webpack loader anyway for new ES features. It's really great that you can just remove Babel and use ts-loader in place as many of the ES features are already in TS.

The IDE support I yearn for is the really nice autocomplete support you see in tools designed specifically for TS. Last I used it, it was very flimsy in Sublime and Atom--very little in the way of helpful suggestions. Perhaps that's been improved, which I would welcome.

The loaders I use in webpack are mostly around asset loading. Style loaders, integration with other languages (coffeescript...ugh) for some weird legacy code, etc.

Flow is JavaScript (with type annotations) while Typescript is an entirely different language that needs to compile to JavaScript. You do not need any source maps for Flow as it just replace the type annotations with spaces. So you get to eat the cookie and keep it, while with Typescript you eat the cookie and lock yourself in.

This is completely untrue. If you follow the progress of TS, you'll see they are completely committed to only adding features that will end up in JS proper. Time and time again they have refused to add features because they aren't part of Ecmascript.

Making Typescript work in pure js files with commented types is a requested feature.

I have absolutely no doubt that it will get implemented sooner or later. Typescript + vscode team pay great attention to the community.

If you want to see it happen, this is the issue to vote on: https://github.com/Microsoft/TypeScript/issues/9694

No, this is hyperbole and misleading.

Follow their roadmap and stated direction. They have always been committed to aligning with standards and whenever ES adopts new functionality they gravitate to it's lead.

They will never drift off to some mutation that isolates you from the JS ecosystem or its benefits.

If you look up "embrace, extend and extinguish" in the textbook, you will see Microsoft mentioned in the first sentence [1]. If you are old enough to remember Internet Explorer, you've already seen how this works. Consider then that static types do in fact extend JS and perhaps you'll see why this is not so reassuring after all.

[1] https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

I appreciate you standing up to bad behavior of companies. The thing is that was a long time ago in a industry where things change very quickly.

MS has for a while now been opening more of its own systems, embracing linux, following standards instead going proprietary etc.

I'm not saying they've found Jesus, it's mostly pragmatic. A few new leaders have found that this approach simply works better and is less douchey at the same time.

So I would say let go of the EEE era. There is lots of bad behavior still going on that is a greater threat. They could benefit from your energy.

In 2017 blurting out EEE every time MS does something good is spreading FUD.

Typescript is an open language anyways, there is nothing to extinguish

As an employee, I can tell you that the company culture has completely changed. I came in to MS a few months before Windows 7 released. I was just about to quit, when Nadella took over. I decided to wait it out and see. I am glad I did.

EEE died a long time ago. It was pretty much gone under Balmer, although we still didn't really play nice with others. Nadella on the other hand came in, started mending fences with other companies that we had previously ignored, or even had some hostility towards. Let me contrast some differences.

Balmer -> Gave all employees a Windows Phone and got pissed if he saw an employee with a competitors phone. I even saw him pretend he was stomping on an iphone at a Company Meeting. Nadella -> Put out a video from himself stating "Unless you work on certain parts of the Windows team, use whatever device want.

Balmer -> Had Office for IOS and Android mostly feature complete and wouldn't release it. Nadella -> Released it quickly after becoming CEO.

You are insane if you think EEE is still going on. That was over like 10. I'm going to skip Balmer as I am sure you can imagine, these are not things he would have done.

Right now Visual Studio for Mac is in preview. We purchased Xamarin and as far as I know it is now free for everyone except Enterprise.

In the last release of Visual Studio, we shipped Chrome as an optional addon.

Released Visual Studio code which is open source, built on open source products from GitHub and Google Chromium.

Open sourced .NET and made it cross platform. This also enabled us to release PowerShell as open source.

Added Bash on Ubuntu on Windows to Windows 10 by collaborating with Canonical. Seriously? Let that sink in @wiredearp. You can now run native command line tools in REAL linux running on Windows.

Invited the Angular team from Google to get a sneak peek at future plans for TypeScript. After the saw it they dropped AtScript and used TypeScript to build Angular (formally known as Angular 2). It is now the preferred language to consume it as well.

SharePoint, the product I work on will soon open source our new app model which now runs on a standard open source web stack. Webpack, gulp, React, all accounted for.

The static types in TypeScript add value, they weren't added as part of some scheme so later we can... what? I can't even imagine a nefarious end game.

No disrespect intended at all, but if you think this is the Microsoft of the Netscape era, you seriously haven't been paying attention.

What's an example of a TypeScript program where erasing the type information won't produce valid ES6? I had thought Flow and TypeScript were the same in this regard, but I am not an expert.

TypeScript supports ES7 features, for example. It also has a few language-local quirks (like parameter properties, described https://www.typescriptlang.org/docs/handbook/classes.html ).

I find the grandparent argument pretty unconvincing though. People writing Flow are generally using JSX or ES modules (the Flow docs recommend the latter, for example), both of which require a transpiler like Babel to be used in a browser anyway.

I believe that one area where TS could stand some improvement are multi-package projects. https://github.com/Microsoft/TypeScript/issues/3469

Couldn't the same be said about TypeScript? "I wish Microsoft would drop TypeScript at this point. It's been a nice contribution and spurred some competition. But there is no real vision for how it's going to add a lot of value above and beyond Flow."

This is a bit meta, but both of you stated a position without providing a concrete rationale.

Something to consider is that people can gloss over an explanation for convenience. For example: in the previous sentence, I didn't provide any proof that it's accurate. You could make the argument that nobody glosses over explanations for convenience.

I don't think it's necessarily worth proving every statement, because that'd be extremely time-consuming. But if you provide an opposing viewpoint, back it up with clear reasons (this helps filter out positions that are undefendable), and I'm interested in defending my position or continuing the discussion, then we can have a meaningful discussion from that.

> This is a bit meta, but both of you stated a position without providing a concrete rationale.

The primary difference being that "my position" was not actually my position, it was just an attempt to point out exactly what you're trying to say.

I guess I failed ;)

So you disagree or just were wanting to understand the backstory? I would try to help you but the sarcasm makes it unclear the best way to do that.

Neither. I think Flow and TypeScript are both great solutions, and neither is clearly better at this point.