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