At this point we have around 60 pages, hundreds of components. It scales very well. Give React a few days when trying it out. We also use our own customer flux implementaion, which makes handling front end data models easier through one directional data flow. I recommend checking that out also, it scales very well. Some of our pages right now would push angular to the limit with hundreds of rows, many different components, etc, React handles it really well without having to meticulously tweak performance, it just works. Angular can do the job as well, just needed a lot of quirks to make it work.

After about six months, I finally feel like I've got a handle on how it works, sort of. It's probably not something I'll use again on future projects though.

You're probably better off using simple_form and Turbolinks with Rails.

But I suspect Components will make forms awesome for React!

With react and react-native i start publish my projects on github, because they has a simple structure and can be easily supported.

I almost forget jQuery, it's really rare situation when i need to access real DOM.

Big amount of flux frameworks (i love [flummox](https://github.com/acdlite/flummox) , [redux](https://github.com/gaearon/redux)).

I read discussions (in twitter, in github issues, in slack http://www.reactiflux.com/) of this guys @sebmarkbage, @Vjeux, @dan_abramov, @acdlite and many others as like "THE BEST PROGRAMMING BOOK I'VE EVER READ"

My [app](https://github.com/istarkov/google-map-react) hit the top trending github apps, thanks to react community. (it's not easy for developer to show his work to the world)

React is GREAT!!!

The only thing I don't like about React is the rapid churn in architecture best-practices (Flux et al). This is in stark contrast to Ember—which nails conventions and tooling but is written far about vanilla JS.

We use React because components are a great abstraction for the web. React components are also very transportable, making them a great addition to integrated systems like Rails.

I like to focus on transferable skills. I don't want to be a Backbone/Ember/Angular/whatever developer. I want to be a good JavaScript developer. React makes that happen.

This is why I'm sticking with Knockout for probably another year or so. It's tiny, safe, easy, stable and it's already been proven to work for large apps.

It also has a beautiful component system and since Knockout simply stays out of your way, you get to focus on Javascript. When the churn dies down in React-land, maybe I'll take another look.

Flux is very boilerplate-y, even with some of the lighter frameworks. But boilerplate isn't particularly complicated, so you get over it.

If I were going to a hackathon I would not use flux+react, I'd probably go with angular. If it's something I plan on maintaining over a long period of time, react is currently my big choice.

Testing react is very nice, especially coming from angular where testing directives was very painful. (And testing everything else was needlessly verbose.)

I made a VERY simple project starter [0] that I'm going to take the chance to plug now. It's built for frontend web applications in mind, and it focuses on giving you the starting environment to build an app. It provides development, testing, and production builds. In development you get live-reload and hot-loading of assets. In production you get minification, concatenation, and cache busting of assets, as well as getting all assets copied to your output folder. There's a live testing environment (i.e. watch files and run tests) as well as a single-run environment. Tests also generate code coverage reports. The best part is that it doesn't use gulp or grunt, it's just a webpack config with a few flags per environment type, and to run every task you just use npm run-scripts. Out of the box it handles ES6/ES7/JSX, CSS, images and fonts, but extending it to support other assets is trivial. I took the time to heavily comment the webpack config in order to help people out.

EDIT: My coworker pestered me to edit this and mention that we're hiring [1]. If you're interested in using React and Flux, reach out!

[0] https://github.com/cesarandreu/web-app

[1] http://www.treasuredata.com/careers

I didn't really like JSX, though, and using straight-up JS to declare components is gross. Using React in general also seemed rather verbose, and I found myself digging through the API docs and trying to reason about the component lifecycle. It just wasn't as simple as I would like.

I ended up settling on RiotJS, which shares a philosophy with React but is closer to bare metal, so to speak. It feels more like a library and less like a framework. (They also just added mixins and HTML transclusion, two things that I missed from React.)

https://github.com/af/JSnoX https://github.com/mlmorg/react-hyperscript https://github.com/jussi-kalliokoski/react-no-jsx

I do wish the React team made their plain JS API less of a "second class citizen" to JSX though.

Also, having worked with both Angular and React alongside less experienced developers, I've noticed developers in general doing a lot less stupid shit with React (not to say none, just less). Angular doesn't have many strong philosophies about programming, so it's largely up to the programmer to make good decisions rather than have the framework make the right thing feel right - the latter, in my opinion, being what growing developers need.

My sample sizes have been limited though, so take this advice with a grain of salt. Also, I picked on Angular because that's the other framework I have a reasonable level of experience with, but you could substitute most frameworks in its place.

EDIT: One thing I'm still missing is Flux. I tend to use React alongside PouchDB, and thus haven't really encountered a need for Flux, but even then - I think I simply don't get it. I mean, it's just a convoluted event bus, right? What's the big deal? I don't mean to undermine the efforts of Facebook's engineering team(s), I rather feel like there must be something about the Flux architecture that I'm missing, that somehow makes it more valuable than a simple event bus.

There's a lot of advantages to this (in terms of performance, but much more importantly, in terms of being able to reason about your code). You could think of it as an event bus, and you might even implement it with one, but that's an implementation detail. In terms of your actual code, your store will list which actions it wishes to be respond to, your views will list which stores they want data from, and you'll have some UI elements that trigger actions. Your view doesn't "know" about events; it knows that it'll be rendered with the data it needs passed in as props, and re-rendered with the new data it needs.

You're probably using PouchDB more or less as a store. If not, you probably should be, and it would be trivial to write a very lightweight wrapper around it to tie it into your existing flux implementation of choice. What flux is trying to get you to avoid is some sort of ugly ball of ad hoc AJAX calls and local component state. PouchDB is already pushing you the same direction. (Which is probably why you don't see a point.)

I haven't used it myself yet, but I'm itching to! I love Reagent and I'm very interested in FRP, especially the proposition that it might simplify the code a great deal if your app is above a certain threshold of complexity.

While I've really enjoyed working with Reagent (I haven't encountered any real deficiencies, though that may just indicate I haven't used it enough), I'm totally open to being convinced in favor of Om.

Are you using Reagent in production or just for personal projects?

Things I love:

- All of the view state, event handlers, and markup in a single place. This makes it super easy to reason about.

- Very easy to learn and get up to speed with relative to a full framework. I found it even easier than Knockout which is saying a lot.

- Injectable into a pre-existing project that was not designed around using ReactJS.

Things that have bugged me:

- Having to add a JSX build step (yes I know you can avoid JSX but it's ugly)

- No standard Flux implementation the community can rally around

- There is a big community focus on utilizing bleeding edge front-end tech such as ES6 (using Babel) and CommonJS (through browserify/webpack), all installed through NPM. Even the FB Flux reference implementation is written in ES6. As someone crawling away slowly from simple jQuery based site, adding a full on front-end stack + ES6 is a huge ask.

[0] https://github.com/cesarandreu/web-app/ [1] https://news.ycombinator.com/item?id=9751949

- some components in the ecosystem are more hobby projects and have trouble keeping up with React's API, even though it's small.

- Documentation for react-native could be a bit better (but react-native is amazing).

- I still haven't found a nontrivial and non-bloated example of react hot loader config, and getting it working on an existing project seems to be a bit of an art.

- Not all open source components are listed in NPM (but they should be).

- Still waiting for more info on Relay, which while cool, has created some uncertainty about best practices.

- Fluxxor is a great flux lib but isn't widely enough acclaimed as the clear winner, though it seems to be (though nothing wrong with competition).

Everyone I've introduced to React was a bit skeptical at first but now loves it and can't believe what life was life before.

- https://facebook.github.io/react-native/docs/animations.html...

- https://facebook.github.io/react-native/docs/direct-manipula...

- https://facebook.github.io/react-native/docs/navigator-compa...

I'd love to hear where you think I should be spending my efforts next.

A few things I've found confusing:

- What is the best way to implement Stripe checkout in a React Native app. I'm a bit surprised nobody has done this yet so wondering if I'm missing something.

- What is the status of the ReactExtensionsManager project? Is that going to be officially supported? What is the plan for modules? Where does Cocoapods fit in?

- Will we always have to drag/drop things using XCode to use some 3rd party components. It would be great to eliminate the need for that.

- Is there a way to wrap a native component without using Objc? From the tutorial it looks like an objc header file is always required, but it's not 100% clear why. It seems like the recommendation do React Native developers would be to just stick with Objc as the IOS language to focus on (aside from RN)

- What is the timeline for releases that cover the rest of the native SDK's major APIs (like payments)?

So I think these fall into the big picture project organization bucket or maybe the FAQ bucket.

We have a lot of existing jQuery plugins, so it seemed that my options were to either add a bunch of new dependencies that duplicate their functionality in React, start a big project to move all jQuery based components over to React, or stick with jQuery (or React wrapping jQuery, which sounds like a number of headaches).

In the end I decided to use Riot.js for new components instead, which is tiny and plays well with all of our existing jQuery dependencies so we don't take a huge hit on overall transfer size. I would use React if I were building a new front end from the ground up.

So far we feel that Reactive Programming allows us to iterate quickly and swap parts of the back end rather easily, because, quite honestly, we don't know exactly yet where this journey is going to take us. We develop based on user feedback and the data we gather from them.

[1] https://keywordbrain.com (Preview of the front end is outdated)

[2] https://github.com/Reactive-Extensions/RxJS

[3] https://medium.com/seek-ui-engineering/the-end-of-global-css...

[4] https://gist.github.com/staltz/868e7e9bc2a7b8c1f754 (Good primer on Reactive Programming)

Functional programming can mean many things, and no side-effects is one of them. However, JavaScript does not support immutable data structures very well, and React suffers by trying to force it, which results in unnecessary boilerplate code for common actions. Mithril does not enforce immutable data (though you can use something like immutable.js if you want to); it embraces JavaScript-the-language better in general.

Also, my favorite quote -

Before React - Don't mix HTML and JS React - Mix HTML and JS

Imagine. It simply tells you - do things like when you started learning web development `<div onClick={handleFunc}>`, change things as much as you want, and we'll take care of it. Just keep doing whatever feels natural. I've been waiting all this while from the moment I started writing code for browser - I wanted to use `onclick=func`, `onchange=func`, and `if (isHidden) return <div hidden=true>` and it just lets me do that.

One thing that I wish was different was the focus on using flux. Flux isn't really for me, I found it really complicated and it made following the data through my app even more complicated than it was with angular.

The solution for me was to use something like Om's cursors (specifically baobab https://github.com/Yomguithereal/baobab). After trying to get a handle on flux for a few days I switched to baobab and the real power of reactjs just clicked for me.

I'm wondering if it will have lasting appeal, though, because ES7 should introduce async/await to javascript, which will probably replace the coroutine style.

The core idea behind React is that it makes a ton of sense to think about views as being composed of pure functions which transform (immutable) data into a DOM. It's a very good idea, and React is a good (and certainly the most popular) implementation of it.

It's not hard to implement in a way which is performant (which is nice), but much more importantly it lends itself to code which is easy to test and reason about.

In addition, it also works well with a flux architecture. It's not the easiest way to write a web app, but there's simply large classes of bugs or potential issues that simply don't apply if you embrace one way data flow and immutable data.

There's nothing magical about React, and there's certainly some alternatives floating around. And you can certainly write terrible React code. But it's still a pretty good starting place, and the more serious you are about the app the better. If it's large, complex, needs full test coverage, and will be maintained by a team of people for the indefinite future, React is pretty good. If it's a weekend hack project, it might be overkill.

As for particular issues I've had:

1) The React team is trying to embrace ES6 syntax (and for good reason) but it's not quite ready for prime time. Some core React functionality relies on mixins, but ES6 classes don't really support mixins. So either you write hideous ES5 code (ewww), or find weird workarounds for the not-yet-ES6 ready bits.

2) Facebook also pushes the testing library Jest, and a lot of React projects use it. Jest is so slow that many people will give up before ever seriously using it, but if you do persevere it you'll find that it's actually a steaming pile of buggy crap. A modern mocha/chai/sinon testing stack will be 100 times faster (I wish that was hyperbole), much more stable, and much better supported.

3) There's a lot of, well, flux, when it comes to flux implementations. I like Marty and Alt, which are both really good (and apparently might be merging soon), but there's several more excellent ones. Which is kind of a problem; it'll be good when things settle down.

4) React doesn't enforce immutable data, probably because it's not a mainstream concept yet, but everything works so much better when you use it. And it's a lot easier to use if you're using it from the start.

I agree with the people saying that "stock" Flux has a lot of boilerplate. The upside is that when you're looking to add or change code, you know exactly where to go even as the UI and business logic get complex. Some of the newer Flux implementations look like they reduce the boilerplate, but I'd like to get more comfortable with the concepts before choosing another opinionated abstraction.

We transpile all of our JS with babel as well. I'd be happy to answer any more specific questions as well.

[0]: https://github.com/rackt/react-router [1]: https://github.com/yahoo/fluxible

I don't mean to echo the already loud voices of people championing React, but they're right: it's just awesome to write.

I think React has the right abstractions for today's web development: I am frequently able to express complex UI with very little SLOC. It's easy to see what a component does, and it's easy to jump into a project with little to no experience.

On that last point: I write software on a team with a lot of Angular.js fans. I've been trying to use React in more places, so I frequently start internal tools that have UI associated with them by using React.

It's going pretty well.

There's a dip. Your team will briefly get really screwed up, because the mind change is big, and since it's just part of the stack, after that you'll have some library support choices to make.

Try it on a side project. Once you have a gut feel for it, you'll know.

----

Edit: splelang si hrad

On the other hand, some clients seem to have heard of react now, so that's a big plus of using it. We'll probably end up doing more.

They are aware of the issue, but too slow in responding to pull requests and mostly reject them for being 'not good enough'

Shadow DOM event support should be in 0.14.

I really love it, but my biggest complaint has to be the mixing of logic and views together, and the duplication of security checks. Although I'm not entirely sure I can blame react for that, I blame my moving from CGI to Ajax/RESTFul interfaces for most of that pain.

We had about 90% of our codebase in RoR. In retrospect, I wish I had used Flux instead of React-Rails, but I didn't have that luxury as I was not starting from scratch.

As far as react and rendering data goes, I do wish there was an easier way in the render stack to conditionally display data. It's hard to squeeze logic into render()

[1] https://gist.github.com/karmajunkie/8dd5367837ee8d2bd5bd

So what are best practices for using React with PHP, for example? For some more context, using Webpack to bundle up all the React logic into a single file. Static views are being served via PHP MVC, and React parent components are attached to window. Then, React parent component is being called within PHP file.

What would be a better way of handling React in a PHP application?

Don't get me wrong - the newest ways of working with 0.13 and ES6/ES2015 are superb.

It's just that as a result of the changes much of the documentation, discussion, questions and answers and blog posts must first be examined to work out which version and way of doing things they are talking about. It's a bit of a mess frankly.

https://babeljs.io/repl/

This will give you a familiar reference for what is going on, and quickly. It also translates the JSX which could be a good or bad thing depending on your preference. Running your own instance offline allows for a lot more customization.

My only gripe: React doesn't play nice with things like Emblem.js (http://emblemjs.com/)

Something like... import {Div, P} from React.Dom

render ->

  Div

   P {color :"blue}, "Hey"

#1 complaint is that watching with grunt react-browserfiy-ing the code buts a 3-15 second complile delay into my dev process.

Having said that, such frantic activity is a double-edged sword. React universe is a rapidly shifting beast - a particular tactic can be the recommended way today, then quickly superseded and discouraged by tomorrow. Some examples include: React's initial createClass() guidance, react-router's "final, final2, final3" API surface, react-dnd's complete and incompatible rewrite between 0.9.8 and 1.0, the many phases of the flux store evolution (from 'just arrays of data', to 'maybe ajax reads', to 'not data at all') etc. In every such case I get annoyed at first, then shortly after I become grateful for the change because the new way _is_ significantly better and it _does_ lead to my app code being appreciably better in structure/flexibility/agility etc. This is great for continuously evolving products - our quality increases with each such iteration. But this can be difficult to budget for, or I do not enjoy going back to the rest of the team with the news that what I asked them to do before should now be avoided. We all learn and our core product benefits, but these quality and engineering efforts are a cost that not every team can maintain indefinitely.

Lastly, React is relatively unopinionated itself which means everyone has a different way to consume it. The freedom is there, and I see many teams using it to shoot themselves in the foot. Take the concept of Flux for example - for clean and maintainable code, very few components should ever have the word 'flux' or 'action' or 'store' in them. The overwhelming majority (>80%) of components should be ridiculously stupid, have no state, and certainly know nothing of flux. But the temptation is there - "oh I'll just drop flux inside and boom I have this power to do anything I want from my ProductSummary component"). This leads to the project having way too many moving parts, overpowered components acting at will, unauthorised data access points which cause subtle bugs, and the project ends up being the same unpredictable mess as we'd' have with jQuery. Yes, the rendering is done with React, but that's a hollow gain if the app is still unwieldy.

Using React demands discipline and focus to have hard boundaries between components, creating clear and predictable data/action flows, removing as much state as possible, and obsessively guarding and layering app's building blocks. Incidentally, if you do it the 'right' way, React itself will be the most inconsequential part of the system that you can swipe away with ease when a better way to write reliable interface will be inevitably discovered.

So far I've managed to get to stuff presented on the window, but as soon as you start messing with references to the DOM components, things start to break down.

It's a shame, I really think Typescript and React would be the answer to getting a decent code base.

One of the cool parts, is that you get to define what your property is with static type checking and have no need to use Reacts on PropValidator.

let search = new SearchBox<{ options:SearchOptions, onSearch:OnSearchHandler> })

That tells you that the SearchBox props contains SearchOptions and a delegate to call when searching

I'm just starting with both React and TypeScript, so it could just be me.

No one cares.

Still figuring out the interoperability between React(JS) and TypeScript.

There are some issues regarding arrays from React that don't have Typescript features, even when casted (like filter() and reduce()

Not to mention the lack of JSX makes things verbose.

Anyway, here's a sample code of Facebooks own tutorial. https://gist.github.com/seivan/fad1a175a5e140299fb2

I REALLY love the one-way flow of data.