Stoyan Stefanov, a web performance engineer formerly at Yahoo, writes about JavaScript, CSS, PHP and browser rendering.
HN links it for web performance advice, including data URIs, MHTML for old IE, and JavaScript class patterns.
A few seconds of googling turns up these relevant articles on how browsers paint via GPU (which date back many years):
- https://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome
- https://www.urbaninsight.com/article/improving-html5-app-performance-gpu-accelerated-css-transitions
- https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-how-webrender-gets-rid-of-jank/
and also how they handle painting and redrawing in general:
- https://www.phpied.com/rendering-repaint-reflowrelayout-restyle/
- https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/
- https://james-priest.github.io/udacity-nanodegree-mws/course-notes/browser-rendering-optimization.html
So no, browsers don't "recompute the entire window". They know what DOM nodes have been mutated, and are able to fairly efficiently redraw just those pieces of the UI that have changed.
I haven't watched the video yet, but React's approach to defining UI structure and updates is considerably different than your typical desktop UI toolkit (ie, Swing, Windows Forms, MFC, Qt, etc). With those classical frameworks, you generally have a bunch of object-oriented class inheritance hierarchies and manually instantiated child widgets with specific parameters (`button.setWidth(80)`, `button.setPosition(20, 40)`, etc), then add a lot of event listeners to manually modify both the data and the UI.
As I previously mentioned, React expects to work with a "retained mode"…
Steve definitely kicked "high performance" into overdrive at Y!, but he's one of many people who have contributed from Yahoo:
Stoyan Stefanov write weekly about performance on his blog http://www.phpied.com/ and actually just released "Web Testing Framework" at Velocity which is a YSlow plugin.
Nicholas Zakas wrote "High Performance JavaScript" (http://www.amazon.com/Performance-JavaScript-Faster-Application-Interfaces/dp/059680279X) and does a ton of stuff for the Yahoo frontpage.
Phil Tellis (author of Boomerang) regularly blogs on performance on http://bluesmoon.info
I (sh1mmer) have done a bunch of performance related stuff with Aristus (now at FB) and I'm working on how network, consumer hardware and other holistic factors affect web performance. Expect some DNS related stuff soon.
I seriously doubt it. You only remove 1 extra request with this technique. The main advantage is that you don't have to maintain a sprite image (but using this without some tool would also be cumbersome).
IMHO one saved request isn't work doing the same thing twice. And MHTML (http://www.phpied.com/mhtml-when-you-need-data-uris-in-ie7-and-under/) doesen't come as a saviour either, as you have to duplicate all images in the CSS, which increases the size of the CSS significantly (if it doesn't you are probably better off using "old fashioned" techniques.
You can avoid the extra request for an image using a data URI - http://www.phpied.com/data-uris-mhtml-ie7-win7-vista-blues/
The main advantage of CSS is that you can change the color and appearance of components without using a graphics package, and they might scale better. But that's about it.
It was a technical exercise rather than a proof of concept. The icons themselves are very simple and limited. I wouldn't recommend using CSS in this way for production work (other than perhaps for very simple arrows).
I don’t know about the brain but it’s good for the final results in my experience coding, writing and composing (orchestral music). The results are better and it takes less time if I start with pen and paper before “committing” to the computer. One of my favorite authors Jennifer Egan also writes fiction on paper (non-fiction articles still on the computer). More thoughts: https://www.phpied.com/starting-in-the-analog-domain/
It's largely a matter of personal preference, but an important consideration is that using site.com will mean any cookies served from site.com will also be served on any subdomains. For more reading on the subject: http://www.phpied.com/www-vs-no-www-and-cookies/
"Basically you should always use www if you're planning to use any other sub-domains and you want them cookie-free."