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.
Static typing is not a single issue. It is several.
From a high-level-language standpoint, static typing is a crutch. It isn't necessary, but it forces you to do things "the right way"... according to some definitions of the right way. It is possible to make mistakes without static typing that you would not make with it... but if you're careful you can also do some good things without it that you can't do with it. It all depends on whether you feel more comfortable with taking control or you feel the need for some restrictions to keep you "in line".
From a purely performance standpoint, there is no question: static typing compiles/interprets to faster code.
Same here. AFAIAC, the default Rails setup has been leaning more and more toward a Basecamp-specific kind of use case, rather than the generalized tool it started out to be.
Turbolinks messes A LOT with conventional design. Unless you really want the "one page" approach, or have a small, simple app or site -- or even if you just want to design a site using normal CSS conventions -- then Turbolinks gets disabled right away.
Fortunately, we can still do that. I can legitimately question the decisions made regarding default settings, but at least those settings can be changed.
Turbolinks is great for some use-cases (like Basecamp for example). But it is not for everybody. It absolutely sucks for other use-cases.
Among other things, since its inception it has messed with the CSS heirarchy, resulting in the fact that by default it loads all the CSS and JavaScript for all pages, in an order you probably don't want. (Note: there is a reason the "C" in CSS stands for "Cascading". It wasn't designed to all be loaded at once.)
If you DO want "one page apps", then fine. If you don't, and you have a significant site with more than a couple of dissimilar pages, it will probably be more performant if you disable Turbolinks and load only the JavaScript and CSS necessary for a given page, i.e., the conventional approach.
But if you have a beef with how much of the domain logic is in the Model, don't blame Rails, blame MVC. I mean, come on.
Either you want to use MVC or you want to go in a different direction. Fine. But don't blame Rails for being a good MVC implementation. Instead, formulate your own, new "philosophy" about how this all should work.
While I don't generally acknowledge the validity of "Before you criticize, think of something better", in this case I think it's appropriate. You appear to be critical of the whole MVC philosophy. And that's FINE. No problem. But before you go criticizing Rails I think you should formulate your own philosophy of how it all should work instead, rather than blaming Rails for doing what it is supposed to do, and doing it well.
But this isn't a failure of "DHH/Rails" philosphy, it's inherent in the MVC paradigm. If we're going to "blame" something, we should be a bit more careful about where that blame actually lies.
The disparity here is between the MVC paradigm and these "emergent" groups being discussed.
The problem is that they don't have a coherent solution. Rather, there are 100 little "solutions" running around with no central philosophy behind them. That's a Bad Thing.
The VALUE is not indirect (i.e., extrinsic). The METHOD OF MEASUREMENT is indirect. Those are two different things. One does not imply the other.
If I measure the "worth" of your automobile in units of "old Chrysler convertibles", that doesn't mean your automobile has any more or less economic value than if I measure it in helium balloons. The method of measurement (if it's done properly) does not affect the actual value.
In the case of Bitcoin, it CAN be traded directly for goods, not dollars. There is nothing REAL distinguishing it from any other commodity, such as rice. The value is roughly equivalent to the cost of production + distribution.
I take that back. There IS one difference, but (at this time) it is minor: that is the ultimately limited supply, but that isn't even remotely close enough yet to affect a RATIONAL market.
An EXTRINSIC value, on the other hand, and to use Wikipedia's example, is like the "value" of a song played on a guitar. It has its own subjective and economic values, but that is completely separate from the cost of manufacturing the guitar. This is NOT even remotely the same situation as Bitcoin.
But you CAN trade Bitcoins for things, not just currency.
You can trade Bitcoins directly for more hardware to mine Bitcoins. So it IS a reversible transaction, and Bitcoins are DIRECTLY (not indirectly) valued at approximately the cost of mining and distribution.
Don't confuse "indirect value" with "indirect measurement of value". They are different things.
The exhaust from your Chevy also doesn't have the "intrinsic worth" of the oil that it ultimately came from, either. Nor does the electricity from my solar cells have the "intrinsic worth" of the silicon they were made of.
So what? That is about the farthest thing from a valid analogy I've seen in a long time.
This isn't a failure of Bitcoin. It's a failure of the market.
Bitcoin has an approximate "intrinsic value", which in economic terms is a bit above the cost of mining. Current market price has been very far from that.
Bitcoin market right now is pretty much the definition of a bubble. Beware. In a "bubble" market, your money can disappear overnight.
But again: that's not Bitcoin's fault. It's the fault of idiots vastly and irrationally driving up market prices.
This is really a textbook lesson in why Wall Street does not represent the "real" exonomy.
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.