"You can write shit, unmaintainable code in anything, but to point at pjax and granular key-based caching schemes as somehow specifically prone to this? What? That doesn't make any sense to me."
To take things to the extreme, if you chose to write Basecamp Next in pure x86 assembly (for speed, of course), I think we'd all agree that the code would be much more prone to maintainability problems. Similarly, it is plausible that choosing to write Basecamp Next entirely with pjax+backend MVC+granular key-based caching could be more prone to maintainability problems. Not that I have any particular reason to believe it will, but we're wondering if there are any particular reasons you believe it won't?
Because neither of those elements have any bearing on maintainability beyond what is customary for a Rails application. The wonders of pjax is that it doesn't require you to change your application style and structure at all, so it has zero impact on maintainability.
The granular caching scheme is similarly just a fragment caching setup using key-based expiration. Nothing new here, just that we used it to full effect.
So you're free to claim that writing Ruby on Rails applications are somehow inherently hard to maintain, but you'd be fighting against 8+ years of evidence to the contrary. Versus, you know, a very short amount of comparable evidence for JavaScript MVC applications based on current, recent frameworks.
To take things to the extreme, if you chose to write Basecamp Next in pure x86 assembly (for speed, of course), I think we'd all agree that the code would be much more prone to maintainability problems. Similarly, it is plausible that choosing to write Basecamp Next entirely with pjax+backend MVC+granular key-based caching could be more prone to maintainability problems. Not that I have any particular reason to believe it will, but we're wondering if there are any particular reasons you believe it won't?