RT @amel_true: Скоро начинаем! #wstdays pic.twitter.com/bIV3jmnBzS
Начинаем 🎬
Сегодня ведут WSD Вадим Макеев и Ольга Алексашенко pic.twitter.com/0eUhpbSfV3
Это уже 40! конференция веб-стандартов, юбилей! 🥳
Используйте официальный хештег #wstdays, чтобы мы могли разделить с вами впечатления 😉
wsd.events/lunch — тут можно найти карту, где покушать в большом перерыве 🍽️
Рома @rdvornov Дворнов начинает с докладом «Почему фронтенд это круто» pic.twitter.com/OORiaUMMTQ
RT @rdvornov: Photo from the stage of #wstdays
Talking why frontend is awesome 🤘 pic.twitter.com/lANZld2MXl
4 кита фронтенда: HTML, CSS, JavaScript, DOM
HTML содержит большое количество фич, о которых мало кто знает. Посмотрите в html.spec.whatwg.org, если ещё этого не делали.
Знать синтаксис CSS != знать CSS. @rdvornov 20 лет постоянно находит для себя что-то новое. Если считаете, что знаете CSS, попробуйте в cssbattle.dev
На CSS можно делать настоящие картины: diana-adrianne.com/purecss-franci…
CSS — язык программирования. Например, сортировку таблицы можно сделать только на нём: kizu.ru/variable-order/
У Лауры Шенк есть исследование про то, почему на CSS можно программировать: notlaura.com/css-is-a-progr…
JavaScript прошёл большой путь. Первый SPA — Gmail — появился в 2004 году. Google Maps — в 2005. Почти 15 лет назад!
"Возможности инструмента определяются умением им пользоваться" (с)
Про DOM часто забывают, потому что между фронтендерами и DOM обычно есть прослойка в виде фреймворка. Отсюда и мифы, что он медленный или с ним что-то не так.
При этом DOM с нами давно и он активно развивается. pic.twitter.com/2K6C6YnFum
"Во фронтенде всё круто" (с)
Вместо изучения фреймворков полезнее изучать то, как работают браузеры, сетевые протоколы и прочие computer science вещи.
Чтобы делать хорошие интерфейсы, можно и нужно быть художником 👨🎨. Изучайте принципы дизайна, UX, анимации, типографики и т.д.
Фронтенд не мёртв. Просто простые задачи закончились, остались сложные. Для простых уже есть решения.
RT @amel_true: Вас много и это офигенно #wstdays pic.twitter.com/Ny2h5FgETA
Что будет во фронтенде дальше? Web Components, CSS Houdini, WebAssembly
Веб-компоненты сейчас мало кто использует. Для них нужен JavaScript (сложно генерировать компоненты на сервере), есть проблемы с SEO. Но в течение 1-3 лет Declarative Shadow DOM может всё изменить.
Про CSS Houdini Рома советует посмотреть доклад @dark_mefody «Houdini — CSS, который JavaScript»: youtu.be/xFXCfTHTmoA
В течение 2-4 лет Houdini изменит то, как мы можем влиять на конвейер рендеринга браузера, даст нам много высокопроизводительных возможностей, которые, однако, потребуют погружения в не самый простой код.
WebAssembly — это MVP. Список новых фич: webassembly.org/docs/future-fe…
Тренды:
- Новые полезные инструменты
- Больше низкоуровневых API
- DSL & AOT
Советы от @rdvornov, как стать лучшим фронтендером: любите, практикуйте, учитесь.
Полностью согласен :) А вы что думаете? pic.twitter.com/puHHHyTIje
Вопрос из зала: "Как развиваться разработчику в сторону дизайна и UX?"
Ответ: Можно поговорить с дизайнерами, которые уже знают, куда лучше смотреть.
Мальчик-бродяга Сергей @chicoxyzzy Рубанов показывает, как работает TC39 pic.twitter.com/jjXnEWGS5J
В 2008 году было принято решение не делать ECMAScript 4, вместо него начали работать над ES5. С ES2016 процессы выстроились понятно и гармонично.
Членами комитета Ecma International являются организации, а не люди.
Структура комитета выглядит так pic.twitter.com/BVlLLz7p4D
RT @not_plasticine: Как нас много! #wstdays pic.twitter.com/Ns7eZR0d4j
В TC39 есть делегаты компаний, приглашённые эксперты (например, члены команды Babel), наблюдатели (которыми может стать почти кто угодно, никакого NDA).
Редакторы — люди, которые отвечают за текст спецификаций. Они меняются от версии стандарта к версии. Их тексты попадают к генеральной ассамблее.
Stage 0 — предложение, которое никому не было показано. Их нельзя использовать в production.
Stage 1 — предложение комитету. Уже определены потенциальные возможности.
Stage 2 — уже должен быть какой-то текст спецификации. Комитет уверен, что имеет смысл развивать фичу.
Stage 3 — есть полный текст спецификации, одобренный рецензентами и редакторами. Тут начинается реализация в движках.
Stage 4 — есть как минимум две проходящие тесты реализации в движках. Готовая для использования фича.
Встречи TC39 проходят по повестке дня. Фичи в повестке отсортированы по stage, начинают с самых высоких.
RT @not_plasticine: Самая лучшая команда волонтёров 💚
#wstdays pic.twitter.com/O8AtAV4w61
Фичи обсуждаются в виде докладов. Ничего космического и сверхъестественного. Разве что уровень погружения в темы очень глубокий.
Председатели комитета следят за тем, чтобы обсуждение не превращалось в хаос. Есть специальное ПО, которое им в этом помогает.
Сейчас процесс полностью открытый, вы тоже можете поучаствовать на GitHub: github.com/tc39
Инструкция по созданию собственного предложения в комитет pic.twitter.com/CiszaPXLh5
Babel — один из способов помочь комитету. Вы можете написать для него плагины.
RT @rdvornov: Слайды доклада – Почему фронтенд это круто (версия 2.0) #wstdays icloud.com/keynote/0D4KqA…
Вопрос из зала: Фич приносится много. Не превратится ли язык в монстра, в котором слишком много всего?
Ответ: Не превратится. В обсуждении участвует большое сообщество, которое не пропустит малозначимые вещи. За сложностью спецификации тоже следят.
Вопрос из зала: Есть ли предпосылки, чтобы TC39 форкнулся ещё раз, как было во времена ES4?
Ответ: Нет. Процессы сейчас налажены так, чтобы этого не случилось.
Фича готова для production, если она уже влита в спецификацию и есть две стабильные имплементации в движках. Бывают такие, которые ещё на Stage 3.
Юля @julia_miocene Музафарова с докладом про CSS-анимации «Make a world» pic.twitter.com/vdJmRADEbR
В 2018 году две демки Юли попали в топ-100 самых популярных демо на @CodePen:
codepen.io/miocene/pen/mj…
codepen.io/miocene/pen/WJ…
Зачем нужны демки на CSS? Обучение, проба нового, развлечение, следование моде, хайп. Всё полезно.
Избегайте сложных градиентов и сильного изменения shape. CSS умеет далеко не всё, и вы можете сильно запариться, если попытаетесь сделать слишком сложные вещи.
Шаг 0. Выберите идею. Она должна вам нравиться. Можно взять готовую gif-ку от дизайнера.
Шаг 1. Постройте таймлайн анимации. Для гифок можно вытащить ключевые кадры.
Шаг 2. Продумайте архитектуру анимации. В HTML и CSS Юля рекомендует BEM-наименование.
Элементы хорошо вкладывать друг в друга, чтобы делать анимации, например, пальцев относительно руки.
Шаг 3. Рисование. Экономьте объекты в DOM. CSS позволяет рисовать квадраты, круги, блобы, треугольники, причём разными способами.
Используйте псевдоэлементы, градиенты, тени и воображение.
Для точной вёрстки хорошо использовать браузерное расширение PerfectPixel: welldonecode.com/perfectpixel/
С ним удобно накладывать ключевые кадры из gif на вашу CSS-анимацию.
RT @amel_true: Нетворкинг, не забывайте про него и не стесняйтесь подходить #wstdays pic.twitter.com/H03mh6vfqR
Шаг 4. Анимируйте. Сначала определите количество кадров: 100% = количество кадров в gif. Затем easing-функцию.
Шаг 5. Отладка. В Chrome Dev Tools есть специальная вкладка Animation, в которой можно замедлять, ускорять, ставить на паузу и сравнивать по таймлайнам разные анимации.
Два способа попасть в топ:
- Challenge. У CodePen есть отдельная страница для них: codepen.io/challenges/
- Просто делаете классную демку, пишете об этом в твиттере, ждёте — профит!
Одна топ-анимация у Юли заняла месяц (по вечерам за сериальчиком), 200 дивов, 3000 строк рисунка, 5000 строк анимации 😱
Владимир @mista_k Кузнецов рассказывает про «Все цвета радуги» pic.twitter.com/8aR1dqEiqL
В 2019 году умные устройства позволяют запечатлить и отобразить цвета, которые раньше не были доступны.
Цвет — понятие субъективное. На картинке шары одинакового цвета, если что pic.twitter.com/zCOLXOJLWq
Исследование восприятия цвета началось более 100 лет назад. Появилась Международная комиссия по освещению. Разные рецепторы в глазу на различные длины волн реагируют по-разному.
В 1931 было построено математическое описание цветового пространства: CIE 1931 XYZ.
В 1976 появился другой стандарт: CIE 1976 L*a*b*.
Оба стандарта описывают абсолютные цветовые пространства.
Устройства ввода-вывода комплектуется цветовым профилем, который позволяет преобразовать какую-то систему координат в CIEXYZ или CIELAB.
Цветовых профилей много, стандарты разные, затрагивают разнообразные цвета (даже невидимые человеческому глазу) pic.twitter.com/qbMqBwr5Py
Интересно посмотреть на цветовую модель в виде 3D-графика. Раскрывает сознание 🤔
Стандарт sRGB был разработан в 1996 совместно HP и Microsoft. Нужен был для одинакового отображения цветов на разных устройствах. В итоге этот стандарт стал стандартом де-факто практически для любой техники.
В CSS цвет можно задать только в пространстве sRGB 🤷♂️
При преобразовании цветовых пространств (например, от RAW-фотографии до фото в пространстве sRGB) цвета могут теряться. В природе цветов гораздо больше, чем может описать некая математическая модель.
Современные устройства Apple, ноутбуки разных фирм умеют воспроизводить изображения с большим цветовым охватом (Display P3, Rec. 2020). Но такие экраны стоят довольно дорого.
В браузере вы можете использовать @media (color-gamut: p3) { ... } в CSS, чтобы определить поддержку другого цветового профиля.
С изменением цветовых профилей нужно быть осторожными: файлы становятся больше, CDN и инструменты оптимизации их могут не поддерживать, нет согласования с цветами из CSS.
При этом изображения на соответствующих дисплеях выглядят эффектнее, конвертация в профиль устройства происходит автоматически, современные ОС это уже умеют.
Firefox по умолчанию не поддерживает цветовые профили v4 🤷♂️
igor-bon.ru — сайт, на котором много различных материалов про цвета.
Отличный доклад, который заставляет задуматься, что даже в ежедневных привычных вещах есть большое количество нюансов. Даже в записи rgb(127, 255, 0) заложена долгая история и векторы роста для спецификаций.
noteskeeper.ru — здесь можно найти много интересных заметок Вовы на тему фронтенда и не только.
Уходим на обед 🥗
wsd.events/lunch — тут есть карта, где можно поесть.
Встретимся через полтора часа ;) pic.twitter.com/v3viyR5MVL
Даниил Крохмаль рассказывает, как (не)удовлетворить Google PageSpeed pic.twitter.com/ks2c4CIafw
First Contentful Paint можно оптимизировать при помощи Critical CSS. Загружаем стили первого экрана сразу внутри тега style, а остальные — при помощи JS асинхронно.
Нужно помнить про TCP-пакеты. Можно ориентироваться на размер 14.6 Кб, чтобы доставить всё необходимое на первый экран.
Прогрессивный CSS — когда перед каждым блоком в body вставляется link с нужным CSS. Так блокироваться рендеринг будет не сразу весь, а только перед каждым блоком. Лучше всего работает с HTTP2.
Если вы разрабатываете SPA, по умолчанию страница сначала пустая, а потом на неё подтягивается контент. Решение — Server Side Rendering (SSR).
RT @amel_true: Тем временем перерыв на обед #wstdays pic.twitter.com/qHICgb5RAR
RT @EvgenyVyushin: #wstdays pic.twitter.com/pU1iYnJfFJ
RT @amel_true: Продолжаем, возвращайтесь к трансляции #wstdays pic.twitter.com/fVAFCmHR4x
Preload + Prefetch могут помочь с загрузкой важных или последующих ресурсов. Поддерживаются в большинстве современных браузеров и ничего не ломают, так что использовать стоит.
Preconnect может "разогревать" соединение с внешними сайтами. Удобно, когда вы встраиваете видосики с ютуба к себе на страницу.
Webpack + html-webpack-plugin + preload-webpack-plugin возьмут на себя расстановку нужных директив во время сборки.
Все вот это 👆 помогло достичь оценки 31 в Google Page Speed :)
Загрузка веб-шрифтов — отдельная задача. FOIT и FOUT — моргание шрифта при загрузке, которое может очень сильно влиять на восприятие контента.
Улучшить загрузку шрифтов можно при помощи preload, unicode-range. Для анализа шрифта можно использовать инструмент wakamaifondue.com
Critical FOFT — способ доставки шрифтов, когда сначала загружается первая часть шрифта с важными для первых экранов символами. Остальное загрузится позже.
font-display: swap — способ сказать браузеру, чтобы он сначала применил шрифт по умолчанию, а когда загрузится кастомный шрифт — перерисовал текст новым шрифтом. Пользователь видит текст сразу и более счастлив, чем с пустым экраном.
Для изображений хорошо использовать lazy loading — ленивую загрузку. Суть в том, чтобы загружать только те изображения, которые попадают в видимую часть экрана. Для этого удобно использовать Intersection Observer API.
Тег <picture> позволяет загружать разные картинки под разные устройства (для больших и маленьких экранов, retina и прочее). Также можно указывать другой формат изображений, который в современных браузерах распознается и весит меньше (например, WebP).
WebP — это формат, который в среднем сжимает лучше, имеет маску альфа-канала, хорошо работает с градиентами, но понимается не всеми браузерами, искажает цвета и сильнее нагружает процессор (сложнее декодируется).
Render-blocking resources — это скрипты, которые блокируют рендеринг. Например, метрики поисковиков. Решение — code splitting. Сначала грузим самое необходимое, остальное — асинхронно позже. Подходы: роут-ориентированный и компонент-ориентированный.
Пакет react-loadable может помочь вам с разбиением кода и динамическими импортами.
Способ оптимизации загрузки гораздо больше, но уже эти 👆 позволили поднять оценку на десктопе до 95. Сделано за 24 часа, пользы много (конверсия +25%). Повод задуматься.
@Neesoglasnaja из зала посоветовала посмотреть в сторону gtmetrix.com, как обёртку над Google Page Speed с дополнительными советами по оптимизации.
Андрей @RIP212 Лось рассказывает про GraphQL как будущее клиентских API pic.twitter.com/1Azz6tvfpj
REST — классический подход к разработке API, где каждая "ручка" отвечает за какой-то ресурс, а HTTP-методы определяют, что делать с этими ресурсами.
Плюсы REST: простота, расширяемость, кэширование, обозримость (предугадываемость), знакомость (все знают, все пользуются). Но мало у кого REST реализован по всем правилам.
RT @mista_k: mistakster.github.io/wsd19-spb-colo… Слайды моего доклада «Все цвета радуги» #wstdays twitter.com/webstandards_u…
Facebook столкнулся с тем, что стал расти рынок смартфонов, вместо приложения нужно использовать веб, а API недостаточно гибкий (из-за сложных структур данных). Множество запросов делать дорого, потому что HTTP1 и плохое соединение. Отдавать лишние данные тоже дорого.
Помимо медленного соединения нужно помнить и про время обработки запроса сервером, оно не нулевое.
Отсюда растут "хотелки":
- Получить все нужные данные (и только их) одним запросом
- Типизация данных
- Иметь документацию на это всё по умолчанию
В итоге появился GraphQL, который всё это реализует pic.twitter.com/lu4DECMzuk
onegraph.com — коммерческий продукт, который позволяет интегрироваться со сторонними сервисами посредством запросов GraphQL.
@RIP212 буквально за минуту показал, как быстро написать запрос и получить данные из twitter. Автодополнение, понятный синтаксис, живой результат — всё, что мы так любим.
GraphQL — спецификация, часть Linux Foundation, язык запросов, язык описания схемы и исполняющий движок. Как много в этом слове :)
Даёт документацию из коробки, типизацию, гибкость.
github.com/kamilkisiela/g… — поможет вам сравнивать схемы (разные версии схем). Умеет интегрироваться с GitHub, можно повесить на CI.
graphql-code-generator.com — смотрит в схему и генерирует код на TypeScript, экономит время.
github.com/APIs-guru/grap… — строит зависимости между сущностями в виде взаимосвязанного графа. Удобно для визуального анализа схемы.
engine.apollographql.com — большая обёртка над GraphQL со статистикой, логированием и прочими важными для анализа production-сервера фичами.
Владимир @tadatuta Гриненко с интригующим докладом "Новая платформа уже здесь" pic.twitter.com/dcqNZZiUuZ
Интерфейсы эволюционировали так: перфокарты ➡️ CLI ➡️ desktop ➡️ touch. Кажется, настало время переодеваться и переходить на голосовые интерфейсы.
Speech Recognition API — API, который уже есть в браузере. Он позволяет распознать речь пользователя с определённой вероятностью. Увы, плохая поддержка браузерами.
Speech Synthesis API — для синтеза речи. Можно пробовать добавлять в речь эмоции специальной разметкой. И поддержка браузерами гораздо лучше.
youtube.com/watch?v=laZ1CF… — тут можно посмотреть подробнее про эти API, @obenjiro рассказывал про речевые API на WSD год назад в Петербурге.
Сложность распознавания речи в акцентах, хриплых голосах, произношении детей. Для таких вещей нужно освоить NLU (Natural Language Understanding).
Siri, Alexa, Cortana — у них.
Алиса, Олег, Маруся — у нас.
Мы про голосовые помощники, естественно.
Голосовые интерфейсы могут быть голосовыми, визуальными (сопровождающими голос), дополняющими привычные способы взаимодействия.
Для ряда людей с ограничениями голосовой интерфейс — единственный способ взаимодействия с вашим сервисом.
А ещё дети, которые не умеют читать и писать, уже могут разговаривать с вашим интерфейсом, если он умеет в голос. И это большой рынок.
Навык для Алисы можно написать в 25 строчках JavaScript без единой дополнительной зависимости. pic.twitter.com/aF058tG7yR
github.com/tadatuta/Finge… — пример бота для игры "Палец". Рабочий.
В разработке вам помогут yandex-dialogs-sdk, ngrok, postman и любые инструменты работы с API. Потому что навык — это API.
yandex.ru/dev/dialogs/al… — вот здесь можно найти подробную и понятную документацию про то, как писать навыки для Алисы. Вы удивитесь, как просто можно написать навык. По своему опыту скажу, что за вечер можно его написать, задеплоить и пройти модерацию в каталоге Алисы.
Пользуясь случаем, дам ссылочку на запись своего доклада "Алиса, пойдём во фронтенд!", где рассказывал про разные аспекты написания навыков для голосовых помощников: youtu.be/yjTH8-O3CMA
В разработке голосовых интерфейсов ещё есть много нерешенных вопросов, потому что направление молодое и активно развивающееся. Единых спецификаций мало, устройства разные, API тоже. Это сложнее, чем поддерживать кроссбраузерную вёрстку.
Очень хорошая книжка по проектированию голосовых интерфейсов: Designing Voice User Interfaces (Cathy Pearl)
Даёшь voice first интерфейсы! (с)
Уникальная возможность посмотреть на кухню подкаста «Веб-стандарты». На сцене золотой состав pic.twitter.com/FcTaWCqm3d
Пожалуй, не буду спойлерить. Вы всё сможете послушать (или посмотреть) в понедельник (но это не точно) в iTunes, ВКонтакте, Яндекс.Музыке, Spotify, SoundCloud и на YouTube. Но это интересно 😉
RT @tadatuta: Слайды доклада «Новая платформа уже здесь» github.com/tadatuta/slide… #wstdays
RT @amel_true: Несмертельный трюк — публичная запись подкаста на сцене в прямом эфире #wstdays pic.twitter.com/WUSzeuqIhi
40-ая конференция WSD официально завершилась. Спасибо всем, кто был сегодня с нами. Вёл трансляцию @dark_mefody. Увидимся 😉 pic.twitter.com/ssLjCKUjNa
Слайды и видео ищите на wsd.events/2019/07/13/ через какое-то время.