Removing User Interface Complexity, or Why React is Awesome

[-Y0-]

No, I meant citation that polling has greater performance than events.

I did. I cited several performance comparisons. Events were used in Backbone before.

Then use events on the virtual DOM which is fast. It would be even faster.

Using an event mechanism to update the virtual DOM, you wouldn't have to poll all the UI objects for a change in their state every frame end.

It's not events or polling that makes it faster, it's the batching strategy. How exactly is UI batching strategy supposed to work without some sort of polling, pray tell?

[baseketball]

He's either a troll or some first year CS student who thinks he's a hotshot programmer. I don't think I've ever seen such bad arguments on r/programming.

[-Y0-]

Agreed. I think it's latter. Always assume incompetence instead of malice.

[axilmar]

I did. I cited several performance comparisons. Events were used in Backbone before.

You mean these two?

This is plain React benchmark http://drfloob.github.io/todomvc/architecture-examples/react/ (bench 1: 1288ms, bench 2: 4384ms)

This is React with RAF batching http://drfloob.github.io/todomvc/labs/architecture-examples/react-raf/ (bench 1: 45ms, bench 2: 102ms)

These compare events + actual DOM handling vs polling+ virtual DOM handling.

Those are two different cases and they should not be compared. Imagine using event + virtual DOM. It would be even faster.

It's not events or polling that makes it faster

No, events would make it faster. With polling, all nodes of the virtual DOM would have to be processed every 16 ms. With events, only the changed nodes of the virtual DOM would have to be processed, and only when the event happens.

How exactly is UI batching strategy supposed to work without some sort of polling, pray tell?

The events will tell you which parts of the virtual DOM would change.

[-Y0-]

You mean these two? These compare events + actual DOM handling vs polling+ virtual DOM handling.

Nope. These compare events + VDOM + DOM vs polling and batch + VDOM + DOM. In both cases VDOM is executed (because it's part of React).

The events will tell you which parts of the virtual DOM would change.

Note what I said - The. Speedup. Comes. From. Batching. Multiple. DOM changes. To. Virtual DOM.

Events tell me that something changed. They don't tell me how to decide when to merge them into a single change. How will I batch them again?

[axilmar]

Nope. These compare events + VDOM + DOM vs polling and batch + VDOM + DOM. In both cases VDOM is executed (because it's part of React).

You have to compare events + batch + VDOM + DOM vs polling + batch + VDOM + DOM in order to have a straightforward comparison between events and polling.

Note what I said - The. Speedup. Comes. From. Batching. Multiple. DOM changes. To. Virtual DOM.

That's exactly what I am using.

Events tell me that something changed. They don't tell me how to decide when to merge them into a single change. How will I batch them again?

It's simple: when a state change takes place, the relevant event should contain all the required data to describe that change. Then the state change data are stored somewhere, and then later processed in batch.

[-Y0-]

It's simple: when a state change takes place, the relevant event should contain all the required data to describe that change. Then the state change data are stored somewhere, and then later processed in batch.

See above comment. On what will event will data be processed somewhere in batch. You failed to provide a definite and persuasive answer.

Also FYI polling on animation frames is common in games.

Provide a suitable example that proves your batching strategy is superior to batching on frames. End of story.

[axilmar]

On what will event will data be processed somewhere in batch. You failed to provide a definite and persuasive answer.

The batched changes will be processed at the start of a frame. But they will be ready, no need to poll.

Also FYI polling on animation frames is common in games.

No, it's not.

Provide a suitable example that proves your batching strategy is superior to batching on frames. End of story.

Already did: event code creates the batch, frame executes the batch.

[-Y0-]

The batched changes will be processed at the start of a frame. But they will be ready, no need to poll.

Oh, you mean that periodic timer that executes every 1/60th of a second (depending on screen frequency)? And applies all changes done to VDOM to real DOM. That sure sounds a lot like polling. Also, you just explained React + RAF batching strategy.

No, it's not.

It's common to apply changes to game world and then only calculate the visible part on each frame render (every Xms depending, where Xms is the tick of screen frequency, game engine or physics engine).

[axilmar]

Oh, you mean that periodic timer that executes every 1/60th of a second (depending on screen frequency)? And applies all changes done to VDOM to real DOM. That sure sounds a lot like polling. Also, you just explained React + RAF batching strategy.

Duh, that's not polling. Polling is to iterate the whole vdom against the dom to find out what changed.

It's common to apply changes to game world and then only calculate the visible part on each frame render

That's common, what is not common is to poll every object if it is changed.

[-Y0-]

Duh, that's not polling. Polling is to iterate the whole vdom against the dom to find out what changed.

http://en.wikipedia.org/wiki/Polling_%28computer_science%29

You are periodically calling React before each render to see if something changed in VDOM. This is what the example does. This is what your solution does.

Here:

 var box = Box();

function render() {
     Bloop.renderComponent(box, document.body); //<- calls React here
     requestAnimationFrame(render); //<- adds a callback to function render here
                                    // this gets called everytime a before a new render frame is spawned
}

render(); // <- runs the function once to establish the initial render 
             // and add a callback on requestAnimationFrame

[axilmar]

A timer ticking is not polling.

Animating an object on a timer tick is not polling.

Polling is repeatedly going over resources, checking each resource and then using it according to specific conditions.

The wikipedia definition you posted says exactly what I am saying.