JSX is no longer my friend
81–90 of 144 posts
Re: JSX is no longer my friend
#82Finally, 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?
Re: JSX is no longer my friend
#83I'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
Re: JSX is no longer my friend
#84I'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
Re: JSX is no longer my friend
#85Earlier 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.
https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...
Re: JSX is no longer my friend
#86I 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() 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
#87As 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
#88This 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…
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
#89Earlier 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...
Re: JSX is no longer my friend
#90This 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…