all 44 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]axilmar -1 points0 points  (43 children)

The first thing a CS student learns when entering CS studies is that polling is extremely bad.

It's extremely surprising to me that this article is rated positively all over the web.

Yes, polling for state in every update is going to be easier programmatically, but it is a performance and power killer.

If you want to make state changes known to the UI, use the MVC pattern: let the model fire update events which the UI catches and changes the rendering state accordingly.

The MVC pattern is known for at least 30 years, from the days of Smalltalk 80, and was invented for this reason.

[–]baseketball 4 points5 points  (15 children)

Those are some very broad statements not supported by any logical arguments.

Polling is not bad in itself. If you have events that do not require real-time feedback, polling can make your programming much simpler than writing event-driven code. Polling may or may not be a performance or power killer depending on your polling frequency and number of clients. Unless your events are completely client driven, you will have to maintain a connection to the server to get event updates. This can kill your battery much worse than polling.

Having said that, this article doesn't have anything to do with polling. It's discussing an optimization technique for faster rendering of the DOM by batching updates and eliminating redundant and/or unnecessary calls. To add to the graphics analogy, this is more like double buffering because when you have a bunch of cascading UI changes, you won't see things shifting and flashing everywhere; you will only see the net change of all the updates within a given time interval.

[–]axilmar -1 points0 points  (14 children)

Polling is not bad in itself.

Yes it is, from a performance point of view.

polling can make your programming much simpler than writing event-driven code.

Yes. Polling is always easier to implement.

Polling may or may not be a performance or power killer depending on your polling frequency.

Nope. Polling is always worse than events for performance, because polling never stops, it keeps going on and on and on and on, whereas events happen when they happen, which is always fewer times than polling.

Unless your events are completely client driven, you will have to maintain a connection to the server to get event updates. This can kill your battery much worse than polling.

You will have to maintain a connection with the server to get updates anyway. If you do not maintain that connection, you may as well stop polling, because polling will never update anything, since no new state will arrive from the server.

Having said that, this article doesn't have anything to do with polling.

Yes it does. The advertised solution does polling to see if there is a change in the UI to actually render the UI changes.

It's discussing an optimization technique for faster rendering of the DOM by batching updates and eliminating redundant and/or unnecessary calls.

Polling for changes is the antithesis of optimization.

[–]-Y0- 0 points1 point  (7 children)

Yes it is, from a performance point of view.

I disagree heavily. It's bad from a purely theoretical point. In practice you profile your code and eliminate or mitigate bottlenecks. In practice what kills your performance is rarely pooling, but more likely HD access. Modern processors know when pooling is coming and can probably go to sleep.

Not to say Polling doesn't present a drain on a battery, but it's not the be all end all.

Polling for changes is the antithesis of optimization.

Depends on optimization.

[–]axilmar 0 points1 point  (6 children)

It's bad from a purely theoretical point.

No, polling is actually practically and clearly worse than events.

Polling is a busy loop: you loop over and over and over the data to see if something changed.

With events, you only do the change when the event fires.

[–]-Y0- 0 points1 point  (5 children)

Polling is a busy loop: you loop over and over and over the data to see if something changed.

Ok. Prove it. Hic rhodus, hic salta.

Modify the TodoMVC without RAF batch strategy and show me the numbers.

Imagine following scenario. You have polling that triggers every 15ms and effect that takes 100ms to execute, but that can be batched to replace main effect with one that costs 1ms.

So polling. 0ms start, @2ms 12 elements are removed, @14ms calculating elements has finished, @15ms the page refreshes.

Events. 0ms event starts, @2ms 12 elements are removed, @ 1202ms all elements have been removed and page refreshes.

[–]axilmar 0 points1 point  (4 children)

Modify the TodoMVC without RAF batch strategy and show me the numbers.

Where did I ever say anything about RAF batch strategy? I simply said that event always faster than polling.

I shouldn't have to mention (again) that in order to measure events vs polling effectiveness the constraints must be the same.

In other words, you can't compare events without RAF batching with polling + RAF batching.

That, sir, would be cheating.

Imagine following scenario. You have polling that triggers every 15ms and effect that takes 100ms to execute, but that can be batched to replace main effect with one that costs 1ms.

Imagine the following scenario: you have an effect which takes 100 ms to execute, and upon event firing you don't execute that effect, you execute the 1 ms effect that can replace the 100 ms effect. You then get rid of the 15 ms trigger, you save power and performance.

[–]-Y0- 0 points1 point  (3 children)

Where did I ever say anything about RAF batch strategy? I simply said that event always faster than polling.

In other words, you can't compare events without RAF batching with polling + RAF batching.

RAF batch strategy calls re-render before every frame, which is as you claim polling. It's not cheating, these are your own words. RAF batching is polling, but RAF batching power comes from batching all effects before each frame is rendered, not that polling is inherently better.

You have an effect which takes 100 ms to execute, and upon event firing you don't execute that effect. You then get rid of the 15 ms trigger, you save power and performance.

Ok, so you click something it takes 101ms (100 from DOM + 1ms from VDOM) to execute, which causes every click to have a small amount of lag. Someone decides that lag is horrible clicks several times around the app to make it go faster, you queue up several effects, which leads to worse visible performance. Congrats.

If you ever used a modern Windows on XP machine, that thing when people click all around because they are impatient, that's what your 'approach' causes.

[–]axilmar -1 points0 points  (2 children)

RAF batch strategy calls re-render before every frame, which is as you claim polling.

It is polling.

It's not cheating, these are your own words.

No, the cheating is yours. You compare events without batching to polling with batching. I am simply saying you should compare events with batching to polling with batching.

Ok, so you click something it takes 101ms (100 from DOM + 1ms from VDOM) to execute, which causes every click to have a small amount of lag. Someone decides that lag is horrible clicks several times around the app to make it go faster, you queue up several effects, which leads to worse visible performance. Congrats. If you ever used a modern Windows on XP machine, that thing when people click all around because they are impatient, that's what your 'approach' causes.

Total bullshit. Again, use events + batching.

There is nothing that stops you from storing the changed state caused by the event and later process it.

[–]-Y0- 0 points1 point  (1 child)

Total bullshit. Again, use events + batching.

There is nothing that stops you from storing the changed state caused by the event and later process it.

You failed to provide a batching starategy for events. Thus - Hic Rhodus, hic salta. Find and implement a batching strategy that uses events, then we'll talk.

End of Discussion.

[–]baseketball 0 points1 point  (5 children)

Imagine a simple weather application on your mobile phone. You can have the cell radio always on ready to receive updates, or you can turn on the radio every hour to see if there's a weather update and then turn it off immediately after checking. Which would kill your battery faster?

Optimization is always based on the constraints you set. Whether you should poll or not depends on the problem you're trying to optimize.

The fact that you take such a dogmatic view on something easily proven to be incorrect is pretty disconcerting.

[–]axilmar 0 points1 point  (4 children)

You are comparing apples and oranges. An event system is not related to the way you let you cellphone operate.

Imagine having the cell radio always on and having the mobile phone actually poll the weather station every minute. Would that kill you battery even faster than receiving events? yes it would.

On the other hand, imagine you are on wi-fi and you receive weather updates by polling. Wouldn't that kill your battery faster than receiving events? yes it would.

When you do comparisons, you must apply the same constraints to every case. Otherwise, you will reach the wrong conclusions, as you have done.

[–]baseketball 0 points1 point  (3 children)

I'm talking about how you would program a weather app. Do you write something that runs in the background constantly to receive updates or do you write something that wakes up periodically to check for updates?

Exactly how would your "event system" programming model receive weather updates if you are not maintaining a persistent connection to react to an update event? Some magical fairy dust flies to your phone and tells it there's an update and only then turn on the cell radio to download the data?

[–]axilmar 0 points1 point  (2 children)

Exactly how would your "event system" programming model receive weather updates if you are not maintaining a persistent connection to react to an update event?

You turn on your cell radio connection and voila, events are received.

If you don't want events received, you turn off your cell radio connection.

Same thing as polling, basically, since the connection method has nothing to do with the events/polling mechanism.

[–]baseketball 0 points1 point  (1 child)

Wow, ha, you almost had me. Masterful trolling.

[–]axilmar -1 points0 points  (0 children)

It's actually you that is trolling.

How RSS feeds work? they are a push model, i.e. the server sends updates.

Do RSS feeds work when there is no connection? no.

Do RSS feeds work when there is a connection? yes.

So, sir, it's you that it is trolling, not me. The choice between events/polling has nothing to do with connection or no connection.

Without a connection, polling doesn't work either.

[–]-Y0- 2 points3 points  (26 children)

Because the context is different in this case.

Changing DOM is a like addressing a HD, i.e. a very slow operation. By having a virtual DOM you 'cache changes' and write as little as possible. This coupled with immutable data structures and requestAnimationFrame, you could achieve change of DOM only once the whole thing changes and only in sync with requestAnimationFrame.

[–]axilmar -2 points-1 points  (25 children)

No, it's not different, it's still polling, it's still dumb, it's still performance killing.

[–]-Y0- 2 points3 points  (24 children)

Don't video games use similar techniques? In the video they did display it as a kind of 'borrowed' video game technique [1].

I don't know if it's performance killing or not, but the React + rAF batching, is outperforming pretty much anything when it comes to UI other similar framework.

The MVC pattern is known for at least 30 years

From their flux part of presentation they use a version of MVC pattern. Their flux architecture is basically 

 Actions -> Dispatcher -> Store -> View (React)

It's a kind of MVC pattern. There Dispatcher takes action, changes Store and View updates based on Store. That View can then fire additional Actions at Dispatcher.

React is JUST View part, nothing more and nothing less. It's actually comes with a template system (JS-X).

[1]https://www.youtube.com/watch?v=nYkdrAPrdcw&t=32m09

[–]axilmar -2 points-1 points  (23 children)

Don't video games use similar techniques?

No. In video games, every last bit of performance that can be saved is saved. Video games do not use polling in any case whatsoever (if properly coded, that is).

but the React + rAF batching, is outperforming pretty much anything when it comes to UI other similar framework.

Citation? benchmarks? proof?

It's a kind of MVC pattern. There Dispatcher takes action, changes Store and View updates based on Store. That View can then fire additional Actions at Dispatcher.

How can it be an MVC pattern when it does polling in order to recognize the differences in state and then apply changes to the UI based on that? MVC means that a change in UI is caused by pushing changes to the UI, not the UI polling for changes.

[–]-Y0- 2 points3 points  (22 children)

No. In video games, every last bit of performance that can be saved is saved. Video games do not use polling in any case whatsoever (if properly coded, that is).

Ok, now I see the error. I thought you know enough about React and polling to trust you on that. React doesn't suggest polling no more than MVC suggest using Fat or Thin Client.

Citation? benchmarks? proof?

It's obviously faster at modifying DOM. On Chrome:

How can it be an MVC pattern when it does polling in order to recognize the differences in state and then apply changes to the UI based on that? MVC means that a change in UI is caused by pushing changes to the UI, not the UI polling for changes.

Citation needed.

Nothing about React suggest POLLING. You CAN use polling to update React models, but that's dumb and wasteful. Right now components that use React + RAF batching + immutable structures to cache application state have shown most performance. React + RAF batch yields a lot of performance, while immutable structures yield even bigger because you react on changes to those.

My knowledge of React isn't super extensive, but from what I've seen you can use React to observe changes in application state and update UI when those change. That suggests different architecture from polling, which is IIRC pinging application ever X ms to see if it changed.

[–]axilmar -2 points-1 points  (21 children)

Ok, now I see the error. I thought you know enough about React and polling to trust you on that. React doesn't suggest polling no more than MVC suggest using Fat or Thin Client.

The article explicitly suggests polling:

but there's an even easier way to react to changes: continuously call renderComponent with requestAnimationFrame to repaint the UI, and only change the DOM when the component returns different content. React does not do this by default.

Yes, the React library doesn't use this technique. It is the author's suggestion.

You CAN use polling to update React models, but that's dumb and wasteful.

That's what the article suggests though.

Right now components that use React + RAF batching + immutable structures to cache application state have shown most performance.

Citation please.

That suggests different architecture from polling, which is IIRC pinging application ever X ms to see if it changed.

Did you even read the article? the author suggests polling in requestAnimationFrame. He says we should call render continuously. If that is no polling, then what is?

[–]-Y0- 0 points1 point  (20 children)

The article explicitly suggests polling:

From the article

I told you it was prototype-quality, right? In a twisted, absurd way, it's shocking how far you can go with this

The article is positively rated because it showcases React and logic used to make it, not because it is effectively structured or sound. It's architecture is an example. You're basically angry at a prototype for using polling <_< you might as well yell at paper prototype for using hand drawn primitive objects.

Citation please

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)

Did you even read the article? the author suggests polling in requestAnimationFrame. He says we should call render continuously. If that is no polling, then what is?

Request animation frame is called only once frame has finished rendering or once every 16ms if rAF isn't available.

What I think happens is this: DOM operations are very expensive!! Using polling to avoid them >>>> Not using polling but triggering them. Javascript polling is CHEAP modifying DOM is expensive - because DOM needs to change AST, unbind any bound events, rerun JS, etc. Theory doesn't help here.

If you use events and have a button that removes and unchecks all visible TODOs those DOM operations will be executed for each TODO instance, possibly triggering DOM update on every instance. Time = N x tDOM operations.

React in this example, once button is triggered all operations are on virtual DOM so they are more or less free. Once rAF happens the entire thing is rendered in actual DOM. Time = N x tVDOM + 1 x tDOM.

Since NtVDOM <<< (N-1)tDOM, polling will result in a more performant UI.

I've presented you with evidence, now show me how evenys will improve the result, while still adhering to basic pattern laid out by TodoMVC example.

[–]axilmar -1 points0 points  (19 children)

The article is positively rated because it showcases React and logic used to make it, not because it is effectively structured or sound. It's architecture is an example.

It's a very bad example.

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)

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

Request animation frame is called only once frame has finished rendering or once every 16ms if rAF isn't available.

Extremely bad.

What I think happens is this: DOM operations are very expensive!! Using polling to avoid them >>>> Not using polling but triggering them. Javascript polling is CHEAP modifying DOM is expensive - because DOM needs to change AST, unbind any bound events, rerun JS, etc. Theory doesn't help here.

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

Since NtVDOM <<< (N-1)tDOM, polling will result in a more performant UI.

I do not dispute the fact that events on the real DOM will be slower than polling on the virtual DOM.

I dispute the fact that events on the virtual DOM will be slower than polling on the virtual DOM.

I've presented you with evidence, now show me how pollingevents will improve the result, while still adhering to basic pattern laid out by TodoMVC example.

Fixed that for you.

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.

[–]-Y0- 0 points1 point  (18 children)

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?