"Pre-process" isn't quite accurate. To me that implies processing before serving, but it appears JSX is processed in the browser by a transpiler weighing in at 300k (uncompressed). http://fb.me/JSXTransformer-0.3.0.js

This is just for making development easy. We have a prebuild step that will do this ahead of time. Just do:

npm install -g react-tools

and you'll have a jsx command available. We cover this towards the bottom of this page: http://facebook.github.io/react/docs/getting-started.html

Thanks for the FYI. I'd consider swapping the order and list the offline method first, since that's the more common approach people take (I'd hope), and it's easier to grok at a glance.

You can also process it offline, so you only ship standard JS. The in-browser processing is an option you can choose to use at development time if you find it quicker/simpler.

Yes, but the code is still pre-processed before it is executed by anywhere.

edit: The fact that the pre-processing library is 300kb uncompressed is a pretty huge deterrent.

Presumably if you run the pre-processer as part of your deploy (the jsx node.js command-line tool) you don't have to ship the pre-processing library to the client.

Am I correct in understanding that one can implement new script language types in Javascript?

You can do `<script type="anything-you-want"></script>`. It's just an attribute. The browser will not run any code in the tag because the `type`-attribute is invalid now.

The next step is to create a compiler for your `anything-you-want` language. That means it transforms the textual contents of the script tag into a string of javascript, and then calls `eval` on the string.

OK, so then your language implementation walks the DOM for script tags with the required type and compiles them.

That's a pretty cool technique.