> With React, I don't really see the point of Ember or Angular

React only deals with the view. In AngularJS, third party objects have a seamless integration with the view.

Imagine you want to paginate datas.

You'd write a Paginator component in React.

In Angular you'd have a Paginator service holding pagination logic. Then you can have multiple representations of paginators,that would be logic less. It's better because it makes it easier to test the pagination logic in isolation,and you can then hide some complexity out of the view.

i did it with a simple notification queue in a project i'm working on :

		.service('Notification', function($timeout, NOTIFICATION_TIME) {
			/**
			 * manage notifications
			 */
			var onNotificationTimeEnd ;
			this.type = {
				'SUCCESS': 'text-success',
				'ERROR': 'text-error',
				'INFO': 'text-info'
			};
			this.timeout = null;
			this.current = null;
			this.notifications=[];
			/**
			 * queue app notifications
			 * @param  {Object} notif
			 */
			this.notify = function(notif) {
				if(notif){
					this.notifications.push(notif);
				}
				if(!this.current){
					this.current = this.notifications.pop();
				}
				if(!this.timeout){
					this.timeout=$timeout(onNotificationTimeEnd.bind(this), NOTIFICATION_TIME);					
				}
			};
			onNotificationTimeEnd = function(){
				this.current=null;
				this.timeout=null;
				if(this.notifications.length>0){
					this.notify();
				}
			};
			
		});

So each time a new notification pops , the view is updated just by adding {{Notification.current}} somewhere in my template

I think React solve parts of the problem while Angular tries to solve the whole problem.

I think there is definetly a middle ground between AngularJS and React virtual DOM that can be found. Let's remember that Misko defines AngularJS as "a better browser",not a framework.

Your comparison makes no sense. React isn't really competing with something like Ember -- the more direct comparison would be React vs HTMLBars (the low level view layer library being used in next generation Ember).

Even if I choose react for my view layer, I'm still going to need infrastructure for managing application state. View layer concerns are probably less than 30% of what I get out of Ember. The rest is bidirectional routing between URLs and models, meaningful controller hierarchies, etc.

React is simple because it ignores all that. But any significant app will still need to deal with those things.

I disagree. You need far less infrastructure for managing application state and if you're willing to settle for the DOM hierarchy communication, you need close to zero, because the communication is endogenous. You can go very very far with only React and a Router without having a mess. There is a default communication layout that is very potent, which makes React simpler than the other frameworks. Even if this were not true, the discussion has nothing to do with MVC...

ractive.js (which I've been using on a couple of projects) also uses a shadow DOM and learning it is shorter than this sentence.

So does Mithril, which weights 8kB minified.

http://lhorie.github.io/mithril/

PS. I think we both mean virtual DOM not shadow DOM.

Are most folks using ReactJS on production running NodeJS to render the first view on the server, or just server the JS and generate everything client side?

(I'm not a particular fan of JS on the server-side yet..)

I've used React on Node on the server side to pre-render the initial HTML. It works great and integrated pretty seamlessly.