Ehh. You should be constantly resizing your browser (as well as testing reloads at those sizes), while developing a design. Not least because people do resize

Ehh. You should be constantly resizing your browser (as well as testing reloads at those sizes), while developing a design. Not least because people do resize browsers on already-loaded pages, do tile views on their iPads, etc., and it is common-sense to deal with that. I mean this bit, for example: > Unintended reflows and re-renders > Narrowing the browser in complex UI with listeners also invokes reflows and re-renders which don’t represent the initial page rendering on device browsers. > If you’re using components with observers like ResizeObservers in carousels, you trigger events and side effects that would otherwise not happen if a user initially loaded the page on a mobile device. Sure. Is it a good substitute for mobile testing? Not specifically. And it's not a great substitute for orientation-change testing. But the issues that come up need sorting, because people do resize windows! And simply reloading the page at that new size is going to help you find really quite a lot of low-hanging-fruit issues that would affect a mobile device loading that page on that fixed viewport. All the other stuff in this blog post is valid and important or essential, but it's meaningless unless you develop these instincts first. You build all that extra stuff on top of starting with a fluid design and then considering what limitations should lead you to adding responsive elements. This way, when you get to device-oriented or device-specific testing you have much less to do, because your build is constructed around being size-agnostic. There's not only no shame in designing without specific device optimisations (like viewport-height stuff) in mind -- it may be the only really meaningful way to design for the web now, when you have no hope of testing even a fraction of the device types out there. Exhaustively testing in BrowserStack or even the Chrome or Safari dev tools is a hiding to nothing. These tools are useful but they are creating busywork and a dependency. You have to design and build in a way that gives you fundamental confidence that you understand how your design might react, and that means embracing the idea that strong flexible design principles, relatively conservative designs, and actual physical device testing on the most commonplace devices or your target devices are the only things that will keep web development sustainable. (This blog post is a bit of a listicle which seems to have been written to justify its silly clickbait headline. Which is a shame because there's useful information in it.)