Live data from Hacker News

JSX is no longer my friend

medium.com

81–90 of 144 posts

Re: JSX is no longer my friend

#82
post #12

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?

The difference is JSX XML syntax is not a templating language but a functional one. In that sense it has nothing to do with PHP templates or any JS templating system based on string templating. it's XML directly in Javascript.

Re: JSX is no longer my friend

#83
post #55
post #43

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 => ` ${item.name} ` const listComponent = items => ` ${items.map(listItem).join("")} `

The compile is a huuuge plus. If you do a error in your template string (e.g. forget a '>'), you won't catch it until you run it in the browser. The JSX will complain loudly when compiled. JSX >>>> ES6 template strings

Ah. I guess html errors yes. If you add "use strict" you will catch js errors at compile time. Plus editor should provide autocomplete in template strings. I wonder if anyone has provided a highlighting package for highlighting html inside template strings.

Re: JSX is no longer my friend

#84
post #47
post #43

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 => ` ${item.name} ` const listComponent = items => ` ${items.map(listItem).join("")} `

It was discussed a long time ago. Some googling found this very old link http://facebook.github.io/jsx/#why-not-template-literals

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.

Re: JSX is no longer my friend

#85
post #76
post #66

Earlier quoted context omitted.

Is it just me, or is the return missing in the `function` (or am _I_ missing something :)? Not important of course, just pointing it out...

Good catch! I wrote that example in a hurry on my lunch break so I take accountability for the mistake.

If you omit the {} you can then also omit the return.

https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...

Re: JSX is no longer my friend

#86

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 t…

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

Re: JSX is no longer my friend

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

Re: JSX is no longer my friend

#88

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 o…

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.

Re: JSX is no longer my friend

#89
post #85
post #76

Earlier quoted context omitted.

Good catch! I wrote that example in a hurry on my lunch break so I take accountability for the mistake.

If you omit the {} you can then also omit the return. https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...

True but irrelevant, the GP is talking about the top level function, not the fat arrow one.

Re: JSX is no longer my friend

#90
post #18

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, co…

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.
Post reply on HN