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.
2) "Basecamp isn't a trivial one page app; it has over 200+ screens." I didn't say it was. Read again. However, Basecamp IS written in such a way as to heavily rely on Turbolinks.
3) "For page changes, CSS is generally scoped by controller action classes. Quick look up by the browser, penalty negligible." Not in our tests with Rails 4.2.
4) "All of the JS is loaded." Yep. The rest of your sentence is not relevant to my point.
You seem to think my objection was that there is some kind of difficulty accessing specific CSS/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.
Obviously that can be compensated for by scoping. That wasn't my point. The point was that IT WORKS DIFFERENTLY THAN THE STANDARD CSS HIERARCHY. Understand?
"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."
There are times when that is desirable over having that CSS and JS always loaded. I get that you don't seem to be able to think of any, but we've encountered many.
I'm not going to get into an argument with you here about which is "better". Which you seem to want. I simply said there are use cases that are appropriate to each.
2) "Basecamp isn't a trivial one page app; it has over 200+ screens." I didn't say it was. Read again. However, Basecamp IS written in such a way as to heavily rely on Turbolinks.
3) "For page changes, CSS is generally scoped by controller action classes. Quick look up by the browser, penalty negligible." Not in our tests with Rails 4.2.
4) "All of the JS is loaded." Yep. The rest of your sentence is not relevant to my point.
You seem to think my objection was that there is some kind of difficulty accessing specific CSS/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.
Obviously that can be compensated for by scoping. That wasn't my point. The point was that IT WORKS DIFFERENTLY THAN THE STANDARD CSS HIERARCHY. Understand?
"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."
There are times when that is desirable over having that CSS and JS always loaded. I get that you don't seem to be able to think of any, but we've encountered many.
I'm not going to get into an argument with you here about which is "better". Which you seem to want. I simply said there are use cases that are appropriate to each.