4 ms·

I'm not certain I agree. I agree with better type systems, but does anyone remember ECMAScript 4? Which Microsoft vetoed after Macromedia had gone ahead and ado

I'm not certain I agree. I agree with better type systems, but does anyone remember ECMAScript 4? Which Microsoft vetoed after Macromedia had gone ahead and adopted it as ActionScript 3 (coincidentally around the time they were trying to get everyone to adopt Silverlight). Well that's basically what TypeScript is (with slightly more advanced type support). It's a nonstandard dialect of JavaScript. Something that everyone (especially MicroSoft) ostensibly agreed was not what was wanted or needed. The alternative to that of course is Babel. Which is standard JavaScript, mostly. Including the draft stuff that isn't ratified yet. But you don't have to use any of that if you don't want. And things like Flow and JSX, which are just plugins so again, you can take them or leave them. The authors argument eventually distills down to a choice between TypeScript and Flow. He concludes that TS is the best choice because it has the momentum, but that's a false choice. The choice is between Microsoft's TypeScript transpiler and Babel. If you use Babel you can choose to use Flow, but if you use TypeScript you lose out on everything else Babel has to offer. And outside of the .Net+Angular world, Babel has all the momentum.

maaaats 11y ago
What does one miss out from Babel, given that TS is a superset of ES6?
- tommyd 11y ago
  I guess the point is that with Babel you can enable so called "stage 0" language features, which aren't in the spec yet but someone has created a Babel plugin for (e.g. decorators). With Typescript, you can't do this, because the code has to pass through the Typescript compiler first, which doesn't support (most of) these features (e.g. it does support decorators IIRC) so will throw an error when it finds an unfamiliar language construct, and it doesn't have a plugin architecture like Babel, so you can't add them in that way. One example is the spread/rest syntax which is sometimes used in React projects isn't fully supported in TS: https://github.com/Microsoft/TypeScript/issues/2103 https://github.com/Microsoft/TypeScript/issues/2103. I should point out you can use Babel and Typescript, so the Babel processes the output from tsc (needed for using e.g. async/await at present, as tsc can't compile these down to ES5), but tsc has to run first to make the code into valid JS (on this note, I was surprised how easy it was to remove TS from a project - Babel will ignore most of the TS specific stuff such as interface and type declarations, as it already strips them out for Flow compatibility and the syntax is largely the same)
- robert_tweed 11y ago
  It depends. The problem isn't so much what you might miss out on if all you are doing is writing a library, the problem is what limitations it places on consumers of your library. The most obvious Babel plugins are JSX and Flow. If your library is using TypeScript then it cannot go through the same build process* as any downstream project that is using any Babel plugin. That means you need to publish your library as ES5 and the client loses most the advantages of your library being in TypeScript in the first place. Also, Babel appears to be doing a slightly better job of keeping up with the draft ES standards, so if you want to use cutting-edge JS features (like async/await) that are on the standards track, you may need to wait a bit longer for TS adoption to get there. I also think it's unlikely TypeScript is going to win out in the long run, so if you commit to TS now you're probably going to be rewriting in a few years. It's better to stick to standard JS where possible. The history of ES4 strongly suggests that TS is never going to become an ECMA standard. * You can, at least in theory, do a two-stage transpile that goes through both Babel and TS, but IMO, nothing good is likely to come from such a setup.
  - danielmason 11y ago
    I'm not sure I understand what you mean by "the client loses most the advantages of your library being in TypeScript in the first place." Your library still exposes a more clearly-defined API by making types explicit. And saying that the downstream consumer doesn't get the benefit of compile-time type checking if they've chosen not to use type checking is...kind of a truism?
    - robert_tweed 11y ago
      The problem is with the author's assertion that all libraries should be using TypeScript and not, say, Flow, or some other alternative that achieves the same goals, perhaps better.
      - MadcapJake 11y ago
        Does Flow offer type definition files?
- aljones 11y ago
  Babel is highly configurable and relatively easy to write plugins for.
jsight 11y ago
I used AS3 at that time and completely hated it. It would have been a terrible approach for JavaScript to adopt going forward. TS is much more suitable for the dynamic nature of JavaScript, IMO. I know that AS3 had dynamic features, but they tended to have a lot of very strange limitations in actual use (it actually felt more limiting than pure Java code in some cases). I haven't tried Babel, though. It easily could be a better path forward. Does it have some equivalent of the typescript type descriptor files?
Bahamut 11y ago
I don't think you understood the point of the article - it was targeted at library maintainers, not all users. Types often end up a part of the documentation, and internal typing is often needed in libraries to keep track of model state, so having it at the foundational level in the library itself adds tremendous benefit.
- robert_tweed 11y ago
  Yes, I don't think I was clear enough but I edited a lot of points out of my post as it was far too long! The biggest problems in any modern, large-scale JavaScript project are the build process and dependency management. If you are publishing a TypeScript library then it can be consumed either natively as TypeScript, or as ES5. If it is being consumed as ES5 then your consumers lose most of the benefits of it being in TS. For them to consume it as native TS puts a fairly hefty constraint on their build process, namely that it must go through the TypeScript compiler. That doesn't negate the internal benefits to your library, but Flow is another option that is a better fit if you are mostly interested in going with the prevailing wind. After all, that was the author's central argument as to why you should choose TS over Flow, and IMO it is quite wrong.
  - Bahamut 11y ago
    The article talks about TypeScript vs. Flow as well - TS has a lot more popularity than Flow currently, and it only looks like the gap is going to grow larger. Types also allows for auto-generation of docs that are guaranteed to reflect the current state of the code. For a library maintainer, a maintainer can just release an ES5 version of the library when publishing via npm - the user then gets the benefit of choosing between TS or ES5. It can also simultaneously be released as ES6 if desired. I should mention that it doesn't make sense for pre-existing libraries to migrate to TS (or anything) if it is already in JS and is a largely used library without a specific end goal that is to be achieved - the article is wrong about that, open source doesn't have infinite resources unfortunately.
  - Eridrus 11y ago
    > If it is being consumed as ES5 then your consumers lose most of the benefits of it being in TS. For them to consume it as native TS puts a fairly hefty constraint on their build process, namely that it must go through the TypeScript compiler. Unless you're making changes to a TS library, there should be no need to build it and you can just use existing the built js files from the library.

maaaats 11y ago

What does one miss out from Babel, given that TS is a superset of ES6?

tommyd 11y ago
I guess the point is that with Babel you can enable so called "stage 0" language features, which aren't in the spec yet but someone has created a Babel plugin for (e.g. decorators). With Typescript, you can't do this, because the code has to pass through the Typescript compiler first, which doesn't support (most of) these features (e.g. it does support decorators IIRC) so will throw an error when it finds an unfamiliar language construct, and it doesn't have a plugin architecture like Babel, so you can't add them in that way. One example is the spread/rest syntax which is sometimes used in React projects isn't fully supported in TS: https://github.com/Microsoft/TypeScript/issues/2103 https://github.com/Microsoft/TypeScript/issues/2103. I should point out you can use Babel and Typescript, so the Babel processes the output from tsc (needed for using e.g. async/await at present, as tsc can't compile these down to ES5), but tsc has to run first to make the code into valid JS (on this note, I was surprised how easy it was to remove TS from a project - Babel will ignore most of the TS specific stuff such as interface and type declarations, as it already strips them out for Flow compatibility and the syntax is largely the same)
robert_tweed 11y ago
It depends. The problem isn't so much what you might miss out on if all you are doing is writing a library, the problem is what limitations it places on consumers of your library. The most obvious Babel plugins are JSX and Flow. If your library is using TypeScript then it cannot go through the same build process* as any downstream project that is using any Babel plugin. That means you need to publish your library as ES5 and the client loses most the advantages of your library being in TypeScript in the first place. Also, Babel appears to be doing a slightly better job of keeping up with the draft ES standards, so if you want to use cutting-edge JS features (like async/await) that are on the standards track, you may need to wait a bit longer for TS adoption to get there. I also think it's unlikely TypeScript is going to win out in the long run, so if you commit to TS now you're probably going to be rewriting in a few years. It's better to stick to standard JS where possible. The history of ES4 strongly suggests that TS is never going to become an ECMA standard. * You can, at least in theory, do a two-stage transpile that goes through both Babel and TS, but IMO, nothing good is likely to come from such a setup.
- danielmason 11y ago
  I'm not sure I understand what you mean by "the client loses most the advantages of your library being in TypeScript in the first place." Your library still exposes a more clearly-defined API by making types explicit. And saying that the downstream consumer doesn't get the benefit of compile-time type checking if they've chosen not to use type checking is...kind of a truism?
  - robert_tweed 11y ago
    The problem is with the author's assertion that all libraries should be using TypeScript and not, say, Flow, or some other alternative that achieves the same goals, perhaps better.
    - MadcapJake 11y ago
      Does Flow offer type definition files?
aljones 11y ago
Babel is highly configurable and relatively easy to write plugins for.

jsight 11y ago

I used AS3 at that time and completely hated it. It would have been a terrible approach for JavaScript to adopt going forward. TS is much more suitable for the dynamic nature of JavaScript, IMO. I know that AS3 had dynamic features, but they tended to have a lot of very strange limitations in actual use (it actually felt more limiting than pure Java code in some cases). I haven't tried Babel, though. It easily could be a better path forward. Does it have some equivalent of the typescript type descriptor files?

Bahamut 11y ago

I don't think you understood the point of the article - it was targeted at library maintainers, not all users. Types often end up a part of the documentation, and internal typing is often needed in libraries to keep track of model state, so having it at the foundational level in the library itself adds tremendous benefit.

robert_tweed 11y ago
Yes, I don't think I was clear enough but I edited a lot of points out of my post as it was far too long! The biggest problems in any modern, large-scale JavaScript project are the build process and dependency management. If you are publishing a TypeScript library then it can be consumed either natively as TypeScript, or as ES5. If it is being consumed as ES5 then your consumers lose most of the benefits of it being in TS. For them to consume it as native TS puts a fairly hefty constraint on their build process, namely that it must go through the TypeScript compiler. That doesn't negate the internal benefits to your library, but Flow is another option that is a better fit if you are mostly interested in going with the prevailing wind. After all, that was the author's central argument as to why you should choose TS over Flow, and IMO it is quite wrong.
- Bahamut 11y ago
  The article talks about TypeScript vs. Flow as well - TS has a lot more popularity than Flow currently, and it only looks like the gap is going to grow larger. Types also allows for auto-generation of docs that are guaranteed to reflect the current state of the code. For a library maintainer, a maintainer can just release an ES5 version of the library when publishing via npm - the user then gets the benefit of choosing between TS or ES5. It can also simultaneously be released as ES6 if desired. I should mention that it doesn't make sense for pre-existing libraries to migrate to TS (or anything) if it is already in JS and is a largely used library without a specific end goal that is to be achieved - the article is wrong about that, open source doesn't have infinite resources unfortunately.
- Eridrus 11y ago
  > If it is being consumed as ES5 then your consumers lose most of the benefits of it being in TS. For them to consume it as native TS puts a fairly hefty constraint on their build process, namely that it must go through the TypeScript compiler. Unless you're making changes to a TS library, there should be no need to build it and you can just use existing the built js files from the library.