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?
77 comments
[ 3.0 ms ] story [ 179 ms ] threadWe 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.
At this point we have around 60 pages, hundreds of components. It scales very well. Give React a few days when trying it out. We also use our own customer flux implementaion, which makes handling front end data models easier through one directional data flow. I recommend checking that out also, it scales very well. Some of our pages right now would push angular to the limit with hundreds of rows, many different components, etc, React handles it really well without having to meticulously tweak performance, it just works. Angular can do the job as well, just needed a lot of quirks to make it work.
After about six months, I finally feel like I've got a handle on how it works, sort of. It's probably not something I'll use again on future projects though.
You're probably better off using simple_form and Turbolinks with Rails.
But I suspect Components will make forms awesome for React!
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.
We transpile all of our JS with babel as well. I'd be happy to answer any more specific questions as well.
[0]: https://github.com/rackt/react-router [1]: https://github.com/yahoo/fluxible
I didn't really like JSX, though, and using straight-up JS to declare components is gross. Using React in general also seemed rather verbose, and I found myself digging through the API docs and trying to reason about the component lifecycle. It just wasn't as simple as I would like.
I ended up settling on RiotJS, which shares a philosophy with React but is closer to bare metal, so to speak. It feels more like a library and less like a framework. (They also just added mixins and HTML transclusion, two things that I missed from React.)
https://github.com/af/JSnoX https://github.com/mlmorg/react-hyperscript https://github.com/jussi-kalliokoski/react-no-jsx
I do wish the React team made their plain JS API less of a "second class citizen" to JSX though.
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
So far I've managed to get to stuff presented on the window, but as soon as you start messing with references to the DOM components, things start to break down.
It's a shame, I really think Typescript and React would be the answer to getting a decent code base.
One of the cool parts, is that you get to define what your property is with static type checking and have no need to use Reacts on PropValidator.
let search = new SearchBox<{ options:SearchOptions, onSearch:OnSearchHandler> })
That tells you that the SearchBox props contains SearchOptions and a delegate to call when searching
I'm just starting with both React and TypeScript, so it could just be me.
No one cares.
Still figuring out the interoperability between React(JS) and TypeScript.
There are some issues regarding arrays from React that don't have Typescript features, even when casted (like filter() and reduce()
Not to mention the lack of JSX makes things verbose.
Anyway, here's a sample code of Facebooks own tutorial. https://gist.github.com/seivan/fad1a175a5e140299fb2
I REALLY love the one-way flow of data.
I really love it, but my biggest complaint has to be the mixing of logic and views together, and the duplication of security checks. Although I'm not entirely sure I can blame react for that, I blame my moving from CGI to Ajax/RESTFul interfaces for most of that pain.
We had about 90% of our codebase in RoR. In retrospect, I wish I had used Flux instead of React-Rails, but I didn't have that luxury as I was not starting from scratch.
As far as react and rendering data goes, I do wish there was an easier way in the render stack to conditionally display data. It's hard to squeeze logic into render()
[1] https://gist.github.com/karmajunkie/8dd5367837ee8d2bd5bd
So what are best practices for using React with PHP, for example? For some more context, using Webpack to bundle up all the React logic into a single file. Static views are being served via PHP MVC, and React parent components are attached to window. Then, React parent component is being called within PHP file.
What would be a better way of handling React in a PHP application?
Don't get me wrong - the newest ways of working with 0.13 and ES6/ES2015 are superb.
It's just that as a result of the changes much of the documentation, discussion, questions and answers and blog posts must first be examined to work out which version and way of doing things they are talking about. It's a bit of a mess frankly.
https://babeljs.io/repl/
This will give you a familiar reference for what is going on, and quickly. It also translates the JSX which could be a good or bad thing depending on your preference. Running your own instance offline allows for a lot more customization.
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.
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!!!
Also, having worked with both Angular and React alongside less experienced developers, I've noticed developers in general doing a lot less stupid shit with React (not to say none, just less). Angular doesn't have many strong philosophies about programming, so it's largely up to the programmer to make good decisions rather than have the framework make the right thing feel right - the latter, in my opinion, being what growing developers need.
My sample sizes have been limited though, so take this advice with a grain of salt. Also, I picked on Angular because that's the other framework I have a reasonable level of experience with, but you could substitute most frameworks in its place.
EDIT: One thing I'm still missing is Flux. I tend to use React alongside PouchDB, and thus haven't really encountered a need for Flux, but even then - I think I simply don't get it. I mean, it's just a convoluted event bus, right? What's the big deal? I don't mean to undermine the efforts of Facebook's engineering team(s), I rather feel like there must be something about the Flux architecture that I'm missing, that somehow makes it more valuable than a simple event bus.
There's a lot of advantages to this (in terms of performance, but much more importantly, in terms of being able to reason about your code). You could think of it as an event bus, and you might even implement it with one, but that's an implementation detail. In terms of your actual code, your store will list which actions it wishes to be respond to, your views will list which stores they want data from, and you'll have some UI elements that trigger actions. Your view doesn't "know" about events; it knows that it'll be rendered with the data it needs passed in as props, and re-rendered with the new data it needs.
You're probably using PouchDB more or less as a store. If not, you probably should be, and it would be trivial to write a very lightweight wrapper around it to tie it into your existing flux implementation of choice. What flux is trying to get you to avoid is some sort of ugly ball of ad hoc AJAX calls and local component state. PouchDB is already pushing you the same direction. (Which is probably why you don't see a point.)
I haven't used it myself yet, but I'm itching to! I love Reagent and I'm very interested in FRP, especially the proposition that it might simplify the code a great deal if your app is above a certain threshold of complexity.
While I've really enjoyed working with Reagent (I haven't encountered any real deficiencies, though that may just indicate I haven't used it enough), I'm totally open to being convinced in favor of Om.
Are you using Reagent in production or just for personal projects?
My only gripe: React doesn't play nice with things like Emblem.js (http://emblemjs.com/)
Something like... import {Div, P} from React.Dom
render ->
#1 complaint is that watching with grunt react-browserfiy-ing the code buts a 3-15 second complile delay into my dev process.
- some components in the ecosystem are more hobby projects and have trouble keeping up with React's API, even though it's small.
- Documentation for react-native could be a bit better (but react-native is amazing).
- I still haven't found a nontrivial and non-bloated example of react hot loader config, and getting it working on an existing project seems to be a bit of an art.
- Not all open source components are listed in NPM (but they should be).
- Still waiting for more info on Relay, which while cool, has created some uncertainty about best practices.
- Fluxxor is a great flux lib but isn't widely enough acclaimed as the clear winner, though it seems to be (though nothing wrong with competition).
Everyone I've introduced to React was a bit skeptical at first but now loves it and can't believe what life was life before.
- https://facebook.github.io/react-native/docs/animations.html...
- https://facebook.github.io/react-native/docs/direct-manipula...
- https://facebook.github.io/react-native/docs/navigator-compa...
I'd love to hear where you think I should be spending my efforts next.
A few things I've found confusing:
- What is the best way to implement Stripe checkout in a React Native app. I'm a bit surprised nobody has done this yet so wondering if I'm missing something.
- What is the status of the ReactExtensionsManager project? Is that going to be officially supported? What is the plan for modules? Where does Cocoapods fit in?
- Will we always have to drag/drop things using XCode to use some 3rd party components. It would be great to eliminate the need for that.
- Is there a way to wrap a native component without using Objc? From the tutorial it looks like an objc header file is always required, but it's not 100% clear why. It seems like the recommendation do React Native developers would be to just stick with Objc as the IOS language to focus on (aside from RN)
- What is the timeline for releases that cover the rest of the native SDK's major APIs (like payments)?
So I think these fall into the big picture project organization bucket or maybe the FAQ bucket.
They are aware of the issue, but too slow in responding to pull requests and mostly reject them for being 'not good enough'
Shadow DOM event support should be in 0.14.
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
Things I love:
- All of the view state, event handlers, and markup in a single place. This makes it super easy to reason about.
- Very easy to learn and get up to speed with relative to a full framework. I found it even easier than Knockout which is saying a lot.
- Injectable into a pre-existing project that was not designed around using ReactJS.
Things that have bugged me:
- Having to add a JSX build step (yes I know you can avoid JSX but it's ugly)
- No standard Flux implementation the community can rally around
- There is a big community focus on utilizing bleeding edge front-end tech such as ES6 (using Babel) and CommonJS (through browserify/webpack), all installed through NPM. Even the FB Flux reference implementation is written in ES6. As someone crawling away slowly from simple jQuery based site, adding a full on front-end stack + ES6 is a huge ask.
[0] https://github.com/cesarandreu/web-app/ [1] https://news.ycombinator.com/item?id=9751949
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.
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)