Почему в проектах 2017 года не нужна Джейквери?

Потому что:
— для работы с DOM есть, как ни странно, спецификация DOM4 с .closest(), .append(), .prepend() и другими удобными методами (https://dom.spec.whatwg.org, полифил: https://webreflection.github.io/dom4/);
— для анимаций есть CSS и Web Animations API (https://w3c.github.io/web-animations, полифил: https://github.com/web-animations/web-animations-js);
— для общения с сервером есть fetch (https://fetch.spec.whatwg.org, полифил: https://github.com/github/fetch);
— готовых библиотек на чистом JS предостаточно (https://plainjs.com, https://microjs.com), и чаще всего они легковеснее и качественнее Джейквери-плагинов.

Оказывается, несколько лет назад (не знаю насчёт сейчас) в Фейсбуке вместо Вебпака использовали собственную систему сборки, использующую машинное обучение для максимально эффективной упаковки зависимостей о_О

На днях выбирал решение для интернационализации интерфейса. Нагуглил три на первый взгляд приличные библиотеки: Polyglot от Airbnb, FormatJS от Yahoo и i18next.

Polyglot оказался крайне примитивен. Его возможности ограничиваются выводом локализованных фраз с плюрализацией, сделанной очень странно:

polyglot.extend({
  "num_cars": "%{smart_count} car |||| %{smart_count} cars",
});

polyglot.t("num_cars", {smart_count: 0});
=> "0 cars"

polyglot.t("num_cars", {smart_count: 1});
=> "1 car"

Загадочные четыре чёрточки, как написано на Гитхабе, это «специфика Airbnb» (читай, «так сложилось исторически»).

FormatJS оказался крайне продвинутым и в то же время неудобным. Помимо локализации фраз умеет форматировать числа/даты, причём даты можно получать в относительном виде, например «5 минут назад». Работает на основе Internationalization API, Unicode CLDR и синтаксиса сообщений ICU. Не монолитен, он состоит из нескольких базовых библиотек и предоставляет библиотеки для интеграции с React, Ember, Handlebars и Dust. В плане возможностей круто, но API очень громоздкий и неюзабельный.

В итоге я остановился на i18next. Помимо базовых фич в ней поддерживаются автоматическое определение локали, загрузка и кеширование текстов, расширение возможностей через плагины. Фразы можно выделять в отдельные пространства имён, например по страницам или по фичам. API не вызывает вопросов и пользоваться им просто и приятно. Жаль, что вместо стандартов вроде синтаксиса сообщений ICU в i18next используются велосипеды.

Про ICU и то, как правильно должна работать плюрализация, можно почитать в статье на A List Apart — https://alistapart.com/article/pluralization-for-javascript

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

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

Даже если говорить о технической стороне, написание кода — тоже дизайн. Интерфейсы ведь бывают не только графические, но и программные. Мало кто станет использовать библиотеку с плохо спроектированным API (всякие OpenGL, Windows API и прочие ужасы не в счёт, там выбора нет).

С чего разработчику интерфейсов начать погружение в дизайн? Рекомендую начать с доклада Артёма Поликарпова «Технолог — тоже дизайнер» о дизайнерских решениях проблем, с которыми может столкнуться любой фронтендер: https://events.yandex.ru/lib/talks/460/

Максим Ильяхов в рамках курса «Работа с клиентом» (https://clients.glvrd.ru) рассказал, как правильно косячить: https://us9.campaign-archive.com/?u=89138ced008e0282fe335b3a8&id=0861674a9d&e=%5BUNIQID

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

Гитхаб добавил в интерфейс уведомления об уязвимостях в зависимостях проекта: https://github.com/blog/2470-introducing-security-alerts-on-github

Помимо этого добавили ещё и публичные/приватные дискуссии: https://github.com/blog/2471-introducing-team-discussions

Раньше я думал, что скрипт test в npm можно запускать двумя способами. Оказывается, их четыре:

npm run test
npm test
npm tst
npm t

На выходных поучаствовал в подкасте «Веб-стандарты» — https://soundcloud.com/web-standards/episode-96

Вадим и Лёша записывались в питерском офисе Академии HTML, я записывался удалённо. Технически запись подкаста с приглашённым гостем устроена так: все созваниваются по скайпу, каждый локально пишет свою звуковую дорожку и после записи присылает её для сведения. Записываться было волнительно, в процессе путались мысли и казалось, что я несу какую-то чепуху (местами так и есть). Зато сделал из всей этой истории важный вывод — нужно меньше переживать, больше практиковаться в подобных вещах, учиться формулировать свои мысли (написание заметок в канал как раз этому способствует).

Три главных совета по вёрстке доступных писем:
1. Задавайте role="presentation" всем таблицам, которые используются не для представления табличных данных, а для раскладки.
2. Старайтесь верстать всё по-честному, а не сплошными картинками. Всем картинкам обязательно задавайте alt (оставляйте его пустым, если изображение декоративное).
3. Используйте семантичные теги header, footer, h1 – h6, etc.

Письма тоже должны быть доступными! Джейсон Родригез с советами по доступной вёрстке писем — https://css-tricks.com/html-email-accessibility/

У «Одноклассников» есть целый мессенджер, сделанный на основе веб-компонентов. В продакшене у них не выключены сорсмапы, интересно почитать исходники. Мне, например, понравился парсер сообщений.

Главное-то забыл, вот ссылка — https://tamtam.chat/

Наткнулся на этот мессенджер в презентации доклада «А так ли нужен VDOM» Сергея Чикуёнка — https://piterjs.org/events/19/2_Sergey_Chikuyonok.pdf

Самая любопытная часть презентации — о новом фронтенд-фреймворке «Одноклассников», который:
— основан на веб-компонентах;
— использует только Web API, добавляя недостающие части: шаблонизатор и передачу объектов в атрибутах;
— позволяет описывать компоненты полностью декларативно;
— не требует shouldComponentUpdate для компонентов;
— весит всего 6 КБ в gzip;
— поддерживает серверный рендеринг на любом языке программирования.

К сожалению, описание фреймворка в презентации ограничивается этим списком преимуществ. Остальную информацию предлагается узнать, устроившись работать в «Одноклассники» :–(

«Мораль истории такова: механизм автоматической вставки точек с запятыми (ASI) предназначен для исправления синтаксических ошибок. Если вы начнёте программировать, опираясь на него как на универсальное правило вставки точек с запятой на месте перевода строки, вы облажаетесь».

Брендан Айк объясняет, почему нужно ставить точки с запятыми в JS-коде — https://brendaneich.com/2012/04/the-infernal-semicolon/

Из переводов «Питера» можно мемы делать

Два часа ночи. Самое время рассказать, как сделать уведомления доступными — https://github.com/andrew--r/ui-developer-tips/tree/master/tips/008-alerts-accessibility