Not to downplay the potential usefulness of some of these, but some of the reasoning for them that is presented is making some assumptions about how the Javascr

Not to downplay the potential usefulness of some of these, but some of the reasoning for them that is presented is making some assumptions about how the Javascript is done, and those assumptions might not be true. JavaScript can load just as fast as CSS etc if done carefully. If you really want to, you can put some JS right in the HTML file, immediately following the elements it is going to operate upon, changing the display of the elements before they are even rendered to the screen. Users will experience no delay (or flashing) at all. Whether or not that is considered good practice is another matter, but it most certainly is possible to eliminate the delay that is discussed in the article without abandoning JavaScript approaches. The problem is when people require a big framework be loaded just to do simple things. Or, I guess they write JavaScript that is so complicated that it causes a noticeable delay simply due to loading the massive code. But that is an awful lot of code. The examples given would never need more than tiny amount of JS code. There are other reasons, of course (people who turn off JS still exist, I'm told), but as someone who simply knows JS well but doesn't know nearly as much about CSS (which has far too many surprises and special cases for my liking), I tend to be of the "if all you've got is a hammer, everything looks like a nail" mindset. So I'm unlikely to figure out how to do something in HTML/CSS if I can do it instantly in JavaScript. (obviously I do regular styling in CSS.... I'm talking about the more advanced stuff as per the article) That's just my reality, right or wrong.