6 ms·

JSX: XML-like syntax extension to ECMAScript – Draft specification

76 points by peterhunt 12y ago

pistle 12y ago
Where's the transformation language JSXT? O.o Why are nearly all the examples pushing literal UI concerns into the code, if not tightly weaving it with the controller? I see what it is, but I see nothing about why it is - I'm open for understanding. Someone please help.
- kansface 12y ago
  JSX/React is not a controller, it is the view. See the React docs: http://facebook.github.io/react/ http://facebook.github.io/react/.
kijin 12y ago
Somebody please enlighten me as to why this is better than good ol' JSON or XML/SGML/HTML, especially if it's meant to be processed into something else anyway?
- kansface 12y ago
  JSX is transpiled into Javascript (which generates HTML at runtime)- its function in React is basically that of a templating language. JSX also allows inlining Javascript in a limited fashion. I could not imagine a sane implementation using JSON. As for XML and friends, you would have to shoehorn in supporting JS.
  - kijin 12y ago
    Thanks, I'd been genuinely curious. (I tend to stay as far away as I can from JS-based templating systems, so that's probably why I didn't appreciate that use case.)
deleted 12y ago
[deleted]
themartorana 12y ago
I can't quite see the logic behind a markup syntax for a transpiler to output code that builds other markup. Can someone with a better understanding explain what the benefit is here? It doesn't seem easier than JS or HTML so I don't understand the point of the abstraction. But I haven't built much on the browser-side in a few years so I am certain I am missing something.
- hderms 12y ago
  I think it's mostly to avoid the whole mess of having Javascript arbitrarily selecting DOM elements that are declared elsewhere and then manipulating them/cloning them to create some new DOM. If you were creating some DOM/code component intended to act as a black box, it may be conceptually simpler to have the DOM part of it created via code and explicitly referenced by the code. YMMV
- hcarvalhoalves 12y ago
  In the "perfect world", we would be using LISP, and our code would be data and our data would be code. We're stuck with JS, so it's convenient to have a declarative syntax that compiles to JS, because nested function calls suck. As the doc states: > The purpose of this specification is to define a concise and familiar syntax for defining tree structures with attributes. This can be used for anything, it has nothing to do with HTML actually. Just like there are many languages and frameworks where you describe UIs with some flavor of XML that compile behind the scenes to API calls to create windows, append buttons, etc.
  - coldtea 12y ago
    >In the "perfect world", we would be using LISP, and our code would be data and our data would be code. Well, it wouldn't be that perfect, because then we'd be forced to live with that Lisp (lack of) syntax.
    - lispm 12y ago
      Well, Lisp has a lot of syntax. It just looks and works different. For example the syntax of IF is: if test-form then-form [else-form] Examples: (if foo 1 2) (if foo 1) That means: after IF there are exactly two or three expressions. LET looks more complicated: let ({var | (var [init-form])}*) declaration* form* Example: (let ((foo 10) bar) (declare (integer foo)) (setq bar foo) foo) Note, the notation with parentheses is not the syntax of the Lisp programming language, but of symbolic expressions. The Lisp syntax is defined on top of s-expressions. Not every s-expression is a valid Lisp program. For example the following are not valid Lisp expressions, but still valid s-expressions: (if foo 1 2 (3) (4)) (let a (declare (integer 10)) 3 + a)
Hytosys 12y ago
It's always odd to see such an effort against the value of separation of concerns. Facebook's team is heavily invested in the doctrine of PHP of course, so JSX is no surprise.
- peterhunt 12y ago
  What concerns are you separating exactly?
  - Hytosys 12y ago
    I'm not arguing that JavaScript cannot be used for UI expression. It just seems that JSX disregards organizational sanity (logic & UI all in one place) to pick up React's slack. Maybe I'm missing the point here (I come from a background in AngularJS). Edit: I'm reading up on React and can see the arguments against strictly templating. Makes sense now!
  - j_s 12y ago
    The React website specifically addresses this: http://facebook.github.io/react/docs/displaying-data.html#jsx-syntax http://facebook.github.io/react/docs/displaying-data.html#js... We strongly believe that components are the right way to separate concerns rather than "templates" and "display logic."
    - Hytosys 12y ago
      Thanks for the reading. Looks like I fell right into their trap! (With my recent response in this thread: "logic & UI")
marcuswestin 12y ago
I think this is a great and well intended effort. One of the biggest use cases for Javascript is to manipulate and create DOMs. jQuery solved the manipulation part beautifully, but DOM creation remained a hassle. Lots of templating solutions have been attempted, but none of them seem to hit the sweet spot just right (that's a primary reason why there are so many). JSX is a novel contender that may be just right - even if it's not, it will hopefully push us as a community towards a better solution by offering a very new approach with its own benefits and problems. Thanks to the peeps at fb for taking the time and effort to make JSX bigger than just reactjs!
cdata 12y ago
The example used to demonstrate template literal "syntax noise" in this proposal is an unfair exaggeration, in my opinion. JSX is handy because it allows authors to think about the hierarchical relationship of components in terms of how they would be laid out in something like HTML. Template literals may not be ideally suited to the JSX case, but they represent a promising "native" solution to the problem JSX tries to solve. I'm always happier when I can leverage something that is native to the language I'm using to solve a problem.
MichaelGG 12y ago
>Balanced named tags is a critical syntactic feature of the XML-style notation. I guess there's an argument for everything. But I thought in general, people usually found XML's verbose endings to be noisy and useless. It could always be opt-in, so you only need to add them where needed. <start><item>something</>...</start> Or you could just add a comment.
bastawhiz 12y ago
So..uh...this was a thing. And nobody wanted it. So it was deprecated and killed. See the "Prior Art" section at the bottom of the page. http://en.wikipedia.org/wiki/ECMAScript_for_XML http://en.wikipedia.org/wiki/ECMAScript_for_XML Brendan Eich was quoted as saying something along the lines of "E4X is crazyland". Parsing it is hard as hell to do right. Think of all the tooling that's out there for JavaScript right now that will either a.) not support JSX code or b.) bloat up beyond belief as it takes into account the suddenly absurd requirements necessary to deal with a similar-but-not-quite-XML-or-even-HTML-for-that-matter syntax. Oh, you want to lint that JavaScript? Bless your heart! You want to add syntax highlighting? Love will find a way. You want to use other static analysis tools, sweet.js macros, or anything else non-trivial? How cute! So essentially, it's a great way for Facebook to push React.js without making React.js a standard.
- grrowl 12y ago
  JSXHint exists[1] and works well, and highlighting libraries exist[2]. Have you actually tried the syntax? It makes sense when used with React.js (which is quite lovely), as almost all of the new syntax exists within a render() function. It's also leaner syntactically than EMCAScript for XML, without introducing additional weirdness like "object.@items" selectors. Work with both JSX and regular JS in React and you'll see why they're doing this. [1]: https://github.com/STRML/JSXHint https://github.com/STRML/JSXHint [2]: https://github.com/reactjs/sublime-react https://github.com/reactjs/sublime-react
- skrebbel 12y ago
  one of the JSX designers answered your entire comment before you even wrote it: http://blog.vjeux.com/2013/javascript/jsx-e4x-the-good-parts.html http://blog.vjeux.com/2013/javascript/jsx-e4x-the-good-parts... Also, you somehow managed to imply that JSX makes it impossible to use sweet.js macros. There's a sweet.js implementation of JSX, so that's absolutely bollocks. https://github.com/jlongster/jsx-reader https://github.com/jlongster/jsx-reader
- coldtea 12y ago
  >So..uh...this was a thing. And nobody wanted it. So it was deprecated and killed. So was Harmony. And then it was ressurected. >Brendan Eich was quoted as saying something along the lines of "E4X is crazyland" I don't think Brendan Eich has his finger in the pulse of the modern web, so to speak.
aeosynth 12y ago
There are even alternative syntaxes: https://github.com/lantiga/react.hiccup https://github.com/lantiga/react.hiccup https://github.com/ForbesLindesay/react-jade https://github.com/ForbesLindesay/react-jade
- twfarland 12y ago
  I have found it easy enough to just use json-serializable literals to represent html, e.g: ['div', {id: 'main'}, ['h1', 'Some title'], ['p', 'Some text']] I wrote a little function to turn this kind of thing into an html string (https://github.com/twfarland/don https://github.com/twfarland/don), but it could also be used as the view descriptor for some kind of view component ala React. Might work on that...
  - wbkang 12y ago
    I like this a lot. I actually used this at work. With a simple function to translate JSON into DOM incrementally, it's a lot more succinct than JSX. And it's fully programmable in JS.
thomasfoster96 12y ago
As much as Facebook's efforts to fix the tools they are forced to use are valliant, this is a little bit ugly. Still, points for trying.
jlongster 12y ago
Really surprised this doesn't mention my project that implements JSX as a sweet.js reader. It's a much better sweet integration than the one list that forces you to use a very different syntax to use JSX. https://github.com/jlongster/jsx-reader https://github.com/jlongster/jsx-reader (Hey React guys... I know you know of my project, what's up with that?)
- mambodog 12y ago
  It's not an exhaustive list of JSX implementations.
- spicyj 12y ago
  This is a mistake; I think we got it confused with andreypopp's sweet-jsx by mistake.
  - jlongster 12y ago
    Cool, thanks.
jonchang 12y ago
Facebook has been doing a lot of work in this area, initially implemented in PHP by Marcel Laverdet in 2010, called XHP[1]. Not only does it permit you to embed conformant HTML into your PHP code without inadvertently introducing XSS vectors, but it also allows you to compose HTML primitives into high-level markup. Stefan Parker has been regularly blogging since 2011 about how Facebook uses XHP in its UI design; one of the best posts on the topic is here[2]. You may also recall the now-defunct "Facebook Lite" which was written completely in XHP. Laverdet also implemented something similar for node.js called js-xml-literals[3], which I don't think has gained much traction. As for how it's different from E4X, refer to this page[4], which makes the argument that parsing and producing XML are two different tasks; E4X attempts to do both while all of these other approaches focus on producing XML. (I don't think that this perspective on the history of react.js/jsx has been well-publicized before, hence the post.) [1]: https://www.facebook.com/notes/facebook-engineering/xhp-a-new-way-to-write-php/294003943919 https://www.facebook.com/notes/facebook-engineering/xhp-a-ne... [2]: http://codebeforethehorse.tumblr.com/post/52824249342/building-a-good-ui-framework-with-xhp http://codebeforethehorse.tumblr.com/post/52824249342/buildi... [3]: https://github.com/laverdet/js-xml-literal https://github.com/laverdet/js-xml-literal [4]: https://github.com/laverdet/js-xml-literal/wiki/Differences-from-E4X https://github.com/laverdet/js-xml-literal/wiki/Differences-...
- kiyoto 12y ago
  My only quip about this JSX is nomenclature: Oku et. al. at DeNA open-sourced a typed variant of ECMAScript under the exact same name a couple of years earlier: http://jsx.github.io/ http://jsx.github.io/ With Facebook's brand and recognition, I am sure this JSX will eclipse the other JSX, which is rather unfortunate.
Skywing 12y ago
So, yea I think this is a great thing and I don't mind JSX. It has been a pleasure to use ... I think. I can't help but be reminded about original PHP, though. When PHP was new, you could write PHP but then you could also write your markup in the same file. The end result was a bunch of bad PHP and markup. JSX is not quite is liberal, but it's along the same vein. You kind of have markup in your Javascript, now (I say now, but I guess you did before in some cases where you built DOM elements with JS). Especially with components that also have HTML-literal content in them, like labels and text and stuff. Like, to literally change the text in a form or something, you might have to go edit your Javascript file ... no wait, your JSX file to change that. Javascript is also already enough of a pandoras box, in regards to common patterns and "how to do X or Y." I don't really know how to articulate my thoughts on it yet, but I feel like I lean towards rather not having to look at code with JSX in it than having to do so.
tgriesser 12y ago
Many of the comments seem to be along the lines of "why create a markup syntax to build more markup and throw it in JavaScript" - In my opinion that's not the real benefit of JSX, but just one use case. The great thing about JSX is that it doesn't build markup. It doesn't even need to be used for markup, it can be used for anything. It's frequently associated with markup because it has been used alongside React, but JSX standalone is a simple syntactic transform for XML-ish notation to JavaScript. This is quite convenient in some cases, as you can elegantly write DSL's, where each of the tag names are JavaScript functions - and writing the equivalent JavaScript would look something closer to a lisp (moving the function name to the right of the paren). This: <Database name="business"> <Table name="user"> <Column name="id" type='int' length={10} /> <Column name="first_name" type='string' length={255} /> <Column name="last_name" type='string' length={255} /> <Column name="choice" type='enum' values={['a', 'b', 'c']} /> </Table> <Table name="account"> <Column name="id" type='int' length={10} /> <Column name="first_name" type='string' length={255} /> <Column name="last_name" type='string' length={255} /> <Column name="choice" type='enum' values={['a', 'b', 'c']} /> </Table> </Database> run through the compiler[1] becomes this: Database({name: "business"}, Table({name: "user"}, Column({name: "id", type: "int", length: 10}), Column({name: "first_name", type: "string", length: 255}), Column({name: "last_name", type: "string", length: 255}), Column({name: "choice", type: "enum", values: ['a', 'b', 'c']}) ), Table({name: "account"}, Column({name: "id", type: "int", length: 10}), Column({name: "first_name", type: "string", length: 255}), Column({name: "last_name", type: "string", length: 255}), Column({name: "choice", type: "enum", values: ['a', 'b', 'c']}) ) ) I find the first easier to read / reorganize in blocks, which can be useful in lots of situations... definitely not all situations - but having declarative markup while being able to imagine it executing as the latter, constructing actual JS objects with specific logic built in - rather than needing to "parse" the XML tree and deal with an extra step of execution, etc, etc. [1]: http://facebook.github.io/react/jsx-compiler.html http://facebook.github.io/react/jsx-compiler.html
- roryokane 12y ago
  > JSX standalone is a simple syntactic transform for XML-ish notation to JavaScript But not necessarily the same translation as in your example (that is, tags to function calls and attributes to first arguments). Perhaps all existing implementations work like that, but the spec leaves the JavaScript representation undefined. The spec draws attention to this intentional ambiguity when it lists “a set of transpilers that all conform to the JSX syntax but use different semantics on the output”.
k__ 12y ago
Some IDE plugin for this would be nice. JSX -> JS -> JSX Just JS gets committed into the repository. When the developer likes/needs JSX he just uses the JSX like an overlay for a specific code part.

76 points by peterhunt 12y ago

Where's the transformation language JSXT? O.o Why are nearly all the examples pushing literal UI concerns into the code, if not tightly weaving it with the controller? I see what it is, but I see nothing about why it is - I'm open for understanding. Someone please help.

kansface 12y ago
JSX/React is not a controller, it is the view. See the React docs: http://facebook.github.io/react/ http://facebook.github.io/react/.

kijin 12y ago

Somebody please enlighten me as to why this is better than good ol' JSON or XML/SGML/HTML, especially if it's meant to be processed into something else anyway?

kansface 12y ago
JSX is transpiled into Javascript (which generates HTML at runtime)- its function in React is basically that of a templating language. JSX also allows inlining Javascript in a limited fashion. I could not imagine a sane implementation using JSON. As for XML and friends, you would have to shoehorn in supporting JS.
- kijin 12y ago
  Thanks, I'd been genuinely curious. (I tend to stay as far away as I can from JS-based templating systems, so that's probably why I didn't appreciate that use case.)

deleted 12y ago

[deleted]

themartorana 12y ago

I can't quite see the logic behind a markup syntax for a transpiler to output code that builds other markup. Can someone with a better understanding explain what the benefit is here? It doesn't seem easier than JS or HTML so I don't understand the point of the abstraction. But I haven't built much on the browser-side in a few years so I am certain I am missing something.

hderms 12y ago
I think it's mostly to avoid the whole mess of having Javascript arbitrarily selecting DOM elements that are declared elsewhere and then manipulating them/cloning them to create some new DOM. If you were creating some DOM/code component intended to act as a black box, it may be conceptually simpler to have the DOM part of it created via code and explicitly referenced by the code. YMMV
hcarvalhoalves 12y ago
In the "perfect world", we would be using LISP, and our code would be data and our data would be code. We're stuck with JS, so it's convenient to have a declarative syntax that compiles to JS, because nested function calls suck. As the doc states: > The purpose of this specification is to define a concise and familiar syntax for defining tree structures with attributes. This can be used for anything, it has nothing to do with HTML actually. Just like there are many languages and frameworks where you describe UIs with some flavor of XML that compile behind the scenes to API calls to create windows, append buttons, etc.
- coldtea 12y ago
  >In the "perfect world", we would be using LISP, and our code would be data and our data would be code. Well, it wouldn't be that perfect, because then we'd be forced to live with that Lisp (lack of) syntax.
  - lispm 12y ago
    Well, Lisp has a lot of syntax. It just looks and works different. For example the syntax of IF is: if test-form then-form [else-form] Examples: (if foo 1 2) (if foo 1) That means: after IF there are exactly two or three expressions. LET looks more complicated: let ({var | (var [init-form])}*) declaration* form* Example: (let ((foo 10) bar) (declare (integer foo)) (setq bar foo) foo) Note, the notation with parentheses is not the syntax of the Lisp programming language, but of symbolic expressions. The Lisp syntax is defined on top of s-expressions. Not every s-expression is a valid Lisp program. For example the following are not valid Lisp expressions, but still valid s-expressions: (if foo 1 2 (3) (4)) (let a (declare (integer 10)) 3 + a)

Hytosys 12y ago

It's always odd to see such an effort against the value of separation of concerns. Facebook's team is heavily invested in the doctrine of PHP of course, so JSX is no surprise.

peterhunt 12y ago
What concerns are you separating exactly?
- Hytosys 12y ago
  I'm not arguing that JavaScript cannot be used for UI expression. It just seems that JSX disregards organizational sanity (logic & UI all in one place) to pick up React's slack. Maybe I'm missing the point here (I come from a background in AngularJS). Edit: I'm reading up on React and can see the arguments against strictly templating. Makes sense now!
- j_s 12y ago
  The React website specifically addresses this: http://facebook.github.io/react/docs/displaying-data.html#jsx-syntax http://facebook.github.io/react/docs/displaying-data.html#js... We strongly believe that components are the right way to separate concerns rather than "templates" and "display logic."
  - Hytosys 12y ago
    Thanks for the reading. Looks like I fell right into their trap! (With my recent response in this thread: "logic & UI")

marcuswestin 12y ago

I think this is a great and well intended effort. One of the biggest use cases for Javascript is to manipulate and create DOMs. jQuery solved the manipulation part beautifully, but DOM creation remained a hassle. Lots of templating solutions have been attempted, but none of them seem to hit the sweet spot just right (that's a primary reason why there are so many). JSX is a novel contender that may be just right - even if it's not, it will hopefully push us as a community towards a better solution by offering a very new approach with its own benefits and problems. Thanks to the peeps at fb for taking the time and effort to make JSX bigger than just reactjs!

cdata 12y ago

The example used to demonstrate template literal "syntax noise" in this proposal is an unfair exaggeration, in my opinion. JSX is handy because it allows authors to think about the hierarchical relationship of components in terms of how they would be laid out in something like HTML. Template literals may not be ideally suited to the JSX case, but they represent a promising "native" solution to the problem JSX tries to solve. I'm always happier when I can leverage something that is native to the language I'm using to solve a problem.

MichaelGG 12y ago

>Balanced named tags is a critical syntactic feature of the XML-style notation. I guess there's an argument for everything. But I thought in general, people usually found XML's verbose endings to be noisy and useless. It could always be opt-in, so you only need to add them where needed. <start><item>something</>...</start> Or you could just add a comment.

bastawhiz 12y ago

So..uh...this was a thing. And nobody wanted it. So it was deprecated and killed. See the "Prior Art" section at the bottom of the page. http://en.wikipedia.org/wiki/ECMAScript_for_XML http://en.wikipedia.org/wiki/ECMAScript_for_XML Brendan Eich was quoted as saying something along the lines of "E4X is crazyland". Parsing it is hard as hell to do right. Think of all the tooling that's out there for JavaScript right now that will either a.) not support JSX code or b.) bloat up beyond belief as it takes into account the suddenly absurd requirements necessary to deal with a similar-but-not-quite-XML-or-even-HTML-for-that-matter syntax. Oh, you want to lint that JavaScript? Bless your heart! You want to add syntax highlighting? Love will find a way. You want to use other static analysis tools, sweet.js macros, or anything else non-trivial? How cute! So essentially, it's a great way for Facebook to push React.js without making React.js a standard.

grrowl 12y ago
JSXHint exists[1] and works well, and highlighting libraries exist[2]. Have you actually tried the syntax? It makes sense when used with React.js (which is quite lovely), as almost all of the new syntax exists within a render() function. It's also leaner syntactically than EMCAScript for XML, without introducing additional weirdness like "object.@items" selectors. Work with both JSX and regular JS in React and you'll see why they're doing this. [1]: https://github.com/STRML/JSXHint https://github.com/STRML/JSXHint [2]: https://github.com/reactjs/sublime-react https://github.com/reactjs/sublime-react
skrebbel 12y ago
one of the JSX designers answered your entire comment before you even wrote it: http://blog.vjeux.com/2013/javascript/jsx-e4x-the-good-parts.html http://blog.vjeux.com/2013/javascript/jsx-e4x-the-good-parts... Also, you somehow managed to imply that JSX makes it impossible to use sweet.js macros. There's a sweet.js implementation of JSX, so that's absolutely bollocks. https://github.com/jlongster/jsx-reader https://github.com/jlongster/jsx-reader
coldtea 12y ago
>So..uh...this was a thing. And nobody wanted it. So it was deprecated and killed. So was Harmony. And then it was ressurected. >Brendan Eich was quoted as saying something along the lines of "E4X is crazyland" I don't think Brendan Eich has his finger in the pulse of the modern web, so to speak.

aeosynth 12y ago

There are even alternative syntaxes: https://github.com/lantiga/react.hiccup https://github.com/lantiga/react.hiccup https://github.com/ForbesLindesay/react-jade https://github.com/ForbesLindesay/react-jade

twfarland 12y ago
I have found it easy enough to just use json-serializable literals to represent html, e.g: ['div', {id: 'main'}, ['h1', 'Some title'], ['p', 'Some text']] I wrote a little function to turn this kind of thing into an html string (https://github.com/twfarland/don https://github.com/twfarland/don), but it could also be used as the view descriptor for some kind of view component ala React. Might work on that...
- wbkang 12y ago
  I like this a lot. I actually used this at work. With a simple function to translate JSON into DOM incrementally, it's a lot more succinct than JSX. And it's fully programmable in JS.

thomasfoster96 12y ago

As much as Facebook's efforts to fix the tools they are forced to use are valliant, this is a little bit ugly. Still, points for trying.

jlongster 12y ago

Really surprised this doesn't mention my project that implements JSX as a sweet.js reader. It's a much better sweet integration than the one list that forces you to use a very different syntax to use JSX. https://github.com/jlongster/jsx-reader https://github.com/jlongster/jsx-reader (Hey React guys... I know you know of my project, what's up with that?)

mambodog 12y ago
It's not an exhaustive list of JSX implementations.
spicyj 12y ago
This is a mistake; I think we got it confused with andreypopp's sweet-jsx by mistake.
- jlongster 12y ago
  Cool, thanks.

jonchang 12y ago

Facebook has been doing a lot of work in this area, initially implemented in PHP by Marcel Laverdet in 2010, called XHP[1]. Not only does it permit you to embed conformant HTML into your PHP code without inadvertently introducing XSS vectors, but it also allows you to compose HTML primitives into high-level markup. Stefan Parker has been regularly blogging since 2011 about how Facebook uses XHP in its UI design; one of the best posts on the topic is here[2]. You may also recall the now-defunct "Facebook Lite" which was written completely in XHP. Laverdet also implemented something similar for node.js called js-xml-literals[3], which I don't think has gained much traction. As for how it's different from E4X, refer to this page[4], which makes the argument that parsing and producing XML are two different tasks; E4X attempts to do both while all of these other approaches focus on producing XML. (I don't think that this perspective on the history of react.js/jsx has been well-publicized before, hence the post.) [1]: https://www.facebook.com/notes/facebook-engineering/xhp-a-new-way-to-write-php/294003943919 https://www.facebook.com/notes/facebook-engineering/xhp-a-ne... [2]: http://codebeforethehorse.tumblr.com/post/52824249342/building-a-good-ui-framework-with-xhp http://codebeforethehorse.tumblr.com/post/52824249342/buildi... [3]: https://github.com/laverdet/js-xml-literal https://github.com/laverdet/js-xml-literal [4]: https://github.com/laverdet/js-xml-literal/wiki/Differences-from-E4X https://github.com/laverdet/js-xml-literal/wiki/Differences-...

kiyoto 12y ago
My only quip about this JSX is nomenclature: Oku et. al. at DeNA open-sourced a typed variant of ECMAScript under the exact same name a couple of years earlier: http://jsx.github.io/ http://jsx.github.io/ With Facebook's brand and recognition, I am sure this JSX will eclipse the other JSX, which is rather unfortunate.

Skywing 12y ago

So, yea I think this is a great thing and I don't mind JSX. It has been a pleasure to use ... I think. I can't help but be reminded about original PHP, though. When PHP was new, you could write PHP but then you could also write your markup in the same file. The end result was a bunch of bad PHP and markup. JSX is not quite is liberal, but it's along the same vein. You kind of have markup in your Javascript, now (I say now, but I guess you did before in some cases where you built DOM elements with JS). Especially with components that also have HTML-literal content in them, like labels and text and stuff. Like, to literally change the text in a form or something, you might have to go edit your Javascript file ... no wait, your JSX file to change that. Javascript is also already enough of a pandoras box, in regards to common patterns and "how to do X or Y." I don't really know how to articulate my thoughts on it yet, but I feel like I lean towards rather not having to look at code with JSX in it than having to do so.

tgriesser 12y ago

Many of the comments seem to be along the lines of "why create a markup syntax to build more markup and throw it in JavaScript" - In my opinion that's not the real benefit of JSX, but just one use case. The great thing about JSX is that it doesn't build markup. It doesn't even need to be used for markup, it can be used for anything. It's frequently associated with markup because it has been used alongside React, but JSX standalone is a simple syntactic transform for XML-ish notation to JavaScript. This is quite convenient in some cases, as you can elegantly write DSL's, where each of the tag names are JavaScript functions - and writing the equivalent JavaScript would look something closer to a lisp (moving the function name to the right of the paren). This: <Database name="business"> <Table name="user"> <Column name="id" type='int' length={10} /> <Column name="first_name" type='string' length={255} /> <Column name="last_name" type='string' length={255} /> <Column name="choice" type='enum' values={['a', 'b', 'c']} /> </Table> <Table name="account"> <Column name="id" type='int' length={10} /> <Column name="first_name" type='string' length={255} /> <Column name="last_name" type='string' length={255} /> <Column name="choice" type='enum' values={['a', 'b', 'c']} /> </Table> </Database> run through the compiler[1] becomes this: Database({name: "business"}, Table({name: "user"}, Column({name: "id", type: "int", length: 10}), Column({name: "first_name", type: "string", length: 255}), Column({name: "last_name", type: "string", length: 255}), Column({name: "choice", type: "enum", values: ['a', 'b', 'c']}) ), Table({name: "account"}, Column({name: "id", type: "int", length: 10}), Column({name: "first_name", type: "string", length: 255}), Column({name: "last_name", type: "string", length: 255}), Column({name: "choice", type: "enum", values: ['a', 'b', 'c']}) ) ) I find the first easier to read / reorganize in blocks, which can be useful in lots of situations... definitely not all situations - but having declarative markup while being able to imagine it executing as the latter, constructing actual JS objects with specific logic built in - rather than needing to "parse" the XML tree and deal with an extra step of execution, etc, etc. [1]: http://facebook.github.io/react/jsx-compiler.html http://facebook.github.io/react/jsx-compiler.html

roryokane 12y ago
> JSX standalone is a simple syntactic transform for XML-ish notation to JavaScript But not necessarily the same translation as in your example (that is, tags to function calls and attributes to first arguments). Perhaps all existing implementations work like that, but the spec leaves the JavaScript representation undefined. The spec draws attention to this intentional ambiguity when it lists “a set of transpilers that all conform to the JSX syntax but use different semantics on the output”.

k__ 12y ago

Some IDE plugin for this would be nice. JSX -> JS -> JSX Just JS gets committed into the repository. When the developer likes/needs JSX he just uses the JSX like an overlay for a specific code part.