Saleforce's problem is that its presentation layer is a giant pile of legacy code, which can be fundamentally changed, because there's a gazillion extensions and customisations that rely on it working the way it currently does. Having worked a bit with it, there's absolutely nothing about it that "benefits" developers, anymore than having to maintain a VB6 app "benefits" developers.
Done right, a modern web app should be better for both developers and users. The one benefit of the crazy shit described in the article is that if you don't weigh down your page with a multiple MB of ad-network and analytics scripts, then it can be incredibly fast.
> Done right, a modern web app should be better for both developers and users.
Right, and you also don't need to make a text-based site an SPA or use any frontend framework. The web was made for documents, so no need for those kinds of sites to be apps.
Salesforce uses a large quantity of DNS indirection, more than even the large CDNs. I measure the amount of lookups that sites and apps require, and the delay it causes. Most sites on the www only require two lookups.
This is perhaps an example of "... the benefits primarily accrue to the developers of the app and not to the customer."
SalesForce slowness does not equate to "all customers of web apps are getting a bad deal".
Go look at reelgood.com. Imagine if Salesforce worked like that. It should be clear as day that this is a SalesForce problem, not a modern-web problem.
When it's finally done loading, you click on a dropdown, and then the dropdown just shows you a loading spinner, as your client asks the server what should be populated in the dropdown menu. And of course it takes another second. Clicking virtually anything, including back (which should be instantaneous on a proper webapp), will present you with yet another loading spinner and a multi-second delay.
I understand the benefits of building webapps this way, but the benefits primarily accrue to the developers of the app and not to the customer.