Reasons to use Babel:
* Babel supports bleeding-edge proposed language features like the pipeline operator, throw expressions, optional chaining, etc.
* Babel lets you run custom transforms like babel-plugin-idx and babel-plugin-rewire.
* Babel gives you more control over exactly which transforms you want to run. In one case, I wanted to disable most transforms, but still had to enable the class transform for interop with CoffeeScript classes. TypeScript would need a custom option for any use case like that.
* Babel supports both Flow and TypeScript.
* Babel is a community project rather than being primarily developed by one company. Microsoft theoretically could make a business decision to stop TypeScript development, but nobody could do that for Flow.
Reasons to use TypeScript:
* From my measurements, TypeScript is quite a bit faster than Babel at compiling ES2017 to ES5. From a quick test, TypeScript took 35 seconds and Babel took 140 seconds when run on my codebase at work.
* TypeScript is probably easier to set up and configure. No individual plugins or presets to install, you just set your compilation target in the config. The TypeScript team has already made the decision about which proposed features (e.g. object rest/spread) are safe to use right now, so there's less decision-making to do in that regard.
* TypeScript is maintained by a full-time team at Microsoft, and there's less risk of the maintainers getting burnt out.
Hmm, I would of thought it would be the opposite but I guess it depends on the setup?
> * TypeScript is probably easier to set up and configure.
Yeah given it's more of a "language" TS can decide on those defaults although you can just make your own preset for your company/project as well. I think we can fix that too with a default/separate thing but not sure yet.
I've actually been hacking on a faster alternative to babel/tsc for simple use cases: https://github.com/alangpierce/sucrase . It has a built-in benchmark (`yarn run benchmark`) with at least one example of where typescript is about 3x faster. So you could look at that config if you want one example to compare the two.
Have you noticed any of the same?
https://github.com/mui-org/material-ui/pull/9453
https://github.com/mui-org/material-ui/issues/9312
https://github.com/mui-org/material-ui/issues/9109#issuecomm...
https://github.com/mui-org/material-ui/issues/9312#issuecomm...
Flow, and probably TypeScript, work best when you do things "the Flow(/TS)" way. MUI authors insist on writing code as they would without Flow, and then inserting Flow in after the fact.
Typed JavaScript does not work well when it's treated simply as vanilla JavaScript with annotations. To be successful, it should be treated as a different (yet similar) language, and written within the confines of what the typed language supports.
The frustrations from the linked attempts at upgrading Flow in MUI stemmed from an insistence on supporting defaultProps through HoCs. This works fine, but requires some slight hacks to get it typed properly. The authors were not willing to make the exchange of implementing these hacks in exchange for an easier upgrade path, as they would have changed the generated documentation.
The contributors of material-ui did not experience an issue with TS because their codebase does not use TS, it only provides external interfaces for it. I am confident they would have experienced similar issues with TS at some point, had it been used for the safety of the library itself instead of just its external API.
There is, at least, an ongoing effort to use TS internally in MUI: https://github.com/mui-org/material-ui/pull/9561