Как выглядит современный процесс верстки?

Question

[Илья]

Добрый день!

Версткой впервые начал заниматься около 10 лет назад. Затем перешел в back-end, но продолжаю изредка заниматься front-end, поскольку искренне люблю этот процесс и легче работать с собственным кодом, чем с чужим.
Однако появилось понимание, что сильно отстал от реальности. Моя верстка аккуратная и рабочая. Но все делаю "первобытным" способом ))

Суть вопроса в том, чтобы получить советы от активных и актуальных верстальщиков по процессу верстки: какие стандарты используете, какие инструменты применяете, как выглядит рабочая область и как проходит рабочий процесс?

Для сравнения, сам я до сих пор верстаю следующим "дедушкиным" способом: создаю папочку с файлами index.html, style.css, script.js, каждый открываю в редакторе (простеньком) и пишу код. Макет смотрю в Photoshop. Недавно освоил XD. Также использую Emmet. Все, больше ничего.

Можно ответить на вопрос жесткой критикой моего подхода с предложениями альтернативы (во всех аспектах). Это будет здорово.
Хочу, чтобы мой вопрос и множество ответов помогли другим верстальщикам (например, новичкам) с первых шагов правильно войти в современную отрасль.

Comments

[Владимир Проскурин]

Возможно будет полезно Верстка с нуля: какие основные этапы работы?

[Илья]

Владимир Проскурин, просто бесценная информация! Всем рекомендую к прочтению топик по указанной выше ссылке.
Сполна отвечает на мой вопрос.
Лично от себя: интересно было бы взглянуть на стрим Вашей работы.
Также, даже после поверхностного просмотра топика есть моменты для дискуссии.
Благодарю за ссылку!

Answer 1

[coderxx]

Не уверен что начинающим верстальщикам нужно заморачивать себе голову всем этим ужосом:) Но может кому-то и пригодится:
- создаю новый проект на базе немного допиленного Optimized4HTML (можно копировать папку руками, можно сохранить в PhpStorm как темплейт, второе разумеется удобнее). Проект имеет следующую структуру:

- открываю его в PHPStorm, через командную строку устанавливаю пакеты и запускаю вотчер со следующей конфигурацией:

(таким образом отслеживаются изменения в файлах index.html, *.scss, common.js, а так же релодится браузер; в процессе верстки просто перескакиваем на виртуальный рабочий стол с открытым сайтом и сразу видим изменения, а если есть второй монитор то вообще песня). Кстати, перечень пакетов ннада?

- из плюшек emmet и sass обязательно, в качестве таскранера - gulp.
- макеты у меня в .sketch, так же кто не пробовал советую попробовать Figma, получите практически скетч в браузере. Adobe Photoshop не люблю. Adobe XD не пробовал, но осуждаю. Здесь наверное больше дело вкуса и реалий, в которых вы работаете (например, в каком формате получаете макеты, какая ОС на рабочем компе).
Вроде все просто. Что непонятно - спрашивайте, отвечу.

UPD. Optimized4HTML недавно перешел на Gulp 4, советую попробовать. Учтите, что Gulp 4 не имеет обратной совместимости с галпфайлами предыдущей версии, так как немного изменился синтаксис.

Comments

[Илья]

Полезный ответ. Спасибо, что поделились опытом!

[coderxx]

Илья, не за что:)

[Александр Талалаев]

А чего тогда не WebStorm?

[coderxx]

Александр Талалаев, чтобы была поддержка PHP

[Alexander]

современный процесс верстки

gulp разве современный инструмент ?

[coderxx]

Alexander, мне норм

[Александр Талалаев]

coderxx, ну мне кажется для верстки/фронтенда лучше вебсторм(а нет, вижуал студио код). Но конечно же если активная разработка с пхп нечего плодить сущности.

[Андрей Саныч]

Александр Талалаев, для справочки: WebStorm + PHP support = PhpStorm

[Александр Талалаев]

Андрей Саныч, ну это понятно. Я больше в контексте производительности.
Ну может это мои личные мыши в голове, но я в целом не сильно удовлетворен скоростью работы их IDE, поэтому парюсь из-за лишних плагинчиков.
PS хотя это говорит человек у которого установлен Nyan Progress Bar (-:

Answer 2

[HamSter]

Меня, вероятно, закидают тапками, но я так же как и Вы и как Юпитер Макс верстаю старым дедовским методом)

Но есть и и другие современные методы.

+ С помощью сборщиков: gulp (уже устарел) , webpack.
Быстро собирают все файлы, минимизируют css\js файлы, оптимизируют картинки, установка необходимых бибилиотек и прочее.

+ С помощью препроцессоров: css - sass\scss\less, html - pug.

+ С помощью js фреймворков: vue, react, ...

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

Препроцессоры, как по мне, тоже не совсем удобные инструменты. Автопрефиксы есть в emmete любого редактора кода, т.е. уже не нужно писать\вставлять дополнительные sass\less ф-ии и прочие возможности препроцессора (миксины, экстенды, переменные, ... ) проще и быстрее написать ручками простым css)

Это все лично мое мнение.

Comments

[coderxx]

gulp (уже устарел)

ну воот...

[Илья]

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

[HamSter]

Илья, да, по всем пунктам целиком придерживаюсь того же мнения. Погоня за модой, некоторые пользуются сборщиками и для верстки лендинга, бывает это прихоть заказчика (типа это круто). Для больших проектов отправляются и исходники, либо как правило все заливается на гитхаб, а дальше уже бакенд стягивает с гитхаба, запускает npm i для установки всех компонентов и запуска проекта у себя.

[HamSter]

coderxx, webpack пришел на смену, но это не значит что gulp можно отбросить полностью, как вариант можно еще им пользоваться)))))))

[coderxx]

HamSter, ну слава богу:)

[Олег]

HamSter, Не правда webpack не может заменить gulp в принципе, потому что это разные инструменты для разных задач, gulp как был так и остался самым популярным таск раннером и для верстки подходит лучше, чем webpack.

[itsjustmypage]

HamSter, так вот кто перебегает с инструмента на инструмент только потому, что использовать его уже не модно. Gulp отличный таск раннер, но можно использовать и просто NPM скрипты. Webpack это другое.

[HamSter]

itsjustmypage, Олег, Gulp и webpack разные вещи?! Различия конечно есть, но для фронтенда вполне себе лучше уже чем gulp. Webpack намного быстрее и удобнее работает (лично у меня). А главное для js фреймворка gulp прямо в самый раз?)

[Flying]

HamSter Gulp - это task runner, он просто запускает задачи (без разницы какие) и выполняет их оркестрацию. Webpack - bundler, его принцип работы - построение дерева зависимостей модулей и пересборка их в bundles. Это в общем случае совершенно разные инструменты и они решают разные задачи, скорость работы здесь не имеет отношения к делу. Т.е. если для сборки необходимо выполнить ряд различных задач (возможно и не связанных непосредственно с кодом) то здесь лучше использовать Gulp, а если нужно как-то хитро перерабатывать исходные файлы - то webpack может быть более подходящим решением. Просто важно помнить что у них разные цели и, следовательно, сферы применения. Да и никто не мешает использовать их вместе, это отлично работает.

[HamSter]

Flying, спасибо, это как раз то что я хотела написать))))))

[Flying]

HamSter рад что помог :)

Кстати позволю не согласиться по поводу использования препроцессоров. У меня были проекты с 500-600кб CSS кода, поддерживать такой объём в maintainable состоянии без пре- или постпроцессора - довольно сложная задача. Кроме того препроцессор (к примеру Sass) существенно расширяет возможности для вёрстки, позволяет автоматизировать кучу рутины и добавить существенную гибкость. У меня буквально несколько дней назад появилась задача - добавить на сайт поддержку арабского языка. А это, если вы знаете, ещё и необходимость "перевернуть" весь сайт справа налево, сделать его зеркальную копию. При этом стили сайта занимают порядка 200кб. У меня базовое решение с использованием Sass уложилось в добавление пары функций, руками это сделать было бы существенно сложнее, а уж поддерживать в адекватном и синхронизированном состоянии - тем более.

[Владимир Проскурин]

HamSter, хотела или хотел? Просто интересуюсь.

[Максим]

Владимир Проскурин, hamster - это девушка ...Лена

[Сергей delphinpro]

Илья,

Илья Илья Автор вопроса
Я так понимаю, мне стоит еще учитывать, что, вполне возможно, все эти дополнительные средства разработки -- банальная погоня за модой.
Кроме того, я также думал о том, что все это нужно только для серьезных, масштабных проектов. Но вижу, как новомодные инструменты применяют даже для небольших персональных сайтов.
Еще волнует вопрос поддержки: конечный код становится негибким, поскольку зависит от исходников.

Неверное понимание. Любые средства разработки призваны ускорить и облегчить процесс. И совершенно не важно какого уровня проект верстается. Будь то одностраничник или интернет магазин. Тут нужно понимать, что сборка не пишется под каждый проект с нуля. У каждого разработчика есть в загашнике готовая, которая используется во многих проектах (возможно немного подпиливается под проект). Как минимум, css-препроцессор с библиотекой удобных миксинов, автопрефиксер, транспайлер babel->es5 и конечно browserSync ну никак не могуд быть лишними.

Ну и по поводу поддержки: тут два варианта - либо отдаете заказчику исходники вместе с билдом, либо настраиваете сборку так, чтобы она выдавала читаемые файлы (форматирование, без сжатия) и отдаете просто билд, который не составит труда изменять.
Если проект остается на поддержке у вас, то тут и вопроса не должно возникать - исходники у вас есть.

[Владимир Проскурин]

Сергей delphinpro, да, к тому же, в webpack очень удобно делить конфиги на файлы .Например scss.webpack.conf.js, less.webpack.conf.js, svg.webpack.conf.js, pug.webpack.conf.js и.т.д. и просто подключать их в главном конфиге. Таким образом вроде получается, что настроил один раз, но можешь кастомизировать под разные проекты разные штуки.
Всякие инструменты могут на первых парах лишь тратить время, а не экономить. Зато потом это в разы окупится.

[HamSter]

Flying, это было мое личное мнение, для простого сайта или лендинга все это дань моде, а не увеличение скорости размера удобства и прочего о чем тут так яро все пишут. Все это подходит для каких-нибудь глобальных веб приложений или проектов. Использовать препроцессор для лендинга значит в любом случае настроить хотя бы простой сборщик, пока настраиваешь теряешь время. )

[HamSter]

Максим Ленский, рассекретил меня))

[Максим]

HamSter, я не специально ..я любя :))

[Илья]

Сергей delphinpro,

Любые средства разработки призваны ускорить и облегчить процесс. И совершенно не важно какого уровня проект верстается.

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

[Сергей delphinpro]

Илья, только станок модульный, легко переконфигурируется, и включается одной кнопкой за 30 сек.

[HamSter]

Максим Ленский, только увидела со стека ушел полностью?

[Максим]

HamSter, да .... слишком много ставят минусы за просто так ... но там один из моих коллег .. правд он с гонором но однако ... есть ..мой акк у него ..я там не бываю уже , только здесь

[HamSter]

Максим Ленский, та да есть такие "товарищи" (((

Answer 3

[Юпитер Макс]

да полно пакетных сборщиков, но я к примеру до сих пор работаю так же как и вы. Никаких проблем это не создает. Главное, чтобы все работало. )

Answer 4

[Flying]

• Верстаю в PHPStorm (просто потому что ещё и работаю с backend кодом на PHP).
  
• Для написания HTML использую Twig (т.к. нравится синтаксис и можно потом без переделки использовать шаблоны на backend'е). Использование шаблонизатора для вёрстки сильно помогает если надо сверстать более 1-2 страниц
  
• Для написания стилей использую SCSS + свою библиотечку + несколько PostCSS плагинов.
  
• Макеты - в Photoshop, InVision или Zeplin, смотря в чём отдают.
  
• Для обычных картинок - Photoshop + оптимизаторы (optipng, pngout, guetzli, xat).
  
• Для SVG иконок - Inkscape + руки + svgo, а затем организовываю всё это через icomoon.io, оттуда можно получить либо иконочный шрифт либо запакованный набор SVG элементов.
  
• Для сборки проекта использую Gulp с набором различных плагинов, список могу дать отдельно если интересно.
  
• Саму структуру проекта обычно просто копирую руками из проекта в проект. Можно конечно сделать какой-нибудь плагин для yeoman или что-то подобное, но меня не ломает скопировать пяток файлов, да и задачи бывают разные - просто вёрстка или вёрстка сразу в контексте сайта.
  

Answer 5

[Dnebl]

https://github.com/tars/tars

Comments

[lloydbanks]

Поддерживаю tars. Детище 2gis, постоянно обновляется, адекватная человеческая поддержка, пользуюсь им уже 2 года.

Answer 6

[tyzberd]

я использую
zeplin, WebStorm.
git через VCS WebStorm, очень удобно.

из плагинов
browser-sync,
gulp-nunjucks-render,
gulp.spritesmith
gulp-sass,
gulp-sourcemaps,
gulp-css-urlencode-inline-svgs
gulp-autoprefixer

иконки почти все спрайтами в отдельном файле

<svg viewBox="0 0 100 100" class="icon shape-codepen">
  <use xlink:href="/images/svg-defs.svg#shape-codepen"></use>
</svg>

https://css-tricks.com/svg-sprites-use-better-icon...

еще недавно использовал Inkscape, что бы отредактировать svg с добавленными классами, illustrator почему то вырезает классы

Comments

[Илья]

Вот подтянулись еще технологии: Zeplin, Git, работа с SVG.
Спасибо, что поделились опытом!

[alex-1917]

Илья, к сожалению, проверили и новый айпад - также тормозит, если svg-картинок больше 20-30 на странице, размер не важен.
но вы продолжайте использовать SVG, ведь это так удобно - поменять цвет/размер иконки за полсекунды и самое главное - это ультра-гипер-модно...
)))

[Илья]

alex-1917, прочитал и нахожусь в замешательстве от полученной порции сарказма. Ведь я не использую SVG ))

[alex-1917]

Илья, ну вам их насоветовали

[Олег]

alex-1917, Это проблемы айпада, а не SVG, точнее браузера на айпаде.

[Владимир Проскурин]

alex-1917, тут еще важна оптимизация. Иконка одним path будет в десятки раз быстрее рисоваться, чем иконка составления из кучи примитивов. Поэтому существуют всякие svg оптимизаторы.

[tyzberd]

alex-1917, не знаю, на айпад не могу проверить? но в остальных прекрасно работает 21 иконка через use. Иконки делаю все одним path.

[Rustam Bainazarov]

alex-1917, что-то у вас не то, открыл свой внутренний проект с порядка 90 ед. различной SVG-графики на iPad Air 2 (iOS 12.1), ничего не тормозит. И там не только иконки, но и парочка сложных иллюстраций.

[alex-1917]

SmthTo, без понятия, я отталкиваюсь от примерно от 18 таких проектов.
заменили все на png-спрайты, клиенты больше не орут.
вообще какой глобальный смысл svg, кроме моднявости, раскраски и ресайза?
эти три преимущества априори полный бред, если вы покажете мне проект, где надо менять цвет и размер иконок каждый месяц, я вам выплачу премию 100 бакинских...
естественно, проект должен быть рабочим, из сферы реального неубыточного бизнеса, а не сайт еще одной веб-студии.

[Rustam Bainazarov]

alex-1917, преимущества SVG:

1. В 98% случаев меньший размер типичных иконок без размытия (ну тут понятное дело, векторный же формат), чем те же PNG-файлы хотя бы 256 на 256 px и в indexed-цветах.

2. Спокойная inline-встройка кодом, что позволяет, к примеру, менять толщину начертания и цвет + убирает лишний запрос на каждую иконку и убирает возню со спрайтами (ну или же пользоваться use). Вы скажете, что можно в base64 сделать иконки, чтобы не было запроса, но декодирование base64 на стороне клиента — не такое быстрое занятие на слабых устройствах, как хотелось бы.

3. Можно анимировать.

P. S. Не знаю, как вы, я все проекты делаю в SVG (маски, декоративные элементы, иконки, шрифтовые иконки и т. п.). Разве что сложные иллюстрации перевожу в растровые форматы, если они изначально векторные и не оптимизированные. Проблем с SVG не имел, все проекты проверяю (если говорить о iOS) на реальных iPhone 5S, iPhone 7, iPhone X, iPad Air 2 и iPad Pro 12.9". Указанных выше проблем с производительностью не замечал.

[alex-1917]

SmthTo, собсно, подтверждение моих слов)))
и еще:

чем те же PNG-файлы хотя бы 256 на 256 px

некорректно. катастрофично некорректно.
иконка - это 16*16, 24*24, ну 48*48 черт побери.
256*256 ???!!!!???!!!????!

[Rustam Bainazarov]

alex-1917, зачем такие иконки, размер которых строго 16 пикселей, а иначе они пойдут пиксельной кашей? А если у вас есть потребность сделать их хотя бы по 50 пикселей? Будете делать ещё один файл разрешением выше? А если нужно их анимировать? Поменять цвет иконки в соответствии с цветом текста?

Не совсем понял про подтверждение ваших слов, потому что все три пункта, которые я привёл выше, выступают против ваших аргументов. Когда, к примеру, с командой делали интерактивный лендинг-презентацию для Procter& Gamble, я не представляю, что бы было, если бы мы делали все графические элементы в растровых форматах. Никакой анимации, размытость элементов на экранах с высокой плотностью вкупе с нулевой экономией килобайт и т. п.

Ну или вот тут, на Toster.ru, когда открывается лайтбокс с картинкой, в правом верхнем углу висит пиксельная мыльная иконка крестика — не знаю, как вам, но мне это не очень нравится. Тем более в конце 2018-го года.

[alex-1917]

SmthTo,

А если у вас есть потребность сделать их хотя бы по 50 пикселей?

да, так бывает, суть в том, что это нужно ОДИН раз на этапе верстки. ОДИН.РАЗ.
разговор про работающие сайты. а не, что для портфолио)))

[Rustam Bainazarov]

alex-1917, наверное, у нас разные понимание «работающих» сайтов. Интернет-магазины (2 российских, 6 немецких), пара десятков лендингов (для США и Германии) — чем не рабочие сайты? И да, опять же, проверяю на реальных устройствах, ни разу не было проблем с производительностью. Даже у IE11 нет особых проблем (разве что с viewBox и трансформациями посредством CSS).

Возможно, вам просто лень делать векторные графические материалы :))

P. S. Портфолио, кстати, не держу. Наверное, зря.

[alex-1917]

SmthTo,
пример работающего сайта:
клиент каждые полгода-год заказывает похожие сайты, говорит, чтобы не привлекать внимания, разбивает категории по сайтам, создает такую своеобразную сеть сайтов...
я спрашиваю - а почему каждый раз надо именно на битрикс М.Б. (каждый сайт - как минимум 35кр за лицензию плюс первичный программинг), клиент говорит - да привык просто к админке...))) Говорит, не считай мои деньги, вот на тебе пачечку, вот эти считай!...)))
пример неработающего сайта - иногда захожу на прошлогодние проекты, там до сих пор крутятся демо-данные)))

Answer 7

[It]

Пробовал множество разных вариантов верстки, от самого "ручного" до webpack или gulp. В итоге понял, что если сайт не SPA, а просто лендинг или корпоративный многостраничник, то идеальным по скорости подготовки и удобству лично для меня является алгоритм:
1. Папка обычной структуры index.html + /img + /css + /js + /fonts + /sass .
2. Сразу инициализирую репозиторий (использую битбакет, а не гитхаб).
3. Открываю папку в VSCode, копирую настройки из любого другого проекта для плагинов.
3.1. Если только начинаем использовать VSCode, то нужно сразу поставить плагин для автокомпиляции Sass в CSS в онлайн режиме (Live Sass Compiler), этот плагин на лету конвертит код + сразу автопрефиксера функционал имеет + css map + минификация. Один раз настраиваем его для всех проектов.
3.2. Ставим Live Server, один раз настраиваем его для всех проектов.
3.3. Подключаем репозиторий во вкладке для репозиториев в VSCode
4. Всё, начинаем работать.
Я пропускаю шаг по настройке VSCode всякими мелочами типа линтеров, подсвечивалок кода, и прочего, тут кому что удобнее.

Такая связка позволяет использовать один инструмент (VSCode) для комфортной и быстрой верстки, если все в норме настроено, то я пишу\правлю код и тут же сразу всё вижу в браузере, не нужно ни обновлять ничего не подтягивать, ни ставить плагины в браузеры. Sass использую давно, ИМХО, ускоряет написание стилей в разы, и это при том, что не использую обычно даже миксины, максимум иногда готовые куски кода, а так обычно только дерево делаю через &, чтобы не писать по BEMу длиннющие цепочки руками и переменные через $.

Если идем дальше и уже верстку натягиваем куда-то, то добавляется еще и OpenServer, и все файлы переносятся в локальную папку виртуального сайта, перебиваются пути и все происходит точно также.
Изображения оптимизирую руками, не знаю почему, привычнее и быстрее, обычным tinypng или встроенными PageSpeedIns инструментами.

WebPack и Gulp много раз пробовал, и через OptimizeHTML, о котором выше писали, но не зашли на простых и средних проектах, слишком много всего нужно настраивать и подключать постоянно, что-то отваливается или криво работает, постоянно отвлекаешься на то, чтобы разобраться почему и что происходит. Ну и огромные папки получается, с нодовскими либами, бейбелами и прочими вещами, которые реально усложняют жизнь.

Для SPA, когда нужен React или Vue тут да, webpack, а на простой верстке - лишнее.
Как-то так, спрашивайте, критикуйте)

Answer 8

[Алекс]

Webpack сборки, можно Webpack + Gulp. Миксины SCSS, BEM методология. Макеты из Adobe XD или Zeplin. Результаты обязательно лить в гит,гитлаб. А то недавно ssd накрылся и фсе если б не было в гите))