Бывает так, что мы буквально обнаруживаем себя на каком-то месте работы, в какой-то роли и не понимаем, как, вообще, попали сюда. Бывает так, что спустя 2-3 года разработки на каком-то языке становится понятно, что выбрал не то направление. Или, например, когда-то согласился быть тимлидом, хотя никогда не было интересно заниматься управлением. Как согласился, почему выбрал такое направление — непонятно.

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

Вы пишете на TypeScript, но хотите узнать больше о нем? Уже справляетесь с типизацией компонентов в реакт, но не можете описать HOC? Михаил Башуров поможет разобраться с в этом и расскажет что такое discriminated unions, как использовать вывод типов, зачем нужна номинальная совместимость и другие аспекты программирования на типах

Dart - язык, который был призван исправить изъяны Javascript. И во многом у него получилось! Но при этом он так и не смог стать популярным, пока не появился Flutter.

В этом докладе мы разберем:
- что такого привлекательно в Dart, чтобы использовать его в веб-разработке вместо Javascript;
- какой путь он прошел с самого начала и в какую сторону он будет развиваться;
- почему стоит попробовать Dart, даже если ты никогда на нем не будешь писать;
- как мы использовали Dart в небольшом проекте с небольшой командой и почему готовы использовать его дальше.

Я покажу вам нечто прекрасное, как маленький npm-пакет может погрузить ваше приложение в хаос.

А если серьезно, каждый день мы используем множество npm-пакетов в наших приложениях, но что мы о них знаем?

Я расскажу вам: как правильно собирать npm-пакеты, что выбрать: webpack или rollup? Какой негативный импакт можно занести в приложение, используя неправильно собранный пакет.

Использование WebGL открывает массу возможностей вплоть до построения собственных миров. Окнами в эти миры являются камеры. Именно камера представляет пользователя в программном мире. Именно от того, как заанимирована камера, будет зависеть пользовательский опыт. Различные библиотеки, например, Three.js, предоставляют доступный интерфейс для работы с камерами. Но действительно ли просто управлять такой камерой? Те, кому приходилось заниматься созданием реалистичных облётов, разворотов и других фигур «пилотажа», знают, какой это может быть пыткой. Задача станет проще, если вспомнить, что камера — это физический объект, и воспользоваться приёмом «риг» (Rig). С помощью этого приёма в анимации упрощается работа с составными связанными системами.

Вы узнаете, что такое «риг», какие риги камер бывают, как риги устроены и как создавать программный риг. Мы разберем, как управлять ригом во время анимации, и сформулируем общий подход создания собственного рига под конкретную задачу.

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

Из доклада frontend-разработчики узнают о том, как с помощью serverless-подхода можно реализовать хранение данных, авторизацию и исполнение кода в облаке без настройки и поддержки серверов. Рассматриваются функции как сервис (FaaS) на примере AWS Lambda с GraphQL API для синхронизации данных. Такой подход может использоваться как для быстрого прототипирования, так и в реальных сценариях, когда требуется неограниченное масштабирование вашего решения. На практических примерах мы рассмотрим существующие serverless-фреймворки и архитектуру serverless-приложений.

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

Я развиваю видеоплатформу в Skyeng и за последний год уменьшил негатив пользователей по видеосвязи в 4 раза, изучил все под капотом этой технологии — и хочу доступно рассказать о том, как передается видео в реальном времени через интернет.

Вы узнаете:
* как устроен путь одного видеокадра в мире WebRTC: от генерации вашей веб-камерой до отрисовки на экране собеседника;
* какие препятствия его ждут, и откуда берутся потери пакетов, пинг или jitter;
* что будет, если кадр не дошел до получателя;
* как работает видеокодек, и почему нам часто хватает 3G для конференции в 720p, но все подвисает, когда в кадре происходит много резких действий.

Фронтенд постоянно радует нас большим числом новых стандартов, призванных облегчить и упростить жизнь программистов, но несмотря на это, год от года сборки сайтов пухнут, а количество и сложность технологий растёт. В 2019-ом создать веб-приложение, отвечающее всем современным требованиям, силами одного разработчика почти нереально. Но возможно не всё потеряно, и есть шанс вернуть былую простоту в веб-разработку!

Событийно-ориентированная архитектура (EDA) является одним из важных подходов в нынешнем вебе. Именно данный подход позволил решить проблему c10k и был взят за основу взаимодействия с DOM.

Какие проблемы были обозначены за время ее использования? Что такое отравление обработчика? Как искать эти проблемы в своих приложениях? Ответим на эти вопросы в докладе.

Также рассмотрим детали реализации event loop. Заглянем в libuv и whatwg. И разберем, как Node.js и браузеры работают с событиями.

Знакомьтесь: GitLab. Превосходная система для организации полного DevOps-цикла и настоящий кошмар для frontend-программиста. В 2019 году у нас есть:
- AJAX-запросы, которые в ответ присылают jquery-код, который надо eval'ить;
- адский микс из JQuery, Vue, VueX, Apollo, SPA- и не-SPA-подходов;
- Karma, Jest, RSpec + Capybara;
- CSS, SCSS, собственная дизайн-система на этапе разработки
и многое-многое другое.

Причина? Проекту 7 лет и frontend долгое время разрабатывался по "остаточному" принципу, без уделения нужного внимания best practices, правильным подходам и т.д.

Мы поговорим о структуре и инструментах для итеративного улучшения таких "backend-first"-проектов. Мы поговорим о линтерах и их месте в CI, тестах, их надежности и мутационном тестировании, о пользе снапшотов, чтобы "быстро двигаться вперед", организации CSS и прочих болях

В докладе будут раскрыты основные задачи, которые решались с помощью Relay Modern, а именно:
- data-fetching и refetch;
- мутация данных;
- подписки: что это такое в контексте Relay Modern и как их применять.

1. Сокращение времени на анимацию HTML5-баннеров, благодаря Adobe Animate.
2. Подготовка баннеров под площадки размещения в пару кликов.
3. Подготовка анимации для web.
4. Создание анимации в Animate для использования в GSAP.

* Зачем это нужно?
* О производительности в JavaScript, сильные и слабые стороны браузерных движков.
* Какие проблемы решает WebAssembly.
* Какие выгоды от использования Rust при компиляции в WebAssembly.
* Инструменты для разработки — сборка и публикация модулей, взаимодействие с JavaScript, отладка.
* Прирост производительности по сравнению с JavaScript.
* Внедрение в существующее веб-приложение.
* Опыт применения в реальном проекте.

Десять лет назад в вебе появились шрифты. Ну и как? Когда загружаются, даже красиво! И немного дорого для пользователей, конечно. И ещё дороже для клиентов. Местами дыряво, иногда криво — но это, думаю, Белка чудит. Но если прыгнуло, то значит точно будет красиво. Хотя, может, ну их? Подключим системные и будем как все, нет?

Нет, давайте разбираться.

Вы узнаете, чем могут отличаться email-рассылки от простых писем и что это за собой влечет.

Мы рассмотрим ключевые особенности и ограничения почтовых клиентов в 2019 году.

Будут рассмотрены исключительно практические «кейсы», с которыми мы столкнулись при верстке рассылок для одной крупной компании.

Рассмотрим, почему для рассылок не подходят популярные фреймворки для верстки писем.

Поговорим о нескольких непростительных ошибках, которые часто встречаются при верстке писем.

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

В моем докладе, основанном на глубоком исследовании возможностей Service Worker API (с использованием Cache Storage, Background Fetch, Background Sync) и собранных UX-находках, мы рассмотрим историю оффлайн-веба, важность рассмотрения подключения как привилегии, текущие проблемы (и их решения) и правильные инструменты.

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

Микросервисы, node.js, тестирование производительности, взаимодействие по web sockets, rest, graphql - как это делать без боли, как разрабатывать быстро и не попасть в проблемы распределённых систем. Frontend и backend - как наладить взаимодействие.

Зачем что-то менять, когда у тебя есть традиционное веб-приложение со всеми его плюсами: прозрачное обновление, работа на любой ОС лишь бы в приличном браузере, простота разработки, дизайна и деплоя? Незачем — до того момента, когда тебе нужно взаимодействовать с оборудованием. Сделать это из песочницы, в которой работает приложение в браузере, затруднительно. Для того и создавалась песочница, чтобы защитить локальный компьютер от поползновений веб-сайтов. Что ещё хуже, есть устойчивая тенденция на ужесточение ограничений песочницы.

Мы столкнулись с этой историей, когда разрабатывали кассу. Для преодоления вышеописанных ограничений мы использовали ActiveX. По сути, IE остался единственным браузером, допускающим прямой доступ к локальному компьютеру через проприетарную технологию COM. Это создавало множество проблем: ограничение по поддерживаемым ОС, длительная настройка браузера, неожиданные проблемы на клиентской стороне и тому подобное.

В докладе я расскажу про решение, которое спасло нас: Electron = Chrome + NodeJS. Оно требует установки на рабочие места, но даёт современный браузер и возможность выполнять код за пределами песочницы (благодаря NodeJS). Кроме того, позволяет приблизить UX к типичному десктопному. Сохраняя при этом большинство плюсов веб-приложения.

Что делать, если в бэклоге продуктовой команды появилась задача по разработке мобильного приложения с целью проверки гипотезы востребованности продукта и его удобства для пользователей?

Я знаю ответ, ведь все это я прожил на собственном опыте. В тот момент мне сильно помог React Native, именно поэтому он и станет основной темой моего доклада.

* Почему его стоит выбрать?
* Какие возможности это даст?
* С какими проблемами можно столкнуться?

Помимо этого, будут рассмотрены реальные кейсы и проблемы из практики, а также показан процесс создания первого приложения с возможностью быстрого перехода от React к React Native.

Я расскажу о способах 3D-рендеринга в реальном времени на примере растеризации и трассировки лучей.

Доклад дает представление о том, какие трюки 3D-разработчики используют сейчас, и как трассировка лучей поможет избавиться от них. Я буду использовать технологии Nvidia RTX и Vulkan API, дам советы о том, как это использовать с Javascript и Node.js, а также покажу финальные рендеры.

* Docker - это не только для админов.
* Чем Docker похож на уже привычные нам инструменты.
* Почему именно фронтенд-разработчик, а не кто-то другой, должен уметь собирать своё приложение в контейнер.
* Кейсы использования Docker для фронтенд-разработчика.
* Почему добавление новых людей в команду гораздо проще, если вы используете Docker.

Вы сделали хорошее приложение: красивое и сложное. Но была проблемка — API не успели сделать достаточно быстрым, и приложение грузится медленно. Решение выбрали простое — overlay с ajax-loader, пока всё не загрузится.

Можно ли улучшить это решение? Можно ли сделать ваше приложение доступным, даже пока от сервера не пришли данные и показывать, казалось бы, нечего?

Доклад о скелетонах: откуда они появились, как их можно использовать, а как не стоит. Вы услышите, как мы использовали скелетоны в работе над проектом длиной в 5 лет. И как мы всё это измеряли и подтверждали — да, пользователи любят скелетоны.

Скелетоны — это одна из самых популярных и простых техник "ускорения" — приложение останется таким же медленным, но пользователи будут думать обратное: "Ничего себе, как всё быстро реагирует!".

Условимся — ускорять API мы не будем, все сможет сделать frontend-разработчик! И нам даже не понадобится дизайнер — достаточно Блокнота.

В интернетах принято ругать CSS, если не понимаешь, как с ним работать. Тем не менее, CSS в связке с HTML — Тьюринг-полный язык программирования, а если к ним добавить Houdini API и CSS Custom Properties — можно творить настоящую магию.

В нашей команде МегаФон, нам часто приходится визуализировать физические процессы в привязке к геолокации.

Я поделюсь опытом создания решения для отображения «скругленных», произвольных многоугольников, а также оптимизацией их работы. Опишу путь от использования стандартных «ломаных» полигонов карты до рисования на canvas'е с минимизацией перерисовки кадров. В ходе этого путешествия рассмотрим, как устроены карты изнутри и как они вычисляют координаты в различных пространствах, а также поговорим о рисовании на canvas'е.

Каждый год CodePen подводит итоги самых популярных демок. Последние два года первые места занимают анимации на чистом CSS, а половина топ-100, в принципе, про рисование CSS'ом.

Расскажу обо всем процессе, как собрать сложную анимацию с персонажами на чистом CSS. И, возможно, в этом году самую популярную демку с тегом "pure css animation" сделает кто-то из вас.

Расскажу о том, как мы подходим к проектированию нетривиальных frontend-приложений.

Многие идеи из Domain Driven Design отлично применимы и в функциональной парадигме, однако применение их на практике не всегда может быть очевидным. Например, алгебраические типы данных, которые я объясню на примерах и пальцах, могут быть мощными помощниками для выражения инвариантов. В докладе я раскрою сразу несколько родственных тем: DDD и его польза для frontend-разработчика, описание вашей предметной области с помощью алгебраических типов данных, подходы к описанию инвариантов в коде, комбинаторный стиль, который позволяет удобно выразить создание сложных композитных типов данных. Все темы будут проиллюстрированы примерами из нашей практики на примере курьерской службы доставки.

Про CSS Grid 2 уровня активно разговаривают на западе, а у нас это всё пока в разряде чёрной магии. Да, они ещё почти не поддерживаются, но вспомните, как быстро пришли гриды.

Я расскажу всё, что знаю про CSS Subgrid — что это такое, как это можно будет использовать и как это сможет упростить жизнь в будущем.

Расскажу о типах данных в CSS и языке их описания, как они обрабатываются в calc() и как влияют на производительность кода.

CSS is a handy language that’s often misunderstood, even with the powerful new layout tools that we have at our disposal. This misunderstanding can lead to some wildly over-engineered solutions where the main byproduct is high-interest technical debt, frustration and worst of all, great expense for users.

In this session, I’m going to share with you the tricks that I use to produce highly flexible CSS for design systems, pattern libraries, rich applications and good ol’ websites. We focus on letting the browser make decisions for us, rather than micromanaging them by using algorithms, axioms, the cascade and a solid component strategy.

By the end of the session, I hope that you will see the value in distilling layout problems to their simplest solutions that utilise the power modern CSS and the browser’s capabilities.

Вы заметили тот момент, когда все вокруг стали обсуждать soft skills? Разумеется, невероятно интересно обсуждать гибкие навыки на примере индустрии frontend-разработки, где благодаря низкому порогу входа собралось множество талантливых людей с абсолютно разным профессиональным бэкграундом. Но характерно то, что люди, объясняя пользу soft skills, приводят в качестве доказательной базы лишь рассуждения и истории из жизни.

У меня, как и у многих, есть сильное мнение, что в 2019 году разработчикам развивать soft skills важнее для успешной карьеры, чем hard skills, но мне бы хотелось это доказать необычным образом. Я приведу в пример различные статистические исследования (в том числе собственное) и проанализирую их результаты, а также расскажу, что из всего многообразия гибких навыков стоит развивать в первую очередь и как это легче всего сделать.

We can use Web Components to create reusable solutions. With Custom Elements, the Shadow DOM, HTML Templates, the Web Speech API, and a little ARIA, we can create a progressively more advanced solution for anyone who wants to listen to content; and when the Accessibility Object Model (AOM) lands, we'll be able to make even more accessible Web Components.