5 ms·

I have looked at react.js a couple times after reading more and more buzz about how fantastic it is. However I'm instantly turned off of switching to it when I

I have looked at react.js a couple times after reading more and more buzz about how fantastic it is. However I'm instantly turned off of switching to it when I read that HTML (which isn't HTML and is actually something called JSX) goes in your js files. With angular I can keep all my HTML in my HTML files. Is this normal or am I completely missing something?

mandazi 11y ago
I too find that unusual. I feel it's hard to maintain the HTML when it's int he JS.
- zecho 11y ago
  This is a good tutorial for people who think the React way is weird. http://courseweb.lis.illinois.edu/~hkim214/lis514/img/Dr_Seuss_Green_Eggs_and_Ham.gif http://courseweb.lis.illinois.edu/~hkim214/lis514/img/Dr_Seu...
revskill 11y ago
Yes, i think you miss something important here. It's a tradeoff. You should make your choice based on pros and cons, it's more objective than subjective when you hate something and you don't use it. It's harmful and useless thought:)
insin 11y ago
Yes, this appears to be the normal reaction to JSX (it took me 3 months to actually try React just because of the idea of it - more fool me). My advice is to try it at least to the point where you've created a couple of components and rendered one inside the other. A component manages everything to do with how it works with props it's given and the state it manages, and how it renders is just another part of that concern. One of the nice pros you get used to quite quickly is having your editor autocomplete event handler and data variable names, as they're all right there in the same file. JSX is just sugar for React.createElement() function calls, the syntax of which otherwise gets quite unpleasant to write and maintain once you start nesting them to any degree (ask anyone who's used a DOM builder library for a complete app).
- moron4hire 11y ago
  Can we really call it syntactic sugar when it leaves a bitter taste in your mouth?
  - insin 11y ago
    The idea of it did, but the experience of it didn't (IME).
  - bowenfreddy 11y ago
    JSX is syntactic aspartame: sweetish and toxic in large doses...
  - pjmorris 11y ago
    Would that be syntactic caramel?
lojack 11y ago
At first I was turned off by this as well. Once I started using React in practice though, it turned out to be pretty nice. It significantly reduces cognitive overhead when thinking about frontend elements. And if you're worried about your javascript file starting to look more like an HTML file, composition of JSX components helps break things up. Even if I can't convince you that it's actually pretty nice, you can write React without using any JSX. Just use a live compiler http://facebook.github.io/react/jsx-compiler.html http://facebook.github.io/react/jsx-compiler.html to translate any documentation into the vanilla JS equivalent.
agmcleod 11y ago
Since it is code that just translates to javascript, it's nice because you can have onClick handlers and such right inline, without having the downsides of inline javascript. You build reusable components that are self contained with their content and their logic. So you know when you use a component, the logic comes with it. You don't miss out on important bindings. Also i've never really gotten into all the string magic that angular templates use. ng-click="myEvent()", vs passing the event to the component as a property feels.
- gordonzhu 11y ago
  The concept behind directives like ng-click is actually pretty simple underneath. The Angular parser will go through the elements in the DOM and look for attributes it knows about like ng-click. When it finds ng-click, it will run the expression "myEvent()" on the controller's $scope.
andybak 11y ago
Ask yourself why that bothers you and boil down your objections to a practical point. You can then evaluate whether there is a real cost and whether it's outweighed by other things. A lot of these issues turn out to be things we learnt were bad ages ago and have forgotten why. The original context you learnt in might be sufficiently different or other factors might mitigate the underlying issue. In the case of JSX - we were all told that to keep css, js and html separate - that inlines js and styles are bad. These things are all partially true but in a react.js project your components are usually tiny and there is always an inescapable dependence between js and html. It is therefore very different from when we used to see long html documents littered with onclick.
- marknutter 11y ago
  Except that there are use cases where you want to use boilerplate HTML in more than one component (i.e. bootstrap). Also, I've never quite understood the argument that everything that goes into defining a component should live in one file. By that logic we should be putting our data stores in the component, any translations required to internationalize the component, the database queries - heck - why not put the tests in the component while your at it. The real reason we keep "technologies" separate is so that we understand what realm we're working at any given moment. Furthermore, we can distribute responsibilities across multiple team members focused on different disciplines. Facebook has the kind of clout internally to force their designers to use JSX and inline styles, but many organizations do not have that kind of alignment.
  - cpr 11y ago
    Actually, with GraphQL and now Om Next, you do put your data store "queries" in the component. It's a great idea.
    - marknutter 11y ago
      I think it's all fine and dandy, and I like the idea of isolated components, but I'm not sold on shoving everything into one file. It just smacks of preference.
deleted 11y ago
[deleted]
stephenhuey 11y ago
There are plenty of examples in other frameworks, e.g. sometimes view helpers in Rails output HTML. In certain situations it helps you write much cleaner code and it's easier to make more complex view components. Rails form helpers output HTML. http://apidock.com/rails/ActionView/Helpers/TextHelper/concat http://apidock.com/rails/ActionView/Helpers/TextHelper/conca... http://thepugautomatic.com/2013/06/helpers/ http://thepugautomatic.com/2013/06/helpers/ http://guides.rubyonrails.org/form_helpers.html http://guides.rubyonrails.org/form_helpers.html https://github.com/rails/rails/blob/dd7af2c413a06ea44e50abf0df205314ba1bfc98/actionview/lib/action_view/helpers/form_tag_helper.rb#L67 https://github.com/rails/rails/blob/dd7af2c413a06ea44e50abf0...

mandazi 11y ago

I too find that unusual. I feel it's hard to maintain the HTML when it's int he JS.

zecho 11y ago
This is a good tutorial for people who think the React way is weird. http://courseweb.lis.illinois.edu/~hkim214/lis514/img/Dr_Seuss_Green_Eggs_and_Ham.gif http://courseweb.lis.illinois.edu/~hkim214/lis514/img/Dr_Seu...

revskill 11y ago

Yes, i think you miss something important here. It's a tradeoff. You should make your choice based on pros and cons, it's more objective than subjective when you hate something and you don't use it. It's harmful and useless thought:)

insin 11y ago

Yes, this appears to be the normal reaction to JSX (it took me 3 months to actually try React just because of the idea of it - more fool me). My advice is to try it at least to the point where you've created a couple of components and rendered one inside the other. A component manages everything to do with how it works with props it's given and the state it manages, and how it renders is just another part of that concern. One of the nice pros you get used to quite quickly is having your editor autocomplete event handler and data variable names, as they're all right there in the same file. JSX is just sugar for React.createElement() function calls, the syntax of which otherwise gets quite unpleasant to write and maintain once you start nesting them to any degree (ask anyone who's used a DOM builder library for a complete app).

moron4hire 11y ago
Can we really call it syntactic sugar when it leaves a bitter taste in your mouth?
- insin 11y ago
  The idea of it did, but the experience of it didn't (IME).
- bowenfreddy 11y ago
  JSX is syntactic aspartame: sweetish and toxic in large doses...
- pjmorris 11y ago
  Would that be syntactic caramel?

lojack 11y ago

At first I was turned off by this as well. Once I started using React in practice though, it turned out to be pretty nice. It significantly reduces cognitive overhead when thinking about frontend elements. And if you're worried about your javascript file starting to look more like an HTML file, composition of JSX components helps break things up. Even if I can't convince you that it's actually pretty nice, you can write React without using any JSX. Just use a live compiler http://facebook.github.io/react/jsx-compiler.html http://facebook.github.io/react/jsx-compiler.html to translate any documentation into the vanilla JS equivalent.

agmcleod 11y ago

Since it is code that just translates to javascript, it's nice because you can have onClick handlers and such right inline, without having the downsides of inline javascript. You build reusable components that are self contained with their content and their logic. So you know when you use a component, the logic comes with it. You don't miss out on important bindings. Also i've never really gotten into all the string magic that angular templates use. ng-click="myEvent()", vs passing the event to the component as a property feels.

gordonzhu 11y ago
The concept behind directives like ng-click is actually pretty simple underneath. The Angular parser will go through the elements in the DOM and look for attributes it knows about like ng-click. When it finds ng-click, it will run the expression "myEvent()" on the controller's $scope.

andybak 11y ago

Ask yourself why that bothers you and boil down your objections to a practical point. You can then evaluate whether there is a real cost and whether it's outweighed by other things. A lot of these issues turn out to be things we learnt were bad ages ago and have forgotten why. The original context you learnt in might be sufficiently different or other factors might mitigate the underlying issue. In the case of JSX - we were all told that to keep css, js and html separate - that inlines js and styles are bad. These things are all partially true but in a react.js project your components are usually tiny and there is always an inescapable dependence between js and html. It is therefore very different from when we used to see long html documents littered with onclick.

marknutter 11y ago
Except that there are use cases where you want to use boilerplate HTML in more than one component (i.e. bootstrap). Also, I've never quite understood the argument that everything that goes into defining a component should live in one file. By that logic we should be putting our data stores in the component, any translations required to internationalize the component, the database queries - heck - why not put the tests in the component while your at it. The real reason we keep "technologies" separate is so that we understand what realm we're working at any given moment. Furthermore, we can distribute responsibilities across multiple team members focused on different disciplines. Facebook has the kind of clout internally to force their designers to use JSX and inline styles, but many organizations do not have that kind of alignment.
- cpr 11y ago
  Actually, with GraphQL and now Om Next, you do put your data store "queries" in the component. It's a great idea.
  - marknutter 11y ago
    I think it's all fine and dandy, and I like the idea of isolated components, but I'm not sold on shoving everything into one file. It just smacks of preference.

deleted 11y ago

[deleted]

stephenhuey 11y ago

There are plenty of examples in other frameworks, e.g. sometimes view helpers in Rails output HTML. In certain situations it helps you write much cleaner code and it's easier to make more complex view components. Rails form helpers output HTML. http://apidock.com/rails/ActionView/Helpers/TextHelper/concat http://apidock.com/rails/ActionView/Helpers/TextHelper/conca... http://thepugautomatic.com/2013/06/helpers/ http://thepugautomatic.com/2013/06/helpers/ http://guides.rubyonrails.org/form_helpers.html http://guides.rubyonrails.org/form_helpers.html https://github.com/rails/rails/blob/dd7af2c413a06ea44e50abf0df205314ba1bfc98/actionview/lib/action_view/helpers/form_tag_helper.rb#L67 https://github.com/rails/rails/blob/dd7af2c413a06ea44e50abf0...