Simple Starter - простой стартер для верстки | Материалы урока

Всем привет, друзья! Сегодня мы поговорим о новом стартере для верстки, который я подготовил для будущих уроков и проектов на CMS. В последнее время я все чаще ловлю себя на мысли, что современная коммерческая разработка стала слишком перегружена различными инструментами, сборщиками, менеджерами задач, зависимостями, пакетами и так далее. Думаю, пришло время упростить рабочий процесс. Действительно ли так важны те инструменты, к которым мы уже привыкли? Давайте разбираться.

Материалы урока и полезные ссылки

• Стартер на GitHub: Скачать
• Урок по настройке окружения: Ознакомиться
• Редактор кода: Visual Studio Code

Настройка Visual Studio Code

Файл > Настройки > Параметры. В правом верхнем углу окна редактора нажимаем иконку «Открыть параметры (JSON)». Мои настройки settings.json: Посмотреть.

Небольшая предыстория

Когда эра браузеров активно развивалась, не было каких-то общих стандартов, не было удобных универсальных возможностей, которые поддерживались бы всеми браузерами одинаково хорошо, стали появляться различные сборщики, бандлеры, препроцессоры, таск-раннеры. По большому счету, если посмотреть в саму суть всех этих инструментов – их задача состояла в том, чтобы расширить стандартные возможности и автоматизировать рутину по обеспечению кроссбраузерности. Например, CSS-препроцессоры дали возможность использовать переменные, создавать миксины (блоки часто используемого кода), импортировать стили, раздавать префиксы для устаревших браузеров и и.д.

Сейчас же огромное количество крутых фич поддерживаются браузерами нативно. По сути, в настоящее время абсолютно все браузеры работают на одном движке и отличаются разве что исполнением интерфейса и наличием дополнительных фич. Наступает эпоха нативной поддержки крутых технологий всеми браузерами в плюс-минус одинаковой степени. Этакая глобальная стандартизация. И это круто!

Следующий момент. Веб-разработку сейчас можно условно разделить на 2 категории – разработка SPA (Single Page Applications и подобных сервисов) и коммерческая разработка, где основной акцент делается на дизайн-решения, затем следует элементарная верстка и посадка на какую-либо CMS. И если мы говорим о коммерческой разработке (не о создании приложений, это важно), CMS сейчас имеют все необходимые возможности для оптимизации кода, изображений и прочих эссетов из коробки или посредством плагинов и дополнений. Кроме того, большинство CMS используют jQuery, и в какой-либо типизации JS-кода нет вообще никакого смысла. Конечно, можно адаптировать сложный стартер вроде OptimizedHTML 5 для той-же WordPress, переработав всю логику работы, которую предлагает CMS из коробки и даже прикрутить Vue.js и использовать CMS как headless, однако, смысла в этом нет, это попытка залезть на другую территорию. Кроме того, оптимизация должна происходить на стороне самой CMS и никак иначе. Плюс после передачи проекта, как показывает практика, поддержка работы Node.js-окружения после вас прекращается. Перекомпилировать тот-же Sass или JS никто не будет, проект просто будет обрастать костылями и переопределениями. Основной упор при использовании любой CMS должен быть на нативную реализацию возможностей по документации, что обеспечит долгую жизнь и безболезненное развитие коммерческого сайта.