Действительно, какая-то дичь. Ежели ты используешь Chrome Devtools, то там есть вывод размера вьюпорта (при эмуляции устройства и если двигать ползунок панели), зачем его скриптом ловить — для меня секрет.
Дальше в комментариях верно отметили про стандартные разрешения — можно взять за референс популярный Bootstrap и повторять его breakpoints до того, как начнешь понимать, что к чему.
Естественно, это не убережет от косяков, ибо да хотя бы пользовательский ввод. Или самое косячное — навигация в шапке. Постоянно с этим сталкиваюсь, особенно при введении новых элементов (сейчас у меня на сайте, к примеру, ни в п... короче ни к месту форма входа, правда ее там никогда и не было). Я к тому, что дизайн в любом случае при некоторых масштабных введениях приходится переделывать. А чтобы максимально избегать провисов между популярными viewport-ами, достаточно осваивать переносы и обрезку контента. Если позволяет условия, конечно.
Например у флексов есть свойство flex-wrap:wrap, а гриды так вообще супер, можно указать минимальный размер для переноса и он будет работать не как в обычных блоках + зависимость от контента. Но, к сожалению это работает по сути только в списках, при верстке специфического контента работают другие условия.
Ну и не забывай, что кроме точек перехода медиазапросов, есть еще и другие свойства, которые можно комбинировать, например ориентация устройства.
PS: чтобы тестировать, как мужик открывай эмулятор и дергай ползунок, прокручивая страницу. Где-то поехало — переделывай). А потом лови лучи боли от IE, в котором забыл оттестировать или Safari на iOS.
PSS: самое малое устройство за базу можешь взять 320 по ширине, а больше 1920. Если шире, то оптимально обернуть в контейнер отцентрированный.
