Hacker News new | comments | show | ask | jobs | submit login
Ask HN: ReactJS – Do you use it? Do you like it?
79 points by Ronsenshi on June 21, 2015 | hide | past | web | favorite | 74 comments
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).

If you do use it - are you happy with it? Maybe there are some things that you wish were different about it?

If you did use it, but not any more - what are the reasons you've stopped?




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.


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.


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.


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.


imho: Forms are one of the things react still sucks in. Standards are missing.


Yeah I'm spoiled silly by Rails forms builder, both the standard as well as the better simple_form!

But I suspect Components will make forms awesome for React!


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) , [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!!!


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!


Thanks a lot for all the links. Great material to go over.


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.


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


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

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


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


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


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


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.


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


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.


Sounds like Re-frame might be the natural next step for you: 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.


This might help explain where flux is useful http://briandipalma.github.io/flux-for-components/


How you liking Reagent? Why did you choose that over Om?


Honest answer? It seemed simpler. I haven't used Om yet so I won't try to compare the two, but Reagent presents very simple interface. Components are just functions which emit Hiccup. Reagent's ratoms are, I'm told, much like Om's Cursors, but different in a way that I haven't investigated enough to understand. Looking at the READMEs for the two projects, Reagent just seemed more approachable to me.

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.


Yea, going through Reagent and Om's tutorials side-by-side, Reagent seems way simpler. I'm new to Clojure and Clojurescript, so I figure learning Reagent would provide a base where I could then delve into Om.

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


Just for personal use right now, though I'm currently implementing something on my own time that I'm hoping will prove valuable enough to be used at work (thus introducing ClojureScript to my company). A bit underhanded, but I genuinely think that the system I have going with CLJS so far is leagues ahead of what we'd get with an Angular implementation (which we used for the other side of our front-end).


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.


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/ [1] https://news.ycombinator.com/item?id=9751949


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.


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


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.


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.


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


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.


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?


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.


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.


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


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.


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.


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.


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 [1]: https://github.com/yahoo/fluxible


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.


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


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


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.


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'


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.


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


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


Not all of your logic has to be in render() itself. You can define other methods on your component that will be bound to `this` in render(), so you can just call them like `this.renderFoo()`. Each one just has to return a single root node with optional children like the render() method does.


I'm using ReactJS with a rails app, and are doing so without needing the security checks on the client side.


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?


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


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?


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.


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.


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

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.


This is precisely my issues, but with TypeScript instead of ES6 , types on this.props is worth switching to TypeScript from CoffeeScript or ES6.


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


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"


That's actually quite helpful. Thanks!


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.


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


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.


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.


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.


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


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


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.


The Redmond cult, closely followed by... a city I've never heard of in Japan? Toss it in the graveyard with the rest: https://github.com/jashkenas/coffeescript/wiki/List-of-langu...


Honestly, who cares? I'm not being mean, it's true, look: https://www.google.com/trends/explore#q=typescript

No one cares.


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


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

I REALLY love the one-way flow of data.


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


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




Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: