А вот задачи, которые IntersectionObserver точно решает нормально — потому что создавался для них
(https://github.com/w3c/IntersectionObserver/blob/gh-pages/explainer.md#observing-position)

Опубликовал Лайкли 2.3: https://github.com/ilyabirman/Likely/releases/tag/v2.3.0
(Лайкли — это клёвые социокнопки)

В этом релизе впервые попробовал другой подход к разработке проекта. Мне не очень нравится кодовая база Лайкли: АПИ для создания новых кнопок довольно неочевидное, плюс в целом хватает непонятных мест и низкоуровневых проблем вроде неиспользуемых переменных. Поэтому я ещё с 2016-го планировал однажды засесть и провести крупный рефакторинг — но никак не добирался.

К Лайкли 2.3 я осознал, что не обязательно садиться и делать всё сразу два дня подряд, а можно просто делать по два-три изменения за раз. Это не потребует много времени, а результат начнёт приносить. В итоге я, кроме кнопок WhatsApp-а — основной фичи релиза — за пару часов починил ещё четыре самых надоевших проблемы.

Короче, частые небольшие итерации — сила.

Ещё по теме:
— Артемий Лебедев про метод прогрессивного джипега
— Людвиг Быстроновкий про разные подходы к работе (исходная статья)

Благодарите авторов библиотек, которыми пользуетесь :–) Я месяц назад впечатлился библиотекой react-table, завёл в ней ишью с благодарностью, а туда ещё много пользователей написало. Разработчиков это очень поддерживает

1. Оказывается, в браузерах уже давно есть нативные селекты с автокомплитом: https://developer.mozilla.org/en/docs/Web/HTML/Element/datalist

Минусы:
— Не работают в Сафари
— Выпадающий список плохо стилизируется

Но если вам это не мешает, то их вполне можно использовать вместо кастомных элементов управления.

2. Бэймард-институт — институт, который проводит кучу UX-исследований — пишет, в каких случаях стоит использовать нативные компоненты (кнопки, инпуты, селекты), а в каких — кастомные: https://baymard.com/blog/custom-vs-native-ui

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

3.
— Зачем мне вообще это всё?
— Заботиться о юзабилити важно, потому что неудобные интерфейсы отталкивают пользователей. Особенно это ощущается в e-commerce, где заработок напрямую зависит от того, сколько пользователей пройдут воронку покупки до конца. У меня нет данных насчёт не-e-commerce-приложений, но я думаю, что неудобные интерфейсы негативно влияют и там — в более долгосрочном плане.

4. А Женя Родионов напоминает, что в целом интерфейс — это костыль, промежуточная прослойка между человеком и компьютером, которая только усложняет взаимодействие. И чем меньше интерфейса, тем лучше.

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

Доклад Ильи Бирмана на эту тему: http://ilyabirman.ru/meanwhile/2010/11/15/1/

(Ну и да, как Женя пишет, фронтенд рано или поздно перестанет быть востребованным, поэтому лучше искать дополнительные специализации уже сейчас.)

https://twitter.com/selenit2/status/903951373082996737

На тему вчерашнего доклада Макеева про a11y. Мысль верная, всё так, об a11y нужно думать и поддерживать (это несложно, посмотрите на a11yproject.com), но фундаментальная проблема в другом.

Интерфейс — это костыль. Синк эбаут ит: человеку нужно конечное действие, а не удобный интерфейс. Вся индустрия фронтэнда и мобильных приложений это промежуточный этап к пониманию машиной человека. Эппл делает Сири и интегрирует в неё сторонние приложения, Гугл делает какую-то хуйню тоже, Амазон — Алексу.

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

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

Написал про кеширование на английском (тут было на русском).

Какие заголовки использовать, как выглядит жизненный цикл ресурса, как максимально избежать лишних запросов на сервер: https://iamakulov.com/notes/caching/

Алексей Иванов рассказывает, почему Бутстрап редко подходит для разработки приложений: https://evilmartians.com/chronicles/bootstrap-an-intervention

У меня с Бутстрапом тоже был неприятный опыт. Два года назад мы в Епаме делали редизайн внутреннего портала и за основу нового дизайна взяли Бутстрап. Это казалось хорошим решением — ведь в Бутстрапе уже есть готовые компоненты, нужно только кастомизировать их. Но по факту это вызвало проблемы:
— Бутстрап содержал много стилей, которые нам не были нужны (вроде прогресс-баров, радиокнопок и типографики). Когда мы стилизировали Бутстрап под свои потребности, пришлось стилизировать и их.

— Более того, когда через год нам всё-таки понадобились прогресс-бары, дизайнер нарисовал их не такими, какими мы их стилизовали. Пришлось переделывать ¯\_(ツ)_/¯

— Наши гайдлайны интерфейса отличались от бутстраповских. Бутстрап определял шесть основных цветов интерфейса, у нас их было больше. Бутстрап определял стили кнопок в системе default/primary/success/error и т.д., у нас был другой подход. Из-за этого приходилось в одних местах использовать бутстраповские классы, а в других — свои (и помнить, где что)

Что использовать вместо Бутстрапа?
— Для сетки — https://github.com/evgenyrodionov/flexboxgrid2 или любую другую
— Для компонентов вроде кнопок и тултипов — свой собственный код. Другие библиотеки брать не стоит — вы поблагодарите себя за собственную реализацию, когда вас попросят сделать поведение, которое библиотека просто не предусматривает

Хинт: когда отключаете правила в ESLint, комментируйте, почему. Сравните, насколько проще разобраться:

Задали вопросы, проясняю.
— У меня на скриншоте не JSON, а обычный JS, поэтому комментарии там работают. Такой конфиг можно писать в файле .eslintrc.js
— Тем не менее, ESLint поддерживает комментарии и в JSON-конфиге. Поэтому смело комментируйте: https://eslint.org/docs/user-guide/configuring#comments-in-configuration-files

Насчёт Бустстрапа в личке напомнили, что, в отличие от приложений, для админок и прототипов он вполне подходит. Согласен, но с парой уточнений:
— Для админки Бутстрап стоит брать, только если админка почти не будет развиваться в будущем. То есть её сделают один раз, потом раз в год будут дописывать модуль, и всё. Если админку придётся регулярно поддерживать и обновлять, Бутстрап будет мешать.
Пример первой админки — самописная страница управления своим сервером, пример второй — админка Медузы

— В прототипах важно выбросить Бутстрап в тот момент, когда прототип начнёт превращаться в реальное приложение. Иначе, опять-таки, Бутстрап будет мешать

Игорь Шевченко пишет, как делать хорошие надписи в интерфейсах. Это о том, почему фраза «Формат поля неверен» — плохое сообщение об ошибке, и том, как делать её лучше: http://igorshevchenko.ru/blog/entries/interface-copy

Главное:
Заботьтесь о пользователе
— Напишите текст просто, как если бы вы говорили это вслух: «В системе произошла неожиданная ошибка» → «Мы не можем закончить покупку из-за неожиданной ошибки»
— Если это сообщение об ошибке, подскажите, что сделать, чтобы её исправить: «Обновите страницу через пару минут»

Смотрите со стороны
— Посмотрите, что может быть непонятно для пользователя. Бывает, полезно добавить деталей: «Неверная дата» → «Дата рождения не может быть в будущем»
— Сделайте, чтобы надпись имела смысл, даже если пользователь переключился на другую вкладку и вернулся к вашей через день: «Ваша оценка: 60» → «Вы получили 60 баллов в тесте по английскому. Что это значит (ссылка)»

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

На моём проекте я заметил реакт-компоненты с вот такими проптайпами:

static propTypes = {
 items: PropTypes.array,
 counters: PropTypes.object,
};

Вот как они должны выглядеть вместо этого:

static propTypes = {
 items: PropTypes.arrayOf(PropTypes.shape({
   id: PropTypes.string.isRequired,
   name: PropTypes.string.isRequired,
   link: PropTypes.string.isRequired,
 })).isRequired,
 counters: PropTypes.objectOf(PropTypes.number).isRequired,
};

Разница — вторые проптайпы гораздо детальнее. Вот почему это важно: https://iamakulov.com/notes/deep-proptypes/