5 ms·

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

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

brlewis 11y ago
I'll know the answer to your question in a couple weeks. I'm working with web content developers who are very good with HTML and CSS but less familiar with JavaScript. We have a project using Mithril (architecturally like React) where we started out without MSX (exactly like JSX) but they think they're going to prefer MSX syntax so we've begun switching over.
- emn13 11y ago
  I've worked with designers with limited JS knowledge on a JSX-free react code. There may have been a short learning curve, but it didn't seem to slow them down much at all, even really early on, certainly not after a week (at that point our codebase was coffeescript, so JSX wasn't a great option). It may have helped that we converted an existing code base (so there was a lot of html-as-JS example material to see), and devs were around the corner for any questions - but in my experience, JSX did not appear to be relevant, not at all. The only advantage jsx does have IME is that it enables copy-pasting real html (sometimes with minor alterations) into your source, and that's a mundane but constant minor boon. All the examples on the net are in html; and if e.g. you use browser dev tools to rearrange a page to look like you want it you can easily copy-paste that back into the source. I don't think that advantage is worth putting up with JSX for, but it's not irrelevant either.
  - acdha 11y ago
    That cuts both ways, though, since that easy “copy and paste” turns into “copy and paste and find everything which conflicts”. That's annoying and in some cases even a source of confusing bugs.
  - staltz 11y ago
    On copy-pasting: here's a handy tool that converts HTML to hyperscript http://html-to-hyperscript.paqmind.com/ http://html-to-hyperscript.paqmind.com/
plaguuuuuu 11y ago
I don't understand the OP's argument either. I'm primarily a back-end dev with a bit of HTML+JS xp, and I had zero issues with JSX when I decided to use React for a small project. I didn't find JSX confusing at all, it took me about 10 mins to understand the syntax fully and the error handling was very explicit. I'm not experienced at JS frameworks (have used Knockout and that's about it) and I'm certainly not from a front-end or designer background, much the opposite actually. What really bothered me at the time was that my code was messy and I was struggling to properly wire up the React components with my data model - thankfully I since discovered Flux and then Redux :)
couchand 11y ago
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.
- rubber_duck 11y ago
  JSX always felt hacky - the cleanest thing I've seen in this area is ClojureScript and Reagent. And that goes for the whole React stack - it just feels like it was made in a wrong language - even the surrounding stuff like Redux. Every single concept they hacked on to JS (immutable types, atom, declarative DSL, etc.) is a first class concept in CLJS - and it works beautifully even when building on top of their JS implementation - I feel sad they didn't just go "all in" on something like CLJS - they have more than enough resources to fix any implementation issues (ie. they have the resources to create a compiler that would generate code you would hand write with immutable.js and JSX - after all they are funding stuff like Flux and babel). I understand why they didn't do it but it still feels so bad to see a hack in a place where a beautiful solution was just a step away.
  - pka 11y ago
    Or even more beautiful - purescript-thermite. But just as js people are scared of Clojure, Clojure people are scared of Haskell :) (it's a joke)
    - sdegutis 11y ago
      I've been a Clojure dev full time for a few years, and last year I looked into Haskell quite a bit [1]. But ultimately the fact that Clojure can do live-programming is what really kept me preferring Clojure. And I'm not even talking about that figwheel stuff. I mean just being able to mess around inside the JVM live from an Emacs buffer via Cider, and reloading parts of my code while my app is still running during development. I'm not interested in giving that up, it's made me more productive than I thought I could ever be. [1]: http://sdegutis.github.io/ http://sdegutis.github.io/

brlewis 11y ago

I'll know the answer to your question in a couple weeks. I'm working with web content developers who are very good with HTML and CSS but less familiar with JavaScript. We have a project using Mithril (architecturally like React) where we started out without MSX (exactly like JSX) but they think they're going to prefer MSX syntax so we've begun switching over.

emn13 11y ago
I've worked with designers with limited JS knowledge on a JSX-free react code. There may have been a short learning curve, but it didn't seem to slow them down much at all, even really early on, certainly not after a week (at that point our codebase was coffeescript, so JSX wasn't a great option). It may have helped that we converted an existing code base (so there was a lot of html-as-JS example material to see), and devs were around the corner for any questions - but in my experience, JSX did not appear to be relevant, not at all. The only advantage jsx does have IME is that it enables copy-pasting real html (sometimes with minor alterations) into your source, and that's a mundane but constant minor boon. All the examples on the net are in html; and if e.g. you use browser dev tools to rearrange a page to look like you want it you can easily copy-paste that back into the source. I don't think that advantage is worth putting up with JSX for, but it's not irrelevant either.
- acdha 11y ago
  That cuts both ways, though, since that easy “copy and paste” turns into “copy and paste and find everything which conflicts”. That's annoying and in some cases even a source of confusing bugs.
- staltz 11y ago
  On copy-pasting: here's a handy tool that converts HTML to hyperscript http://html-to-hyperscript.paqmind.com/ http://html-to-hyperscript.paqmind.com/

plaguuuuuu 11y ago

I don't understand the OP's argument either. I'm primarily a back-end dev with a bit of HTML+JS xp, and I had zero issues with JSX when I decided to use React for a small project. I didn't find JSX confusing at all, it took me about 10 mins to understand the syntax fully and the error handling was very explicit. I'm not experienced at JS frameworks (have used Knockout and that's about it) and I'm certainly not from a front-end or designer background, much the opposite actually. What really bothered me at the time was that my code was messy and I was struggling to properly wire up the React components with my data model - thankfully I since discovered Flux and then Redux :)

couchand 11y ago

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.

rubber_duck 11y ago
JSX always felt hacky - the cleanest thing I've seen in this area is ClojureScript and Reagent. And that goes for the whole React stack - it just feels like it was made in a wrong language - even the surrounding stuff like Redux. Every single concept they hacked on to JS (immutable types, atom, declarative DSL, etc.) is a first class concept in CLJS - and it works beautifully even when building on top of their JS implementation - I feel sad they didn't just go "all in" on something like CLJS - they have more than enough resources to fix any implementation issues (ie. they have the resources to create a compiler that would generate code you would hand write with immutable.js and JSX - after all they are funding stuff like Flux and babel). I understand why they didn't do it but it still feels so bad to see a hack in a place where a beautiful solution was just a step away.
- pka 11y ago
  Or even more beautiful - purescript-thermite. But just as js people are scared of Clojure, Clojure people are scared of Haskell :) (it's a joke)
  - sdegutis 11y ago
    I've been a Clojure dev full time for a few years, and last year I looked into Haskell quite a bit [1]. But ultimately the fact that Clojure can do live-programming is what really kept me preferring Clojure. And I'm not even talking about that figwheel stuff. I mean just being able to mess around inside the JVM live from an Emacs buffer via Cider, and reloading parts of my code while my app is still running during development. I'm not interested in giving that up, it's made me more productive than I thought I could ever be. [1]: http://sdegutis.github.io/ http://sdegutis.github.io/