27 ms·

The TypeScript team really made the right call by adding support for TypeScript syntax to Babel. Ever since that got merged, the floodgates have opened: more an

by Vinnl 8y ago

The TypeScript team really made the right call by adding support for TypeScript syntax to Babel. Ever since that got merged, the floodgates have opened: more and more projects support TypeScript by default or practically only requiring you to flip a switch, making the cost of adopting it (if you don't need to spend time learning it as well) practically zero. No matter how small the project, if I start a new one today, it will be written in TypeScript. Adoption is now at a point where it is exponential: more projects adopting TypeScript, resulting in more typings being available, resulting in more projects adopting TypeScript. If there's one thing you can focus on to learn as a Javascript developer in the near future, I'm sure it is TypeScript.

scrollaway 8y ago
As an uninformed typescript dev, can you explain to me how TS Babel support changed things? I understand its mechanical implications, but I don't see why it would matter for adoption.
- jypepin 8y ago
  Yesterday's post about migrating to typescript [1] explains it well. tldr: This release meant that adopting TypeScript no longer meant buying into the entire TypeScript ecosystem and that we could keep using Babel to emit JavaScript. More importantly, this meant that we could actually use TypeScript as a type checker, and not so much as a "language" per se. [1] https://davidgom.es/porting-30k-lines-of-code-from-flow-to-typescript/ https://davidgom.es/porting-30k-lines-of-code-from-flow-to-t...
- Vinnl 8y ago
  For example, it made it much easier for projects like Create React App to add optional support for TypeScript. When they added support, that just involved adding an optional extra step to the compilation process (checking whether you violated the type constraints) to make sure you actually get the benefits of TypeScript. Other than that, though, TypeScript projects using CRA use the exact same infrastructure when they use TypeScript, and the compiled output should be similar. Before, this would have involved replacing Babel with TypeScript for transpiling. This means projects could have slightly different results depending on whether they were using TypeScript or not, increasing the surface area for bugs and adding an extra step to the debugging process.
  - Rapzid 8y ago
    Doesn't create react app use webpack behind the scenes?ts-loader already worked pretty well? Not sure how that affected anyone using Babel In a built pipeline, but the announcement made it sound like there were tons of people doing bespoke balbel-only builds.. Have not experienced that myself.
    - Vinnl 8y ago
      Yes, it uses Webpack. Its TypeScript support does not use ts-loader, which would be used in place of Babel loader - which would affect the team behind CRA, who would now have to maintain two sets of documentation, ask bug reporters whether they use TypeScript, etc. TypeScript support as its implemented in CRA just uses Babel like it did before, with some minor modifications such as also passing it .ts files. In parallel, it also runs the ForkTSChecker plugin for Webpack, which notifies you of type errors you made - however, it would work just the same if that plugin was not activated. Hence, there is far less divergence from regular CRA projects.
    - akras14 8y ago
      Babel is a commonly used plug-in Webpack though. So I am guessing all projects that used Babel/Webpack got TypeScript support for free. It’s a TIL for me, definitely going to have to look into this. Sounds exciting.
      - Vinnl 8y ago
        Note that "TypeScript support" in Babel means that Babel can now strip the extra syntax that is part of TypeScript applications. It doesn't actually parse them. A way to think about it is to consider TypeScript to be a linter, like ESlint - but one that you can help by annotating your code with e.g. the types of values you expect it to get passed. Babel can now strip those annotations before it transpiles your code, but you still need TypeScript to do the actual "linting". See https://vincenttunru.com/TypeScript-vs-Javascript https://vincenttunru.com/TypeScript-vs-Javascript
        8y ago
- whatever_dude 8y ago
  It's easier to plug it in because there's a lot of projects already using babel, so you just need to add a transformer. Previously you'd need to add a new step to your compilation process using tsc, which could be very difficult depending on how you built your project, especially if it wasn't Webpack-based. For example, you _could_ use TypeScript before with React Native. But it was convoluted: there were 3 different way to do it, none of them perfect, and all really brittle. But with Babel 7, you just add another transformer to your babel file and bam, it's treated as a first class citizen. It's literally a one line change.
mcv 8y ago
I just started a new project in Vue (which is new to me), and was sad to discover Vue doesn't do TypeScript out of the box. I definitely see the use case for TypeScript in my project, though: I'm dealing with lots of different types of data. It's useful to know what I've got in my hands.
- Vinnl 8y ago
  Well, that's part of the opened floodgates: Vue 3 is being written in TypeScript, so that should get a lot easier for future projects as well.
- Rapzid 8y ago
  It's not quite OTB but with Vetr and and such it's the best worst experience. By that I mean, as the worst TS experience it's miles ahead of tooling for say.. Python. That being said, Vue... Oh Vue. It settled on its own string template syntax that never got the tooling love of JSX. There have been efforts to get them typed, but those efforts never quite rounded second. Lack of typing in the Vue templates seems to be a sticking point for many.. I don't believe they are long does this world; JSX is the future for Vue.
  - philliphaydon 8y ago
    Works fine for me in VSCode using vetur.
    - basil-rash 8y ago
      vetur doesn't give you cross-module type checking
  - t1amat 8y ago
    I strongly agree with your point regarding Vue template strings and JSX being the future of Vue. Coming from React + TS projects, Vue + TS is a lesser experience in many ways. Another such way is the community’s infatuation with exporting raw object literals for component definitions, and forcing you to defy common language idioms to support them hoisting this object literal into a component context.
yazaddaruvala 8y ago
I think it’s also for themselves. More and more the TypeScript devs can focus on the typesystem and less on the whole ecosystem of deploying Javascript. I can imagine a day soon when Babel is integrated into tsc to do all of the non typesystem stuff. I also can imagine the TS team continuing to improve Babel support to a point where TypeScript is “just another plugin” for Babel. At which point tsc can be deprecated. The less the TS devs have to maintain the more they can focus on their core value add.

by Vinnl 8y ago

scrollaway 8y ago

As an uninformed typescript dev, can you explain to me how TS Babel support changed things? I understand its mechanical implications, but I don't see why it would matter for adoption.

jypepin 8y ago
Yesterday's post about migrating to typescript [1] explains it well. tldr: This release meant that adopting TypeScript no longer meant buying into the entire TypeScript ecosystem and that we could keep using Babel to emit JavaScript. More importantly, this meant that we could actually use TypeScript as a type checker, and not so much as a "language" per se. [1] https://davidgom.es/porting-30k-lines-of-code-from-flow-to-typescript/ https://davidgom.es/porting-30k-lines-of-code-from-flow-to-t...
Vinnl 8y ago
For example, it made it much easier for projects like Create React App to add optional support for TypeScript. When they added support, that just involved adding an optional extra step to the compilation process (checking whether you violated the type constraints) to make sure you actually get the benefits of TypeScript. Other than that, though, TypeScript projects using CRA use the exact same infrastructure when they use TypeScript, and the compiled output should be similar. Before, this would have involved replacing Babel with TypeScript for transpiling. This means projects could have slightly different results depending on whether they were using TypeScript or not, increasing the surface area for bugs and adding an extra step to the debugging process.
- Rapzid 8y ago
  Doesn't create react app use webpack behind the scenes?ts-loader already worked pretty well? Not sure how that affected anyone using Babel In a built pipeline, but the announcement made it sound like there were tons of people doing bespoke balbel-only builds.. Have not experienced that myself.
  - Vinnl 8y ago
    Yes, it uses Webpack. Its TypeScript support does not use ts-loader, which would be used in place of Babel loader - which would affect the team behind CRA, who would now have to maintain two sets of documentation, ask bug reporters whether they use TypeScript, etc. TypeScript support as its implemented in CRA just uses Babel like it did before, with some minor modifications such as also passing it .ts files. In parallel, it also runs the ForkTSChecker plugin for Webpack, which notifies you of type errors you made - however, it would work just the same if that plugin was not activated. Hence, there is far less divergence from regular CRA projects.
  - akras14 8y ago
    Babel is a commonly used plug-in Webpack though. So I am guessing all projects that used Babel/Webpack got TypeScript support for free. It’s a TIL for me, definitely going to have to look into this. Sounds exciting.
    - Vinnl 8y ago
      Note that "TypeScript support" in Babel means that Babel can now strip the extra syntax that is part of TypeScript applications. It doesn't actually parse them. A way to think about it is to consider TypeScript to be a linter, like ESlint - but one that you can help by annotating your code with e.g. the types of values you expect it to get passed. Babel can now strip those annotations before it transpiles your code, but you still need TypeScript to do the actual "linting". See https://vincenttunru.com/TypeScript-vs-Javascript https://vincenttunru.com/TypeScript-vs-Javascript
      - 8y ago
whatever_dude 8y ago
It's easier to plug it in because there's a lot of projects already using babel, so you just need to add a transformer. Previously you'd need to add a new step to your compilation process using tsc, which could be very difficult depending on how you built your project, especially if it wasn't Webpack-based. For example, you _could_ use TypeScript before with React Native. But it was convoluted: there were 3 different way to do it, none of them perfect, and all really brittle. But with Babel 7, you just add another transformer to your babel file and bam, it's treated as a first class citizen. It's literally a one line change.

mcv 8y ago

I just started a new project in Vue (which is new to me), and was sad to discover Vue doesn't do TypeScript out of the box. I definitely see the use case for TypeScript in my project, though: I'm dealing with lots of different types of data. It's useful to know what I've got in my hands.

Vinnl 8y ago
Well, that's part of the opened floodgates: Vue 3 is being written in TypeScript, so that should get a lot easier for future projects as well.
Rapzid 8y ago
It's not quite OTB but with Vetr and and such it's the best worst experience. By that I mean, as the worst TS experience it's miles ahead of tooling for say.. Python. That being said, Vue... Oh Vue. It settled on its own string template syntax that never got the tooling love of JSX. There have been efforts to get them typed, but those efforts never quite rounded second. Lack of typing in the Vue templates seems to be a sticking point for many.. I don't believe they are long does this world; JSX is the future for Vue.
- philliphaydon 8y ago
  Works fine for me in VSCode using vetur.
  - basil-rash 8y ago
    vetur doesn't give you cross-module type checking
- t1amat 8y ago
  I strongly agree with your point regarding Vue template strings and JSX being the future of Vue. Coming from React + TS projects, Vue + TS is a lesser experience in many ways. Another such way is the community’s infatuation with exporting raw object literals for component definitions, and forcing you to defy common language idioms to support them hoisting this object literal into a component context.

yazaddaruvala 8y ago

I think it’s also for themselves. More and more the TypeScript devs can focus on the typesystem and less on the whole ecosystem of deploying Javascript. I can imagine a day soon when Babel is integrated into tsc to do all of the non typesystem stuff. I also can imagine the TS team continuing to improve Babel support to a point where TypeScript is “just another plugin” for Babel. At which point tsc can be deprecated. The less the TS devs have to maintain the more they can focus on their core value add.