
JSX is no longer my friend - tosh
https://medium.com/@jador/jsx-4b978fbeb290
======
bicknergseng
This needs to be prefaced: this argument is overdone. JSX is not hard to
learn. It's an order of magnitude better than the hampered DSLs of handlebars
or dust, and I'm concerned that any engineer is so scarred that learning it
takes more than 5-10 minutes of RTFM. After all, TFM on JSX is all of 200
words or less [1].

I've been using JSX since React 0.4. React's greatest strength is its
simplicity. You can read all of React's documentation in 20 minutes. There's
hardly any learning curve compared to the larger JS frameworks out there. It's
all just JS*--no "logic-less-ish-kinda-sorta" template for loops, or two way
data bindings, or figuring out when to render.

I don't think JSX is the terrible problem the hyperscript people make it out
to be, but I think it might be time for it to retire. While JSX is as mild as
learning curves come, it's still a learning curve. It still requires
transpilation. It requires the extra characters. To reframe the conversation,
does it make sense for the learning curve to be "it's HTML-ish with caveats
like camelcasing but it works like JS" or "it's a collection of functions that
generate HTML that are named for the HTML tag they generate."

I'm also really interested in the "but it makes sense to designers" argument.
Is that actually true? Are there designers out there who understand JSX but
wouldn't understand well formatted hyperscript? I feel like that's saying "yah
I get ERB but HAML doesn't make any sense."

Again, I don't think this is a big enough deal for the amount of attention it
gets paid. I'd love to see the React team bring in first class hyperscript-
like syntax that is 100% JS, but it's hardly a reason to not use React.

[1] [https://facebook.github.io/react/docs/jsx-in-
depth.html](https://facebook.github.io/react/docs/jsx-in-depth.html)

~~~
couchand
I've also been using JSX since the good old days, when a component was just a
function -- "hyperscript" (such as it is) was built right in. Notably, writing
React apps in CoffeeScript was beautiful:

    
    
        div
          className: "greeting"
          "Hello, world!"
    

As you pointed out, the biggest problem with JSX is not that it isn't JS, it's
that it isn't HTML. It's a leaky abstraction. Camel casing is only the most
obvious problem, things like className and htmlFor are more insidious.

So as soon as a developer realizes that it's just sugar over JS, they are in a
world of trouble, invariably trying to stick an if-else into it. If everyone
had enough grounding in language theory to tell them: "JSX is just a JS
primary" all would be well, but alas, that's putting the cart before the
horse.

~~~
jabagawee
I'd like to learn enough to understand the statement "JSX is just a JS
primary," and I can't find out what a "$lang primary" is in PLT. Can you point
out some resources for me to figure this out?

~~~
bottled_poe
The previous comment is trying to sound smart by using obscure terminology. I
would guess they mean to say that JSX is a translated subset of JS?

~~~
couchand
Thanks for your generosity. This is what I was referring to: _JSX extends the
PrimaryExpression in the ECMAScript 6th Edition (ECMA-262) grammar_.

Please take a look at the draft JSX spec [0] for details.

[0]: [https://github.com/facebook/jsx](https://github.com/facebook/jsx)

------
jador
So I'm the guy who wrote the post in question.

As the view counter started to exceed my expectations I thought there would be
a fair amount of negative feedback. I was surprised that there wasn't much.
Turns out that it's all here on HN! :P

First off, I can't believe all of you actually read that. You have both my
sympathy and thanks. Even more thanks for commenting on it.

I want to address a few of the points brought up in the comments.

1| Yes the title is click bait. The title is the initial hook to the reader
(and often the only thing you'll see before deciding to check it out). So by
definition it is click bait lol It is also true.

2| The post wasn't intended to say JSX is bad or that you should use
hyperscript (although I do think you should try it). It is an account of my
decision to investigate hyperscript and some reasons why I chose to stick with
it.

Each team and project is different and I am not so assured of my opinion to
say that you _should_ use hyperscript. I've seen some who genuinely prefer
React.createElement. I've seen react-jade also brought up today. If there is a
view abstraction that you like better then you should use it.

3| Yeah, the argument I present for why I implemented hyperscript may seem
rather thin. For my team, however, it was not.

4| Despite the fact that we often talk about React and JSX in the same
sentence they are not synonymous (see the "use the one you like" argument
above). JSX does take some setting up to use. And you'd be surprised how often
I field questions about the JSX transformer even though it was deprecated
nearly a year ago...

5| The RTFM argument. If you knew the developers on my team they could tell
you that I tell them to RTFM several times a day. I think it is very important
for them to consult the docs whenever they have a question instead of me. That
being said, I'd rather them RTFM about immutable-js or functional combinators
than view syntax.

If you've got more heat lay it on :)

~~~
wwalser
I started reading with skepticism and you hadn't convinced me by the end that
you were any more or less "correct" than my own approach. That being said, I
never for a second thought you were wrong and needed correcting either. Your
tone never implied to me that the you thought anything similar about the
reader either. Your responses in the comments on Medium basically confirmed in
my mind that you were just talking to the void about what has worked for you
and your team.

1| Don't let anyone bother you about headlines that attract readers and
healthy conversation. Despite the romantic notions we may harbor about
writing, it is an attention game for most who do it. Good headlines are a part
of that game.

Kudos on handling the unexpected attention well :).

~~~
jador
I have to say, and I'm honestly sorry I haven't gotten around to it till now,
that I genuinely appreciate your kind and rational words. ^.^

------
CuriouslyC
The thing that the author misses is that JSX is very natural for designers. If
you properly encapsulate any logic into methods on the component rather than
having it all inline in the render return, even designers with mediocre
technical skills can productively work with JSX files. This can be a huge
productivity win, and beyond that honestly I don't know many engineers that
enjoy translating designer mock-ups.

~~~
jedrek
JSX is also very natural for people who've written HTML for years.

I wasn't a fan when I started, but now I love it to bits.

~~~
merpnderp
I fell in love at first sight. Since it was in wide use at Facebook I got my
team to take a look at it. Now they love it. Once you start breaking up things
into small mostly reusable components, the true power of JSX shines through.
And since most files never end up being very large with well reasoned
interfaces between components, it's much easier to reason about your user
interfaces.

------
mg74
My brain parses JSX way better than Hyperscript, so I will stick with it and
suffer the extra keystrokes.

And the context switch has not proved to be a problem for me, but I'm
sympathetic to the argument.

</2cents>

------
wimagguc
I very much like how the recommended Hyperscript looks, but the package was
last updated last December, and it doesn't even list React 0.14 in the
compatibility list: it stops at v0.13, which was released in May 2015. Half a
year _before_ the last update of Hyperscript.

It's arguably a small package that you could just rewrite if things go wrong,
but is it a smart idea to base any project on semi-abandoned code?

~~~
PopsiclePete
That's what I don't like about a lot of bleeding-edge web development. You end
up depending on a half-dozen abandoned pet projects. Somebody had an itch,
scratched it, got bored.

I swear half of the gulp eco-system is just that - half-abandoned, half-
working little cute plugins that someone did because someone else's plugin,
even though 99% identical, didn't do the one thing they wanted, so they wrote
their own and then abandoned it, instead of maybe contributing to the other
one. Sometimes, web development frameworks and libraries just feel like a
giant software ghetto - a giant web of dependencies that someone combined into
something with little thought given to long-term maintainability.

One of my team members refuses to incorporate a dependency that is by "some
guy" and hasn't had any commit activity in the last month.

~~~
jessaustin
If a major framework hasn't had commits for a month that _might_ indicate
something. If it's just some random module that's small and has no major open
issues, then that policy is unreasonable. Does your team regularly audit the
commit streams of already-in-use dependencies so you can rip them out when the
maintainers take a break?

~~~
PopsiclePete
It's more of a tongue-in-cheek thing but it was born out of real frustration.
It really depends like you said - it helps to look at the source code and see
if it is maintainable by our team in case it is abandoned.

------
supernintendo
This article includes a tweet which demonstrates a very contrived example of a
for loop using JSX. If you're ever writing code like this, please reevaluate
your career in software development.

As an aside, we recently moved from Nunjucks templates to React / JSX at work
and the frontend team couldn't be more pleased. Components reflect
improvements made to them across the board and provide a happy medium between
designer and JS dev. I have also found a lot of power in refs by implementing
superclass functions that provide reusable logic for elements based on the key
of the ref when certain functions are implemented on the corresponding
component. This can be used for state persistence in forms, analytics or
anything else the developer imagines.

Context switching has not been an issue but all of our frontend devs also do
work on the backend. This may be an issue to consider for teams that don't
embrace cross disciplinary roles.

~~~
chrshawkes
"If you're ever writing code like this, please reevaluate your career in
software development."

That's a pretty nasty comment to make about anyone in this industry over a
simple for loop.

~~~
untog
Well, it is just plain wrong. Even if you wanted to do a for loop in JSX you'd
do

    
    
        <div>
            {for (var x=0;x<10;x++) {
                <div/>
            }}
        <div>
    

Not a templated component like that. That said, I have created repeater
components and the like before, largely because JSX is _so_ friendly that more
design-minded people can use it very easily.

EDIT: turns out that doesn't actually work, ha. I've never written JSX that
way.

    
    
        <div>
            {[0,1,2,3].map((i) => {
                <div/>
            }}
        <div>
    

on the other hand...

~~~
gberger
You just proved the author's point. The JSX you provided is invalid, since you
can't pass `for` as a function argument (see his equivalent bit about `if`).

~~~
untog
Huh. Well, my only defense is that I would never even try to write JSX like
that anyway - the actual JS in my JSX templates is basically just Array.map
calls.

------
stevebmark
This person and the person he quotes seem to be quite confused about what JSX
is and how it works. Hyperscript looks cool and use it if suits you but I
don't think most of these reasons are valid nor actually make sense (like
[https://twitter.com/andrestaltz/status/674313202197520384?re...](https://twitter.com/andrestaltz/status/674313202197520384?ref_src=twsrc%5Etfw)
isn't related to JSX at all)

------
thom_nic
Better markup DSLs have already been written, which "mingle" better in code:
HAML and Jade. Unfortunately reactjs-jade never gained any momentum it seems.

Hyperscript seems like a "reasonable alternative" to JSX. I won't say "better"
because you're trading <angle brackets> for `h([ , ])` symbols that also
contribute to line noise. And other common pain points like "you can't put an
`if` block inside your markup" still persists.

~~~
formula1
I disagree. I have no desire to go back to jade

------
esses
no offense to the author, seems like hyperscript has achieved what it hopes...
but the benefits of not having to learn some confusing piece of JSX-ness do
not seem to outweigh the cost of h('strong','uglify')-ing everything from a
legibility standpoint.

disclaimer: only read the README, didn't try actually using hyperscript.

------
bcheung
It would be nice if it had more of a Jade indentation like syntax. The angle
brackets and closing tags are just syntactic noise.

If we want to go with the code route then the DOM as code is actually really
clean with Coffeescript.

Elm is interesting but I don't like having to do [] (empty array) when there
are no attributes or [] for the children when there are obviously no children
(hr, br, img, etc).

~~~
funksta
It is an alpha-quality library, but I've been playing around with something
like this, using ES2015 template strings:
[https://github.com/af/slashpile](https://github.com/af/slashpile)

I've yet to figure out if the run-time performance hit is reasonable, but I
vastly prefer the syntax to either JSX or hyperscript (I previously wrote a
hyperscript-like library as well, and have used it for several months)

------
formula1
Notably we must first understand that there is a differemce between react as a
framework and jsx. Jsx provides a means to generate ui patches which in turn
resolve to html through react. What makes jsx so great is that it looks like
html so you dont have to think in some special library way. Your using pre-
existing technologies which is wonderful.

A more important point is the handlebars. So, handlebars implys block in
javascript but what is actually happening is the context is evaluated and
passed to the component. Kindof how parenthesis work

(A || b).property(array.sort(compareFactory())

The fact we use handlebars when the text inside is actually evaulated how
parenthisis work probably enables this sort of confusion. The reality is
handlebars is for the angular/mustache crowd and to ensure they feel at home.
But in parenthisis would build on exisisting knowledge of how js works

<div count={count?true:false} />

<div count=(count?true:false) />

~~~
ricardobeat
The "handlebars" are just plain javascript syntax for a block, not template
markers. You can try it in your browser console.

    
    
        { console.log(123); }

~~~
couchand
Not exactly... within JSX the handlebars signify "now I'm going back to plain
JS".

compare

    
    
        <div>
            console.log(123)
        </div>
    

with

    
    
        <div>
            { console.log(123) }
        </div>
    

The first outputs a div with the text "console.log(123)" inside. The second
logs "123" and outputs an empty div (since console.log returns undefined).

~~~
ricardobeat
That's the point.

------
shados
Honestly, if I thought JSX was too complicated (it lints very well with
ESlint, so even if it was problematic, you can just let the tool figure it out
for you), all I'd do is use destructuring with the React.DOM built in element
factories and call it a day. They're fairly simple to use, and then it really
is just javascript.

But I've never seen anyone, not even the most junior, backend-only developer
touching React for the first time, have any issues with it for more than 4-5
minutes. ESLint catches any mistake they make.

The only real argument, and it is a valid one, is that Babel does not use
shorthands in the output, so it's a trainwreck to read. If that was the
primary argument, I could get it. Though then IMO the solution would just be a
better Babel plugin for development.

------
Kiro
<For i={1} condition={i < 10} step={i++}>

Why would you ever do that instead of having the logic in the component
itself?

------
wwwigham
A long time ago I tossed together a template-language DSL of my own[1] when a
bunch of my friends complained that there were "too many choices" and that "we
should just use plain JS and HTML without a complicated framework" (I feel
like this tagline gets used by many newer 'microframeworks').

Sometimes you just don't want to RTFM, and so you get to enjoy the standards
problem[2] rather than learning someone else's tool. Sometimes you just have a
lot of spare time and want to re-implement something as a learning experience.
But it's a good idea to acknowledge the technical merits of those who've come
before when you want to go down that route - JSX is a _well done_ project. If
you don't learn from it's good parts (familiarity, ease of use, prolific
tooling), as well as the bad you feel you see, you don't get anywhere. The
author became familiar with JSX to the point where his perspective of its
benefits and flaws shifted - after using it for a long time you can forget its
benefits until you no longer have them.

For example, I would argue that the contextual switching the author complains
about is a _good_ thing - I find the extra hesitation helps you create
boundaries and keep unneeded code out of your views.

[1][http://ham.io/not.js/](http://ham.io/not.js/)
[2][https://xkcd.com/927/](https://xkcd.com/927/)

------
WesleyJohnson
Perhaps not the best avenue for this, but I thought I'd take advantage of eyes
on this discussion. How might I go about using JSX outside of React or
creating something similar? I basically want to turn custom <xml-style> code
into JavaScript that instantiates custom classes that have nothing to do with
the DOM. I'd like to do this via a babel plugin as well.

If you can't tell, I enjoy JSX tremendously and I'd like to use it or borrow
from it extensively outside of React.

~~~
brotchie
It's pretty straight forward to use JSX outside of React. If you're using
Babel you can simply add

    
    
        /** @jsx ExampleDOM */
    

As the first line in your Javascript source file. This indicates to the
transpiler to convert statements of the form

    
    
        <example name="Wesley" age={15}>
            <Message text="hello"/>
            <Message text="world"/>
        </example>
    
    

into

    
    
        ExampleDOM('example', { name: 'Wesley', age: 15 },
            ExampleDOM(Message, { text: 'hello'}),
            ExampleDOM(Message, { text: 'world })
        )
    

where you implement ExampleDom as

    
    
        function ExampleDOM(element_or_component, attributes, ...children) {
    
    
        }
    

Note that because 'example' starts with a lowercase character, it is
transpiled into a string first-argument to the ExampleDOM function. If it
starts with an Uppercase letter (i.e. 'Message' above) it is interpreted as an
in-scope Javascript variable.

We've had really good results using JSX outside of the core react library. For
example, we've built a "React.js for Excel" that lets us easily create rich
Excel workbooks:

    
    
          <worksheet
            clear
            protect
            flow="column"
            name={`Bespoke - ${network.shortname} - WACC`}
            tabColor={theme.bespokeBlue}
            displayGridlines={false}
            style={worksheetStyle}>
            <PageLayout
              title={`${network.name} Cost-of-Capital Worksheet`}
              lastUpdated={new Date()}>
              <UpdatedWACCEstimates network={network} determination={determination}/>
              <WACCForecast network={network} forecast={forecast}/>
            </PageLayout>
          </worksheet>
    

Which looks a lot like React.js and behaves almost exactly the same, but it's
targeting the Excel COM Object model rather than the HTML DOM.

~~~
WesleyJohnson
Fantastic. Thank you for the detailed response and examples.

------
mmv
This article's direction makes sense for the task of 'writing HTML in JS'. I
find that JSX true power comes when you actually start building reusable
components for the many pieces of your UI.

This becomes even better when using a TypeScript capable editor with TSX,
creating classes for the components and taking advantage of full autocomplete
and syntax checking from your editor. Your code ends up pretty readable,
composable and error free.

~~~
couchand
You can still get all of those advantages using React without JSX. Reusable
components have nothing to do with JSX. Syntax checking/highlighting/etc. is
arguably easier (in a global sense) without JSX since we don't need to fork
acorn or esprima to get it.

------
csense
I was nodding and agreeing right up until he got to the part where he was
talking about how he's using Hyperscript as a replacement. Hyperscript's just
the same problematic design with a different syntax.

Mixing HTML and server side code may let you do toy projects quickly, but in
the real world it's a great recipe for building an unmaintainable,
undifferentiated, monolithic mess.

~~~
bigpeopleareold
The historical problem with mixing HTML and server-side code has been one of
mixing responsibilities. I'd probably still recommend keeping them separate
for an HTML/server-side code application, but for frontend work, it takes on a
different character.

I work on very "functionality-oriented" applications; no dedicated designers
here. Having a split between JS view code (example, in the form of Backbone
views) and template code is just frustrating to deal with. React addresses the
issue by putting the relevant pieces of view code together. The React code
should be separate from other code types (whatever you would call it: models,
business logic etc.), but that's just like what we are trying to solve with
separating server-side + HTML.

I still think however, React is controversial. I would be considerate when
deciding to use it, because I just don't think it is that important for many
applications.

------
smussell
I don't have any issue with the hypersrcipt library presented here. In fact I
find it interesting that, this is more or less how React used to work many
versions ago. All JSX tags mapped directly to functions and there was no such
thing as React.createElement. In fact I was always a little sad that React
made that change, it was such a natural mapping. I understand there are under
the hood implementation advantages to the move, but having the option to do
React.dom.ul(...) was kinda cool.

That said I really don't find any of the authors arguments particularly
persuasive. I work with many inexperienced JS devs and haven't seen them
struggle with these issues in JSX. Not to discount the authors experiences, it
just seems this article could have been more about highlighting the library,
rather than creating highly contrived seeming examples of why JSX is bad. I
also agree with some of the others, that the advantage of JSX mostly comes in
working with designers and people more familiar with HTML than JS.

~~~
spicyj
> React.dom.ul(...) was kinda cool

React.DOM.ul() works as it always did. Even if we change that (since it's
kinda silly to ship down a big list of tags that we don't otherwise need), you
can also do

var ul = React.createFactory('ul');

and then ul(). No big deal.

~~~
staltz
It's not that simple, and hyperscript [A] is much more practical than
createFactory [B].

[B] requires the first argument always to be props, so most of the time for
empty props, people end up always giving `{}` or `null` as the first arg. In
[A] they are optional. In JSX if you don't have props you don't need to
provide any "empty props" object.

In [A], children are always an array, while in [B] sometimes a single-child
parent only accepts that child as last argument, instead of an array with one
child. Otherwise it's a runtime error or warning. This special case treatment
is only visible when using [B], but transparent when using JSX.

In [A], the first (optional) argument can be a CSS selector to declare the
classnames and id. In [B] you have to give it explicitly as props.

All this indicates that while React supports a non-JSX workflow, [B] is way
less practical than JSX, probably because Facebook itself uses JSX
extensively, and supporting non-JSX workflow was an afterthought when
releasing React to the public.

------
platform
Since about December 2015 I have been learning React-native for my android
needs. While I had programmed extensively in Javascript in 2008 (dojo) -- I
have forgotten number of things, and just essentially re-learning (and I had
never done a production mobile app before).

I find JSX, at least within context of react-native is very useful.

I specifically like being able to have this 'duality' of a view for a
Component.

JSX allows a custom component to viewed by outside as first-class citizen of
an HTML mark up. But within the component -- it is a class with members,
Eiffel-like preconditions for construction, and explicitly managed state.

I think React-folks got the separation between Presenters and Interactors
exactly right.

I would not mind even more features where the state management relies on
channels that are can contain Parent, children, and may be even 'peer' events.
(something like clojurescript's CoreAsynch for the above 3 categories of
events affecting states for a given component).

------
nzonbi
In my opinion JSX is usable, and gets the job done. I have used it, and
enjoyed it. However, my personal preference to write html is one that I think
looks beautiful in comparison to template engines. Nicely enhanced by syntax
highlighting, and perfectly pure in its structure. And with the most known
syntax. It is the most simple and productive. It is: writing html in html
itself. (I am describing my personal favorite, not saying that it should be
the right way for everyone). I prefer frameworks that let me structure the
html views of my projects, using declarative html.

In the same line, breaking things into components is best achieved, in my
opinion, using web components. The syntax is a little muddy, due to all the
html legacy cruft. But I find it better than the alternatives, for example
react components. With web components, the great thing is that any styles and
javascript functionality is scoped to the component. That allows for better
separation of concerns in separated components. This is specially useful when
you have components with functional styles: animations, transitions, etc.

After componetization is solved by web components, the problems with html in
html boils down to mostly two things: generating multiple elements from some
data, or setting data in elements based on some other data. For these things I
prefer the syntax style of data binding and "repeaters". My favorite is
polymer([https://www.polymer-project.org/1.0/](https://www.polymer-
project.org/1.0/)). Example:

    
    
      <el-container id="listbox">
        <el-list-items itemsdata="{{model.itemlist}}"></el-list-items>
      </el-container>
    

And the concern of repeating multiple elements is trapped in a component. In
the example above, in <el-list-items>. In general, when using this technique,
data binding must not be abused, or the view becomes a mess.

~~~
rk06
have you tried vue? it has similar syntax but does not require polyfills.

------
evolve2k
I think the issue here is one of perspective. My thought would be that
removing JSX and replacing it with other JS conventions _may_ make it easier
for new devs but I'm quite certain that now you've made your code base highly
inaccessible for front end designers who just want to find the HTML hidden
amongst all this code.

------
tlrobinson
The decision to use JSX or not is really one of the least important decisions
you need to make when writing a React application. It's essentially a style
preference.

Personally I like JSX. It's nice having a special syntax that your editor and
linter [1] can understand. And if you are part of the stateless/minimal-logic
component camp then most of your components will look more like HTML/JSX with
a little bit of JS interspersed than vice-versa.

[1] [https://github.com/yannickcr/eslint-plugin-react#jsx-
specifi...](https://github.com/yannickcr/eslint-plugin-react#jsx-specific-
rules)

------
levemi
After many Medium posts of uninformed, not very insightful complaints about
react and the state of JavaScript I am becoming inclined to just avoid Medium
posts about JavaScript in general.

Medium has become the analog to Tumblr posts for opinionated engineers to
whine about things that don't really impact development in ways that matter.

Really all this developer had to do was talk about Hyperscript in a positive
way and I would have found this post interesting instead of rolling my eyes
paragraph after paragraph. Oh poor you and your angle brackets, such a burden!
Putting HTML directly into my JavaScript is awesome and I never want to go
back to separate template files ever again. It's wonderful and results in
great code that works well, is readable, and is easy to test.

~~~
disbelief
I think his points about new developers having to learn JS, React, and JSX all
at the same time and then context switch between them in ways that aren't
entirely clear was pretty spot on. I don't know how you draw that comparison
without mentioning the shortcomings of JSX. Also with Hyperscript you're still
building your markup directly in your Javascript, just using JS for it instead
of JSX, not templates. Not sure if that's what you meant with your "separate
template pages" statement.

~~~
vcarl
But optimizing for those with no development experience isn't one of the goals
of React. From the "thinking in react" page in the docs,

"React is, in my opinion, the premier way to build big, fast Web apps with
JavaScript."

Nowhere in the documentation does it stress that it's easy to learn or ideal
for beginners. If you don't know Javascript, writing React applications (or
any application, really) is going to be painful. Full stop. JSX adds cognitive
load when writing code, but reduces cognitive load when comparing the DOM to
the component that created it. Given the amount of time I spent debugging and
refactoring, I'm happy to use JSX.

~~~
disbelief
Whether or not React's goal is to cater to beginners doesn't make the argument
any less valid. Also React doesn't equal JSX. The React docs also mention how
to do things _without_ JSX.

Maybe it's the article's title that has understandably rankled some people by
seemingly maligning JSX. However, I think it's a very valid concern to have
when ramping up a team that's unfamiliar with JS and React.

~~~
vcarl
It doesn't make it less valid, but "is JSX bad" has been done to death. It's
been the subject of Medium posts like OP since I started using it in 2014. If
you're "ramping up a team that's unfamiliar with JS and React," maybe you
should be deciding whether to hire somebody experienced with JS and React
instead of deciding whether or not to use JSX.

~~~
disbelief
Agreed, the title was link bait done to death.

I'm not in the situation of ramping up a team unfamiliar as the author was.
But it sounds like he was experienced with JS and React himself. Or are you
suggesting he should replace his team with people more familiar with JS+React?

------
brettlangdon
If anyone was curious about other alternatives, we use r-dom at work. I am
personally happy with it as an alternative to JSX.

[https://www.npmjs.com/package/r-dom](https://www.npmjs.com/package/r-dom)

------
crudbug
JSX is the template layer not tied to React.

I think of it as a child of - XML + JS.

I am waiting for JSS - CSS + JS, for the styling part.

Radium [1] is a promising start.

[1] [http://stack.formidable.com/radium/](http://stack.formidable.com/radium/)

~~~
cel1ne
I find tachyons css the best complement for react

------
justaaron
this might be the wrong place to ask this, but i've been noting a few trends
over the last 20 years or so...

why are web-developers so damned clever? do we really need to do all of this
to ourselves?

the web is just a port, a protocol, and a model for interaction, underneath it
all.

why on earth can we not live with the existing web, and move on towards
inventing other spaces?

a browser is just a shitty sandboxed OS with a declarative markup renderer.
there's nothing to stop anyone from making a different client-side
x-terminal... (as that's what people are trying to turn the web into,
apparently)

------
crl112864
[https://discuss.reactjs.org/t/jsx-or-pure-
js/3496](https://discuss.reactjs.org/t/jsx-or-pure-js/3496) yes, fuck jsx

------
wangii
should we write {0x68, 0x65, 0x6c, 0x6c, 0x6f} instead of "hello"?

joke aside, I think JSX does a great job to reduce the cognitive load,
bridging codes as representation and its result.

------
breck
I'm wondering what the advantages of JSX are now in a world with ES6 template
strings?

This seems plenty easy to read and write and has the benefit that it's pure JS
and doesn't need to be compiled during development:

    
    
      const listItem = item => `<li><a href="${item.link}">${item.name}</a></li>`
      const listComponent = items => `<ul>${items.map(listItem).join("")}</ul>`

~~~
vcarl
It was discussed a long time ago. Some googling found this very old link

[http://facebook.github.io/jsx/#why-not-template-
literals](http://facebook.github.io/jsx/#why-not-template-literals)

~~~
breck
Thanks for the link! This makes my case stronger as their example for why not
to use literals is weak. Box should be a component that takes param(s), not a
var for a tag name.

------
kin
In my experience, if JSX becomes too complex to read/write, then that just
means I need to break down my components.

------
zaro
And here it comes reinventing JSX under different name :)

------
scotty79
JSX is little verbose but CJSX is a bliss.

------
vmware505
I dont like JSX either. just a hype...

------
beders
The author might like RiotJS instead.

------
KuhlMensch
And so the wheel turns...

------
intrasight
JSX was never my friend. Compiling is so 20th century.

------
jorgecurio
as much as people bash Angular, it was a relief just being able to take HTML
code from a designer, sprinkle some ng- attributes and watch it come alive. I
didn't even need to learn anything, it just made intuitive sense.

Unfortunately, as much as I want to learn React.js, there was too much context
switching.

The only reason I'm persisting is because of react native. As soon as somebody
comes up with a better way I'm ditching react

back to my good ol' jQuery

------
draw_down
JSX strikes me as inelegant and I don't care for it, but I don't think I agree
with some of these arguments here. If JSX is honestly giving you trouble or
confusing you in some way you should take some time to practice, I think.

------
stevebmark
You really should edit your blog posts before releasing them. This is very
clearly a one-take ramble and the quality suffers from it.

------
vmware505
I don't like JSX also... Totally agree with the author... JSX is just a hype,
as I feel...

------
Mizza
Finally, somebody said it. I thought we abandoned that garbage when we left
PHP, and now all of a sudden everybody wants to start mixing markup and code
again?

~~~
M4v3R
Exactly this. Can someone explain to me what do people see in JSX way of
creating components? What happened to good ol' code vs template separation and
what's now wrong with having two separate files - .html (or jade, or whatever)
and .js?

~~~
bicknergseng
What does code/template separation actually achieve? Ignoring JSX for a
moment, why are templates a good thing? Are you actually simplifying something
by using {{#each}} instead of .map()? Is {{#if}} really better than if()?
Seems to me like templates don't actually decouple code.

------
omarforgotpwd
JSX always looked like an abomination to me. Don't know a single person who
uses it

~~~
untog
I assure you, plenty do. Including myself. I had a very negative reaction when
I first read about it (much like the article author) after 5 minutes it
started to make a lot of sense to me.

~~~
omarforgotpwd
I know that many people use React and JSX. anecdotally, I don't know any of
them personally

