[paaaaaaaaaa]

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?

[andybak]

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]

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.

[davnicwil]

> Except that there are use cases where you want to use boilerplate HTML in more than one component

In this case, you can split out that boilerplate into a separate, smaller component and reuse it inside as many other components as you need.

> By that logic we should be putting our data stores in the component, any translations required to internationalize the component, the database queries.

I respectfully disagree with your inference here - such functions can be abstracted and used by many components - in most cases there's no value in baking them directly into a component.

The exception to this is if the function is not abstract at all, makes no sense outside the context of the component, and therefore can't be reused. Then, it probably makes more sense to put it inside the component, rather than breaking it out into a separate file.

This is true of most if not all of the markup and styles used inside a component, which is why React encourages JSX and inline styles to be put directly inside the component as it's the only place they make sense, and the only place they'll be used. The markup, styles and component behaviour are intrinsically coupled, there is a lot of 1:1 referencing, and separating them out into separate files means you'll just be flicking between three files when working on a component, instead of one. Where there is 1:n referencing, well, that's when you should break your component into smaller, reusable pieces.

[cpr]

Actually, with GraphQL and now Om Next, you do put your data store "queries" in the component. It's a great idea.

[marknutter]

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.

[misuba]

So split it up. Most React projects make use of Webpack or Browserify, or use ES6 modules via Babel. There are emerging patterns for keeping concerns in separate places but still having one component you can drop in declaratively.

[mateuszf]

One file per one component sounds like a better representation of one real world concept using code. It translates 1 to 1.

[marknutter]

Then just put all the files for a component into a single folder, which translates 1 to 1. Again, this is all just a matter of preference, and with pre-compilers you could glob all your js/css/html into one file using any framework if you really wanted to. Seems silly to me, but to each their own.

[WorldWideWayne]

It bothers me because my super intelligent HTML editor becomes useless if I choose to use React.

The reason like Knockout.js because all the magic happens in a standard data-bind attribute, no funky syntax or paradigm shifts required. A purely functional solution like React seems like it's good for making games. Beyond that, for most sites, I think it would be more work to use React for little to no gain.

[nightski]

Knockout is a decent framework, I am using it on a large application currently. It has made some things that would be very hard much easier.

However it has a few issues.

1. Wrapping everything in observables is a bit annoying. Subtle issues can arise here in there especially if using the mapping plugin (which you kind of have to, it makes the process bearable).

2. If you start to have a lot of bindings on a page (a few hundred) performance degrades rapidly and there is a ton of DOM thrashing. Part of the problem is that a binding places an event handler directly on the DOM element. But there is also the initial load "flicker"/DOM thrash which for a significant page can take a second or two.

3. There are lots of workarounds such as rate limited observables, etc... But these are applied individually and become very tedious. They do not solve the entire problem either.

React solves all 3 of these so I can see significant benefits there. I have not switched myself but am experimenting. I do think Flux, Stores, etc.. are very overkill and actually poor architecture. But thankfully there are many alternatives cropping up which are much better.

[WorldWideWayne]

There are definitely some issues. Regarding the mapping plugin, I managed to build a large custom CRM and accounts payable system without using it, but I did have to build out some custom routines in order to standardize my workflow...

React.js seems like it could be a good core for something like those alternative frameworks that you mentioned popping up. Aurelia looks interesting to me, but I don't think it uses React by default.

[insin]

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]

Can we really call it syntactic sugar when it leaves a bitter taste in your mouth?

[insin]

The idea of it did, but the experience of it didn't (IME).

[pjmorris]

Would that be syntactic caramel?

[bowenfreddy]

JSX is syntactic aspartame: sweetish and toxic in large doses...

[lojack]

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 to translate any documentation into the vanilla JS equivalent.

[stephenhuey]

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

http://thepugautomatic.com/2013/06/helpers/

http://guides.rubyonrails.org/form_helpers.html

https://github.com/rails/rails/blob/dd7af2c413a06ea44e50abf0...

[mandazi]

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

[zecho]

This is a good tutorial for people who think the React way is weird.

http://courseweb.lis.illinois.edu/~hkim214/lis514/img/Dr_Seu...

[agmcleod]

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]

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.

[revskill]

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