6 ms·
Ask HN: ReactJS – Do you use it? Do you like it?
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?
- bwilliams 11y agoI'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.
- deleted 11y ago[deleted]
- nperez 11y agoI 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.
- nlolks 11y agoHi, since it a small project. Why not try using the MEAN stack. mongodb express angularjs node.
- Cshelton 11y agoI'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 11y agoI 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 11y agoI 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 11y agoA 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.
- andreasklinger 11y agoimho: Forms are one of the things react still sucks in. Standards are missing.
- seivan 11y agoYeah 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!
- simplify 11y agoI 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 11y agoI 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 11y agoYou 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.
- biscarch 11y agoWe 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
- mattmc 11y agoI 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 11y agoI 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.
- seivan 11y agoI 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 11y agoWould you mind elaborating on the TypeScript comment? Is anything broken or just suboptimal?
- seivan 11y agoIt'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.
- colinmegill 11y agoThe 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-languages-that-compile-to-JS https://github.com/jashkenas/coffeescript/wiki/List-of-langu...
- colinmegill 11y agoHonestly, who cares? I'm not being mean, it's true, look: https://www.google.com/trends/explore#q=typescript https://www.google.com/trends/explore#q=typescript No one cares.
- netik 11y agoI 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 11y agoI'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
- nearengine 11y agoNot 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.
- supercoder 11y agoI'm using ReactJS with a rails app, and are doing so without needing the security checks on the client side.
- ConAntonakos 11y agoReally 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?
- andrewstuart 11y agoIt'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.
- seivan 11y agoThis is precisely my issues, but with TypeScript instead of ES6 , types on this.props is worth switching to TypeScript from CoffeeScript or ES6.
- guscost 11y agoIf 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.
- clord 11y agoWe'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.
- cybice 11y agoI'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 11y agoYour 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!
- Ronsenshi 11y agoThanks a lot for all the links. Great material to go over.
- notduncansmith 11y agoI'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 11y agoThe 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.)
- hliyan 11y agoWe 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/)
- neovive 11y agoI'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 11y agoI've wrapped a few jQuery plugins into a React components and had no issues or pain. YRMV.
- alexmuro 11y agoI 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 11y agoYou 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
- grandalf 11y agoI 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 11y agoHi 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#content https://facebook.github.io/react-native/docs/animations.html... - https://facebook.github.io/react-native/docs/direct-manipulation.html#content https://facebook.github.io/react-native/docs/direct-manipula... - https://facebook.github.io/react-native/docs/navigator-comparison.html#content https://facebook.github.io/react-native/docs/navigator-compa... I'd love to hear where you think I should be spending my efforts next.
- grandalf 11y agoThat 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.
- ziahamza 11y agoReact 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 11y agoWhen 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.
- cgag 11y agoI 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.
- TheAceOfHearts 11y agoI 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
- lastofus 11y agoI'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 11y agoYou'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
- ttaylorr 11y agoShort 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 11y agoI think repeating some of the already mentioned answers is good - it shows common things that developers like.
- heyalexej 11y agoOur 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-90d2a4a06284 https://medium.com/seek-ui-engineering/the-end-of-global-css... [4] https://gist.github.com/staltz/868e7e9bc2a7b8c1f754 https://gist.github.com/staltz/868e7e9bc2a7b8c1f754 (Good primer on Reactive Programming)
- Lazare 11y agoYes, 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.
- jbhatab 11y agoIt 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.
- JohnHaugeland 11y agoI 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
- deleted 11y ago[deleted]
- e1g 11y agoFor 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.
- guscost 11y agoI'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.
- colinmegill 11y agoUnbelievably 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).
- colinmegill 11y agoUnbelievably 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).
- chantastic 11y agoI 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 11y ago> ...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.
- scriptle 11y agoI 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 11y agoI'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 11y agoHow 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.
- shinzui 11y agoIt's hard to beat react right now. I came to react from ember and I regret not adopting react earlier.