5 ms·

Because a lot of notable ReactJS projects are irritatingly enamored with all the latest ES6/ES7/ESCloudCuckooLand features, not all of which are supported by Ty

by mhd 10y ago

Because a lot of notable ReactJS projects are irritatingly enamored with all the latest ES6/ES7/ESCloudCuckooLand features, not all of which are supported by TypeScript. I've noticed this a lot in the Redux realm. For every possible problem there seems to be a solution that harnesses one particular new/proposed bell & whistle.

k__ 10y ago
This. Many React projects use JSX, decorators and class properties to the max, so they needed babel in the first place. Now if you want to add types, Flow is easier to integrate than switching to another compiler.
- patates 10y ago
  My opinion is that all the extensions on JavaScript should be implemented as Babel plugins, including Typescript. That would solve all the compatibility problems. Well, when Babel first came out I also thought that it should have been a Sweet.js plugin so maybe I don't have the best understanding of this "transpiling" circus.
  - RyanCavanaugh 10y ago
    It's tempting to think this way, but it's a performance/complexity nightmare. If everything is a plugin, then you need ways for different parsers to talk to each other to deal with nested syntax, plus ways for different syntactic transformers to correctly handle nesting of certain things. For example, if you desired to implement a plugin for "thin arrows", and a plugin for JSX, how would you parse this? const x = <foo x = {y -> <y/> } /> You'd have to have the JSX parser know to invoke the thin arrow parser, then the thin arrow parser has to know how to invoke the JSX parser, then when you emit, you have to do the whole dance over again. If you're willing to take some trade-offs in the parsing phase, it's OK. But the emit is where you get killed - either every plugin has to be written generically and correctly enough to deal with any arbitrary nesting of syntaxes (including the cases where the semantics of nesting aren't even clear, like where a 'fat' arrow here would capture 'this' from), or you do one tree pass per transformer, which gets very expensive. There's a reason you don't usually see architectures like that live very long.
    - patates 10y ago
      Well, this is not the first time that a comment on HN not only made me change my opinion but also taught me something. Thank you for the detailed answer. Maybe the specific example you give can be solved in a very hacky way with something like a priority system but I can see how messy it can get even when tokenizing the possible expressions for such an open "playground", let alone transforming in the correct sequence. Thank you, Ryan. edit: Oh you are the person who implemented JSX support for Typescript! How do we buy you a beer, or in this case a six-pack?
    - pluma 10y ago
      Aren't the Babel people trying to define a common standard format for the AST so different parsers and code generators can better work together? That said, if you look at TS as a superset of Babel plugins, there's actually not much to TS that is TS-specific. Adding that to Babel would be relatively simple. You seem to be arguing it's a slippery slope. We're not talking about arbitrary syntax. We're talking about a fairly well-established syntax extension backed by Google and Microsoft. It doesn't have to perfectly universal and generic to support TS. EDIT: If you were specifically addressing the parent: yes, if every syntax extension was created as a parser plugin, getting them to work together would be messy, but that's basically what we have in PostCSS isn't it? Plugins explicitly instructing users "this conflicts with X, please add it after Y but before Z" -- which is fine IMO as you only need to care about the most popular ones and everybody else knows their stack is experimental.
      - phpnode 10y ago
        > Aren't the Babel people trying to define a common standard format for the AST so different parsers and code generators can better work together? Actually kind of the opposite - babel used to use the common ESTree AST format, but they've moved away to something similar but incompatible.
    - yortus 10y ago
      > it's a performance/complexity nightmare Babel itself demonstrates the truth of this. If you look at the source code for any of Babel's syntax plugins, they are literally only a few lines long, because all they do is activate a feature that is actually part of the parser core.
  - coldtea 10y ago
    >My opinion is that all the extensions on JavaScript should be implemented as Babel plugins, including Typescript. That would solve all the compatibility problems. Then we'll have the Babel problem. E.g. how they handled 2 to 3 transition doesn't inspire confidence.
gotofritz 10y ago
In other words, "things I don't use = cuckooland"
pjmlp 10y ago
This is another reason: > If you work outside the San Francisco bubble and are stuck on Windows, Flow isn't really an option at the moment.
- yuchi 10y ago
  It is not the case anymore. Flow now supports windows out of the box.
  - pjmlp 10y ago
    If you read the initial part of the comment I took that remark from: > A big factor in my company recently switching to TypeScript was Windows performance, even with the recent massive advancements for Flow on Windows it's still painful to use and the tooling is miles behind.
dangoor 10y ago
As far as I've seen, it's really only Object spread (likely ES2017 feature) that's commonly used that is not yet supported by TypeScript. Microsoft has promised support for it in TS 2.1, and generally stays on top of ECMAScript proposals that have gained enough traction that they seem likely to ship.
- vcarl 10y ago
  On the other hand, Flow is removed from the code transformation, so it doesn't have to bother with keeping up with the spec. That's a pretty strong point in Flow's favor in my opinion, single responsibility principle and all that :)
  - spankalee 10y ago
    You can do that in TypeScript too: just target ES6, use all the features like spread/rest and async/await, then compile the result with Babel.
    - dangoor 10y ago
      But The TS parser will see object spread as a syntax error.
  - dangoor 10y ago
    But Flow still needs to be able to parse the JS. If it thinks your JS is invalid, you'all get an error.
  - bsimpson 10y ago
    Flow understands some TC39 proposals, if you use the right flags: esproposal.class_instance_fields=enable but it chokes on ones it doesn't understand. I tried using Flow and RxJS in the same codebase. RxJS makes heavy use of the pipeline operator: stream::map(thing) vs map.call(stream, thing) Flow will stop checking types as soon as it sees ::. Babel parses it, but Flow runs in parallel, so it needs to be able to walk the AST itself.

by mhd 10y ago

k__ 10y ago

This. Many React projects use JSX, decorators and class properties to the max, so they needed babel in the first place. Now if you want to add types, Flow is easier to integrate than switching to another compiler.

patates 10y ago
My opinion is that all the extensions on JavaScript should be implemented as Babel plugins, including Typescript. That would solve all the compatibility problems. Well, when Babel first came out I also thought that it should have been a Sweet.js plugin so maybe I don't have the best understanding of this "transpiling" circus.
- RyanCavanaugh 10y ago
  It's tempting to think this way, but it's a performance/complexity nightmare. If everything is a plugin, then you need ways for different parsers to talk to each other to deal with nested syntax, plus ways for different syntactic transformers to correctly handle nesting of certain things. For example, if you desired to implement a plugin for "thin arrows", and a plugin for JSX, how would you parse this? const x = <foo x = {y -> <y/> } /> You'd have to have the JSX parser know to invoke the thin arrow parser, then the thin arrow parser has to know how to invoke the JSX parser, then when you emit, you have to do the whole dance over again. If you're willing to take some trade-offs in the parsing phase, it's OK. But the emit is where you get killed - either every plugin has to be written generically and correctly enough to deal with any arbitrary nesting of syntaxes (including the cases where the semantics of nesting aren't even clear, like where a 'fat' arrow here would capture 'this' from), or you do one tree pass per transformer, which gets very expensive. There's a reason you don't usually see architectures like that live very long.
  - patates 10y ago
    Well, this is not the first time that a comment on HN not only made me change my opinion but also taught me something. Thank you for the detailed answer. Maybe the specific example you give can be solved in a very hacky way with something like a priority system but I can see how messy it can get even when tokenizing the possible expressions for such an open "playground", let alone transforming in the correct sequence. Thank you, Ryan. edit: Oh you are the person who implemented JSX support for Typescript! How do we buy you a beer, or in this case a six-pack?
  - pluma 10y ago
    Aren't the Babel people trying to define a common standard format for the AST so different parsers and code generators can better work together? That said, if you look at TS as a superset of Babel plugins, there's actually not much to TS that is TS-specific. Adding that to Babel would be relatively simple. You seem to be arguing it's a slippery slope. We're not talking about arbitrary syntax. We're talking about a fairly well-established syntax extension backed by Google and Microsoft. It doesn't have to perfectly universal and generic to support TS. EDIT: If you were specifically addressing the parent: yes, if every syntax extension was created as a parser plugin, getting them to work together would be messy, but that's basically what we have in PostCSS isn't it? Plugins explicitly instructing users "this conflicts with X, please add it after Y but before Z" -- which is fine IMO as you only need to care about the most popular ones and everybody else knows their stack is experimental.
    - phpnode 10y ago
      > Aren't the Babel people trying to define a common standard format for the AST so different parsers and code generators can better work together? Actually kind of the opposite - babel used to use the common ESTree AST format, but they've moved away to something similar but incompatible.
  - yortus 10y ago
    > it's a performance/complexity nightmare Babel itself demonstrates the truth of this. If you look at the source code for any of Babel's syntax plugins, they are literally only a few lines long, because all they do is activate a feature that is actually part of the parser core.
- coldtea 10y ago
  >My opinion is that all the extensions on JavaScript should be implemented as Babel plugins, including Typescript. That would solve all the compatibility problems. Then we'll have the Babel problem. E.g. how they handled 2 to 3 transition doesn't inspire confidence.

gotofritz 10y ago

In other words, "things I don't use = cuckooland"

pjmlp 10y ago

This is another reason: > If you work outside the San Francisco bubble and are stuck on Windows, Flow isn't really an option at the moment.

yuchi 10y ago
It is not the case anymore. Flow now supports windows out of the box.
- pjmlp 10y ago
  If you read the initial part of the comment I took that remark from: > A big factor in my company recently switching to TypeScript was Windows performance, even with the recent massive advancements for Flow on Windows it's still painful to use and the tooling is miles behind.

dangoor 10y ago

As far as I've seen, it's really only Object spread (likely ES2017 feature) that's commonly used that is not yet supported by TypeScript. Microsoft has promised support for it in TS 2.1, and generally stays on top of ECMAScript proposals that have gained enough traction that they seem likely to ship.

vcarl 10y ago
On the other hand, Flow is removed from the code transformation, so it doesn't have to bother with keeping up with the spec. That's a pretty strong point in Flow's favor in my opinion, single responsibility principle and all that :)
- spankalee 10y ago
  You can do that in TypeScript too: just target ES6, use all the features like spread/rest and async/await, then compile the result with Babel.
  - dangoor 10y ago
    But The TS parser will see object spread as a syntax error.
- dangoor 10y ago
  But Flow still needs to be able to parse the JS. If it thinks your JS is invalid, you'all get an error.
- bsimpson 10y ago
  Flow understands some TC39 proposals, if you use the right flags: esproposal.class_instance_fields=enable but it chokes on ones it doesn't understand. I tried using Flow and RxJS in the same codebase. RxJS makes heavy use of the pipeline operator: stream::map(thing) vs map.call(stream, thing) Flow will stop checking types as soon as it sees ::. Babel parses it, but Flow runs in parallel, so it needs to be able to walk the AST itself.