Средства контроля качества кода
В общем-то, при написании кода HTML и CSS прощаются многие огрехи. Можно просчитаться с количеством вложенных элементов, забыть поставить кавычки или слеш в самозакрывающемся теге и при этом даже не всегда заметить какие-либо проблемы. Несмотря на это, мне чуть ли не еженедельно приходится сталкиваться с собственными просчетами в разметке. Иногда это ляпы вроде опечаток. А иногда школярские ошибки типа вложения div в span (разметка, при которой элемент блочного уровня div попадает в линейный элемент span, приводит к непредсказуемым результатам). К счастью, нам в помощь разработаны специальные инструментальные средства. В худшем случае, если возникли проблемы, обратитесь по адресу http://validator.w3.org/ и вставьте на этот сайт свою разметку. В результате будут помечены все ошибки и получены номера их строк, что существенно облегчит их устранение.
А еще лучше установить и настроить средства контроля качества вашего кода HTML, CSS и JavaScript. Или же выбрать текстовый редактор с определенным уровнем встроенной проверки правильности кода. Тогда по мере набора будут сразу же обозначаться проблемные области кода. Посмотрите на пример простой ошибки в написании кода CSS, которая сразу же была замечена редактором кода от компании Microsoft.
Я специально набрал widtth вместо width. Редактор это заметил и указал на ошибку, предлагая при этом ряд вполне разумных альтернатив. По возможности нужно пользоваться именно такими инструментальными средствами. Лучше потратить время на их подбор, чем на выискивание простых синтаксических ошибок в своем коде.
Производительность
Наряду с эстетическим восприятием не менее важно рассмотреть вопросы производительности своих адаптивных веб-конструкций. Но производительность представляется чем-то вроде движущейся цели. Например, браузеры обновляются и улучшают способы обработки ресурсов, взамен существующих оптимальных методов разрабатываются новые технологии, получающие со временем достаточный уровень браузерной поддержки и становящиеся на путь широкого внедрения. И этот перечень можно продолжить.
Но есть некоторые базовые особенности реализации, остающиеся практически неизменными (по крайней мере для большинства из них до широкого внедрения HTTP2 все останется как есть). К ним относятся следующие.
1. Сведение к минимуму количества ресурсов (например, не загружайте 15 файлов JavaScript, если объединяете их в одно целое).
2. Максимальное облегчение страницы (если есть возможность сжать изображения, значительно уменьшив их размер по сравнению с исходным, то так и нужно поступать).
3. Отсрочка загрузки второстепенных ресурсов (если можно отложить загрузку CSS и JavaScript до вывода страницы на экран, это может существенно улучшить восприятие скорости загрузки страницы).
4. Обеспечение как можно более ранней возможности использования страницы (обычно соблюдение этой рекомендации является побочным продуктом выполнения всех предыдущих).
Имеются также весьма эффективные средства для определения уровня производительности и ее оптимизации. Лично я предпочитаю пользоваться сайтом http://webpagetest.org/.
В наипростейшем варианте набирается URL-адрес и делается щелчок на кнопке START TEST. Сайт покажет полный анализ страницы, но, что еще полезнее, он покажет раскадровку страницы по мере ее загрузки, позволяя сконцентрироваться на как можно более быстром завершении вывода страницы на экран.
На следующей странице показано, как выглядит раскадровка загрузки главной страницы сайта BBC.
Перед попыткой оптимизации производительности нужно обязательно провести количественные измерения, иначе вы не сможете понять, насколько эффективной была работа по повышению производительности. Затем нужно внести поправки, выполнить тестирование и повторить цикл.
В преддверии великих перемен
Одно из обстоятельств, повышающих интерес к разработке веб-интерфейса, заключается в работе в условиях быстрых перемен. Всегда есть что-то новое для изучения, и веб-сообщество всегда придумывает способы, как при решении тех или иных задач все улучшить, ускорить и сделать намного эффективнее.
Например, за три года до выхода данного издания книги адаптивных изображений (получаемых с помощью атрибута srcset и элемента picture, подробно рассмотренных в главе 3) не было и в помине. Тогда, чтобы получить более подходящие для окон просмотра различных размеров изображения, нам приходилось пользоваться хитроумными обходными средствами от сторонних разработчиков. Теперь же, когда эти насущные потребности нашли свое отражение в стандартах W3C, мы можем с удовольствием пользоваться стандартными средствами.
Аналогично этому не так давно Flexbox еще только мерещился тем, кто создавал спецификацию. И даже по мере развития спецификации ее реализация давалась с большим трудом до тех пор, пока Андрей Ситник (Andrey Sitnik) и такие же умные, как он, ребята из Evil Martians (https://evilmartians.com/) не создали Autoprefixer, после чего мы смогли с относительной простотой воспользоваться кросс-браузерным кодом.
В будущем нам предстоит осваивать еще более захватывающие возможности. К примеру, в главе 4 уже упоминалось средство Service Workers (http://www.w3.org/TR/service-workers/), предоставляющее один из лучших способов создания приложения на основе веб-технологий, способных работать в автономном режиме.
Есть также Web Components — коллекция стандартов, составленная из Shadow DOM (http://w3c.github.io/webcomponents/spec/shadow/), Custom Elements (http://w3c.github.io/webcomponents/spec/custom/) и HTML Imports (http://w3c.github.io/webcomponents/spec/imports/), которая позволяет создавать полностью предсказуемые и многократно используемые компоненты.
На подходе и другие более совершенные средства вроде CSS Level 4 Selectors (http://dev.w3.org/csswg/selectors-4/) и CSS Level 4 Media Queries, частично рассмотренные в главе 2.
И наконец, на горизонте забрезжили еще более грандиозные перемены, связанные с появлением протокола HTTP2. Он обещает все, что сейчас считается передовыми наработками, просто выбросить на свалку. Чтобы получить о нем более глубокое представление, предлагаю прочитать заметки Дэниела Стенберга (Daniel Stenberg) о том, что такое HTTP2, свободно распространяемые в PDF-формате. Или же в качестве краткого обзора прочтите великолепную статью Мэтта Уилкокса (Matt Wilcox) HTTP2 for front-end web developers (https://mattwilcox.net/web-development/http2-for-front-end-web-developers).
Резюме
Поскольку время нашего с вами общения подошло к концу, ваш покорный слуга, он же автор этой книги, надеется, что теперь в вашем распоряжении имеются все технологии и инструментальные средства, необходимые для того, чтобы приступить к разработке вашего следующего сайта или веб-приложения в адаптивной манере.
Я убежден, что расчетливый подход к веб-проектам наряду с внесением ряда изменений в существующие рабочие процессы, сложившиеся методики и технологии позволит вам создавать адаптивные веб-конструкции, обеспечивающие сайты с высокими показателями скорости работы, гибкости и легкости в поддержке, у которых будет потрясающий внешний вид независимо от устройств, с которых их будут посещать.
За время, проведенное вместе, мы охватили весьма обширный объем информации, рассмотрели методики, технологии, способы оптимизации производительности, спецификации, основы организации рабочего процесса, вопросы применения различных инструментальных средств и многое другое. Я не думаю, что кому-то удастся все это усвоить за один присест. Поэтому, когда в следующий раз вам нужно будет вспомнить тот или иной синтаксис или освежить в памяти что-либо относящееся к рассмотренным в книге приемам разработки адаптивных конструкций, я надеюсь, что вы снова вернетесь к углубленному изучению материалов, изложенных на ее страницах. Я же здесь буду ждать вашего возвращения.
А пока желаю вам удачи на вашем нелегком, но увлекательном пути разработки адаптивного веб-дизайна.
До новых встреч.