Про PiterJS 13

Делюсь с вами впечатлениями и знаниями с piterjs 13!

Я сходил на PiterJS 13, который прошел в Селектеле, ниже информация, которую я почерпнул от докладчиков.

Re-imagining Webpack

Оказалось, что в Хельсинки одновременно с PiterJS проходил митап про react, и доклад Юхо Вепсалайнена мы слушали через скайп. Юхо рассказал про путь появления вебпака из не принятого пулл реквеста (#меняневзяли), про того, каких успехов добилася проект и показал красивые экспоненциальные графики роста скачиваний. Вот несколько интересных фактов и идей, которые я запомнил из его рассказа:

  • Вебпак хотят децентрализовать, отделить разработку ядра от разработки различных лоадеров. Для них есть отдельное сообщество, где ссылки на все репозитории есть в одном месте, очень удобно;
  • Вебпак принимает пожертвования через платформу Open Collective, вы можете видит все траты на проект и отправить деньги в помощь, в идеале, автор хочет работать над вебпаков фул-тайм и это вполне возможно с помощью этого механизма;
  • Можно голосовать за фичи, которые будут у разработчиков в приоритете на специальной странице;
  • Юхо написал книжку про вебпак (и ещё одну про реакт), её можно бесплатно прочитать тут или купить через leanpub.

Документация кода в JS

Вадим Горбачёв рассказал про то, как писать комментарии так, чтобы они были понятными. В целом, советы применимы к любому языку, самое важное:

  • Старайтесь, чтобы названия переменных и методов объясняли, что они делают;
  • Обязательно комментируйте код, в котором есть высокий уровень сложности, какие-то хаки и сюрпризы;
  • Автоматизируйте процессы — используйте автогенерацию и линтеры;
  • Указывайте в комментариях используемые единицы измерения и допустимые диапазоне;
  • Прочитайте книги «Code Complete» и «Clean Code».

А видео можно посмотреть по этой ссылке.

Нужен ли мне TypeScript?

Александр Баумгертнер попытался разобраться, нужна ли типизация и можно ли без неё обойтись. В качестве альтернативы TypeScript’у и Flow, Александр предлагает использовать очевидные названия переменных и функций, а для удобства работы в редакторах использовать простые JSDoc аннотации.

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

  • Без использования внешних инструментов, требуется, что все участники разработки обладали достаточной дисциплиной для написания кода в «правильном» стиле, а это сложно, особенно когда разработчики разного уровня;
  • Необходимость писать аннотации типов для абсолютно всех вещей в коде, даже тех, которые никто не увидит. Это требует колоссальных усилий, а качество комментариев понижается из-за чисто технический записей;
  • Иногда бывает сложно придумать очевидное название для функции, или в некоторых случаях, как например с переменной, которая содержит дату, тип этой переменной может быть непонятен и можно с ней совершить неправильно операцию. В случае с типизацией, код не скомпилируется, а без проверок — упадёт в рантайме;
  • Падение в яму провала — поддерживая руками типы вместо использования автоматических инструментов, вы увеличиваете вероятность появления ошибки, которая рано или поздно произойдёт и приведёт к проблемам.

Дискуссия интересная, поэтому я советую посмотреть видео тут.

Про #pitercss 11

Делюсь с вами впечатлениями и знаниями с pitercss 11!

Про «Semrush»

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

Относительный CSS

Первым выступил Валерий Любимов  рассказал про относительные величины в CSS — rem, vw, vh, vmax, vmin и currentColor. Лично для меня это были новые вещи, потому что за CSS я не особо слежу, хотя про rem слышал.

Можно задать цвет для блока или родителя один раз, а потом использовать currentColor в других свойствах блока, где нужно указать тот же самый цвет, позволяет сократить количество редактирования кода, когда нужно поменять один и тот же цвет в одном блоке или потомках много раз, удобная переменная.

Аналогичную экономию труда предлагает rem — единица измерения, которая вычисляется относительно корня html, а не от текущего размера шрифта, как у простого em. В сложном коде бывает непросто понять, от какого именно размера считается em, в случае с rem вы всегда знаете число и для изменения размеров под разные вьюпорты с помощью медиа-выражений достаточно в одном месте задать разные варианты размера font-size для тега html, чтобы получить адаптивность для всего проекта. Из минусов rem-ов можно отметить сложность создания изолированных компонентов, так как появляется жесткая внешняя зависимость от размера тега html, возможные проблемы с браузерным зумом и сложность конвертации абсолютных величин из макета дизайнера в относительные величины от размера шрифта, не уверен, что тут можно получить пиксель-пёрфект верстку.

vw, vh, vmax и vmin — позволяют задавать размер в процентах от вьюпорта, что супер полезно, когда вы хотите разместить блок на весь экран, например для лайтбоксов или промостраниц, можно заменить javascript код на простой изящный CSS. Правда, тут есть свои особенности, связанные с подсчётом ширины скроллбаров и адресной строки, которая исчезает в браузерах.

Презентация доклада: https://pitercss.ru/11/pres/relative-css/

Учите дизайнеров верстать

Дизайнер Вадим Матвеев рассказал зачем он научился верстать. Оказалось, что знания верстки даёт кучу преимуществ всей команде.

  • Дизайнер получает возможность самостоятельно творить «красоту», великолепные анимации и переходы — все это можно редактировать прямо в браузере самостоятельно и не требует внимания кодера.  Дизайнер так же знает, какие элементы дизайна сделать сложно, какие легко и может принимать решения с полной информацией.
  • Фронтендер получают коллегу, который не преподносит сложных в реализации сюрпризов, умеет мыслить блоками и компонентами и экономит всеобщее время.
  • Компания получает кучу сэкономленного времени на верстке и дизайне и качественный продукт, соответствующий реалиям современного интернета.

Презентация доклада: https://pitercss.ru/11/pres/design-code.pdf

Дизайн-системы. В поисках «идеального компонента»

Роман Ганин рассказал про дизайн системы и показал, как очень легко можно превратить обычный параграф текста в интерактивный и информационный веб-документ минимальными средствами без кучи фреймворков. Посмотрите презентацию: https://pitercss.ru/11/pres/ideal-component/

Фронтендер + Дизайнер = ♥

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