Removing User Interface Complexity, or Why React is Awesome

I thought it was nifty. The shocking aspect might just be the big layout change. Perhaps a notification ("Check out the demo") so the user has to click it to enable the side pane, and then its business as usual.

Based on my initial explorations using React with Rails, I'd say React might even be better when used with an existing server-side framework.

With React, you can basically store all you data (state) in the root component (which could be the root of your entire page), and replace that with new state without thinking too much about the DOM updates and view changes that result from this.

This is perfect for a server-side framework, because such a framework by definition already renders everything whenever something changes (page refresh). Without React, the framework does a bunch of things and finally craps out objects that are transformed to HTML by the view (where the views are as 'dumb' as possible). With React, instead of rendering the object to HTML, you just pass these objects, as JSON, to a React component (which could be the whole page), and it figures out what needs updating. You don't have to deal (as much) with client-side logic if you don't want to, and things will still be performant.

This also significantly simplifies server-side rendering, to the point where it might require only one extra call to render the component server side (the handy renderComponentToString).

Of course, in practice it's often not quite that simple, but because of how React operates, you can get pretty far with relying primarily on the server-side framework and little logic on the React-side of things (plus you can achieve the 'holy grail' of seamless server- and client-side rendering.

(apologies if I'm getting things wrong, by the way. I'm by no means an expert on these matters and only just diving into React.)

It was really cool, until I realized that scrolling broke the back button.

I thought one of the cardinal sins of web design was don't break the back button.

Thanks for the rational response, Tom. I hope this doesn't get buried (someone is going through and downvoting at least all of my comment to 0).

Blog posts are best when they are sensational, and I try not to overdue it. I think React has a lot of good ideas, but "revolutionary" is a strong word. I think "refreshing" is a better word. Regardless, I think both React and Ember are the best 2 solutions out there right now, with quite different philosophies, and I'm happy that users have a choice.

Using rAF in my post was pretty much a hack. I think it was fun to take that and run with it. When you use React though, you don't actually do that, you use its `setState` method, or you use something like Cortex. If you look at my cortex example, you do use setters and getters, which give you a way to notify data change. Why don't we just use models like Ember? Because React still doesn't care how we model our data -- even if we have to call `set()` to trigger a paint update, what we get is the choice to use something like persistent data structures for our models.

=== I was completely wrong about Om, it does not continuously trigger rerendering/diffing ever 16ms with rAF. It only uses rAF to batch rendering, so multiple repaints are throttled to a minimum of 16ms ===

The on-screen issue is interesting; I need to think about it more to see if we can actually leverage it in production apps. I think we can for large list views. You don't share scroll state, do you? I absolutely agree that too many JS apps are breaking the web, and I love that Ember has defaults to make that not happen. There is a grave danger in using React and not taking care to do things right.

I'm actually really, really happy about the idea of React and Ember being the 2 ways to choose to build webapps. I have the upmost respect and love for Ember, I think it does a lot of things right, and I wouldn't be surprised if things like routing wasn't copied for libraries to use for React. <3

I think a lot of people see frameworks like Ember and Angular and get scared by their vastness. You don't "get" them in one evening. I have spent many hours poring over documentation, articles and videos for both Angular and Ember and I still feel that there's more to learn. But things like routing, data persistence and controllers will be a part of your app even if you use React.

What I find good about Ember/Angular is that they are very particular about how your app should be constructed. When I started writing single page JS apps, I didn't know what the best practices were. If I had started with Ember, I would've learnt. If I had started with React, I would have been making it up as I went along. If you know what you're doing, maybe that's good. For me, I find that I really like having Ember tell me how to structure my app.