3 ms·

Isn't Facebook's own jstransform library (which is used by their JSX compiler) supposed to be composable already? They have various ES6 transforms in their repo

by jannes 12y ago

Isn't Facebook's own jstransform library (which is used by their JSX compiler) supposed to be composable already? They have various ES6 transforms in their repository. Plus, there are JSX transforms in the React repository. There are also some third-party transforms on Github – for example es6-destructuring-jstransform. Could anyone highlight what the differences between jstransform and sweet.js are? jstransform: https://github.com/facebook/jstransform/ https://github.com/facebook/jstransform/ es6-visitors: https://github.com/facebook/jstransform/tree/master/visitors https://github.com/facebook/jstransform/tree/master/visitors jsx-visitors: https://github.com/facebook/react/tree/master/vendor/fbtransform/transforms https://github.com/facebook/react/tree/master/vendor/fbtrans... es6-destructuring-jstransform: https://github.com/andreypopp/es6-destructuring-jstransform https://github.com/andreypopp/es6-destructuring-jstransform

chc 12y ago
To my understanding, JSTransform is essentially a toolchain for writing transpilers, while Sweet.js is a macro system for JavaScript. They both fall into the "things that allow you to output JavaScript from a file with user-defined constructs," but JSTransform is more "tool"-oriented while Sweet.js is essentially a language that's a superset of JavaScript with Scheme-ish macros.
jlongster 12y ago
There's a big difference: that's basically just a pipeline for AST tranforms. That's not very hard. Basically just a bunch of different JS libraries that you hand an AST through. That's not actually that useful. In my post, I mentioned adding syntax for literal persistent objects, using something like Mori data structures. The syntax could look like this: * #[1, 2, 3] <- persistent vector * #{x: 1, y: 2} <- persistent map An AST pipeline makes the "analyze" phase extensible, but it doesn't do anything to the parser. You can't actually add syntax, ever. So it's just not that useful for extending the language. It's good for something like implementing various parts of ES6. Actually, it's even better for something like types or modules, which really need the whole AST. But in my opinion, everything else is better as macros. sweet.js works on a tree of tokens, and it allows extending actual syntax. It's also way easier to transform code because it has a pattern matching language and you don't have to manually wrangle AST nodes. Lastly, sweet.js keeps track of scoping, and in the future it will have modules, so you will be able to do something like: ``` import JSX from "jsx-reader"; import # from "mori"; // code ... ``` And those language extensions are only available inside the module. Everything is scoped.
- modarts 12y ago
  Where can I check out the macros for persistent data structures? That sounds awesome
- davedx 12y ago
  "Reliable source maps" - going to give this a try. If it works I'll buy you a beer.

by jannes 12y ago

chc 12y ago

To my understanding, JSTransform is essentially a toolchain for writing transpilers, while Sweet.js is a macro system for JavaScript. They both fall into the "things that allow you to output JavaScript from a file with user-defined constructs," but JSTransform is more "tool"-oriented while Sweet.js is essentially a language that's a superset of JavaScript with Scheme-ish macros.

jlongster 12y ago

There's a big difference: that's basically just a pipeline for AST tranforms. That's not very hard. Basically just a bunch of different JS libraries that you hand an AST through. That's not actually that useful. In my post, I mentioned adding syntax for literal persistent objects, using something like Mori data structures. The syntax could look like this: * #[1, 2, 3] <- persistent vector * #{x: 1, y: 2} <- persistent map An AST pipeline makes the "analyze" phase extensible, but it doesn't do anything to the parser. You can't actually add syntax, ever. So it's just not that useful for extending the language. It's good for something like implementing various parts of ES6. Actually, it's even better for something like types or modules, which really need the whole AST. But in my opinion, everything else is better as macros. sweet.js works on a tree of tokens, and it allows extending actual syntax. It's also way easier to transform code because it has a pattern matching language and you don't have to manually wrangle AST nodes. Lastly, sweet.js keeps track of scoping, and in the future it will have modules, so you will be able to do something like: ``` import JSX from "jsx-reader"; import # from "mori"; // code ... ``` And those language extensions are only available inside the module. Everything is scoped.

modarts 12y ago
Where can I check out the macros for persistent data structures? That sounds awesome
davedx 12y ago
"Reliable source maps" - going to give this a try. If it works I'll buy you a beer.