10 ms·

JSX in detail

129 points by Pishky 9y ago

cstrat 9y ago
Thanks for posting this, it's a good read so far. I have been using JSX quite a bit and this is helping me get a better understanding.
brochington 9y ago
Experimenting with JSX has introduced me to two language constructs: the Pragma, and the Macro. I know that these might seem a bit pedestrian to most folks, but they opened up my understanding of programming languages considerably. I am genuinely a bit surprised that the Javascript community hasn't played around more with the possibilities that both can offer.
- viebel 9y ago
  In LISP based languages like ClojureScript, macros are part of the language. No need to build tools like JSX (that requires to run on webpack + IDE tooling etc...).
  - masklinn 9y ago
    JSX could be language-integrated (witness the now-deprecated E4X for XML literals in Javascript), it just is not. And most lisps don't have unfettered reader macros which would allow embedding macros using non-lisp syntax (aka JSX). A macroed JSX wouldn't make much sense in Lisps really, and AFAIK isn't used with most clojurescript vdoms using either hiccup structures or regular function calls.
    - viebel 9y ago
      who needs JSX when you have hiccup!
      - deleted 9y ago
        [deleted]
      - masklinn 9y ago
        Possibly a more uniform treatment of components versus "literal elements", but yeah the value proposition becomes very low. In fact I'd argue the value proposition of JSX is already relatively low when you factor in hyperscript in regular javascript (and yes there are component-compatible hyperscript helpers for React).
        lilactown 9y ago
        I think that Hiccup's idea of writing the tree as a tree-like data structure is superior to writing a tree of function calls. I tried doing something similar in JavaScript; the result looks a bit silly (I realized the elegance of not needing to delimit lists with a , in LISP right here) and has questionable performance: https://github.com/Lokeh/hux https://github.com/Lokeh/hux
  - amk_ 9y ago
    I could be wrong, but I don't think a LISP macro can transform the structure of the code in the same way that the JSX pragma turns an XML tree "inside-out". For example here's the source for the Babel JSX transformer: https://github.com/babel/babel/blob/master/packages/babel-plugin-transform-react-jsx/src/index.js https://github.com/babel/babel/blob/master/packages/babel-pl...
    - sbergot 9y ago
      A lisp macro see a code block as a tree of symbols/primitives. It can do anything. This means that it is easy to write a library with a nice dsl, but hard to read other people's code.
      - masklinn 9y ago
        > A lisp macro see a code block as a tree of symbols/primitives. It can do anything. No, a regular macro still needs to be syntactically sensible. To handle arbitrary non-lisp syntax you need your lisp to support arbitrary reader macros (as in Common Lisp or — I believe — Racket) and that gets significantly more complex and involved and requires extensible/pluggable parsing. Scheme does not have that for instance, SFRI-10 reader macros need to be wrapped in `#,()`, you can't just dump JSX or XML in Scheme source and expect it to work.
        shakna 9y ago
        > Scheme does not have that for instance, SFRI-10 reader macros need to be wrapped in `#,()`, you can't just dump JSX or XML in Scheme source and expect it to work. That's not 100% true. See SRFI-105 which gives you infix expressions without needing to wrap them, and mixing and matching is supported the moment you dive into reader macros. #!curly-infix (+ 2 {a + b + c}) You do need to enable the reader modification, either in your own read (useful if you want safe eval, and parsing in limited environments), in which case you'd just provide an argument to read, or if you want it globally it'll probably just look like: #!jsx DOM.render( <h1>Hello world</h1>, document.getElementById((string-append "hel" "lo")) ) Writing the reader would be considerable work, but hardly impossible for Scheme to play nicely.
  - ghusbands 9y ago
    In Lisp, if you created something like JSX, your IDE or text editor would still be unlikely to understand it, as it'd be a very complicated reader macro. It doesn't magically solve all macro problems. Doing it the Lispy way, though, you'd likely use sexprs directly, with maybe some normal macros, so you wouldn't have HTML-like syntax but would have something that worked nicely in your editor.
    - shakna 9y ago
      SXML has been around a while, and makes working with HTML in most Lisps a breeze. See this for example [0]. '((html (head (title "My Title")) (body (@ (bgcolor "white")) (h1 "My Heading") (p "This is a paragraph.") (p "This is another paragraph.")))) [0] http://www.neilvandyke.org/racket/html-writing/ http://www.neilvandyke.org/racket/html-writing/
    - davexunit 9y ago
      Lisp comes with a built-in templating system: quasiquote. Systems such as SXML (an s-expression representation of XML documents) build on top of that. This takes care of multiple problems with JSX: 1) writing HTML/XML is annoying (remembering to put the close tag in the right place, etc.) 2) JSX is a DSL, not an embedded DSL, so you need new compiler infrastructure to work with it. Here is a snippet of real code that produces an SXML tree. It generates atom feeds for websites that use a static generator I wrote: `(feed (@ (xmlns "http://www.w3.org/2005/Atom")) (title ,(site-title site)) (subtitle ,subtitle) (updated ,(date->string* (current-date))) (link (@ (href ,(string-append (site-domain site) "/" file-name)) (rel "self"))) (link (@ (href ,(site-domain site)))) ,@(map (cut post->atom-entry site <> #:blog-prefix blog-prefix) (take-up-to max-entries (filter posts)))) By far the best templating system I've ever used.
  - bananicorn 9y ago
    They work something like this in LISPs, right? Like, can you define new language constructs with them? http://www.red-lang.org/2016/12/entering-world-of-macros.html http://www.red-lang.org/2016/12/entering-world-of-macros.htm... (BTW, have a look at red for desktop apps, it's not even at 1.0 and already fucking amazing) But on topic; Are Macros a well-defined "thing"? Since a macro in C, seems to be rather different from a RED or LISP Macro. Or is it just that C macros are essentially the same, just more restricted?
    - lmkg 9y ago
      C macros are text substitution, implemented in a separate less-expressive language (the C pre-processor). Lisp macros access the input program fragment as structured data, and manipulate that using the same Lisp functions and data structures that you use for regular, normal Lisp code. I think that both forms are technically Turing-Complete, but Lisp is more expressive. In particular, it's much more common to see Lisp macros that destructure and reform their inputs, where C macros tend to see their inputs as black boxes that can't be opened. The textual-substitution model of C also has some extra perils, because code fragments can be context sensitive (such as creating identifiers that are already in scope). In both cases, Macros are well-defined "things" in the sense that they are thoroughly defined in their respective language documents, but in both cases they are not first-class language items because they don't exist at run-time.
- Vinnl 9y ago
  Here you got me interested in this post hoping it would use JSX to introduce Pragma's and Macro's, turns out it just reiterates what JSX compiles down to...
- blauditore 9y ago
  I'm not sure what exactly you're referring to by macros. A container for boilerplate code to avoid repetition, as in templating languages? If so, the React solution would probably be extracting a simple component which just provides markup.
- deleted 9y ago
  [deleted]
danenania 9y ago
Has anyone else made the switch from JSX to hyperscript? JSX works well enough, but I love the consistency and composability of building views with plain old functions and data structures.
- madeofpalk 9y ago
  JSX is just 'plain old functions' - just with some syntactic sugar on top to make it a bit easier to write. In fact, JSX compiles down to functions looking very similar to hyperscript...
- insin 9y ago
  I switched the other way, as JSX fixed the main problem I've had for years using "hyperscript" (or DOM builders, as we used to say). Its comma-free syntax sugar for function calls, element lists and attribute objects makes it so much easier to write and maintain.
- iMark 9y ago
  Our team moved from hyperscript to JSX as well. Personally, I find JSX much more readable, and there was little love for hyperscript on the team.
- doublerebel 9y ago
  There are a number of template languages that compile to hyperscript, I use jade/pug [0]. I haven't had to change my templates in years but I can still take advantage of virtual DOMs like React. Before hyperscript, there was Templatizer which also compiled templates to JS functions. There are numerous good reasons to be able to manipulate templates easily as functions. Nevertheless there are numerous good reasons for templates (e.g. my designers don't need to know JavaScript, template languages last longer than JS trends, etc.). [0]: https://github.com/nextorigin/gulp-pug-hyperscript https://github.com/nextorigin/gulp-pug-hyperscript
- amk_ 9y ago
  Yeah, I wrote about it last week: https://medium.com/@alexkrolick/writing-react-components-for-3rd-party-embedding-50331c18e26 https://medium.com/@alexkrolick/writing-react-components-for... "Overall it's not a bad experience. JSX makes HTML feel more at home, but tends to obscure the underlying Javascript. Composition and higher-order components are more obvious in plain JS. If I was writing a library using those patterns heavily I might be tempted to go JSX-free even if bundling with Webpack + Babel."
thomasfl 9y ago
Hyperscript markup looks like a nice replacement for JSX. The source for hyperscript-react is 50 lines of code, including comments and empty lines, so it's fairly easy to learn: https://github.com/mlmorg/react-hyperscript/blob/master/index.js https://github.com/mlmorg/react-hyperscript/blob/master/inde...
- Androider 9y ago
  To me this looks much less readable than the equivalent JSX. JSX has been such a non-issue for me, it's extremely reliable and you can use all the new JS map/filters, loops, etc. instead of learning some half-finished template language.
  - gyrgtyn 9y ago
    > learning half-finished template language javascript?
- blorenz 9y ago
  It may be fairly easy to learn, but mentally evaluating context during usage will be the friction much akin to HAML.
keymone 9y ago
https://github.com/lantiga/react.hiccup https://github.com/lantiga/react.hiccup
haukur 9y ago
Another good resource to learn about JSX (by the author of Preact): https://jasonformat.com/wtf-is-jsx/ https://jasonformat.com/wtf-is-jsx/
omegote 9y ago
It's funny how, for years, we've been trying to get away from HTML mixed with code (specially in spaguetti PHP), just to get back to something similar again.
- dudul 9y ago
  Can't upvote this enough. Each time I try to dive into React/JSX I have some dark visions of PHP and JSP in my head.
- lkrubner 9y ago
  You bring up a point that was discussed 35 days ago: https://news.ycombinator.com/item?id=14925899 https://news.ycombinator.com/item?id=14925899 Tarikyn said: "Most developers I knew in person didn't care about CSS or didn't 'get' it." Part of my response was: "Some people looked at the chaos of non-standard HTML and decided the Web was successful because it had been broken from the beginning, and it had learned to work well while broken. I reached a different conclusion. It became clear to me that what developers wanted to do simply had nothing to do with HTTP/HTML. We don't yet have the technology to do what developers want to do. HTML was an interesting experiment, but it suffered from a dual mandate. Sir Tim Berners Lee wanted HTML to both structure data and also present it in graphical form. Almost from the start, developers were conflicted about which mandate they should obey, but the preference, since at least 1993, if not earlier, was to give priority to the visual. For all practical purposes, developers saw HTTP/HTML as GUI for IP/TCP. Previous IP/TCP technologies (email, gopher, ftp) had lacked a visual component, but HTML finally offered a standard way to send things over Internet and format the end result visually (emphasis on "standard"; I could insert an aside here about X window systems and some cool software of that era, but every app implemented their own ideas about visual presentation. X-Emacs, for instance, had its own system for visual formatting over a network)." The point is, HTML was an interesting experiment, but we now know that it doesn't work for what developers want to build. So it is time to get rid of HTML and move on to something better.
  - ageofwant 9y ago
    Developers can build whatever they want with the html/css/javascript stack we have today, and they have. Its up to you whether or not you write semantically pure html using display agnostic <div>, <article> etc. structural elements and only use css for styling. That is, after all, what they are for. You can have what you want by simply pretending that browsers do not have default rendering rules, and not use the html elements that are arguably presentation only things, like <h1>, <table> etc.
viebel 9y ago
Here is the author of the Klipse plugin[1] that powers the interactive code snippets. I've opened a github issue[2] to suggest to integrate the Klipse plugin on react.js official documentation. If you like the code interactivity, feel free to express yourself on the github issue[2]. 1: https://github.com/viebel/klipse https://github.com/viebel/klipse 2: https://github.com/facebook/react/issues/10646 https://github.com/facebook/react/issues/10646
whitefish 9y ago
Note that JSX is not limited to React. You can use JSX (or TSX in the case of Typescript) as a better replacement for Moustache or Handlebars. See here: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder
- WorldMaker 9y ago
  I didn't think JSX made sense until I used it in Typescript (TSX). Having type safety and refactoring support in views and templates is wonderful. I know that both Vue and Angular have worked to build Typescript compiler plugins to support type checking their view files, but TSX is out of the box, has great editor support, and gives you the full power of Typescript's downleveling transpiler, too. For what it is worth, the project I'm primarily using TSX in isn't using React either. It's built with Cycle.JS which uses competitor virtual DOM Snabbdom.
  - hvvvggg 9y ago
    > downleveling transpiler What's wrong with the JS "scene", in two words. Good lord.
hzoo 9y ago
Gave a talk at React Rally that goes over this briefly. https://github.com/hzoo/so-how-does-babel-even-work https://github.com/hzoo/so-how-does-babel-even-work, and a basic version of the actual Babel transform: http://astexplorer.net/#/gist/ccb201a61db3d581c8be3161bf78065d/b4651fda44c10da9d252896809caa6439afb2a16 http://astexplorer.net/#/gist/ccb201a61db3d581c8be3161bf7806...

129 points by Pishky 9y ago

Thanks for posting this, it's a good read so far. I have been using JSX quite a bit and this is helping me get a better understanding.

brochington 9y ago

Experimenting with JSX has introduced me to two language constructs: the Pragma, and the Macro. I know that these might seem a bit pedestrian to most folks, but they opened up my understanding of programming languages considerably. I am genuinely a bit surprised that the Javascript community hasn't played around more with the possibilities that both can offer.

viebel 9y ago
In LISP based languages like ClojureScript, macros are part of the language. No need to build tools like JSX (that requires to run on webpack + IDE tooling etc...).
- masklinn 9y ago
  JSX could be language-integrated (witness the now-deprecated E4X for XML literals in Javascript), it just is not. And most lisps don't have unfettered reader macros which would allow embedding macros using non-lisp syntax (aka JSX). A macroed JSX wouldn't make much sense in Lisps really, and AFAIK isn't used with most clojurescript vdoms using either hiccup structures or regular function calls.
  - viebel 9y ago
    who needs JSX when you have hiccup!
    - deleted 9y ago
      [deleted]
    - masklinn 9y ago
      Possibly a more uniform treatment of components versus "literal elements", but yeah the value proposition becomes very low. In fact I'd argue the value proposition of JSX is already relatively low when you factor in hyperscript in regular javascript (and yes there are component-compatible hyperscript helpers for React).
      - lilactown 9y ago
        I think that Hiccup's idea of writing the tree as a tree-like data structure is superior to writing a tree of function calls. I tried doing something similar in JavaScript; the result looks a bit silly (I realized the elegance of not needing to delimit lists with a , in LISP right here) and has questionable performance: https://github.com/Lokeh/hux https://github.com/Lokeh/hux
- amk_ 9y ago
  I could be wrong, but I don't think a LISP macro can transform the structure of the code in the same way that the JSX pragma turns an XML tree "inside-out". For example here's the source for the Babel JSX transformer: https://github.com/babel/babel/blob/master/packages/babel-plugin-transform-react-jsx/src/index.js https://github.com/babel/babel/blob/master/packages/babel-pl...
  - sbergot 9y ago
    A lisp macro see a code block as a tree of symbols/primitives. It can do anything. This means that it is easy to write a library with a nice dsl, but hard to read other people's code.
    - masklinn 9y ago
      > A lisp macro see a code block as a tree of symbols/primitives. It can do anything. No, a regular macro still needs to be syntactically sensible. To handle arbitrary non-lisp syntax you need your lisp to support arbitrary reader macros (as in Common Lisp or — I believe — Racket) and that gets significantly more complex and involved and requires extensible/pluggable parsing. Scheme does not have that for instance, SFRI-10 reader macros need to be wrapped in `#,()`, you can't just dump JSX or XML in Scheme source and expect it to work.
      - shakna 9y ago
        > Scheme does not have that for instance, SFRI-10 reader macros need to be wrapped in `#,()`, you can't just dump JSX or XML in Scheme source and expect it to work. That's not 100% true. See SRFI-105 which gives you infix expressions without needing to wrap them, and mixing and matching is supported the moment you dive into reader macros. #!curly-infix (+ 2 {a + b + c}) You do need to enable the reader modification, either in your own read (useful if you want safe eval, and parsing in limited environments), in which case you'd just provide an argument to read, or if you want it globally it'll probably just look like: #!jsx DOM.render( <h1>Hello world</h1>, document.getElementById((string-append "hel" "lo")) ) Writing the reader would be considerable work, but hardly impossible for Scheme to play nicely.
- ghusbands 9y ago
  In Lisp, if you created something like JSX, your IDE or text editor would still be unlikely to understand it, as it'd be a very complicated reader macro. It doesn't magically solve all macro problems. Doing it the Lispy way, though, you'd likely use sexprs directly, with maybe some normal macros, so you wouldn't have HTML-like syntax but would have something that worked nicely in your editor.
  - shakna 9y ago
    SXML has been around a while, and makes working with HTML in most Lisps a breeze. See this for example [0]. '((html (head (title "My Title")) (body (@ (bgcolor "white")) (h1 "My Heading") (p "This is a paragraph.") (p "This is another paragraph.")))) [0] http://www.neilvandyke.org/racket/html-writing/ http://www.neilvandyke.org/racket/html-writing/
  - davexunit 9y ago
    Lisp comes with a built-in templating system: quasiquote. Systems such as SXML (an s-expression representation of XML documents) build on top of that. This takes care of multiple problems with JSX: 1) writing HTML/XML is annoying (remembering to put the close tag in the right place, etc.) 2) JSX is a DSL, not an embedded DSL, so you need new compiler infrastructure to work with it. Here is a snippet of real code that produces an SXML tree. It generates atom feeds for websites that use a static generator I wrote: `(feed (@ (xmlns "http://www.w3.org/2005/Atom")) (title ,(site-title site)) (subtitle ,subtitle) (updated ,(date->string* (current-date))) (link (@ (href ,(string-append (site-domain site) "/" file-name)) (rel "self"))) (link (@ (href ,(site-domain site)))) ,@(map (cut post->atom-entry site <> #:blog-prefix blog-prefix) (take-up-to max-entries (filter posts)))) By far the best templating system I've ever used.
- bananicorn 9y ago
  They work something like this in LISPs, right? Like, can you define new language constructs with them? http://www.red-lang.org/2016/12/entering-world-of-macros.html http://www.red-lang.org/2016/12/entering-world-of-macros.htm... (BTW, have a look at red for desktop apps, it's not even at 1.0 and already fucking amazing) But on topic; Are Macros a well-defined "thing"? Since a macro in C, seems to be rather different from a RED or LISP Macro. Or is it just that C macros are essentially the same, just more restricted?
  - lmkg 9y ago
    C macros are text substitution, implemented in a separate less-expressive language (the C pre-processor). Lisp macros access the input program fragment as structured data, and manipulate that using the same Lisp functions and data structures that you use for regular, normal Lisp code. I think that both forms are technically Turing-Complete, but Lisp is more expressive. In particular, it's much more common to see Lisp macros that destructure and reform their inputs, where C macros tend to see their inputs as black boxes that can't be opened. The textual-substitution model of C also has some extra perils, because code fragments can be context sensitive (such as creating identifiers that are already in scope). In both cases, Macros are well-defined "things" in the sense that they are thoroughly defined in their respective language documents, but in both cases they are not first-class language items because they don't exist at run-time.
Vinnl 9y ago
Here you got me interested in this post hoping it would use JSX to introduce Pragma's and Macro's, turns out it just reiterates what JSX compiles down to...
blauditore 9y ago
I'm not sure what exactly you're referring to by macros. A container for boilerplate code to avoid repetition, as in templating languages? If so, the React solution would probably be extracting a simple component which just provides markup.
deleted 9y ago
[deleted]

danenania 9y ago

Has anyone else made the switch from JSX to hyperscript? JSX works well enough, but I love the consistency and composability of building views with plain old functions and data structures.

madeofpalk 9y ago
JSX is just 'plain old functions' - just with some syntactic sugar on top to make it a bit easier to write. In fact, JSX compiles down to functions looking very similar to hyperscript...
insin 9y ago
I switched the other way, as JSX fixed the main problem I've had for years using "hyperscript" (or DOM builders, as we used to say). Its comma-free syntax sugar for function calls, element lists and attribute objects makes it so much easier to write and maintain.
iMark 9y ago
Our team moved from hyperscript to JSX as well. Personally, I find JSX much more readable, and there was little love for hyperscript on the team.
doublerebel 9y ago
There are a number of template languages that compile to hyperscript, I use jade/pug [0]. I haven't had to change my templates in years but I can still take advantage of virtual DOMs like React. Before hyperscript, there was Templatizer which also compiled templates to JS functions. There are numerous good reasons to be able to manipulate templates easily as functions. Nevertheless there are numerous good reasons for templates (e.g. my designers don't need to know JavaScript, template languages last longer than JS trends, etc.). [0]: https://github.com/nextorigin/gulp-pug-hyperscript https://github.com/nextorigin/gulp-pug-hyperscript
amk_ 9y ago
Yeah, I wrote about it last week: https://medium.com/@alexkrolick/writing-react-components-for-3rd-party-embedding-50331c18e26 https://medium.com/@alexkrolick/writing-react-components-for... "Overall it's not a bad experience. JSX makes HTML feel more at home, but tends to obscure the underlying Javascript. Composition and higher-order components are more obvious in plain JS. If I was writing a library using those patterns heavily I might be tempted to go JSX-free even if bundling with Webpack + Babel."

thomasfl 9y ago

Hyperscript markup looks like a nice replacement for JSX. The source for hyperscript-react is 50 lines of code, including comments and empty lines, so it's fairly easy to learn: https://github.com/mlmorg/react-hyperscript/blob/master/index.js https://github.com/mlmorg/react-hyperscript/blob/master/inde...

Androider 9y ago
To me this looks much less readable than the equivalent JSX. JSX has been such a non-issue for me, it's extremely reliable and you can use all the new JS map/filters, loops, etc. instead of learning some half-finished template language.
- gyrgtyn 9y ago
  > learning half-finished template language javascript?
blorenz 9y ago
It may be fairly easy to learn, but mentally evaluating context during usage will be the friction much akin to HAML.

keymone 9y ago

https://github.com/lantiga/react.hiccup https://github.com/lantiga/react.hiccup

haukur 9y ago

Another good resource to learn about JSX (by the author of Preact): https://jasonformat.com/wtf-is-jsx/ https://jasonformat.com/wtf-is-jsx/

omegote 9y ago

It's funny how, for years, we've been trying to get away from HTML mixed with code (specially in spaguetti PHP), just to get back to something similar again.

dudul 9y ago
Can't upvote this enough. Each time I try to dive into React/JSX I have some dark visions of PHP and JSP in my head.
lkrubner 9y ago
You bring up a point that was discussed 35 days ago: https://news.ycombinator.com/item?id=14925899 https://news.ycombinator.com/item?id=14925899 Tarikyn said: "Most developers I knew in person didn't care about CSS or didn't 'get' it." Part of my response was: "Some people looked at the chaos of non-standard HTML and decided the Web was successful because it had been broken from the beginning, and it had learned to work well while broken. I reached a different conclusion. It became clear to me that what developers wanted to do simply had nothing to do with HTTP/HTML. We don't yet have the technology to do what developers want to do. HTML was an interesting experiment, but it suffered from a dual mandate. Sir Tim Berners Lee wanted HTML to both structure data and also present it in graphical form. Almost from the start, developers were conflicted about which mandate they should obey, but the preference, since at least 1993, if not earlier, was to give priority to the visual. For all practical purposes, developers saw HTTP/HTML as GUI for IP/TCP. Previous IP/TCP technologies (email, gopher, ftp) had lacked a visual component, but HTML finally offered a standard way to send things over Internet and format the end result visually (emphasis on "standard"; I could insert an aside here about X window systems and some cool software of that era, but every app implemented their own ideas about visual presentation. X-Emacs, for instance, had its own system for visual formatting over a network)." The point is, HTML was an interesting experiment, but we now know that it doesn't work for what developers want to build. So it is time to get rid of HTML and move on to something better.
- ageofwant 9y ago
  Developers can build whatever they want with the html/css/javascript stack we have today, and they have. Its up to you whether or not you write semantically pure html using display agnostic <div>, <article> etc. structural elements and only use css for styling. That is, after all, what they are for. You can have what you want by simply pretending that browsers do not have default rendering rules, and not use the html elements that are arguably presentation only things, like <h1>, <table> etc.

viebel 9y ago

Here is the author of the Klipse plugin[1] that powers the interactive code snippets. I've opened a github issue[2] to suggest to integrate the Klipse plugin on react.js official documentation. If you like the code interactivity, feel free to express yourself on the github issue[2]. 1: https://github.com/viebel/klipse https://github.com/viebel/klipse 2: https://github.com/facebook/react/issues/10646 https://github.com/facebook/react/issues/10646

whitefish 9y ago

Note that JSX is not limited to React. You can use JSX (or TSX in the case of Typescript) as a better replacement for Moustache or Handlebars. See here: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder

WorldMaker 9y ago
I didn't think JSX made sense until I used it in Typescript (TSX). Having type safety and refactoring support in views and templates is wonderful. I know that both Vue and Angular have worked to build Typescript compiler plugins to support type checking their view files, but TSX is out of the box, has great editor support, and gives you the full power of Typescript's downleveling transpiler, too. For what it is worth, the project I'm primarily using TSX in isn't using React either. It's built with Cycle.JS which uses competitor virtual DOM Snabbdom.
- hvvvggg 9y ago
  > downleveling transpiler What's wrong with the JS "scene", in two words. Good lord.

hzoo 9y ago

Gave a talk at React Rally that goes over this briefly. https://github.com/hzoo/so-how-does-babel-even-work https://github.com/hzoo/so-how-does-babel-even-work, and a basic version of the actual Babel transform: http://astexplorer.net/#/gist/ccb201a61db3d581c8be3161bf78065d/b4651fda44c10da9d252896809caa6439afb2a16 http://astexplorer.net/#/gist/ccb201a61db3d581c8be3161bf7806...