I recently did the exact same job as the author of this post.<p>Migrating 15K LoC from JS to TS.<p>The author of Vue.JS also migrated Vue completely to Typescript.<p>At first I had major apprehension because of how much Microsoft generally enforces things on developers.<p>It's well know that if you start using C# , your entire stack will generally be MS based...(SQL Server, Azure etc... )<p>But after I did the migration , I was blown away by how confident and how much flexibility I had when i was writing my code.<p>Even if I have been writing code with Java / C# for nearly a decade , nothing has come close to Typescript in terms of productivity,flexibility and confidence.<p>Having used Javascript since before Node.JS , I think the whole idea of having to "transpile" my code to something or to respect some "rules" define by a company with a reputation that wasn't really "all in open source" .<p>But after using Typescript on multiples projects , you just can't go back , it's incredible how well it's scale without enforcing anything on the developers.<p>Hopefully , one day bootcamps will include Typescript in their trainings to demonstrate how typings can solve maintainability issues...
They wrote: "The TypeScript compiler could theoretically perform bundle optimizations based on types and you are missing on that by having a separate emitter and type checker."<p>Actually, this isn't true, and it's a fundamental property of TypeScript. It's actually the secret to being a TypeScript wizard, and the more you internalize it, the more questions about TypeScript you can answer in advance. I go through some others here: <a href="http://neugierig.org/software/blog/2016/04/typescript-types.html" rel="nofollow">http://neugierig.org/software/blog/2016/04/typescript-types....</a><p>It's an important property in part for exactly the reasons this author worries about it -- it preserves the property always safe to type check and emit separately.<p>It's so fundamental to TS that their bug tracker, when reporting a bug, has a checkbox about whether your request violates this property, and if so they will discard your bug.
Even though I'm a huge TypeScript fan, I'm grateful for the existence of Flow.<p>Their focus on soundness has shown the TypeScript team that they should give a lot more priority to getting the typesystem in a better shape over the years. If Flow didn't exist, I doubt we'd be seeing many of the features in TypeScript's --strict mode.<p>Plus, they were the first to develop some features like intersection types, or even some of the advanced type transformations. Shame it was (at least historically) a bit difficult to find them in the docs.<p>I'm hoping Flow can push TS to close up the remaining soundness gaps, and fix up some of their features (sealed vs open types is much better than the strange object literal checks in TS)
Are there any people that have switched to TypeScript that still think dynamically typed languages have advantages over statically typed ones? Even for small projects with only me working on them, I find static typing saves me a ton of time and dynamic features are very rarely required or useful. The vast majority of bugs in my TypeScript programs collect around the places they interface with untyped JavaScript code.
This is wrong: (from the article)<p><pre><code> function f(leaves: Array<Leaf>, aggregators: Array<Aggregator>): Array<MemsqlNode> {
// The next line errors because you cannot concat aggregators to leaves.
return leaves.concat(aggregators);
}
</code></pre>
That's just wrong, of course you can't concat aggregators and leaves! and Typescript is OK to not accept it. If you want that to be ok, you could do something like<p><pre><code> [].concat(leaves, aggregators)</code></pre>
What about the speed of type-checking? Flow is near-instant by keeping everything live from the last check whereas TypeScript has always been much slower.<p>Other than that aspect (which is very important!) I do think TypeScript is likely a better choice if you use any third party libraries that already have definitions available.
> unfortunately when you share a TypeScript playground link, those settings are not saved in the URL. For this reason, you have to manually set them when you open any TypeScript playground link from this article.<p>There is a much better typescript playground[0] that supports all options in the permalink, for example see this link[1] that has `removeComments` enabled.<p>[0]: <a href="https://typescript-play.js.org" rel="nofollow">https://typescript-play.js.org</a><p>[1]: <a href="https://typescript-play.js.org/?removeComments=true#code/PTAEBUAsEsGdQMYHsC2KCmA7ALqA7tADaGgAmcAhgA5XoUBOAUMprEoegHSFIDmAFAHIocUBliwKvdPiIl66FBWiZBASgDcQA" rel="nofollow">https://typescript-play.js.org/?removeComments=true#code/PTA...</a>
I wish Typescript had support for partial function application, since I use that much more than “Executioner” classes.<p>Actually, I’ve moved away from OOP in general in my JavaScript, only as a last resort. (Not going to put in long comment from tablet screen...)
I'm currently porting about 15k lines of my own JS to TS. There's something so satisfying about finding all kinds of bugs through this process.<p>And what I love the most: anywhere that I absolutely positively don't want to deal with it yet: `any`
> Lower quality editor/IDE integrations (when compared to TypeScript)<p>This is one of my favorite aspects of TypeScript, the first-class support it receives in Monaco Editor (part of VS Code) which is one of the reasons I also chose first-class TypeScript support when making Autumn, since I could embed Monaco right into it and get countless amazing IDE features for free.<p>> unfortunately, we had to change a very small amount of runtime code to fix some logic that TypeScript could not understand<p>Would be very curious what this is, I've only found maybe one or two things TypeScript could not understand, and they were already under active development in the Github repo.
Thanks for sharing that.<p>We've just started a new Node project where typing was one of the main drivers and went through a similar thought process.
We use Flow on our client code but the positive chatter about TypeScript had made us wonder if we should re-think that.
We have similar thoughts on a lot of the trade-offs. Flow feels better at inference but the TypeScript ecosystem is amazing.<p>We ended up sticking with Flow for consistency (and we don't want to migrate the client right now).
It's good to know that a migration isn't impossible if we ever change our minds.
Thanks for this writeup! We also chose Flow in 2016 for the exact same reasons you listed.<p>We aren't planning on switching anytime soon because we also are using Relay which generates flow types for our GraphQL queries - but its good to know its doable if we need to.
For anyone working on Nodejs targeted TypeScript I would highly recommend checking out ts-node. I use it a ton when I want to not worry about the pre-compilation step for various reasons. Can work with absolute imports, and caches code on the first run as well. Pretty sweet.<p><a href="https://github.com/TypeStrong/ts-node" rel="nofollow">https://github.com/TypeStrong/ts-node</a><p>Article mentions ts-jest; can also recommend. I use Jest for all my TS projects from serverless to selenium. Its watch mode is fantastic.<p>I also typically use ts-loader with Webpack instead of Babel.<p>Eh, might as well toss a few more recommendations in there:<p>* source-map-support<p>* Bluebird for long stack traces with async/await(v8 now has a zero-cost feature behind a flag now though as of end of 2018)<p>* Get the debugger hooked up to your browser/nodejs process for a great debug experience
> This number scared us (a lot) at first but we quickly figured out that most of these were related to TypeScript not supporting .js files.<p>Typescript actually does support .js files. You just need to use the `--alowJs` option.
What are the chances of ecmpascript adopting optional typing like they adopted the features in coffescript?<p>I've seen a few proposals around but it seemed that they were are stalled.
Lots of love here for TS. I'd like to share my personal experience with it: I went from "fast and convenient" with JS to constantly fighting against the TS compiler and linter above cryptic type errors. Man, was it frustrating and JS felt suddenly crippled because it was hard to use its dynamics. TS catched a mistake here and there - true - but that did not equal out the hours burned by writing and debbugging type structures. In the end I removed every bit of TS from my projects and continued happily without it. I found out that using JSdoc comments and relying on the linting abilities of my IDE plus writing unit tests gave me stable code as well, without pulling my hair out. I was there before TS and just went back to it.<p>I get that TS may be a good idea if you deal with teams of mediocre devs to prevent they do stupid things but by talking with a couple of JS devs and looking at my own JS experience it seems like the desire of using TS vanishes if you reach a certain experience ans confidence using vanilla JS. It looks like the most people who embrace TS see JS as some kind of inferior thing, anyways - but that might just be a wrong observation by me.
> A very common function in our source code is the invariant function. I can't explain it any better than the documentation does<p>Seems like you'd have an easier time explaining what it does if you'd just called it "assert()" in the first place. This isn't a new concept, why does it have a new name?
No experience of Flow, and I hear all of the opponents of these "superset JavaScript" solutions who lament their inability to really tighten up the language in a way that a true static language would. However, JavaScript is clearly going nowhere anytime soon, and whilst WASM has the ability to change the state of play, I've found adopting TypeScript in general to be hugely beneficial.<p>It's 100% fair to point to all of the things it <i>doesn't</i> provide, or indeed the way that it tries to make JS out to be some classical OOP language which it's not, but it's helped me track bugs and refactor code in ways which would never have been possible without it, and for that I'm grateful. In comparison to other tools such as mypy, TypeScript is light-years ahead in its general ease of use and community support.
I migrated Polar from JS to Typescript:<p><a href="https://getpolarized.io/" rel="nofollow">https://getpolarized.io/</a><p>It's a pretty sizable app. The migration wet pretty smooth and I would absolutely never go back. Typescript is amazing.
Partially inspired by this post (I was already convinced), I finally finished adding typescript to a javascript project I recently inherited. I'm an experienced backend developer but relatively new to frontend javascript stuff. Short term, I need to own this until we can expand our team.<p>Errors that a compiler would normally save me from when doing Java/Kotlin are a major PITA when you are dealing with a foreign code base in Javascript. Over the past few weeks I've slowly gotten comfortable with the code base, the build system (rollup, babel, less, and a few other things etc.), and the frameworks we use (redom, mainly). After updating everything to their latest versions (e.g. babel 6 -> babel 7) and getting that working; I figured adding typescript should be straightforward.<p>Turns out this is super easy and delivers instant value. The hardest part was figuring out what part of our somewhat convoluted build.js script to modify so that it processes ts files as well. After finding the relevant for loop and adding the rollup plugin for typescript that seemed to be working out of the box. I added a tsconfig.json file to support some ecmascript2017 stuff we apparently are using.<p>After that it got easier. I fixed a few hundred lines of javascript code to have types. That's in my first hour of using typescript. VS Code and tslint are very helpful. I also found and fixed the first type bug that slipped through earlier: instant value.<p>Kudos to MS. Vs Studio Code is a game changer. I've been shying away from doingb frontend stuff for years for reasons of it seeming to be backwards to be coding blindfolded with your hands behind your back. VS Studio Code changes that. Autocomplete, quick fixes, refactorings, import organizing, etc. So much better than my browser telling me I messed up by not loading the page.<p>I renamed several js files. Worked my way through the clearly marked warnings. Mostly quick fix works reasonably well. You do need to replace the any type with something more appropriate usually (like e.g. string). Anyway, free of warnings and vs studio code also found and added a redom type definition for us. Awesome. Very impressed with how easy that went.<p>Typescript only for me going forward. Opting out of a perfectly good type system seems silly.
Glad to hear Typescript is winning hearts and minds. They’ve been great maintainers; avoiding the infighting, toxicity, and the perverse incentives that unfortunately plague the front-end landscape.
> We didn't have to buy into an entirely new ecosystem of JavaScript development. Dropping Babel for tsc (TypeScript compiler) was scary because it wouldn't give us the flexibility<p>This shouldn't really have been an issue. It's always possible to not do any transpilation and leave it to another tool
Ok, well done! BUT.... Now port it to something you can really trust like Reason ML. See <a href="https://www.reaktor.com/blog/fear-trust-and-javascript/" rel="nofollow">https://www.reaktor.com/blog/fear-trust-and-javascript/</a>
What is Typescript providing that you don't get by writing 1 test that checks type and by following modern ECMAScript specs? Does that justify a new syntax? The answer I think is no. I see much praise in this thread, but very little definition of why that praise is merited.