16 ms·

Porting 30K lines of code from Flow to TypeScript

434 points by munchor 8y ago

sephoric 8y ago
> Lower quality editor/IDE integrations (when compared to TypeScript) 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. > unfortunately, we had to change a very small amount of runtime code to fix some logic that TypeScript could not understand 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.
- _asummers 8y ago
  > countless amazing IDE features for free. Is this just from LSP? Or are there extras that are built into VSCode?
  - rsimp 8y ago
    Ironically typescript doesn't have a supported language server from MS. TSServer (in the typescript npm package) is language server-esque and that's what VS Code plugs into. I believe the main language server for typescript is maintained by sourcegraph. VS Code is written in typescript though and the projects have a pretty nice cadence of new features. Typescript is very much a first class citizen in VS Code
    - int_19h 8y ago
      Pretty much anything that comes from Microsoft today that is a web app, or uses the HTML for UI on the desktop (such as Electron apps), is likely to be written in TS. Not even because there's some push to do so, but because people who mostly write in C# and C++ find TS far more preferable. (That, by the way, is one reason why you can trust that it's not going away anytime soon.)
- grrowl 8y ago
  In our case, we had some "fun" React HOCs which were difficult to type properly in TypeScript. We re-wrote the HOC to be easier to read and maintain, so while it cost effort I consider it a net gain.
evmar 8y ago
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." 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: http://neugierig.org/software/blog/2016/04/typescript-types.html http://neugierig.org/software/blog/2016/04/typescript-types.... 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. 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.
- munchor 8y ago
  Author here, I actually addressed this in a footnote linked directly to that sentence you quoted. EDIT: This is incorrect ^, I misread your comment at first. Thank you for bringing this up, this makes me feel even better about using Babel to emit code.
  - RussianCow 8y ago
    I might be missing something, but that sentence does not appear to have a footnote, nor do any of the footnotes directly address the OP's comment.
    - munchor 8y ago
      Oops, you're right, I misunderstood the original comment.
  - evmar 8y ago
    It was a great post, sorry to only have written a criticism! I vaguely recall there was some issue with the Babel emit of enums, but I can't remember it well enough to even remember whether it was fixed or not.
- 8y ago
funkaster 8y ago
This is wrong: (from the article) 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); } 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 [].concat(leaves, aggregators)
- paulddraper 8y ago
  Also, you may consider [...leaves, ...aggregators]
- sephoric 8y ago
  If the return type was Array<Leaf | Aggregator>, wouldn't TypeScript be able to infer the right type U in Array<T>.concat => Array<U> ?
  - WorldMaker 8y ago
    No, because JS concat is an in place operation, Typescript models it as Array<T>.concat() (intentionally leaves it "narrow") rather than Array<T>.concat<U extends T>(). In this case it is the input type that potentially would need to change so that the left hand side was Array<Leaf | Aggregator>. Or as others point out, array spread does widen unlike concat (because it isn't an in-place operation).
    - WorldMaker 8y ago
      Apparently concat does not operate in place, my mistake. I've been coding in TS for so long I assumed its definition was correct. https://news.ycombinator.com/item?id=18907771 https://news.ycombinator.com/item?id=18907771 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/concat https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- munchor 8y ago
  Author here. I understand this example may be a little controversial. However, from my point of view, if I annotate my function as returning an `Array<MemsqlNode>` and `leaves.concat(aggregators)` can be cast to `Array<MemsqlNode>`, then I don't see why I shouldn't be able to return this in this function without verbose syntax or "tricks".
tinyvm 8y ago
I recently did the exact same job as the author of this post. Migrating 15K LoC from JS to TS. The author of Vue.JS also migrated Vue completely to Typescript. At first I had major apprehension because of how much Microsoft generally enforces things on developers. It's well know that if you start using C# , your entire stack will generally be MS based...(SQL Server, Azure etc... ) 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. 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. 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" . 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. Hopefully , one day bootcamps will include Typescript in their trainings to demonstrate how typings can solve maintainability issues...
- sephoric 8y ago
  I'm starting to think Microsoft's strategy with things like VS Code, Monaco editor, and Typescript is "blow the developer away with how amazingly productive they are so that they will want to use more of our products". Because it's just so high quality yet also gratis/libre (MIT license), that I can't see what else they could be trying to do.
  - evilduck 8y ago
    It's probably multi-faceted. Part of me thinks it's just something they use internally extensively and that branching out to the public means they can easily hire talent to work on their own projects. It's also probably an effort to stay relevant and make amends with web developers, who have long held them in low regard. And yeah, Azure is a booming business for them. VSCode has a bunch of first-party extensions that reduce friction for working on their platform.
  - jcmoscon 8y ago
    Yes, and I will start looking into azure because of this same amazing feeling I'm having with VS code and typescript.
styfle 8y ago
> 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. 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. [0]: https://typescript-play.js.org https://typescript-play.js.org [1]: https://typescript-play.js.org/?removeComments=true#code/PTAEBUAsEsGdQMYHsC2KCmA7ALqA7tADaGgAmcAhgA5XoUBOAUMprEoegHSFIDmAFAHIocUBliwKvdPiIl66FBWiZBASgDcQA https://typescript-play.js.org/?removeComments=true#code/PTA...
- russley 8y ago
  There's also a good TypeScript playground clone here as well: https://agentcooper.github.io/typescript-play/ https://agentcooper.github.io/typescript-play/
  - styfle 8y ago
    This links to the same code as my post. You might just have an older bookmark. See this PR[0]. [0]: https://github.com/agentcooper/typescript-play/pull/24 https://github.com/agentcooper/typescript-play/pull/24
ajross 8y ago
> A very common function in our source code is the invariant function. I can't explain it any better than the documentation does 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?
- geoelectric 8y ago
  A function by that name is apparently treated specially for flow. My guess is it interprets it like the if statement OP ended up using, where applies the first condition to the type checking. https://github.com/facebook/flow/issues/112 https://github.com/facebook/flow/issues/112
- zamalek 8y ago
  It originates from design by contract (but is still the incorrect term). An assertion is not a contract.
  - beatgammit 8y ago
    How so? The major design by contract language I know of is D, and its contracts are essentially asserts that are either placed at the beginning of the body or prior to all returns. You can certainly get substantially similar behavior just using asserts at the beginning of the function body and ensuring asserts at the end before a return are hit by all code paths (e.g. make an anonymous function that contains the body, then call it wrapped in a try/catch and assert on the return value. Unless I'm missing something about design by contract, it's essentially just asserts at the beginning and end of a function.
    - zamalek 8y ago
      Precondition (called invariant here): a set of conditions that must be met in order to call a method. Another name for argument validation, but it can be other things (e.g. connected must be true before calling methods on a connection). Postcondition: guarantees that a method makes. For instance, it won't return null. Invariants (incorrectly used): conditions that always hold true on a type, e.g. the starting index on a slice must always be greater or equal to zero. https://en.m.wikipedia.org/wiki/Design_by_contract https://en.m.wikipedia.org/wiki/Design_by_contract I guess D is guessing via implications, but from what you've said it can't support invariants, meaning it doesn't strictly qualify as DbC.
emilsedgh 8y ago
What are the chances of ecmpascript adopting optional typing like they adopted the features in coffescript? I've seen a few proposals around but it seemed that they were are stalled.
- WorldMaker 8y ago
  TC39 still has scars from ES4 which tried to add optional typing (and is the only "lost" ES standard that browsers never implemented). My hope is that since then we have examples like Python's PEP 3107 [0] that help make sense as where a TC39 proposal could move forward: encourage browsers to AST parse type annotations, and ignore them by default; leaving the actual semantics still to tools like Flow and Typescript until there is a better convergence in semantics and/or browsers have greater needs of specific type annotations. [0] https://www.python.org/dev/peps/pep-3107/ https://www.python.org/dev/peps/pep-3107/
- pitaj 8y ago
  It's a really hard thing to spec for runtime.
- Jach 8y ago
  I've had the same thoughts. Seeing what happened with CS, getting too involved in the TS ecosystem seems like setting yourself up for some future pain if what you're doing will be long-lived. I actually think we'll see more advances in webassembly first, though. It won't surprise me if Java makes a comeback for the frontend.
drew-y 8y ago
> 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. Typescript actually does support .js files. You just need to use the `--alowJs` option.
- ng12 8y ago
  I think it's a catastrophically poor decision to not have the allowJs behavior as the default. That one flag fixed almost all of the QOL issues I was having.
  - WorldMaker 8y ago
    It's the default if you name your project-level config file jsconfig.json instead of tsconfig.json, which is an interesting convention versus configuration trade-off. VSCode makes this somewhat clear in some of its tools (it will offer to create a jsconfig or tsconfig for you and tries to guess based on source code metrics), but it's easy to miss in most Typescript documentation.
Waterluvian 8y ago
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. And what I love the most: anywhere that I absolutely positively don't want to deal with it yet: `any`
seanwilson 8y ago
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.
- draw_down 8y ago
  I use Flow at work, and have plenty of experience with both statically-typed and dynamically-typed languages. I think it's a simple tradeoff- more certainty for more toil. It can be a real chore convincing Flow that working code works, and this can force you to use less-readable idioms to make the typechecker happy. It also lards up your code with extra dollar signs, angle brackets, and other crud, making it less readable. These can be acceptable costs depending on your project, particularly the size of it (in lines of code, components, number of engineers, however you care to count).
- Roboprog 8y ago
  Small population that would expend the effort for something expected to be of little benefit at best. Some people can’t seem to function without static (global?) types though, and this works for them.
- Jach 8y ago
  Does TypeScript let you build a program interactively as a living thing? Example of what dynamic languages for the browser (ClojureScript) have been doing for 5 years now: https://www.youtube.com/watch?v=KZjFVdU8VLI https://www.youtube.com/watch?v=KZjFVdU8VLI Given that frontend work is so often an endless series of tweaks I don't know how people stand doing anything big for a long duration the classic way of edit -> compile (refresh) -> rebuild runtime state to look at what changed/play around/test -> repeat.
  - WorldMaker 8y ago
    Typescript can be indeed run directly inside the browser, though that's often not recommended, and none of the currently recommended "Hot Module Reloading" tools that I know of take that approach. Most of the HMR tools out there support Typescript in some way directly or indirectly (Typescript plugins for webpack, etc). `tsc --watch` is quite handy and useful in those situations where an HMR tool doesn't support Typescript or you aren't using an HMR tool at all. (For instance, on one project recently I've been just using npm package `lite-server` which implements "BrowserSync" automatic reload and `tsc --watch`, because I currently don't need a full bundler like webpack, though I expect that to change soon.)
burtonator 8y ago
I migrated Polar from JS to Typescript: https://getpolarized.io/ https://getpolarized.io/ It's a pretty sizable app. The migration wet pretty smooth and I would absolutely never go back. Typescript is amazing.
- lf-non 8y ago
  Polar looks brilliant. Thanks for creating this and making this open source.
chrisan 8y ago
Any opinions on Webstorm vs Visual Studio for using TypeScript?
- alexishere1234 8y ago
  I was a long time Webstorm user until switching to Typescript, and found that its Typescript support is pretty far behind VSCode's. Its been around 6 months since I switched so I can't remember the specifics, except that VSCode generally had better indicators of what was wrong with the type. Neither is perfect at displaying errors but that might also have something to do with your ts config. I also think that Webstorm is a much better editor than VSCode in every other respect, but for me VSCode is 1% better for my productivity so I am forced to use it.
  - h1d 8y ago
    Wouldn't relying on the language server service yield the same results from checks?
  - smt88 8y ago
    > found that its Typescript support is pretty far behind VSCode This isn't (can't be?) true. Both editors use the same language server. I've used both and found their language support to be identical, and WebStorm feels a little more natural to me when using automated refactoring. I also have both eslint and tslint set up through WebStorm, so I have everything integrated in one place: hinting, linting, compiler warnings, and compiler errors. VS Code can do the same, as far as I know. I just prefer WebStorm for other reasons.
- brett40324 8y ago
  Unless I'm mistaken, one major difference is that Webstorm costs money.
  - h1d 8y ago
    Which isn't "major" if you figure out it's just $5 a month (down to $3 from your 3rd year).
NoParking 8y ago
Thanks for sharing that. 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. 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.
derekdahmer 8y ago
Thanks for this writeup! We also chose Flow in 2016 for the exact same reasons you listed. 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.
- eliperkins 8y ago
  Relay supports generating Typescript types for queries as of v1.7.0 [1]: https://github.com/facebook/relay/pull/2293 https://github.com/facebook/relay/pull/2293 [2]: https://github.com/relay-tools/relay-compiler-language-typescript https://github.com/relay-tools/relay-compiler-language-types...
Roboprog 8y ago
I wish Typescript had support for partial function application, since I use that much more than “Executioner” classes. 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...)
- paulddraper 8y ago
  Outside of type annotations, Typescript never supports syntax that isn't in an ECMAScript standard or a popular proposal. That said, there is a Stage 1 TC39 proposal for partial application. https://github.com/tc39/proposal-partial-application https://github.com/tc39/proposal-partial-application
  - Roboprog 8y ago
    Thanks for the tip. I have been using Ramda’s R.partial() function a bit, as well as some in-house stuff (e.g. - to generate 0-arity event handlers), but this would be a very helpful feature, particularly once IDE recognition becomes widespread. Background: suite of related projects started in early 2015, ES5 on IE11 kind of limitations... (recently started using a transpiler for syntactic sugar)
- javadocmd 8y ago
  Partial function application would be sweet. I wind up manually currying a lot of functions and readability starts to get sketchy. const foo = (a: number, b: number): number => { /*...*/ } to const foo = (a: number) => (b: number): number => { /*...*/ }
gregwebs 8y ago
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. 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.
- Rapzid 8y ago
  I work exclusively in VS Code with TypeScript. It is very fast after it first parses the project which isn't instant, but I often use the AWS SDK and some other packages with very large type surfaces. I'm not sure how fine grain it gets with caching, but it feels like it at most only ever needs to re-evaluate the file you are editing and this is practically unnoticeable to me.
- iamaelephant 8y ago
  I work on a >100KLOC Flow codebase and I can tell you the type checker is anything but instant.
spion 8y ago
Even though I'm a huge TypeScript fan, I'm grateful for the existence of Flow. 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. 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. 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)
- nojvek 8y ago
  Competition, even for open source projects is a great boon. I really would hate for Facebook to kill off flow because Typescript is popular. Microsoft, as great as they are at OSS, they still have to answer to a chain of Managers who are distant from the actual users of their software.
  - ssttoo 8y ago
    > Microsoft, as great as they are at OSS Just a few years ago, that would have been a laugh. Don’t get me wrong, I love the world we’re living in :)
  - acifani 8y ago
    I actually think TS team is much closer to the community than Flow's. Just look at the number of open and closed Issues on GitHub. To me, Flow feels like something they needed in Facebook and they happened to open source. Their main focus is still FB's internal use and the direction is set by it. TypeScript, on the other hand, does not feel like this at all. They truly put the community first, or so I - and many others - feel like.
    - smt88 8y ago
      > Flow feels like something they needed in Facebook and they happened to open source This is how most Facebook tools feel to me. It makes me afraid to use them. React is possibly an exception, but again -- too afraid to use it because Facebook's open-source offerings seemed to have only selfish goals in the past and often seem to be full of important bugs.
Rapzid 8y ago
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. https://github.com/TypeStrong/ts-node https://github.com/TypeStrong/ts-node Article mentions ts-jest; can also recommend. I use Jest for all my TS projects from serverless to selenium. Its watch mode is fantastic. I also typically use ts-loader with Webpack instead of Babel. Eh, might as well toss a few more recommendations in there: * source-map-support * 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) * Get the debugger hooked up to your browser/nodejs process for a great debug experience
- jelling 8y ago
  We use it but it can cause complications with other tools that expect compiled JavaScript such as testing and code coverage. They're solveable but the choice isn't free.
- h1d 8y ago
  Note for --transpileOnly flag which speeds up compilation if you've already checked for typing errors in your editors and don't need to do it again on compilation. There's also ts-node-dev which is a variation of node-dev that auto reloads files loaded on change. As for a bundler, parcel supports TypeScript out of the box which just allows you to write browser side code with TS without effort.
hitekker 8y ago
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.
diaktifkan 8y ago
> We're not done with improving the static type analysis in our code. Nor will you ever be. And that's why you shouldn't write back-ends in JS.
chris_engel 8y ago
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. 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.
- PudgePacket 8y ago
  Damn, a sweeping generalisation if ever I've seen one. Are all the people using c++, java, haskell just mediocre devs because they like the safety brought by a type system over lisp or python? Microsoft, Facebook, and Google all wrote either a type system over JS or a JS alternative because of the problems they faced with vanilla JS. Facebook is even doing both ‍️. Perhaps spending some time looking at how certain libraries write their type definitions will help you learn how to use them, if you're constantly fighting you are probably missing some fundamental concept that TS operates with. TS has also gotten much better at expressing more complex types over time and there are still more things on the roadmap. For me TS only grows more useful as the size of the codebase increases. It allows safe refactorings you could only dream of in a large JS codebase.
- wwwigham 8y ago
  > I went from "fast and convenient" with JS to constantly fighting against the TS compiler and linter above cryptic type errors Would you, perchance, be able to share an example of such an error? We generally strive to improve error clarity where possible~ > I found out that using JSdoc comments and relying on the linting abilities of my IDE Ah. Well, spoiler alert: if your IDE is vscode or VS that JSDoc is actually still getting typechecked by TypeScript ;)
fbn79 8y ago
Ok, well done! BUT.... Now port it to something you can really trust like Reason ML. See https://www.reaktor.com/blog/fear-trust-and-javascript/ https://www.reaktor.com/blog/fear-trust-and-javascript/
- islon 8y ago
  Or Purescript =)
2T1Qka0rEiPr 8y ago
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. It's 100% fair to point to all of the things it doesn't 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.
kyranjamie 8y ago
> 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 This shouldn't really have been an issue. It's always possible to not do any transpilation and leave it to another tool
jillesvangurp 8y ago
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. 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. 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. 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. 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. 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. Typescript only for me going forward. Opting out of a perfectly good type system seems silly.
Zooper 8y ago
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.
- icholy 8y ago
  > writing 1 test that checks type If you enjoy being a human type checker, no-one in stopping you.
- manigandham 8y ago
  Tests don't cover everything and just on input and result. All the code in the middle can still have bugs that are uncaught because you don't have the right test for it. Type systems provide a lot of safety with less work, meaning less bugs and more productivity. Just having the definitions available when writing makes you go faster.
  - speedplane 8y ago
    > Type systems provide a lot of safety with less work, meaning less bugs and more productivity I hear this argument all the time. As well as the opposite: type systems slow you down and only catch easy-to-find bugs. Would love to see a real study that quantifies productivity among static and dynamic systems and ends this flame-war once and for all.
    - manigandham 8y ago
      I dont think there are formal studies but there are quite a few discussions, this one on SE is good: https://softwareengineering.stackexchange.com/questions/59606/is-static-typing-worth-the-trade-offs https://softwareengineering.stackexchange.com/questions/5960...

434 points by munchor 8y ago

> Lower quality editor/IDE integrations (when compared to TypeScript) 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. > unfortunately, we had to change a very small amount of runtime code to fix some logic that TypeScript could not understand 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.

_asummers 8y ago
> countless amazing IDE features for free. Is this just from LSP? Or are there extras that are built into VSCode?
- rsimp 8y ago
  Ironically typescript doesn't have a supported language server from MS. TSServer (in the typescript npm package) is language server-esque and that's what VS Code plugs into. I believe the main language server for typescript is maintained by sourcegraph. VS Code is written in typescript though and the projects have a pretty nice cadence of new features. Typescript is very much a first class citizen in VS Code
  - int_19h 8y ago
    Pretty much anything that comes from Microsoft today that is a web app, or uses the HTML for UI on the desktop (such as Electron apps), is likely to be written in TS. Not even because there's some push to do so, but because people who mostly write in C# and C++ find TS far more preferable. (That, by the way, is one reason why you can trust that it's not going away anytime soon.)
grrowl 8y ago
In our case, we had some "fun" React HOCs which were difficult to type properly in TypeScript. We re-wrote the HOC to be easier to read and maintain, so while it cost effort I consider it a net gain.

evmar 8y ago

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." 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: http://neugierig.org/software/blog/2016/04/typescript-types.html http://neugierig.org/software/blog/2016/04/typescript-types.... 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. 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.

munchor 8y ago
Author here, I actually addressed this in a footnote linked directly to that sentence you quoted. EDIT: This is incorrect ^, I misread your comment at first. Thank you for bringing this up, this makes me feel even better about using Babel to emit code.
- RussianCow 8y ago
  I might be missing something, but that sentence does not appear to have a footnote, nor do any of the footnotes directly address the OP's comment.
  - munchor 8y ago
    Oops, you're right, I misunderstood the original comment.
- evmar 8y ago
  It was a great post, sorry to only have written a criticism! I vaguely recall there was some issue with the Babel emit of enums, but I can't remember it well enough to even remember whether it was fixed or not.
8y ago

funkaster 8y ago

This is wrong: (from the article) 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); } 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 [].concat(leaves, aggregators)

paulddraper 8y ago
Also, you may consider [...leaves, ...aggregators]
sephoric 8y ago
If the return type was Array<Leaf | Aggregator>, wouldn't TypeScript be able to infer the right type U in Array<T>.concat => Array<U> ?
- WorldMaker 8y ago
  No, because JS concat is an in place operation, Typescript models it as Array<T>.concat() (intentionally leaves it "narrow") rather than Array<T>.concat<U extends T>(). In this case it is the input type that potentially would need to change so that the left hand side was Array<Leaf | Aggregator>. Or as others point out, array spread does widen unlike concat (because it isn't an in-place operation).
  - WorldMaker 8y ago
    Apparently concat does not operate in place, my mistake. I've been coding in TS for so long I assumed its definition was correct. https://news.ycombinator.com/item?id=18907771 https://news.ycombinator.com/item?id=18907771 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/concat https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
munchor 8y ago
Author here. I understand this example may be a little controversial. However, from my point of view, if I annotate my function as returning an `Array<MemsqlNode>` and `leaves.concat(aggregators)` can be cast to `Array<MemsqlNode>`, then I don't see why I shouldn't be able to return this in this function without verbose syntax or "tricks".

tinyvm 8y ago

I recently did the exact same job as the author of this post. Migrating 15K LoC from JS to TS. The author of Vue.JS also migrated Vue completely to Typescript. At first I had major apprehension because of how much Microsoft generally enforces things on developers. It's well know that if you start using C# , your entire stack will generally be MS based...(SQL Server, Azure etc... ) 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. 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. 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" . 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. Hopefully , one day bootcamps will include Typescript in their trainings to demonstrate how typings can solve maintainability issues...

sephoric 8y ago
I'm starting to think Microsoft's strategy with things like VS Code, Monaco editor, and Typescript is "blow the developer away with how amazingly productive they are so that they will want to use more of our products". Because it's just so high quality yet also gratis/libre (MIT license), that I can't see what else they could be trying to do.
- evilduck 8y ago
  It's probably multi-faceted. Part of me thinks it's just something they use internally extensively and that branching out to the public means they can easily hire talent to work on their own projects. It's also probably an effort to stay relevant and make amends with web developers, who have long held them in low regard. And yeah, Azure is a booming business for them. VSCode has a bunch of first-party extensions that reduce friction for working on their platform.
- jcmoscon 8y ago
  Yes, and I will start looking into azure because of this same amazing feeling I'm having with VS code and typescript.

styfle 8y ago

> 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. 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. [0]: https://typescript-play.js.org https://typescript-play.js.org [1]: https://typescript-play.js.org/?removeComments=true#code/PTAEBUAsEsGdQMYHsC2KCmA7ALqA7tADaGgAmcAhgA5XoUBOAUMprEoegHSFIDmAFAHIocUBliwKvdPiIl66FBWiZBASgDcQA https://typescript-play.js.org/?removeComments=true#code/PTA...

russley 8y ago
There's also a good TypeScript playground clone here as well: https://agentcooper.github.io/typescript-play/ https://agentcooper.github.io/typescript-play/
- styfle 8y ago
  This links to the same code as my post. You might just have an older bookmark. See this PR[0]. [0]: https://github.com/agentcooper/typescript-play/pull/24 https://github.com/agentcooper/typescript-play/pull/24

ajross 8y ago

> A very common function in our source code is the invariant function. I can't explain it any better than the documentation does 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?

geoelectric 8y ago
A function by that name is apparently treated specially for flow. My guess is it interprets it like the if statement OP ended up using, where applies the first condition to the type checking. https://github.com/facebook/flow/issues/112 https://github.com/facebook/flow/issues/112
zamalek 8y ago
It originates from design by contract (but is still the incorrect term). An assertion is not a contract.
- beatgammit 8y ago
  How so? The major design by contract language I know of is D, and its contracts are essentially asserts that are either placed at the beginning of the body or prior to all returns. You can certainly get substantially similar behavior just using asserts at the beginning of the function body and ensuring asserts at the end before a return are hit by all code paths (e.g. make an anonymous function that contains the body, then call it wrapped in a try/catch and assert on the return value. Unless I'm missing something about design by contract, it's essentially just asserts at the beginning and end of a function.
  - zamalek 8y ago
    Precondition (called invariant here): a set of conditions that must be met in order to call a method. Another name for argument validation, but it can be other things (e.g. connected must be true before calling methods on a connection). Postcondition: guarantees that a method makes. For instance, it won't return null. Invariants (incorrectly used): conditions that always hold true on a type, e.g. the starting index on a slice must always be greater or equal to zero. https://en.m.wikipedia.org/wiki/Design_by_contract https://en.m.wikipedia.org/wiki/Design_by_contract I guess D is guessing via implications, but from what you've said it can't support invariants, meaning it doesn't strictly qualify as DbC.

emilsedgh 8y ago

What are the chances of ecmpascript adopting optional typing like they adopted the features in coffescript? I've seen a few proposals around but it seemed that they were are stalled.

WorldMaker 8y ago
TC39 still has scars from ES4 which tried to add optional typing (and is the only "lost" ES standard that browsers never implemented). My hope is that since then we have examples like Python's PEP 3107 [0] that help make sense as where a TC39 proposal could move forward: encourage browsers to AST parse type annotations, and ignore them by default; leaving the actual semantics still to tools like Flow and Typescript until there is a better convergence in semantics and/or browsers have greater needs of specific type annotations. [0] https://www.python.org/dev/peps/pep-3107/ https://www.python.org/dev/peps/pep-3107/
pitaj 8y ago
It's a really hard thing to spec for runtime.
Jach 8y ago
I've had the same thoughts. Seeing what happened with CS, getting too involved in the TS ecosystem seems like setting yourself up for some future pain if what you're doing will be long-lived. I actually think we'll see more advances in webassembly first, though. It won't surprise me if Java makes a comeback for the frontend.

drew-y 8y ago

> 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. Typescript actually does support .js files. You just need to use the `--alowJs` option.

ng12 8y ago
I think it's a catastrophically poor decision to not have the allowJs behavior as the default. That one flag fixed almost all of the QOL issues I was having.
- WorldMaker 8y ago
  It's the default if you name your project-level config file jsconfig.json instead of tsconfig.json, which is an interesting convention versus configuration trade-off. VSCode makes this somewhat clear in some of its tools (it will offer to create a jsconfig or tsconfig for you and tries to guess based on source code metrics), but it's easy to miss in most Typescript documentation.

Waterluvian 8y ago

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. And what I love the most: anywhere that I absolutely positively don't want to deal with it yet: `any`

seanwilson 8y ago

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.

draw_down 8y ago
I use Flow at work, and have plenty of experience with both statically-typed and dynamically-typed languages. I think it's a simple tradeoff- more certainty for more toil. It can be a real chore convincing Flow that working code works, and this can force you to use less-readable idioms to make the typechecker happy. It also lards up your code with extra dollar signs, angle brackets, and other crud, making it less readable. These can be acceptable costs depending on your project, particularly the size of it (in lines of code, components, number of engineers, however you care to count).
Roboprog 8y ago
Small population that would expend the effort for something expected to be of little benefit at best. Some people can’t seem to function without static (global?) types though, and this works for them.
Jach 8y ago
Does TypeScript let you build a program interactively as a living thing? Example of what dynamic languages for the browser (ClojureScript) have been doing for 5 years now: https://www.youtube.com/watch?v=KZjFVdU8VLI https://www.youtube.com/watch?v=KZjFVdU8VLI Given that frontend work is so often an endless series of tweaks I don't know how people stand doing anything big for a long duration the classic way of edit -> compile (refresh) -> rebuild runtime state to look at what changed/play around/test -> repeat.
- WorldMaker 8y ago
  Typescript can be indeed run directly inside the browser, though that's often not recommended, and none of the currently recommended "Hot Module Reloading" tools that I know of take that approach. Most of the HMR tools out there support Typescript in some way directly or indirectly (Typescript plugins for webpack, etc). `tsc --watch` is quite handy and useful in those situations where an HMR tool doesn't support Typescript or you aren't using an HMR tool at all. (For instance, on one project recently I've been just using npm package `lite-server` which implements "BrowserSync" automatic reload and `tsc --watch`, because I currently don't need a full bundler like webpack, though I expect that to change soon.)

burtonator 8y ago

I migrated Polar from JS to Typescript: https://getpolarized.io/ https://getpolarized.io/ It's a pretty sizable app. The migration wet pretty smooth and I would absolutely never go back. Typescript is amazing.

lf-non 8y ago
Polar looks brilliant. Thanks for creating this and making this open source.

chrisan 8y ago

Any opinions on Webstorm vs Visual Studio for using TypeScript?

alexishere1234 8y ago
I was a long time Webstorm user until switching to Typescript, and found that its Typescript support is pretty far behind VSCode's. Its been around 6 months since I switched so I can't remember the specifics, except that VSCode generally had better indicators of what was wrong with the type. Neither is perfect at displaying errors but that might also have something to do with your ts config. I also think that Webstorm is a much better editor than VSCode in every other respect, but for me VSCode is 1% better for my productivity so I am forced to use it.
- h1d 8y ago
  Wouldn't relying on the language server service yield the same results from checks?
- smt88 8y ago
  > found that its Typescript support is pretty far behind VSCode This isn't (can't be?) true. Both editors use the same language server. I've used both and found their language support to be identical, and WebStorm feels a little more natural to me when using automated refactoring. I also have both eslint and tslint set up through WebStorm, so I have everything integrated in one place: hinting, linting, compiler warnings, and compiler errors. VS Code can do the same, as far as I know. I just prefer WebStorm for other reasons.
brett40324 8y ago
Unless I'm mistaken, one major difference is that Webstorm costs money.
- h1d 8y ago
  Which isn't "major" if you figure out it's just $5 a month (down to $3 from your 3rd year).

NoParking 8y ago

Thanks for sharing that. 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. 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.

derekdahmer 8y ago

Thanks for this writeup! We also chose Flow in 2016 for the exact same reasons you listed. 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.

eliperkins 8y ago
Relay supports generating Typescript types for queries as of v1.7.0 [1]: https://github.com/facebook/relay/pull/2293 https://github.com/facebook/relay/pull/2293 [2]: https://github.com/relay-tools/relay-compiler-language-typescript https://github.com/relay-tools/relay-compiler-language-types...

Roboprog 8y ago

I wish Typescript had support for partial function application, since I use that much more than “Executioner” classes. 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...)

paulddraper 8y ago
Outside of type annotations, Typescript never supports syntax that isn't in an ECMAScript standard or a popular proposal. That said, there is a Stage 1 TC39 proposal for partial application. https://github.com/tc39/proposal-partial-application https://github.com/tc39/proposal-partial-application
- Roboprog 8y ago
  Thanks for the tip. I have been using Ramda’s R.partial() function a bit, as well as some in-house stuff (e.g. - to generate 0-arity event handlers), but this would be a very helpful feature, particularly once IDE recognition becomes widespread. Background: suite of related projects started in early 2015, ES5 on IE11 kind of limitations... (recently started using a transpiler for syntactic sugar)
javadocmd 8y ago
Partial function application would be sweet. I wind up manually currying a lot of functions and readability starts to get sketchy. const foo = (a: number, b: number): number => { /*...*/ } to const foo = (a: number) => (b: number): number => { /*...*/ }

gregwebs 8y ago

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

Rapzid 8y ago
I work exclusively in VS Code with TypeScript. It is very fast after it first parses the project which isn't instant, but I often use the AWS SDK and some other packages with very large type surfaces. I'm not sure how fine grain it gets with caching, but it feels like it at most only ever needs to re-evaluate the file you are editing and this is practically unnoticeable to me.
iamaelephant 8y ago
I work on a >100KLOC Flow codebase and I can tell you the type checker is anything but instant.

spion 8y ago

Even though I'm a huge TypeScript fan, I'm grateful for the existence of Flow. 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. 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. 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)

nojvek 8y ago
Competition, even for open source projects is a great boon. I really would hate for Facebook to kill off flow because Typescript is popular. Microsoft, as great as they are at OSS, they still have to answer to a chain of Managers who are distant from the actual users of their software.
- ssttoo 8y ago
  > Microsoft, as great as they are at OSS Just a few years ago, that would have been a laugh. Don’t get me wrong, I love the world we’re living in :)
- acifani 8y ago
  I actually think TS team is much closer to the community than Flow's. Just look at the number of open and closed Issues on GitHub. To me, Flow feels like something they needed in Facebook and they happened to open source. Their main focus is still FB's internal use and the direction is set by it. TypeScript, on the other hand, does not feel like this at all. They truly put the community first, or so I - and many others - feel like.
  - smt88 8y ago
    > Flow feels like something they needed in Facebook and they happened to open source This is how most Facebook tools feel to me. It makes me afraid to use them. React is possibly an exception, but again -- too afraid to use it because Facebook's open-source offerings seemed to have only selfish goals in the past and often seem to be full of important bugs.

Rapzid 8y ago

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. https://github.com/TypeStrong/ts-node https://github.com/TypeStrong/ts-node Article mentions ts-jest; can also recommend. I use Jest for all my TS projects from serverless to selenium. Its watch mode is fantastic. I also typically use ts-loader with Webpack instead of Babel. Eh, might as well toss a few more recommendations in there: * source-map-support * 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) * Get the debugger hooked up to your browser/nodejs process for a great debug experience

jelling 8y ago
We use it but it can cause complications with other tools that expect compiled JavaScript such as testing and code coverage. They're solveable but the choice isn't free.
h1d 8y ago
Note for --transpileOnly flag which speeds up compilation if you've already checked for typing errors in your editors and don't need to do it again on compilation. There's also ts-node-dev which is a variation of node-dev that auto reloads files loaded on change. As for a bundler, parcel supports TypeScript out of the box which just allows you to write browser side code with TS without effort.

hitekker 8y ago

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.

diaktifkan 8y ago

> We're not done with improving the static type analysis in our code. Nor will you ever be. And that's why you shouldn't write back-ends in JS.

chris_engel 8y ago

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

PudgePacket 8y ago
Damn, a sweeping generalisation if ever I've seen one. Are all the people using c++, java, haskell just mediocre devs because they like the safety brought by a type system over lisp or python? Microsoft, Facebook, and Google all wrote either a type system over JS or a JS alternative because of the problems they faced with vanilla JS. Facebook is even doing both ‍️. Perhaps spending some time looking at how certain libraries write their type definitions will help you learn how to use them, if you're constantly fighting you are probably missing some fundamental concept that TS operates with. TS has also gotten much better at expressing more complex types over time and there are still more things on the roadmap. For me TS only grows more useful as the size of the codebase increases. It allows safe refactorings you could only dream of in a large JS codebase.
wwwigham 8y ago
> I went from "fast and convenient" with JS to constantly fighting against the TS compiler and linter above cryptic type errors Would you, perchance, be able to share an example of such an error? We generally strive to improve error clarity where possible~ > I found out that using JSdoc comments and relying on the linting abilities of my IDE Ah. Well, spoiler alert: if your IDE is vscode or VS that JSDoc is actually still getting typechecked by TypeScript ;)

fbn79 8y ago

Ok, well done! BUT.... Now port it to something you can really trust like Reason ML. See https://www.reaktor.com/blog/fear-trust-and-javascript/ https://www.reaktor.com/blog/fear-trust-and-javascript/

islon 8y ago
Or Purescript =)

2T1Qka0rEiPr 8y ago

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. It's 100% fair to point to all of the things it doesn't 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.

kyranjamie 8y ago

> 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 This shouldn't really have been an issue. It's always possible to not do any transpilation and leave it to another tool

jillesvangurp 8y ago

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. 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. 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. 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. 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. 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. Typescript only for me going forward. Opting out of a perfectly good type system seems silly.

Zooper 8y ago

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.

icholy 8y ago
> writing 1 test that checks type If you enjoy being a human type checker, no-one in stopping you.
manigandham 8y ago
Tests don't cover everything and just on input and result. All the code in the middle can still have bugs that are uncaught because you don't have the right test for it. Type systems provide a lot of safety with less work, meaning less bugs and more productivity. Just having the definitions available when writing makes you go faster.
- speedplane 8y ago
  > Type systems provide a lot of safety with less work, meaning less bugs and more productivity I hear this argument all the time. As well as the opposite: type systems slow you down and only catch easy-to-find bugs. Would love to see a real study that quantifies productivity among static and dynamic systems and ends this flame-war once and for all.
  - manigandham 8y ago
    I dont think there are formal studies but there are quite a few discussions, this one on SE is good: https://softwareengineering.stackexchange.com/questions/59606/is-static-typing-worth-the-trade-offs https://softwareengineering.stackexchange.com/questions/5960...