Юрий Ярош

Популярность JavaEE в современных проектах стремится к нулю - большая часть существующих фреймворков отказываются от сервлетов и "ынтерпрайсностей" в пользу ванильной Java с Netty, и тому есть довольно много причин. Ну, хотя бы намного более высокая производительность, по моему личному опыту где-то 1:30. Из исключений припоминаются Grails, Ninja framework. Есть ещё динозавры типа Struts и Wicket - их часто используют "по привычке" вместе со Spring'ом, но практической выгоды от подобного не много. В общем у всех есть свои причины "ынтерпрайстности", но по большей части это связано с "бюрократией" контор-разработчиков.

Стоит познакомится с Vert.x и ratpack.
Play2 - тоже хорошо, но наблюдается значительный overhead из-за использования Akka + Scala.
Стоит разобраться с GraphQL и Relay + React. Ну и поиграться чуток с Meteor + React.
На определённом этапе нужно реализовывать свой собственный транспорт для EventSource, я как раз собираюсь этим заняться в свободное время.

Можно рендерить в браузере, либо фильтровать.
Никто не мешает делать вот так

<b style="width:expression(alert('bad style!'))"> \o/ </b>

Так что, чаще всего, кастомные стили тоже напрочь выпиливают.
Хотя, после CSS кейлоггеров в скроллбарах и в SVG'шках, я уже мало чему удивляюсь.

Я сам хочу разобраться с проблемой отсутствия нормальных полифилов для относительных величин, с учётом изменения размеров и переопределением пиксельной сетки.

Вот тут достачно порезать тостер jsfiddle.net/x7ztp5vd
#toster {
width: 293px;
height: 301px; -> 300px;
}

Так как у нас берётся 25% то при масштабировании получается 1/4 пикселя которая округляется в меньшую сторону и даёт "пробел".

Проблема в подборе размеров для элементов, что бы при округлении оно всё хорошо влазило в пиксельную сетку браузера и не давало подобных артефактов. Этим грешны все существующие относительные величины в вэбките :(

p.s. если будет желание заняться разработкой полифила - пишите в скайп.

Есть самописные polyfill'ы на Intl vmin vmax и rem'ы, но поддерживаю ie9+.

Тут всё сложно...
Нужно прикрутить сборку на gulp, с использованием csslint. Препроцессоры нужно использовать по шустрее, желательно postcss или stylus, sass/scss довольно медленные. ~4000 это очень много, ~1000-1500 потолок Нужно использовать относительные размерности, vmin, vmax, и rem, для осликов и iOS7 есть нормальные polyfill'ы. media-queries там тоже получаются довольно специфические, но все выводятся по формулам и оформляются в виде одного mixin'a. Одним из главных критериев качества разметки является количество div'ов на странице - уж больно сильно людей тянет на дикие раздувательства, но не зря же в html5 добавили тучу тэгов для упрощения структурирования контента, а для сss'a обычно достаточно селекторов из двух элементов, что бы не раздувать CSSOM и упростить рендер. Тестировать это всё дело можно в galen и browserstack.

Вообще вопрос QA в вёрстке сейчас довольно проблематичен - в постсоветском его почти нет, а всплывает чаще всего только во всяких забугорных lean стартапах, у которых есть деньги на наукоёмкие решения и их анализ.

Отзывчивость - изменение размеров под конкретное расширение, это горизонтальные ритмы в % и вертикальные в em'ах rem'ах, или любых других относительных шрифтовых размерностях.

Адаптивность - изменение позиционирования и формы каждого конкретного элемента с возможной заменой другими.

Есть display: table, display: table-cell, display: table-column, display: table-row их можно использовать для того что бы сделать из div'ов (или ещё чего-нить) табличку.

Количество колонок которое целесообразно отображать зависит от текущей ориентации дисплея.
Обычно для портретной ориентации это 2-3 колонки, а для альбомной 4-5.

На телефонах лучше всячески избегать табличек и откатываться к спискам.
На планшетах возможно построение таблички, но обычно просто сам список выводят в 2-3 колонки.

Адаптивность реализовывается посредством media queries.

Желательно использовать препроцессоры с миксинами для упрощения генерации под весь набор расширений.