
Ask HN: ReactJS – Do you use it? Do you like it? - Ronsenshi
Just started working on a small node.js based personal project and would like to hear opinions regarding the general situation in the ReactJS environment from people who use it now or used it in the past but stopped for some reason(s).<p>If you do use it - are you happy with it? Maybe there are some things that you wish were different about it?<p>If you did use it, but not any more - what are the reasons you&#x27;ve stopped?
======
Cshelton
I'm using it for a very large enterprise app. React's advantage is the
declarative style, very easy to reason about your View logic. Team
productivity is up, fixing/changing older UI is easier/quicker, it's great.
We've tried angular, we were using just vanilla JS and Jquery, React is great.
A great resource you should check out is the slack channel Reactiflux. Many
active people and they will answer any question you have!

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.

~~~
tmm
I am using React for a smaller enterprise application and find it quite
difficult to reason about. But perhaps it's not well suited to deeply nested
forms with lots of fields.

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.

~~~
seivan
I feel like you lose out on using React if your application isn't going to be
huge in terms of "components" and states.

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

~~~
nulltype
A better alternative in my experience is to implement just the unidirectional
data flow idea. This gives you some of the advantages of react without a lot
of the complexity.

------
cybice
I've moved from angular to react and i'm happy. Simple, really simple!!!
interface. All you need is to remember just few methods of one (ONE!!!) class.
It's fast enough to create interfaces with a lot of objects.

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](https://github.com/acdlite/flummox))
,
[redux]([https://github.com/gaearon/redux)](https://github.com/gaearon/redux\))).

I read discussions (in twitter, in github issues, in slack
[http://www.reactiflux.com/](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](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!!!

~~~
joshstrange
Your google maps component looks awesome. I'm looking at a few frameworks for
my company and react is the one that I'm leaning towards (I've used angular
before but react feels more performant out of the gate). We use google maps a
lot so having this would be awesome!

------
chantastic
I like React because it's closer to JavaScript than any other JS library I've
used. The public API is tiny; you get better at React by getting better at
JavaScript.

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.

~~~
WorldWideWayne
> ...rapid churn...

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.

------
TheAceOfHearts
I use it at work and for personal projects. It's great, creating sophisticated
interactions is a lot simpler with flux and react.

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](https://github.com/cesarandreu/web-app)

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

------
colinmegill
Unbelievably productive. I don't think there is another good choice right now.
I've been on every other framework (large, complex backbone apps, companies
you've heard of) and the codebases have been insane. New programmer onramp
time is down a lot, time to feature is down a lot. The codebase complexity
seems to scale linearly with actions and stores, other frameworks felt more
like quadratic (jk, don't respond to that).

------
mattmc
I used it for a project, along with a simple Flux implementation, and it did
the job well enough. The declarative, state-based aspect of it is great. This
might be a small thing, but I also missed their unified onChange event when I
moved to another tool.

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

~~~
funksta
I agree on the JSX point, but there are a few libraries that make using plain
JS less awkward:

[https://github.com/af/JSnoX](https://github.com/af/JSnoX)
[https://github.com/mlmorg/react-hyperscript](https://github.com/mlmorg/react-
hyperscript) [https://github.com/jussi-kalliokoski/react-no-
jsx](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.

------
notduncansmith
I've used it for multiple apps at this point and it's been a huge win for me
in terms of productivity (I'm also quite enjoying Reagent with ClojureScript
so far, but I'll withhold judgement on that for now). Trying to apply simple
FRP-style abstractions over state changes like Signals becomes infinitely more
tractable in React, where components are just functions that return data (as
opposed to most frameworks, like Angular, with their very effectful
controllers and other code).

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.

~~~
Lazare
The point of flux is one way data flow. Your data lives in ONE place (the
"store"), and then it's fed into your views, which render it in a
deterministic fashion. User interaction triggers actions, which circle back
around to modify the data in your stores. Data should only be modified by
actions, and views should only change when your data does.

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

~~~
notduncansmith
Okay thanks, that actually clears things up a lot. Funnily enough, I found
myself using this exact pattern in ClojureScript yesterday, using a ratom as
my store and having what I suppose I should call "actions" which (may make
HTTP calls and) update the data.

~~~
Reefersleep
Sounds like Re-frame might be the natural next step for you:
[https://github.com/Day8/re-frame](https://github.com/Day8/re-frame)

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.

------
lastofus
I've been slowly injecting it into a project that was previously all JS +
jQuery.

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.

~~~
TheAceOfHearts
You're the target of this repo [0] that I put up! It's meant to give you a
complete environment for building a frontend application. I just wrote a
comment [1] explaining some of the features it provides.

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

------
grandalf
I love it. The only things that could be improved are:

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

~~~
brentvatne
Hi grandalf! Which sections do you think are most lacking in the react native
documentation? I've put some time into improving it this week by adding:

\- [https://facebook.github.io/react-
native/docs/animations.html...](https://facebook.github.io/react-
native/docs/animations.html#content)

\- [https://facebook.github.io/react-native/docs/direct-
manipula...](https://facebook.github.io/react-native/docs/direct-
manipulation.html#content)

\- [https://facebook.github.io/react-native/docs/navigator-
compa...](https://facebook.github.io/react-native/docs/navigator-
comparison.html#content)

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

~~~
grandalf
That Navigator Comparison doc is excellent. I suggest you link to it toward
the top of the Navigator and NavigatorIOS docs.

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.

------
nperez
I evaluated and used it briefly for a hobby project before starting my current
job.

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.

------
heyalexej
Our front end developer seems to like it. We decided to use React in combo
with RxJS[2], utilizing a unidirectional data flow for a new project[1]. React
plays well with D3 and local CSS[3] to create reusable charting components.
Our app produces a relatively high number of objects in a "table". The results
would otherwise be paginated from here to oblivion and back to make it usable.
Lazy rendering the results does the trick in our case.

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](https://keywordbrain.com) (Preview of the front
end is outdated)

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

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

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

------
simplify
I tried it for a small project, but end up using Mithril.js for all my new
projects instead. JSX, OOP, and Flux may be fine for some people, but I prefer
to use plain, functional JavaScript.

~~~
notduncansmith
I know that React likes to use the ES6 `class` syntax, and `React.createClass`
otherwise, but the spirit of React seems very rooted in functional programming
to me. Create pure functions that return data, no side-effects; use immutable
data structures; minimize state where possible. I'm curious what about React
gives off an OOP smell, besides the (admittedly curious) choice of syntax?

~~~
simplify
You said it: class syntax and React.createClass. In Mithril, a component is a
plain JS object with two properties (controller and view).

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.

------
scriptle
I use React for almost all my projects and I'm definitely happy with it. It
addresses one of the main problems - many developers in your team contributing
to the same code. React IMO helps us write predictable code even when there
are many developers contributing to the same code.

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.

------
swlkr
I've used it on a few personal projects with a koa powered API on the backend
and one smaller project at work. I like it a lot, I've tried angular and
jquery as well, both really don't stack up at all.

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](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.

~~~
BFay
How do you like koa? I really like the way it handles async stuff with
coroutines.

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.

------
Lazare
Yes, I use it at work. Yes, I'm happy with it. My thoughts are:

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.

------
guscost
I've been using React and Flux for a few enterprise projects, and although I
don't have tons of experience with browser applications it is the most helpful
and pleasant JavaScript technology I've ever used (aside from maybe jQuery,
but that solves a very different problem).

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.

------
biscarch
We use it at $work in an "isomorphic" context along with react-router[0] and
fluxible[1]. I'm very happy with it and the ecosystem developing around it.
Using React also provides an interesting lead-in to native apps with react-
native.

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](https://github.com/rackt/react-
router) [1]:
[https://github.com/yahoo/fluxible](https://github.com/yahoo/fluxible)

------
ttaylorr
Short answer: it's great.

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.

~~~
Ronsenshi
I think repeating some of the already mentioned answers is good - it shows
common things that developers like.

------
JohnHaugeland
I adore react. I've moved two companies to it, one on my own and one with a
team, from angular and template toolkit respectively. It's been an enormous
boon to each team, who have both found that it rapidly leads to clearer
shorter code.

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

------
clord
We're in the final stages of migrating a large non-web system to react for a
client right now (we're up to ~200kLOC of JS) first big project our new
company is doing. Next time I'd use an immstruct layer for maintaining state,
and maybe a thinner vdom library instead of react. Not a fan of flux at this
scale, it's too easy to have components being dependent on their position in
the tree, so we tend to have lots of wrapper-boilerplate that just pulls data
out of the store and pass it to immutable components. I'd rather just have a
module dedicated to the task, and have immstruct sort out how to dispatch
updates efficiently, acting as a 'JSON-view' of the server's state.

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.

------
ziahamza
React is a pain to use with web components. The event handling in React blows
up when it is rendered under shadow DOM, so building chrome extension through
React can be a bit of pain.

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

~~~
spicyj
When we accept a pull request, we have to support that code forever, so I hope
you'll excuse us for being a little bit picky in what we accept.

Shadow DOM event support should be in 0.14.

------
netik
I migrated nearly all of troupeit.com over to ReactJS.

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

~~~
karmajunkie
I'm moving a project over to flux (well, reflux), and I'm still using react-
rails. I'm probably doing a lot of stuff "wrong", but what I'm basically doing
is instead of injecting data directly into the react component is inject it
directly into the store.[1] Mainly I'm doing it as an intermediate step
towards a separated client app with an api, but the upshot is (I think) my
components are doing it in something that resembles a sane way, so all I need
to modify later is the store logic. (Keeping in mind this is my first go-round
with React, so those more experienced with it may tell both of us what a
horrible idea this is. :) )

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

------
neovive
I'm stuck in the middle right now with dependencies on jQuery for existing
projects, while trying to learn both React and AngularJS. I've also been
experimenting with Vue.js which seems like a nice middle ground between React
and Angular. I am also wondering if it's just better to wait for Angular2
before fully-deciding either way. There is also a strong argument to be made
for Polymer + Web Components as the better platform for future projects as the
Web Components standard gains further vendor support. Any opinions?

~~~
bryogenic
I've wrapped a few jQuery plugins into a React components and had no issues or
pain. YRMV.

------
ConAntonakos
Really loving it so far! Having a harder time actually organizing all of the
application's assets and figuring out a more optimized way of having all of
the assets work well together.

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?

------
bwilliams
I've been using React a good bit lately and it's fun to use. Overall I'd say
I'm happy working with it and Flux. It's definitely a toss up between it and
Ember for me.

------
andrewstuart
It's great but it's a real pity that the most recent way of doing things with
version 0.13 and ES2015 is quite different to the earlier ways of doing
things.

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.

~~~
guscost
If you're comfortable with ES5, one option is to paste examples into the Babel
REPL here:

[https://babeljs.io/repl/](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.

------
hliyan
We recently developed a large application using Ember. It works very well, but
I get the feeling it would have been a bit more maintainable had we done it
with React using Flux architecture.

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

~~~
seivan
You won't be needing Emblem if you use CoffeeScript and React.Dom instead of
JSX.

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

render ->

    
    
      Div
    
       P {color :"blue}, "Hey"

~~~
hliyan
That's actually quite helpful. Thanks!

------
alexmuro
I use it, am very happy with it. Use npm for client and server. Modular
design, and uni directional data flow makes project management better than
ever.

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

~~~
hoffer
You need to jump on that webpack train with react hot loader. No turning back.
Here's a great boilerplate. [https://github.com/cesarandreu/web-
app](https://github.com/cesarandreu/web-app)

------
cgag
I like it a lot for my tiny (400 lines) app, but I'm already annoyed at
threading callbacks everywhere, which I think flux is supposed to solve, so I
suspect I'll love it after I get that handled.

------
jbhatab
It has been amazing for me. The one directional data flow of react and flux
has made component design so simple. The modular design of flux and react
makes it versatile for various projects too.

------
e1g
For me, the most significant benefit of using React is the community around
it. Rightly or wrongly, React had been crowned as the darling of "modern front
end" and that has attracted huge amounts of criticism, debates, and
exploration into how we build complex UIs. Over the last year the cumulative
output of those people plus the related projects such as Babel and Webpack
have collectively taught me a smarter way of developing complex dynamic
interfaces for the web. The highest praise I can offer is that for the first
time in 15 years I feel like I can bring the same level of engineering to the
frontend that has been available to us the backend - code that is predictable,
reliable, testable, maintainable, and understandable by others.

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.

------
seivan
I wish it worked better with TypeScript. I love the concept and I've always
felt that front-end web was broken compared to iOS.

I've worked on converting some of Reacts tutorial to TypeScript just to try it
out. Here's some of the code, and it's not 100%.
[https://gist.github.com/seivan/c01a3b1173cd237b8531](https://gist.github.com/seivan/c01a3b1173cd237b8531)

~~~
bdr
Would you mind elaborating on the TypeScript comment? Is anything broken or
just suboptimal?

~~~
seivan
It's suboptimal and obscure. There is barely any up to date resources on it.

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.

~~~
bdr
Thank you. I'd love to use these together.

~~~
seivan
Hey! I got started with Webpack and now got a decent workflow.

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](https://gist.github.com/seivan/fad1a175a5e140299fb2)

I _REALLY_ love the one-way flow of data.

------
shinzui
It's hard to beat react right now. I came to react from ember and I regret not
adopting react earlier.

------
nlolks
Hi, since it a small project. Why not try using the MEAN stack. mongodb
express angularjs node.

