3

I grew up using JQuery and have been following a programming pattern which one could say is "React-like", but not using React. I would like to know how my graphics performance is doing so well, nonetheless.

As an example, in my front-end, I have a table that displays some "state" (in React terms). However, this "state" for me is just kept in global variables. I have an update_table() function which is the central place where updates to the table happen. It takes the "state" and renders the table with it. The first thing it does is call $("#table").empty() to get a clean start and then fills in the rows with the "state" information.

I have some dynamically changing data (the "state") every 2-3 seconds on the server side which I poll using Ajax and once I get the data/"state", I just call update_table().

This is the perfect problem for solving with React, I know. However, after implementing this simple solution with JQuery, I see that it works just fine (I'm not populating a huge table here; I have a max of 20 rows and 5 columns).

I expected to see flickering because of the $("#table").empty() call followed by adding rows one-by-one inside the update_table() function. However, the browser (chrome/safari) somehow seems to be doing a very good job of updating only that elements that have actually changed (Almost as if the browser has an implementation of Virtual DOM/diffing, like React!)

Forhad Ahmed
  • 1,761
  • 13
  • 18
  • You probably know: the big difference between kind-react-approach and real ReactJS or alike library - is the Virtual DOM presence; you can't do that with jQuery or alike. That makes React-like programming maybe better readable then typical jQuery code, but still it losses 90% of the react value with absence of VD – shershen Apr 15 '16 at 20:55
  • Thanks. Just to be clear, I'm not advocating JQuery over React. I was just very curious to know how the browser is achieving this "Virtual DOM"-like performance without React. – Forhad Ahmed Apr 15 '16 at 21:02
  • 1
    Rendering 20 rows with 5 columns without flickering isn't "Virtual DOM"-like performance, with such a small and simple dataset its just no big deal for a modern computer to handle it. – Karl-Johan Sjögren Apr 15 '16 at 21:04

2 Answers2

4

I guess your question is why you can have such a good graphics performance without React.

What you see as a "good graphics performance" really is a matter of definition or, worse, opinion.

The classic Netscape processing cycle (which all modern browsers inherit) has basically four main stages. Here is the full-blown Gecko engine description.

As long as you manipulate the DOM, you're in the "DOM update" stage and no rendering is performed AT ALL. Only when your code yields, the next stage starts. Because of the DOM changes the sizes or positions of some elements may have changed, too. So this stage recomputes the layout. After this stage, the next is rendering, where the pixels are redrawn.

This means that if your code changes a very large number elements in the DOM, they are all still rendered together, and not in an incremental fashion. So, the empty() call does not render if you repopulate the table immediately after.

Now, when you see the pixels of an element like "13872", the rendering stage may render those at the exact same position with the exact same colors. You don't have any change in pixel color, and thus there is no flickering you could see.

That said, your graphics performance is excellent -- yes. But how did you measure it? You just looked at it and decided that it's perfect. Now, visually it really may be very very good. Because all you need is avoid the layout stage from sizing/positioning something differently.

But actual performance is not measured with the lazy eyes of us humans (there are many usability studies in that field, let's say that one frame at 60 Hz takes 16.6 ms, so it is enough to render in less than that). It is measured with an actual metric (updates per second or whatever). Consider that on older machines with older browsers and slower graphics cards your "excellent" performance may look shameful. How do you know it is still good on an old Toshiba tablet with 64 MB graphics memory?

And what about scaling? If you have 100x the elements you have now, are you sure it will scale well? What if some data takes more (or less) space and changes the whole layout? All of these edge conditions may not be covered by your simple approach.

A library like React takes into account those cases you may not have encountered yet, and offers a uniform pattern to approach them.

So if you are happy with your solution you don't need React. I often avoid jQuery because ES5/ES6 is already pretty good these days and I can just jot down 3-4 lines of code using document.getElementById() and such. But I realize that on larger projects or complex cases jQuery is the perfect tool.

Look at React like that: a tool that is useful when you realize you need it, and cumbersome when you think you can do without. It's all up to you :)

pid
  • 11,472
  • 6
  • 34
  • 63
2

When you have something like this:

$("#table").empty()
           .html("... new content of the table ... ");

then the following happens:

  1. .empty() removes content and marks rendering tree / layout as invalid.
  2. .html() adds new content and marks rendering tree / layout as invalid.

mark as invalid among other things calls InvalidateRect() (on Windows) that causes the window to receive WM_PAINT event at some point in future.

By handling WM_PAINT the browser will calculate layout and render all the result.

Therefore multiple change requests will be collapsed into single window painting operation.

c-smile
  • 26,734
  • 7
  • 59
  • 86