Comments 28
Разве верстальщик уже давным давно не слился с фронтом?
Как по мне, то верстальщик и фронтэндер должны быть разные люди.
Один создаёт адаптированные макеты под весь зоопарк устройств.
Другой пишет логику работы между макетами и беком, если говорить например о SPA.
Это конечно если они работают в веб студии и у них есть поток работ.
это все отмазки, чтобы верстальщику не учить js а фронту уметь верстать
Тут такое дело, что чтобы делать хорошую вёрстку, надо не только уметь делать «адаптированные макеты под весь зоопарк устройств», но и хорошо понимать специфику движка, на которую эта вёрстка будет натягиваться. А если знаешь специфику, то не проще сразу писать компоненты для движка?
Как по мне, то верстальщик и фронтэндер должны быть разные люди.
Вы много в каких компаниях такое разделение в реальности видели?
Я такое деление видел один раз в Cбертехе. И не видел в Яндексе, Mail.ru, а также судя по вопросам на собеседованиях ещё в Альфа Банке.
Один создаёт адаптированные макеты под весь зоопарк устройств.
Я не уверен что сложные макеты под весь зоопарк устройств можно создать без не самого тривиально JS. А заодно сделать элементы этих макетов переиспользуемыми.
Ну и потом, вспомните Adobe Flash — все постепенно пересядут на нормальную технологию, никуда не денешься.
Что там в 2020 году есть для видеовещания с низкой задержкой? ну, для вебинаров? А альтернативы флешу все еще нет, протокол rtmp до сих пор не дает спокойно похоронить flash.
Практика показывает, что все потихоньку переходят на Figma, Sketch и Avocode.
Как там в фигме-то пятнами градиентик то поверх фото сделать? А в офлайне поработать? Она очень хороша, компонентный подход просто сказка, переопределения своств — тоже сказка. Для интерфейсов самое оно. Двигать полотно, блоки туда сюда можно элементарно. Господи, да там же можно ссылки вешать на экраны и демонстрировать макеты до верстки. Но без связки с возможностями шопа для фотографий Фигма не самостоятельна. И ее аналогом скорее выступает adobe xd.
Извиняюсь, что немного не по теме. Я как-то не в курсе — БЭМ все еще используется в проектах на современных технологиях? Для чего? Или он добавлен из-за того, что нужен на jQuery проектах?
Проблема коллизии имен уже давно решается с помощью css модулей.
Для повторного использования вместо блоков уже давно есть компоненты в web components и фреймворках (вроде react, vue, angular).
По-моему, только модификаторы актуальны.
Может еще для глобальных стилей БЭМ актуален. Не все же локальными стилями делать.
Проблема коллизии имен уже давно решается с помощью css модулей.
Для повторного использования вместо блоков уже давно есть компоненты в web components и фреймворках (вроде react, vue, angular).
По-моему, только модификаторы актуальны.
Может еще для глобальных стилей БЭМ актуален. Не все же локальными стилями делать.
с помощью css модулей.CSS-модули это точно такой же костыль, только автоматизированный.
А какой шаблонизатор поддерживает css модули? Использовать фреймворк только ради того, чтобы использовать scoped стили на лендинге — выглядит еще более костыльно.
Есть же куча вариантов, где нужен простой сайт с минимумом js.
Есть же куча вариантов, где нужен простой сайт с минимумом js.
Не знаю, как обстоят дела с изоляцией стилей в шаблонизаторах.
Не подумал про серверный рендеринг. Ну да, в таких случаях возможно нет других вариантов, кроме как ручного именования по какой-нибудь css-методологии.
Не подумал про серверный рендеринг. Ну да, в таких случаях возможно нет других вариантов, кроме как ручного именования по какой-нибудь css-методологии.
Читаю ветку, слова вроде знакомые, но в общую картинку как-то не складываются) Попробую распутать.
Отправная точка как проблема — коллизия имен стилевых классов, так как все они находятся на глобальном уровне. Решается тремя основными подходами:
— уникальное именование (в том числе по БЭМ). Недостатки — длинные имена классов, ручное именование, соответственно высока возможность ошибки, нет автодополнения в IDE — в общем, пригодится только для маленьких проектов.
— большая специфичность (`.landing-block.list-item{}` вместо просто `.list-item{}`) — подход, гармонично воплощенный во всех препроцессорах методом вложенности классов. То есть подобная склейка происходит автоматически, что дает на выходе АНБ (абсолютно независимый блок) «из коробки». Недостатки — у родительских классов все равно приходится вручную поддерживать уникальность, нет автодополнения.
— добавление уникального ключа к каждому классу либо какой-либо человекопонятной переменной вроде названия папки (CSS Modules). Наиболее прогрессивный метод, когда все файлы стилей подключаются непосредственно в js-файлах компонентов и проходят через специальный обработчик (например, css-loader Webpack). Присутствуют все «бонусы» — модульность, автодополнение, уникальность, ну и если еще используется препроцессор — то и все его возможности.
Смутили в ветке обсуждения такие выражения, как
— «локальные стили» — это как? CSS классы в любом случае будут глобальными. Условно «локальными стилями» можно считать только те, которые указаны в атрибутах типа <div style=""/>, но так сейчас делают только письма ввиду отсутствия поддержки отдельных CSS-файлов, либо CSS-in-JS — ужасный паттерн, который я намеренно не стал перечислять выше, пусть он уже совсем уйдет в небытие.
— «А какой шаблонизатор поддерживает css модули?» — их поддерживает не шаблонизатор, а сборщик, но только при импорте в js-файлах. То есть el.innerHTML = '<div class="${styles.myClass}"/>' можно сделать на «ванильном шаблонизаторе»)
— «Использовать фреймворк только ради того...» — вместо БЭМ и лучше него — препроцессоры с вложенностью классов, но и css модули тоже можно использовать, как писал выше, никакие фреймворки не требуются.
Так что вроде понимаю слова — типа локальные стили, шаблонизатор, модули, фреймворк… Но как будто они накиданы наобум
Отправная точка как проблема — коллизия имен стилевых классов, так как все они находятся на глобальном уровне. Решается тремя основными подходами:
— уникальное именование (в том числе по БЭМ). Недостатки — длинные имена классов, ручное именование, соответственно высока возможность ошибки, нет автодополнения в IDE — в общем, пригодится только для маленьких проектов.
— большая специфичность (`.landing-block.list-item{}` вместо просто `.list-item{}`) — подход, гармонично воплощенный во всех препроцессорах методом вложенности классов. То есть подобная склейка происходит автоматически, что дает на выходе АНБ (абсолютно независимый блок) «из коробки». Недостатки — у родительских классов все равно приходится вручную поддерживать уникальность, нет автодополнения.
— добавление уникального ключа к каждому классу либо какой-либо человекопонятной переменной вроде названия папки (CSS Modules). Наиболее прогрессивный метод, когда все файлы стилей подключаются непосредственно в js-файлах компонентов и проходят через специальный обработчик (например, css-loader Webpack). Присутствуют все «бонусы» — модульность, автодополнение, уникальность, ну и если еще используется препроцессор — то и все его возможности.
Смутили в ветке обсуждения такие выражения, как
— «локальные стили» — это как? CSS классы в любом случае будут глобальными. Условно «локальными стилями» можно считать только те, которые указаны в атрибутах типа <div style=""/>, но так сейчас делают только письма ввиду отсутствия поддержки отдельных CSS-файлов, либо CSS-in-JS — ужасный паттерн, который я намеренно не стал перечислять выше, пусть он уже совсем уйдет в небытие.
— «А какой шаблонизатор поддерживает css модули?» — их поддерживает не шаблонизатор, а сборщик, но только при импорте в js-файлах. То есть el.innerHTML = '<div class="${styles.myClass}"/>' можно сделать на «ванильном шаблонизаторе»)
— «Использовать фреймворк только ради того...» — вместо БЭМ и лучше него — препроцессоры с вложенностью классов, но и css модули тоже можно использовать, как писал выше, никакие фреймворки не требуются.
Так что вроде понимаю слова — типа локальные стили, шаблонизатор, модули, фреймворк… Но как будто они накиданы наобум
Извиняюсь, если не грамотно что-то называю.
«Локальные стили» — встречается такое именование:
vue-loader.vuejs.org/guide/scoped-css.html#mixing-local-and-global-styles
github.com/css-modules/css-modules#naming
«Локальные стили» — встречается такое именование:
vue-loader.vuejs.org/guide/scoped-css.html#mixing-local-and-global-styles
github.com/css-modules/css-modules#naming
вместо БЭМ и лучше него — препроцессоры с вложенностью классов,Во всех последних мною виденных Multi Page Application проектах, помимо препроцессоров, использовался также БЭМ. Почему-то вложенность как замену БЭМ там не использовали.
Кроме подхода «использовать технологию, чтобы решить проблему» разработчики используют еще «потому что привыкли», «потому что где-то прочитали, что так хорошо», «потому что могут» — не менее распространенные подходы, чем первый) Думаю, стоит узнать у тех разработчиков — для чего вместо
.form { .input { & .red {} } }
писать
.form { .form__input {} .form__input_red {} }
так как никакого практического смысла это не несет.
.form { .input { & .red {} } }
писать
.form { .form__input {} .form__input_red {} }
так как никакого практического смысла это не несет.
Эм, а canvas верстальщику зачем?
Больше всего смутило, что верстальщику приписали умение натянуть верстку на битрикс или вордпресс.
Там как бы знание PHP нужно. Если не делается совсем уж стандартный блог, где нужно будет просто файл стилей подменить, то без этого никак. А если человек PHP знает, то он, скорее всего, и на Javascript напишет всё, что необходимо для сайта, и в целом это уже Fullstack получается.
Там как бы знание PHP нужно. Если не делается совсем уж стандартный блог, где нужно будет просто файл стилей подменить, то без этого никак. А если человек PHP знает, то он, скорее всего, и на Javascript напишет всё, что необходимо для сайта, и в целом это уже Fullstack получается.
Согласен с Named — в статье явно верстальщику приписываются компетенции от другой профессии — «веб-мастер», а надо бы их разделять.
Так что я бы оставил в списке целевых технологий: адаптивная верстка, препроцессоры, Git, работа с готовыми javascript-библиотеками (уметь подключить и кое-что подправить на упрощенном js типа jQuery), несколько графических редакторов, работа с изображениями и svg-масками, шрифтами, особенности верстки писем, владение вставкой переменных в каком-либо шаблонизаторе (предпочтительно JSX+Pug), принципы SEO и оптимизации для поисковиков. Зарплата как я могу судить по мониторингу рынка с 2000-х будет в районе 1000$ за такой набор, а при отличном владении и высокой производительности — до 1500$. Обучаться ремеслу придется в районе года-полутора.
А вот для веб-мастера плюсом к этому нужно знание нескольких CMS-движков, уметь настраивать большое количество модулей к ним и темы, заказать хостинг и выложить это дело на сервер, базово раскрутить в поисковиках, написать кастомные js-компоненты на базовом уровне, поправить серверный код на php, написать документацию по пользованию системой и терпеливо поддерживать клиентов. Продвинутые веб-мастера могут делать сложные интернет-магазины. Зарплата тут будет зависеть от конторы, но можно рассчитывать при достаточном опыте на 2000-2500$, я вот мог в бородатое время и больше «наработать» — например, за месяц успевал сделать по 3 проекта по типу такого полностью «под ключ», с кастомной админкой под каждый проект и инлайн-редактированием. Обучаться этому ремеслу придется + 1-2 года от становления хорошим верстальщиком.
Ну, а Node.js и Webpack — это уже от третьей профессии, javascript-разработчик. Это альтернативный веб-мастерингу путь, который приведет к становлению frontend-разработчиком (комбо верстка+js на крутом уровне), тут и так все понятно)
Так что я бы оставил в списке целевых технологий: адаптивная верстка, препроцессоры, Git, работа с готовыми javascript-библиотеками (уметь подключить и кое-что подправить на упрощенном js типа jQuery), несколько графических редакторов, работа с изображениями и svg-масками, шрифтами, особенности верстки писем, владение вставкой переменных в каком-либо шаблонизаторе (предпочтительно JSX+Pug), принципы SEO и оптимизации для поисковиков. Зарплата как я могу судить по мониторингу рынка с 2000-х будет в районе 1000$ за такой набор, а при отличном владении и высокой производительности — до 1500$. Обучаться ремеслу придется в районе года-полутора.
А вот для веб-мастера плюсом к этому нужно знание нескольких CMS-движков, уметь настраивать большое количество модулей к ним и темы, заказать хостинг и выложить это дело на сервер, базово раскрутить в поисковиках, написать кастомные js-компоненты на базовом уровне, поправить серверный код на php, написать документацию по пользованию системой и терпеливо поддерживать клиентов. Продвинутые веб-мастера могут делать сложные интернет-магазины. Зарплата тут будет зависеть от конторы, но можно рассчитывать при достаточном опыте на 2000-2500$, я вот мог в бородатое время и больше «наработать» — например, за месяц успевал сделать по 3 проекта по типу такого полностью «под ключ», с кастомной админкой под каждый проект и инлайн-редактированием. Обучаться этому ремеслу придется + 1-2 года от становления хорошим верстальщиком.
Ну, а Node.js и Webpack — это уже от третьей профессии, javascript-разработчик. Это альтернативный веб-мастерингу путь, который приведет к становлению frontend-разработчиком (комбо верстка+js на крутом уровне), тут и так все понятно)
Профессия верстальщик мертва. За последние лет 6 я видел её в двух компаниях при том что вторая отпочковалась от первой.
В статье очень много описаного того, что должен знать фронтендер, стоит сделать маленький шаг вперёд и значительно повысить свою привлекательность на рынке труда.
Другое дело дизайнеры, которые должны знать основы вёрстки, понимать сетки и соответственно рисовать то, что можно будет реализовать за минимальное время.
Sign up to leave a comment.
Что должен уметь верстальщик, чтобы его все хотели