Compiling JSX with Sweet.js using Readtables
jlongster.com
jlongster.com
Could anyone highlight what the differences between jstransform and sweet.js are?
jstransform: https://github.com/facebook/jstransform/
es6-visitors: https://github.com/facebook/jstransform/tree/master/visitors
jsx-visitors: https://github.com/facebook/react/tree/master/vendor/fbtrans...
es6-destructuring-jstransform: https://github.com/andreypopp/es6-destructuring-jstransform
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.
Is there any traction on this front, something like a system where the source map actually embeds the AST or the like?
As a complete macro noob, I'm starting to wonder whether readtables would also allow all of TypeScript to be compiled with sweetjs. Or at least transformed, without type checking.
I haven't tried yet but I think all the syntax forms in TypeScript can be handled with just plain sweet.js macros, no need for the readtable. Actually handling the types in TypeScript via macros should also be eventually possible (Typed Racket [1] does typing via macros) once we have a bit more feature parity with Racket's macro system.
I'm gonna port this to work with Mithril ( http://lhorie.github.io/mithril ) when I get a chance.
I ask that you think hard about sweet.js. Give it 5 minutes. Maybe give it a couple of hours. Play around with it: set up a gulp watcher, install some macros from npm, and use it. Don't push back against it unless you actually understand the problem we are trying to solve. Many arguments that people give don't make sense (but some of them do!).
Regardless, even if you think this isn't the right approach, it's certainly a valid one. One of the most troubling things about the software industry to me is how vicious we can be to one another, so please be constructive.
So often commenters seem to be people who've never tried the technology in question reacting to imagined abuses ("Monkeypatching? I'd never allow that in production!").
It's fairly popular in the React community because everybody sees JSX and is like "bleh" and rejects the tech out of hand, which is disappointing because React is IMO the most important advance in frontend development since the DOM Inspector or at least since jQuery.
Is such tooling even possible for something like sweet.js?
For the most part, you still get all the info you used to have. Generally you don't use macros that are overly aggressive in modifying scope, or changing the basic rules of JS that tern looks for.
You will not get autocompleting on expressions that expand with macros, no. But you could easily add a plugin to tern that tells it the rules for that syntax if you really wanted to.
Macros in Racket are as awesome as they are because they are deeply integrated with DrRacket. Having s-exps based syntax helps, but that's not a prerequisite - DrRacket handles #langs which are not based on sexps too. It's one of Racket's goals to let you create your own language and make it work with syntax-highlighting and auto-completion (and more) automatically. That's what makes Racket absolutely awesome for experimenting with languages.
Sweet.js is young and it's possible it will get editor support with plugins later. For now, however, the lack of such support makes the experience worse than CoffeeScript or LiveScript or ClojureScript. Which is a shame, because extensibility granted by powerful macro system is very desirable in JS and would render many of compile-to-JS languages redundant, while allowing better composability.
In short I like sweet.js idea very much, I played with it a bit, but I unfortunately will have to wait for better tooling before using it in production.
https://www.youtube.com/watch?v=DgVS-zXgMTk#t=182
Basically, the idea is that most JS templating solutions separate technologies (HTML , JS, templating languages), but don't actually separate concerns, because the concern is simply generating and updating DOM regardless of how many technologies you use.
Most JavaScript frameworks or libraries that handling generating and updating DOM, like Ember's two-way binding with Handlebars and Angular's dirty checking with directives, don't really separate markup from logic. They just invent a new language to mix with your HTML, and that new language is deliberately made extremely weak.
[0] http://www.confreaks.com/videos/2953-jsconfeu2013-rethinking...