1) The use-cases in which not all JavaScript or CSS is (or should be) loaded up front. There are many such. You should be able to think of several just off-hand. I can.<p>2) &quot;Basecamp isn&#x27;t a trivial one page app; it has over 200+ screens.&quot; I didn&#x27;t say it was. Read again. However, Basecamp IS written in such a way as to heavily rely on Turbolinks.<p>3) &quot;For page changes, CSS is generally scoped by controller action classes. Quick look up by the browser, penalty negligible.&quot; Not in our tests with Rails 4.2.<p>4) &quot;All of the JS is loaded.&quot;  Yep. The rest of your sentence is not relevant to my point.<p>You seem to think my objection was that there is some kind of difficulty accessing specific CSS&#x2F;JavaScript under Turbolinks. Nothing of the sort. Rather the opposite, really: it was that there is too much loaded, specifically in ways that disrupt standard CSS hierarchy.<p>Obviously that can be compensated for by scoping. That wasn&#x27;t my point. The point was that IT WORKS DIFFERENTLY THAN THE STANDARD CSS HIERARCHY. Understand?<p>&quot;Weighed against the traditional: a full request to the server which includes a download of relevant CSS for the page, a download of relevant javascript for the page, parsing of that css, parsing of js, and then execution of that js.&quot;<p>There are times when that is desirable over having that CSS and JS always loaded. I get that you don&#x27;t seem to be able to think of any, but we&#x27;ve encountered many.<p>I&#x27;m not going to get into an argument with you here about which is &quot;better&quot;. Which you seem to want. I simply said there are use cases that are appropriate to each.