Buy an iPad pro because time and time again we have seen that optimizing is not a priority for the majority of business.
I think the cynicism here is that if only these frontend developers would just learn to optimize we would all finally be better off. I think there are two factors that push against this though. First, if you learn to optimize then you can charge more for your labor, and you will likely get a job somewhere else. Second, companies exist for profit, and optimizing is not often the most profitable next step.
Amazon and Google have published a truly tremendous amount of data about how fraction-of-a-second differences in loading time can have outsized impacts on bounce rate. It continues to be amazing to me that so many businesses just completely fail at understanding this basic truth. Speed is a competitive advantage. Doubly so when many of your competitors don't realize it.
The catch is that you're looking at this through the lens of "comparison shopping between two user-facing apps", decided on by a random consumer out on the net. In that context, it's absolutely true. I personally experienced this with google vs. all of the other portal search sites like yahoo, excite, etc - google loaded much faster, and on my shitty 28.8 modem that was a matter of minutes, sometimes. So I switched to google.
The thing is - most web software isn't comparison shopped. It's developed on contract. I work at a company that does a lot of this, and, hypothetically, maybe we'd get hired to do an internal app for some retailer (imagine Best Buy or Walmart). When you build something like that, there's a gun to your head about time-to-deliver. They don't care if it's good — it's just got to meet a "reasonably decent" metric of quality. The only thing they really care about is getting it released on a certain timetable.
And all of this is because of contract law - timetables are provable breach-of-contract. You promised you'd make something by February, but you weren't done until April - that's something that's a provable failure-to-deliver. That's got financial penalties. But quality? Quality's gotta be astoundingly bad to be "provable". "Lag" or "the site's kinda slow" doesn't hold up in a lawsuit. (These things rarely lead to lawsuits, but do lead to 'punishment' by a refusal to renew a contract, knowing that the contractor can't sue the company because the contractor provably failed to deliver what was agreed on.) So they optimize for what's punishable according to the terms of the contract.
That's why all of this corporate enterprise software sucks - because nobody gets punished if it's slow or crappy; they just get punished if it's late, or if it's provably broken, because that's the stuff that's easy to pull out of a contract for.
You're not wrong, but if you're trying to view your local city hall meeting minutes or paying for your garbage bill, it's not like you can go somewhere else.
And it's true that the people paying for it could go elsewhere, but page performance probably weighs pretty low on that list.
I’ve talked to the Google people on these reports — the effect is real when the resulting page loads are under about 1.8s all in. No difference between 7s and 3s. Big difference between 2s and 1s. At least in eCommerce.
>> Second, companies exist for profit, and optimizing is not often the most profitable next step.
That's true and reasonable. And after this 5nm node, TSMC has 3nm and IIRC 2nm. We are at the point where throwing more hardware at slow software is becoming a non solution.
The good news is that in many cases there is a LOT of performance on the table on the software side.
The node size numbers have been made up for decades. Even if process shrinks bottom out two or three node shrinks from now there will still be improvements in process, materials, thermals, and packaging to allow things like greater z-axis stacking. And there's a ton of room for targeted improvement in things like vector instructions.
That's not to say that there isn't an enormous amount of improvement available in software. Projects like simdjson prove that there's a 2x or more improvement available for many high-performance use cases by migrating to vector instructions.
You don't even have to reach for SIMD to get better performance. Just stop letting crappy software get written.
I'm currently agonizing over an application that has an 80-120ms response time for 5 hops (including db writes). Yet I know many people who code in my language would find that number amazing for the work being done in those hops.
No SIMD. Nothing too crazy. Just well thought out processing flow and proper separation of the stupid.
I have an iPad using a four-year-old chip that's perfectly snappy. If this drift exists on iOS (it probably does) it is generally less pronounced compared to the life of the device.
I think the cynicism here is that if only these frontend developers would just learn to optimize we would all finally be better off. I think there are two factors that push against this though. First, if you learn to optimize then you can charge more for your labor, and you will likely get a job somewhere else. Second, companies exist for profit, and optimizing is not often the most profitable next step.