React v0.11 | Hacker News Reader

React v0.11

facebook.github.io

208 pointssophiebits104 comments

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.

Anyone have any opinion on React vs Polymer?

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

I'd love to know what you love about Polymer so we can make React better. :)

What I like a lot about polymer is that you can isolate css per component. And that you can also apply styling on your new element names..

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.

http://programmers.stackexchange.com/questions/225400/pros-a...

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.

makes sense to me

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.

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.

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.

http://facebook.github.io/react/docs/working-with-the-browse... http://www.polymer-project.org/resources/compatibility.html

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.

This is not the best React feature. React solves a bigger problem: nested components. You'll never find other framework that solves it.

You can have nested components with AngularJS. That's what transclusion is for.

If the name for their solution is so pompus and factoryProxySingletonBean like, such as "transclusion", I'd hate to see the code behind it...

You cannot pass state down to transcluded elements. They can only get their state from factories, just like... jQuery. Or no framework at all.

React has Virtual DOM diffing which turns it into a very fast rendering layer over the DOM.

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.

James Long from Mozilla has his answer for this:

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.

See http://jlongster.com/Removing-User-Interface-Complexity,-or-...

Great stuff. I really love React. Especially stuff like server-side prerendering of the DOM is extremely cool.

But that assumes a world where everyone uses Node :)

React server side rendering doesn't require Node. Works just fine with Java 8's Nashorn too.

Awesome news. Not enough resources on Nashorn out there.

It works with CouchDB too: https://github.com/fiatjaf/reactive-couch

maybe not yet, but I just wrote a blog post why in the future here: http://radar.oreilly.com/2014/07/next-generation-web-apps-wi...

100% javascript, that would be living the dream......

Is my sarcasm meter on the blink again?

I don't know, but this subthread is off the charts on the Poe scale.

violent beeping

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!

If you've ever used Ember's router and liked it, I'd suggest the react-nested-router[0]. So easy to use

[0] - https://github.com/rpflorence/react-nested-router

Do you happen to have a boilerplate of your stack on github?

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.

What should we do with all the Javascript code between the brackets?

It only assumes a world where everyone uses JavaScript. And in this context, "everyone" is web developers, so it's a fair assumption.

There's a ASP.NET MVC plugin for server-side rendering of React http://reactjs.net/

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.

The docs recommend passing a callback for parent-child communication:

http://facebook.github.io/react/tips/communicate-between-com...

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.

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.

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.

https://github.com/react-bootstrap/react-bootstrap?

Try the paper elements demo [1] in Firefox mobile before finalizing that choice. It's pretty maddening.

[1] http://www.polymer-project.org/components/paper-elements/dem...

Or on an ipad. It doesn't work very well and even crashed my ipad air. I'll definitely not use it for a webapp.

Does everyone just use Backbone.js with React, or are there other models, routers, and controllers that people use?

I created imvvm https://github.com/entrendipity/imvvm . It uses the Model-View-ViewModel pattern with React as the View

It also has pushState routing built in

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.

React is not meant to replace something like Backbone, it is only the 'V' in MVC although you could argue it is also the C.

React does not ship with any code for saving your data to the server.

And the best thing is that I can use react with Clojurescript (Om), which makes it even faster =)

Has anyone written a large React application yet? Preferably open source?

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'm assuming he meant 'replaced backbone views with react'

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.

[1]: https://github.com/Khan/perseus

[2]: http://vimawesome.com/

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.

Yes, this is my bad. :) I added an issue to GitHub about it: https://github.com/divad12/vim-awesome/issues/14

Pull requests welcome!

The Atom text editor being created by github just introduced a react back end for all of its rendering, and it recently went open source. :)

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

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.

How do you bind Backbone Models/Collections to React Components as in the case with Backbone.View?

I use React.Backbone for this. Very easy to use, makes sure the components rerender whenever the model or collection they are bound to changes.

https://github.com/usepropeller/react.backbone

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.

instagram.com

but not open source

Literally Canvas uses React for its GUI: http://literallycanvas.com

It isn't using JSX yet because CoffeeScript integration didn't exist until recently, but it was still a joy to use.

If you hold the mouse down and drag off-canvas to the left or bottom sides, the painting cursor shoots up to y = 0 and leaves a streak.

Thanks for the bug report. I've saved it in the GitHub issue tracker. Pretty weird behavior, definitely fixable.

Where does JSX + Coffeescript integration exist now?

I wrote a JSX transformer for Coffeescript, it's quite stable now:

https://github.com/jsdf/coffee-react-transform

I used this for a small app (drawplz.com) and liked it quite a bit. Thanks for your work.

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.

[1] https://github.com/mesosphere/marathon

[2] https://github.com/mesosphere/marathon/tree/master/src/main/...

[3] https://facebook.github.io/react/docs/class-name-manipulatio...

[4] https://facebook.github.io/react/docs/reusable-components.ht...

We just launched a Drag and Drop website builder made in React:

http://buildicus.com/

I have been distilling all the lessons learned into a lesson plan: https://github.com/zbyte64/reactjs-crashcourse

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.

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.

www.camlistore.org

https://camlistore.googlesource.com/camlistore/+/master/serv...

I'm finishing a commercial project now and the experience has been very positive.

Shorter time to ship, fast UIs and less bugs (because it's easier to reason about state).

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

According to their blog post in May, "Khan Academy, New York Times, and Airbnb (and naturally, Facebook and Instagram) are using React in production."

http://facebook.github.io/react/blog/2014/05/29/one-year-of-...

http://facebook.github.io/react/docs/examples.html

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.

Current work on the front end can be tracked here - https://github.com/glimpse/glimpse.client/tree/version-2. Very much a work in progress but all good so far.

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

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

Why React and not Mithril?

I'm all for variety, but does someone have to mention that framework every time another one is being talked about?

I get that the creator advertises it here pretty heavily, an that's cool. Doesn't mean everyone else has to as well.

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.

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.

I actually think that comparison is fair. Don't read as a negative towards React at all.

I got the same impression.

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.

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.

I agree. It is ugly. It must be because of HTML reuse or something.

But you should try writing React templates in pure Coffeescript[1], perhaps reusing your HTML through a tiny tool[2] I wrote for it.

[1]: http://blog.vjeux.com/2013/javascript/react-coffeescript.htm...

[2]: http://html2react.alhur.es/

I should mention that I have changed my mind about JSX after actually giving it a try.

"Update: New $apply command to transform values"

What is that? No, no, no, stop that! You're becoming Angular!

React much?

That's referring to an immutability helper, not like angular at all

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.

Reply on news.ycombinator.com