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.
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.
That's the problem I have with the Babel-everything mentality of a lot of developers, they don't realize that they are essentially created their own quasi-language that they'll have to support on their own.
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.
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.
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?
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.
Actually kind of the opposite - babel used to use the common ESTree AST format, but they've moved away to something similar but incompatible.
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.
It seems like Perl 6 is trying to implement pluggable grammars that work like that. Can anyone here familiar with the Perl 6 ecosystem comment on how it's going over there? Can you feasibly write a module with 5 or 6 different grammar extensions? What's it like? My understanding of the situation has matched what RyanCavanaugh expressed here for a while, and I'm curious if people's experiences match it or not.
Then we'll have the Babel problem. E.g. how they handled 2 to 3 transition doesn't inspire confidence.
> If you work outside the San Francisco bubble and are stuck on Windows, Flow isn't really an option at the moment.
> 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.