Статическая перезагрузка сайта

Современные принципы веб-разработки требуют не меньшего внимания от дизайнера, чем проектирование видимой части сайтов. Ежедневно встречая незнакомые термины, чувствуешь себя явно отстающим.

Это всегда заставляло меня думать: «Вот дерьмо, я же ничего про это не знаю, надо скорее учиться». Но этот момент всегда откладывался, так как реальной причины изучить всё не было. Единственное, что могло дать толчок — сделать что-то свое, без особой ответственности перед другими, ведь явно не всё получится сразу.

Последние 5 лет все сайты клиентов, которые делала наша лаборатория, мои личные проекты и сайты друзей — все работали на CMS разной степени сложности. При этом у них у всех была одна общая черта: функциональность была запредельно высокой и явно избыточной. Например, у Вордпресса есть стандартная возможность обновлять сайт через iOS приложение. Насколько круто бы это не звучало, сама идея абсурдна: я ни разу в жизни не испытывал необходимости написать пост, находясь вдалеке от моего ноута. Особенно, если речь идет о большой странице с картинками.

Вторая общая черта этих CMS: все они работали с базами данных, как правило, MySQL. Все страницы генерируются на лету, движок оборачивает содержимое шаблоном и показывает пользователю на сайте. Это занимает некоторое время. Все осложняется различными плагинами, часто плохо написанными, особенностями настройки W3 Total Cache и проблемами безопасности.

Я маньяк контроля

Основное, что подтолкнуло меня перейти на статические генераторы сайтов, это контроль. Попытка приручить контент, обернутый петлями CMS, функциями и кодом, который я не до конца понимаю да и вовсе не писал, было пустой тратой времени. Сверстать шаблон для прошлого движка Эгея было пыткой: от версии к версии менялась внутренняя структура да и в целом существование проекта остается под вопросом.

Удовольствия это не приносило никакого и я забросил блог на год с лишним, даже не смотря на то, что под рукой теперь были инструменты для публикации в блог откуда угодно и в любое время. На выбор осталось 2 варианта: забросить все окончательно или построить систему с нуля, собственноручно, избавившись от всех ненужных свистелок и перделок.

Приручение Jekyll

Разбираться с базами данных и функциями вызова переменных не было никакого желания, делать разрозненные HTML-странички — тем более. Совершенно случайно под руку попался Cactus — предельно простой генератор статических сайтов, использующий язык шаблонов Jango. Но этот проект был слишком сырой и с мутными перспективами. Сложнее блога на стандартном макете или 2-3 страничек собрать в нем было рискованно: что-нибудь обязательно переставало работать или же требовало неординарных хаков.

На слуху был Jekyll, но он жутко пугал отсутствием интерфейса и массой незнакомых терминов. Но погуглив пару-тройку абстрактных вопросов относительно того, как в нём реализованы разные функции, сомнений не осталось: у джекила огромное сообщество, великолепная документация и мощная поддержка авторов проекта.

Теперь для публикации поста или страницы нужно:

Создать текстовый файл с разметкой Markdown.
Добавить YAML Front Matter заголовок в начало этого файла, в котором указано, какой шаблон использовать, мета-данные страницы (заголовок, время и дата создания), картинка обложки, категория и теги.
Запустить `jekyll` в терминале.
Загрузить готовый сайт на гитхаб.

Процесс может немного отличаться от раза к разу, но в целом это минимально необходимые шаги после того, как все шаблоны и блоки в `_layouts` и `_includes` сверстаны и подготовлены.

Процесс немногим более сложный, чем написание поста в Вордпрессе, ощутимо привлекательнее тем, что дает полный контроль над каждой мелочью. Я могу сам определить структуру сайта и папок, входящих в него; настроить иерархию; использовать любую автоматизацию, наподобие Grunt для оптимизации всего на свете и т. д. Разумеется, все это доступно практически в каждой CMS, но далеко не всегда так же прозрачно и часто требует кастомизации и дописывания кода для корректной работы.

Нельзя не отметить, что Jekyll — не для каждого. С ним непременно придется испачкать руки, разбираясь в формировании XML карт сайта, RSS, функции вызова социальных кнопок и куче других вещей, которые есть в Вордпрессе сразу из коробки. Но для меня изучение этих деталей и создание чего-то с нуля несло намного больше вдохновение, чем установка очередного плагина в Вордпрессе, который сделает все автоматически.

Jekyll помог мне достичь нескольких важных целей: плотнее познакомиться с базовыми принципами HTML5 и CSS3; дал возможность делать страницы с уникальным в рамках сайта дизайном и структурой; разобраться с CSS препроцессорами типа LESS и перестать теряться в гигантском файле стилей и сделать сайт адаптивным.

Что вдохновило в процессе

HTML5 Boilerplate

Одной из самых значимых вещей в процессе ознакомления с HTML5 было изучение HTML5 Boilerplate. Все файлы очень подробно прокомментированы, поэтому понять что, как и почему используется действительно легко. В качестве удобного справочника по элементам типа `figure`, `section`, `article` и т.д. я использовал HTML5 Doctor.

Less is More

Принцип препроцессоров отпугнул меня сразу, как только я впервые услышал про Less и Sass. Борьба с CSS в факультативном режиме и так довалась мне не легко, а внесение еще одного уровня сложности к этому казалось абсурдным. Вторым знакомством была попытка хотя бы поэкспериментировать с Less, тем более нашелся простой и наглядный инструмент — CodeKit. Принцип использования переменных для шрифтов и цветов выглядел привлекательно, но будучи дизайнером мне не сильно-то хотелось сталкиваться с это не-совсем-дружелюбной-средой из области программирования.

К моменту создания текущей темы оформления я перешел с Less на Sass, полюбил Bourbon ~~за название~~ а так же Neat для управления mixin’ами и сеткой.

Основная прелесть Less для меня — синтаксис. Можно даже ничего не менять в существующих css файлах, достаточно было изменить расширение файлов с .css на .less и все уже работало. Все новое можно внедрять постепенно. Использование переменных и миксинов помогает очень быстро собрать прототип страницы и позволяет мыслить модульно и комплексно.

Модульные сетки

Больше всего в модульных сетках меня отталкивает их антисемантическая структура. Я никогда не хотел дружить с абстрактными `.grid_x`, .`push_x` или `col_x`. Это здорово для больших проектов, быстрого прототипирования или разработки, но в своем проекте хотелось обойтись ванильным css. Не сказать, что это получилось идеально, но благодаря ряду статей и проектов задел на будущее сделан.

Перезагрузка проекта

Переход на Jekyll подтолкнул меня к полной реструктуризации сайта. Я буду стараться писать большие и цельные статьи в блог, с нормальным оформлением, а мелкие заметки, цитаты и картинки переедут на отдельную страницу или в свой раздел.

Что осталось доделать

Перенос постов из прошлого движка наконец-то завершен, в чем мне сильно помог Автоматор в OS X. Хоть записей в блоге не так уж и много, но заполнить для каждого имя файла и 5-6 полей в YAML-заголовке — ужасная рутина. Многим не хватает новых элементов, которых не было в прошлом шаблоне: обложки и превью страницы; большого количества новых блоков верстки типа сносок и так далее.

Адаптивная графика

Отдельным пунктом стоит доработка и оптимизация картинок. Если остальные составляющие оптимизированы худо-бедно, то с картинками придется основательно потрудится. Сейчас они оптимизированы алгоритмами сжатия без потерь, что экономит до 60% веса файла, но все равно загружаются в полном масштабе. Научить Джекилл нарезать их для в разных размерах для десктопов и смартфонов еще предстоит и будет очень не просто, так что этот пункт задвинут в самый конец очереди.

Контроль версий

Выкладывать исходники сайта в открытый доступ пока не хватает духу, ребята засмеют же. Так что для контроля версий я использую приватный репозиторий на BitBucket, в то время как сайт публикую на GitHub. Такое разделение позволяет познакомиться с системами более плотно и выбрать более удобную, раз уж они обе поддерживают бесплатный хостинг статических сайтов.