Earlier quoted context omitted.
Dan Luu's post, which I also read months ago, is very detailed, has a lot of data, but fails to make sense or come to a helpful conclusion in the end. Like so many of his posts. With helpful conclusion I don't mean just stating the facts or comparing transistors or input latency with network latency. As if developers stopped caring and created crappy software on purpose. The post compares an Apple 2e, which is a sing…
> But we know, that it's plenty of layers of GUI and OS code, that most people don't want to miss. You're missing the main point: you're just assuming that we must trade those features for improved latency, but this is just not true. The properties he measured are a result of particular architectural and abstraction choices, but other choices could be made that don't necessarily require such sacrifices. For instance,…
Unfortunately in IT you always trade one set of problems for another. And clean architectures have to be watered down with time to stay practical.
Nobody is smart enough to predict all pros and cons accurately. We're always smarter after the fact. When we have finished a transition and gained some experience with the new technology. But then it's mostly too late to go back.
On top of that, computing is always a moving target. Now you have to target highly mobile devices with small batteries traveling at high speed in metal tubes connecting to unreliable networks. While more or less related to keyboard input lag, depending on where the action should be registered, you have to be careful where you spend your development resources.
That's why I think this is an oversimplification. True in its deepest form, but neglecting reality.