I like seeing articles like this. I would just point out what I think is a not-so-discussed aspect: The transition from layout-consideration to mobile-consideration, a real issue that was capable of turning every project into a mess of puzzling layout questions from the start. This has been and remains a huge energy-level blow to a design effort, if you are a layout-design-first thinker, or just feel like approaching a given project in that way.<p>The article seems to be rooted in this kind of design-first preference, and I don't see that as a huge problem, but it needs to be pointed out because a lot of us here on HN can swing both ways, so to speak--cover your economically-necessary base and go with the flow (see frameworks, below), or focus on beautiful creative design.<p>While this shift to accommodation of mobile device was troubling from a workload perspective early on, it soon became clear that if many / most of your audience were going to consume your content on a mobile, then there was a huge energy-expenditure incentive to focus on layouts that stack up, component-by-component. This became a strong hidden incentive for web designers to say, "I see your fancy designs but things like this need to be mobile-friendly or even mobile-first these days. Also, simplicity is going to be huge for a lot of different reasons." A big reason: If you color outside of the lines, you now have a huge number of ways and places in which you need to test and troubleshoot your layout.<p>So the economics of site design quickly shifted: Get a vertically-stacked, mobile-friendly site with a relatively boring layout and save money, OR go all sorts of creative with the layout and pay more by creating more of a fractal of work for yourself. Maybe you'd pay just a little more, but still: More--maybe more time, or more money, or both.<p>Eventually as this pattern locked into place, the broader "website creation economy" rediscovered a certain level of energy efficiency as frameworks and libraries were developed around the mobile-consideration standard.<p>And as it turns out, these frameworks and libraries now underwrite a specific, stacking-friendly, tech-first approach to design. If you don't want to work that way, you need to go looking in the manual or cross your fingers and spend some time with Google. Or you have to hire someone who does. Or you have to look at DIY platforms with other trade-offs, like fragile designs that stack up a huge load of technical debt over time, gradually introduce subtle design bugs, and then go unsupported.<p>IMO these various effects are a big contributor to what the authors discuss.