Nikita Prokopov is right. Performance matters. - It is a major part both UX and the utility of a program. The success of the iPhone is often attributed to desi

Nikita Prokopov is right. Performance matters. - It is a major part both UX and the utility of a program. The success of the iPhone is often attributed to design, but it was also really responsive, fast and simple in comparison to other smartphones. - We tend to do stuff to "fix" performance on top of things that make the whole system much more complicated and brittle. Caching is the best example here. Caching proliferates and adds complexity to every layer. Another one is adding more machines. Same story. - Programmer time is valuable. But how about reducing the complexity of a system and make it reasonably fast? Less failure modes means less worry and work. Fast feedback loops are absolutely _essential_ to keep a programmer in a productive flow. - It costs less. See the two points above. - It is enabling. There are things you don't even consider doing because everything is slow. You don't have enough currency in the form of time and cycles to do more. - It is not that hard. As described in the article, it is often just a matter of throwing stuff away that isn't needed. Start with less abstractions and "flexibility". Build something reasonable that cares somewhat about performance and you probably get orders of magnitude faster results. What hinders us? People introduced the joke of "just wait a year or two and it's faster" because hardware kept fixing bad performance. This is over. We're drowning fast hardware with slow software, quicker than hardware can keep up. Also many of the improvements are on the level of parallelization and caching. Programs need to be aware of that at some level. There is the famous quote "premature optimization is the root of all evil". I'm not talking about optimization here. I don't even know how to do optimization outside of trivial things. What I'm talking about is just removing or avoiding unnecessary cruft, and very basic efficiency. Overhead is not taken seriously. When I read comments like "IO performance dominates web apps" then I wonder if they have ever run a profiler. Do you really need to make that many db calls? Have you designed your data model with respect to access patterns at all, or did you follow some "Best Practices" modelling which is disjoint from what your app is doing? Is all that indirection necessary for you to write maintainable, concise code? Adding unnecessary cruft is endemic in web development and seems to be part of our culture. We're very much concerned with short term productivity and everything keeps changing quite fast. Part of this is businesses decision makers wanting to think of developers as interchangeable and development as a commodity. I disagree. I think there is a niche for web agencies that make simple, robust and performant things.