Comment by bicknergseng | Hacker News Reader

Comment by bicknergseng | Hacker News Reader

Parent Full thread

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

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

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.

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.

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)

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/

Live coding with ClojureScript/Reagent/Re-frame/Figwheel/REPL is a holy-grail-kind of dev experience for me (and React really does feel like it was ported to JS from a better place), but one has to admit the potential maintainability/refactorability issues when projects grow beyond a certain size (as compared to something like Haskell or PureScript).

Plumatic Schema [1] goes a long way towards narrowing that gap though and I cannot recommend it enough. Whether it goes far enough in terms of safety is certainly a matter of project type/size and personal preference, but to me, for my kind of work so far it does and they'll take away my ClojureScript when they pry it from my cold, dead hands. :)

Also (and slightly off-topic) the combination of clairvoyant + re-frame-tracer [2][3] (+[4] for some minor, so far mostly React Native-relevant additions) should be way more popular than it seems to be. It's definitely one of the most important tools in my toolbox and completely changed the way I approach debugging.

[1]: https://github.com/plumatic/schema [2]: https://clojars.org/day8/re-frame-tracer [3]: https://clojars.org/gnl/re-frame-tracer [4]: https://clojars.org/gnl/clairvoyant

You can do that in Haskell as well though [0]. With ghci, making a code change is almost instantaneous even for big code bases, and you are assured that your code is self consistent. Then mess with your long-running state all you want.

At least for backend stuff, this is no worse than Clojure.

Give it a try :) Ping me if you have any questions.

[0] http://chrisdone.com/posts/ghci-reload

This is one part of the CLJS story that I think prevented it from becoming more widespread - it lacked a good REPL/compile story for a long time because of closure compiler. I would almost characterize that decision as a premature optimization - they focused on producing small output from the start, IMO larger JS size wouldn't matter that much in majority of use cases (you won't use CLJS to write websites, and webapps can tolerate few hundred k or even a MB of JS that's easy to cache), but they gave up one of the signature strong points for CLJ/Lisp so it wasn't as attractive even to CLJ devs.

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?

The full name is primary expression. The meat of it is that a primary is usually just a literal value, identifier, or something in parentheses, but it varies based on the particular language.

For a deep dive you'll want to read resources about parsing. To name one article that came up recently on HN, take a look at "Why Parsing Tools are Hard" [0].

[0]: http://blog.reverberate.org/2013/09/ll-and-lr-in-context-why...

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?

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

Replacing JSX with Coffeescript is really beautiful, and makes large components much more readable. I am a bit worried as it does not have much traction. JSX does not even allow to copy-paste from HTML as we need to rename all keys containing hyphens with some CamelCase.

Here is some of my Coffeescript render function, it is much more elegant than the equivalent JSX.

render: -> div className: "btn-group" role: "group" style: width: '100%'

        for option in @props.options
            label
                key: option.value
                className: @buttonClass @state.selected == option.value, option.bsColor
                style:
                    minWidth: (100 / @props.options.length) + '%'
                input
                    type: 'radio'
                    required: true
                    name: @props.name
                    value: option.value
                    checked: @state.selected == option.value
                    readOnly: false
                    onClick: @handleClick
                    "data-key": option.value
                    option.label

It doesn't have as much traction because as a whole, coffee script is almost always unreadably ambiguous (even moreso than jsx).

And the best parts are already here in es2015.

In what sense are you using the word "primary" in "JSX is just a JS primary"? I have a passing interest in language theory and strong interest in PL theory, but I don't think I've seen usage that before.

I specialised in programming languages in university, and I, too, have not heard of that term. :/ @OP: some exposition please?

The full name is primary expression, things like literal values, identifiers, and other expressions in parentheses.

Thanks!

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.

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.

On copy-pasting: here's a handy tool that converts HTML to hyperscript http://html-to-hyperscript.paqmind.com/

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.

Reply on news.ycombinator.com