I just started using React on my project this week. It's incredibly easy to use and get running, I'm loving it. It's really simplified my UI development. The UI for my project is something I need to just get done for now, while I build out the rest of the functionality. I'll come back later to make it prettier. But React makes that super easy to do.
Wish I'd talked to the guys at FB about it more before I left.
It's something i've been struggling with quite a bit. Conceptually i love Polymer, and really want to switch, but React's serverside rendering is just hard to beat. I'm scared of showing users page load spinners while my 20 Polymer components all load their data heh
Facebook has been using React in production since 2011. Polymer is a "developer preview", aside from the Material Design presentation, I haven't heard of anything public-facing that Google's actually done with it yet.
React is backwards compatible to IE8. Polymer? Not so much. Unless you live in that mythical world of evergreen browsers, Polymer is sort of just a really great demo.
I haven't worked at a place that has cared about IE since 2009. Besides old versions of IE Polymer works everywhere. Worrying about being backwards compatible with old browsers is a thing of the past with constant updates to Chrome and Firefox. If you're developing a mobile site you can't use any of the newest things until Safari updates (about once a year, seriously) but you should be otherwise ok.
I work at a site where about 20% of traffic comes from IE8. Many are users on corporate machines with no alternatives. I really appreciate that React runs on older browsers and is decently performant without a huge payload. All this with a well designed API and a nice development experience... I think it's hard to beat!
Anyway the more traffic your site gets, the harder it becomes to ignore certain cohorts.
But Polymer depends, for example, on Shadow DOM, which is currently only supported by Chrome, Opera (Chrome-based) and Android browser - not even by Firefox yet (http://caniuse.com/#search=shadow%20dom). There are pollyfills but they're too slow to treat them as a viable solution.
In my experience, React has been a better realization of the concept behind Polymer ("reusable web components"), without the non-sense. I don't even consider server-side rendering the killer feature.
Aren't you tired of having to query the DOM tree and manually manage the structure to create UIs? Web Components doesn't solve this at all, it just tries to encapsulate the work. The problem is that building apps is building components, so you inevitably are forced back into the manual DOM management to create your app-specific components (like how you constantly have to create directives in Angular). You also need to jump into JavaScript to configure and wire up any Web Components you used. It's a very messy abstraction, and fools you into desiring a pure HTML-based declarative way to write apps, which is like wanting steak but eating liver.
I too struggle with the choice. Polymer/web components _might_ be an easier sell to my boss as it doesn't require as much framework specific knowledge and would make it easier to get new teammates up and running.
However, the polyfills + ammount of http requests in a very modular project don't inspire the confidence that Polymer is ready for prime time.
My thought is that when web components lands in browsers natively, and if some of the request problems are smoothed over, it would be easier to translate a react project than a project in another framework. You could replace things piecemeal. But by then, who knows how much more compelling react might be.
What I gathered is that Polymer, at this time, is simply not ready or even intended for production use; it's an experimental technology aimed to implement the Web Components standard, which at this time is still heavily under development. Polymer is aiming at the future, and as such will only become usable in the future.
It's also not intended to support older browsers; I'm okay with that.
Well, as unhelpful as this.. I love everything about Polymer, except the possible HTTP request spam and lack of serverside rendering.
Polymer is sort of React Components "To the extreme" (to me). They represent everything i love about React Components, with encapsulated JS, CSS, and HTML. Meaning that i can pull in someone elses Polymer component, or use one from another project, and it "just works".
Granted, the HTTP spam scares the hell out of me. Vulcanize may help with that, but i have yet to really figure out the whole process for my workflows.
Having to load an html wrapper, do clientside routing, load the data into the clientside templates and render templates all for the first page load just scares me with Polymer. React solves this by letting me do it all serverside, and it is wonderful at that.
I really do love React. I'll likely stick with React for another project or two, unless i conceptually have an "ah hah" moment with Polymer.. but until i can render Polymer serverside, i'll always be longing for React.
edit: Come to think of it.. If someone could bake html imports and shadow dom into React, i may be in heaven.
React already can render into shadow roots, and eventually we could add a mode that tosses aside server rendering in favor of shadow DOM. However, if all you want is style encapsulation, you can get that with conventions.
I'm not terribly experienced with React, but from briefly using it, I definitely prefer polymer's simple vanilla html+js declarative data-binding approach over react's JSX + element injection, from a basic usage perspective.
I think they solve two different problems. Polymer I see as useful for creating atomic UI elements while React.js is better for stringing the UI elements together into a cohesive experience.
Not to mention, that react side-steps the entire issue of heavy DOM reflows/rerendering as individual components update. I don't see Polymer doing anything but make that issue worse until browsers support it natively, and even then it will take some changes to the way browsers handle rendering to improve performance there.
I do think that long-term (5+ years) something like Polymer will become the preferred solution. For now, imho, React is about as good as it gets for componentized web applications.
I disagree; I think the weakest part of React is the lack of a true controller mechanism.
Everything is a view, even components that are structural more than visual. You achieve an MVC-like separation by designating some components as being owners of data, but it feels awkward.
Facebook's Flux looks like it may be a good solution, but I haven't tried it out yet. At any rate it is more about data flow than high-level application orchestration.
Fwiw, i use serverside React rendering with a Golang API server. My JS code has an interface layer which interfaces to browser/node, and on first load a balancer throws the request to Node, which makes local API calls to the api server, and renders it all in node.
Technically i use Node, but only to implement a small interface layer for things like http requests. So i don't really consider it a Node app. The real code is all React and Golang.
Awesome stack. It's exactly what I've started working on lately. I have 2 questions for you :)
1. What router do you use for react as it's necessary if you want multiple entry points into your app ? Rrouter seems promising.
2. How do you elegantly proxy client cookies from your node app to your api ? (both way: read and writes)
Thx!
The JSX translation shouldn't be too hard to write a binding. I know that it happened with mustache. Now, it would mean keeping it in sync, but it might not be a bad idea for people outside node and the JVM.
I have been trying to use React in an application I am building. One recurring issue I have with React is child to parent component communication. The recommended way seems to be to have the child component emit events which are then caught and handled by the parent component.
Unfortunately, this approach does not work very well in the cases where I have multiple instances of the same component, in which case all the parents will be recieving and handling the event emitted by a single child. I would love to hear any possible solutions for this that do not involve either registering unique event names for each instance of the component or passing in a unique id as part of the event payload, which is then verified by the handler function.
Maybe I'm not understanding the problem correctly, but I simply had the child components 'know' their index or id (stored in props) and then pass that to the parent with any call.
Could you elaborate here on what you mean by "all the parents will be recieving and handling the event emitted by a single child"? Or perhaps post a question on StackOverflow.
What a great site for reading. I'm not usually into design, but reading through that blog forced me into a new appreciation for layout, font, and color.
I planned on using React for my next mobile app project until Polymer was shown off at I/O. React is a fantastic alternative to Angular, but the Paper Elements make Polymer too good to pass up.
I would be over the moon if React had a UI Kit that could be included. We need more app-centric first UI options for rapid development.
Is it only me or does that remind anyone else about basic MVC frameworks, like Backbone used properly?
Oh and don't get me wrong that this pattern gets used again. I can see it being extended here and it looks really nice and promising. I just don't understand the sudden hype.
At Khan Academy most of our frontend is now using React (including our personalized learning dashboard, coach reports, question editor [1], etc.) and we're really happy with it. We have about 750 React components and 50,000 lines of JSX now. We've migrated pieces incrementally and React is really great for doing that because it doesn't try to own your whole app.
My friends and I also just launched Vim Awesome [2], which is not "large" but is completely written in React and is open source if you're curious to look at it.
When I scroll down the Vim Awesome home page, click a link, and then go back to the home page (Alt-Left), I'm directed to the top of the home page rather than the location on the home page where I left off. Is this issue caused by React? (Every site I've evaluated that's powered by Meteor has this issue, and I hate it.)
No, this is most likely an artifact of react-nested-router (https://github.com/rpflorence/react-nested-router) not currently preserving the scroll position. Definitely not a constraint imposed by React.
Edit: Or this may be due to the fact that we don't properly cache the fetched plugin list on the client side so we end up re-fetching it when you go back. Either way, this is not a React problem.
Our UI for Marathon[1], a framework on top of Apache Mesos, is written in React and uses Backbone models. It uses Require JS for modules and compiling the source into a single file for distribution. The JS root is in the assets directory[2].
There are a few guidelines we have adopted through trial and error so far:
* Use React.addons.classSet[3] liberally. Class name generation becomes simpler for future developers to read.
* Define propTypes[4] for every component. Debugging becomes easier because React gives you informative warnings about mismatched propTypes.
I don't have any open source examples, but I have multiple friends at different mid-size startups who replaced backbone with react and they are all super happy about it.
I'm looking forward to try React myself, but haven't yet.
Seems like React is here to stay and become really really awesome, I haven't heard anybody say bad things about it.
> I have multiple friends at different mid-size startups who replaced backbone with react
They all replaced backbone with react? I haven't really used either, but I thought a lot of people used backbone and react together, since they excel at different things.
I downloaded and took a look at your lesson plan. Nice. It's solid and covers a bunch of usage patterns that aren't clear in the react tutorial.
My one suggestion: host it on github pages and put a link to that in the README. It's already basically ready to roll. Way more accessible than downloading a zip and opening an html file.
Not enterprise kind-of large, but I'm in the process of building a booking web app (https://zapla.co) using React and Backbone Models/Collections.
I made the decision to switch from Backbone.View to React about ~2 weeks into the project, and so far I'm extremely pleased with it and have not regretted it! Unfortunately, the code isn't open source though.
What I've settled with for now is to attach an instance of the Model/Collection as a prop on the React component and syncing it to Reacts' state.
I do this by attaching a callback on the sync, add, change, remove events and use the the toJSON() method to copy it to the React state like so:
this.setState({data: this.props.model.toJSON()});
When saving a form, I have a method which handles the form submission. It copies over the state to the model and then saves it using:
this.props.model.set(this.state.data);
this.props.model.save();
In additional to this, I've built a tiny dispatcher to instantitiate my models and collections only once. In this way all parts of the app will always work on the same data and by in sync.
Glimpse v2 is using React/Flux for pretty much everything client related and all parts are open source and on github.
For those who don't know, Glimpse is an OSS diagnostics platform and we are in the process of building out v2 (including NodeJS and .NET backends) - http://getglimpse.com.
The system is quite large. In the end it will contain several major "sub applications" that users can switch between and each "application" has large number of components, major interactions, etc.
We are currently using the following stack:
- Views - ReactJS,
- Server Comms - Superagent + Primus (SocketIO),
- Build - Gulp,
- Packaging components - Webpack,
- Module System - CommonJS,
- Message Bus/Dispatcher - Postal.js,
- Testing - Jasmine, Jest, Chance, Karma, etc
The majority of the UI for Camlistore is written in React. Unfortunately it's not running anywhere publicly, so you can't play with it. But you could run it locally and poke around.
I've architected two enterprise-class business apps - both projects would have failed without react IMO. Neither are open source, but both use this library for widgets: https://github.com/wingspan/wingspan-forms
At Ruboss, we rewrote Dashcube (https://dashcube.com/) in React, after having performance issues with another JS framework. The rewrite took 4 months, and was totally worth it. We're extremely happy with React...
Wooohoo! Nice release. I especially like the JSX Namespacing! I sometimes found myself sacrificing better organization/naming just so my component rendering code wasn't so hideous.
We still recommend exporting small modules internally in your code base so that things are easier to reason about and dead code elimination can work better -- but when interfacing with third-party libraries, the namespacing feature can be helpful. :)
I seems to me that Mithril is inspired by React, and it's awesome that someone is trying to make things better than React.
That said, I have a bad impression of Mithril, because, in any case, its author should bear some respect to React, as a son to his father. But, instead, he appears very arrogant when talking about React (look here: http://lhorie.github.io/mithril/comparison.html#react) as if it was React that was inspired by Mithril and was reimplement Mithril ideas with worse performance.
That bad impression, caused just by words (and other comments from its author here), pulls me away from Mithril, which is a situation I don't love.
But I built my web-apps with a similar pattern for years.
Keeping an virtual structure of my components and rendering the delta to the DOM when finished, so React didn't seem like a big deal for me. But I liked, that they baked the idea into a reusable framework.
It's relevant because it's similar to React (but more lightweight and claims to be faster). Mentioning it here can be useful for those who are looking for alternatives to React.
Inline JSX is such a stupid idea, and react.js doubles down on stupid. Why do this? The documentation never explains why it is good to add some invalid JavaScript syntax to a library. I want my templates in the same file as my JavaScript logic, inline no less, peppered throughout variable declarations and function calls all over the place, like I want to stub my toe. I do not want to stub my toe and I don't want to use JSX. Notice the complete lack of support in Webstorm.
Every night when I close my eyes I envision a future in which React surpasses HTML and browsers start to only render REACT code, documents are written and named index.react, amateurish people say they are REACT programmers and everything is so beautiful that you can't stop looking.
_________
Now seriously: there should be a way to turn React from a library to a DSL that could be rendered by any language, so all servers, not only Node, could generate their pages in React and pass them to the browsers.
Event handling could still be javascript, as servers don't need them, but code that rendered elements according to specific this.props should be universal.
Wish I'd talked to the guys at FB about it more before I left.