Hacker News Reader

Comment by Vinnl | Hacker News Reader

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.

View on HN

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.

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.

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.

Works fine for me in VSCode using vetur.

vetur doesn't give you cross-module type checking

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.

> I strongly agree with your point regarding Vue template strings and JSX being the future of Vue.

I wonder whether that's really true. Most adoption of Vue is from after React and JSX were a thing, and many of the Vue adopters (or at least the ones I encounter online) are adopting it because they found React to complex, or had trouble collaborating with their designers. That sounds like templates are one of its main selling points, especially when compared to React.

I noticed that a lot of Vue users where coming from PHP and Laravel, where string templates are the norm and familiar.

I come from Angular and I have no problem with Vue templates. I have a problem with Vue's tight coupling and lack of injectable services.

I don't have a problem with React either. I try to avoid PHP.

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.

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

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.

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.

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.

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

It’s more than a linter though. The Typescript compiler can handle the most common usage of Babel, namely targeting older runtimes.

If you set the build target to ES5 you can still use modern features like async/await and it will rewrite them using a regenerator function that runs on older platforms.

Sure, it can do that - but in CRA's setup, it doesn't; Babel handles that for you. Babel's TypeScript support allows CRA to re-use its Babel pipeline, and the linter metaphor was meant to help people understand that.

Like most metaphors, it's not a one-on-one match.

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.

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.

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.

Reply on news.ycombinator.com