
JSX in detail - Pishky
http://blog.klipse.tech/javascript/2016/12/14/jsx.html
======
whitefish
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
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.

------
danenania
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.

~~~
insin
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.

------
brochington
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
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...).

~~~
amk_
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-
pl...](https://github.com/babel/babel/blob/master/packages/babel-plugin-
transform-react-jsx/src/index.js)

~~~
sbergot
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
> 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
> 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.

------
viebel
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)

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

------
hzoo
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/ccb201a61db3d581c8be3161bf7806...](http://astexplorer.net/#/gist/ccb201a61db3d581c8be3161bf78065d/b4651fda44c10da9d252896809caa6439afb2a16)

------
thomasfl
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/inde...](https://github.com/mlmorg/react-
hyperscript/blob/master/index.js)

~~~
Androider
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
> learning half-finished template language

javascript?

------
cstrat
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.

------
omegote
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.

~~~
lkrubner
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
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.

------
keymone
[https://github.com/lantiga/react.hiccup](https://github.com/lantiga/react.hiccup)

