Фронтенд Почты Mail.Ru долгое время являлся огромным монолитом, в котором появлялось всё больше проблем. Поэтому новую функциональность стали реализовывать как отдельные сервисы.

Основные проблемы, которые мы решили:
- Ускорили процесс разработки.
- Уменьшили время ручного тестирования и автотестов.
- Стали внедрять все больше новых технологий, так как смогли быстро обкатывать их в реальных проектах.
- Увеличили читабельность кода, каждый сервис получился достаточно простым и сделанным по определенному шаблону.
- Тот код, что мы пишем на фронте, полностью смогли использовать в наших Android и iOS.
- Имеем возможность быстро с нуля переписать проект.
- Значительно уменьшили порог входа в проект.

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

Прогрессивные веб-приложения становятся все популярнее. А современные возможности браузера поражают.

В этом докладе мы разберем, как с помощью современных возможностей браузера сделать свое приложение более нативным и дружелюбным для пользователя. Будут примеры применения новейших браузерных API на реальном проекте, которые покажут, как выделить свое приложение среди конкурентов.

Истории из реальной жизни реализации нескольких анимаций в браузере. Будет рассказано о способах оптимизаций анимаций и о возможных альтернативных путях для рисования прямо в браузере.

The primary subject is CSS Fonts 4, which primarily deals with how to use Variable Fonts on the Web, and restyling Color Fonts. That specification has changed a lot in the last few months, and continues to do so; I am actively involved in developing that specification, and I will be explaining the latest changes.

70% of websites use downloadable fonts now, at least at a basic level. But with CSS Fonts 4 support for OpenType Variable Fonts — a single font file that behaves like multiple fonts, or even an infinity of morphing fonts — and for restyling the palette of Color Fonts, the capabilities opening up for typography on the web are extraordinary. In this session, Chris Lilley explains the most recent, cutting-edge developments and also recaps OpenType font features from CSS Fonts 3, to further improve typography with CSS. Learn what's possible today, and in the near future.

В конце прошлого года технология WebRTC стала доступна во всех четырех основных браузерах. Но сбылась ли мечта убить Flash для голосовых и видеозвонков, которую группа инженеров воплощала в жизнь с 2009 года?

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

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

Первая мысль - давайте перепишем приложение на Elm!
Первый вопрос - а что это такое?
Первое сомнение - а возможно ли переписать приложение не сразу, а по "кусочкам"?

Elm - это не фреймворк. Elm - это язык, который компилируется в JavaScript. За 40 минут я расскажу вам, что именно у нас тормозило, что не устраивало в архитектуре, какие решения мы пробовали, и они нам не понравились (спойлер: React, TS, Vanilla.js, coffeescript) и как, наконец-таки, мы переписываем наше приложение по частям на Elm и планируем в будущем оставить только его в приложении (долой AngluarJS!).

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

Мы проговорим только то, что касается именно веб-разработки, в рамках, например, React. Какие плюсы, минусы, узкие места. Отдельно проговорим про мобильную и веб-разработку. На что стоит обратить внимание.

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

Как объяснить бизнесу, что вам нужно полгода, чтобы все переписать с нуля на этом модном и современном фреймворке (спойлер: никак).

В своем докладе расскажу об опыте миграции нашего большого и сложного приложения с Backbone (и иже с ним jQuery/underscore) на Vue. Как мы смогли это осуществить, с какими проблемами сталкивались и почему нам это удалось без вреда для бизнеса (а даже наоборот). Доклад будет интересен всем без исключения разработчикам, а не только ценителям jQuery и Vue.

Кажется, что разработчикам очень нравится Vue, но мало кто решается использовать его на большом проекте.
Чего боятся разработчики, пожелав выбрать Vue в крупной разработке?

Как разработчик N1.RU, весь фронтенд которого работает на Vue, я расскажу о том, какие возможности сегодня дает разработчику экосистема Vue, и поговорю о страхах и сомнениях разработчиков при выборе Vue для большого проекта.

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

Как использовать изоморфность для написания абсолютно любых веб-приложений - от простых сайтов до сложных SPA. Что делать, если нужно, чтобы веб-приложение загружало мегабайтные бандлы без ущерба для скорости загрузки и индексировалось поисковиками. Как сделать полноценный Progressive Enhancement, чтобы даже юзеры с выключенным JS могли использовать ваше сверхсовременное веб-приложение. Как при правильном подходе добиться 100% общего кода в любом окружении. А также другие интересные кейсы.

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

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

Сегодня многие клиенты хотят получить персонализированную библиотеку элементов, созданную под их стиль. Мы разберемся с тем, какие плюсы и минусы есть у разных решений, и, вообще, всегда ли стоит создавать библиотеку элементов или в некоторых случаях это бесполезно? Разберем принципы, нюансы и подводные камни, а также раскроем следующие темы:
1) Кому и зачем нужны библиотеки элементов;
2) Частые требования к реализации;
2) Как грамотно реализовать репозиторий под библиотеку;
3) Компоненты: правильная верстка - это еще не всё;
4) Настраиваем сборщик: меньше действий, больше удобства;
5) NPM-пакеты на практике;
6) Документация - это важно!

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

Тесты, тесты, кругом тесты. Этот доклад снова про тесты. Но не про привычные нам юниты, а про е2е.

Мы рассмотрим, что же за зверь такой эти "е2е-тесты". Как правильно их писать, что такое PageObject pattern, какие инструменты нам для этого доступны, и какие выбрали мы.

Также поговорим про BDD-подход в тестировании. Разберем cucumberjs как инструмент для использования BDD и посмотрим, как его использовать для написания тестов.

После чего немного поговорим, как все это встроить в Agile-процесс разработки. Какую роль в этом могут играть владельцы продуктов, а также, почему им это интересно и выгодно.

После чего посмотрим небольшую демку - приложение, написанное на Angular и тестируемое с помощью этих инструментов.

Как разработчики, мы всегда в поиске самых удобных и простых в использовании инструментов, фреймворков, библиотек, плагинов для новых или текущих проектов. То, с чем и как мы работаем, может существенно повысить (или понизить) качество и продуктивность нашей работы. Как правило, начав писать свои первые проекты, мы очень неохотно делаем переход с одного инструмента на другой, меняем среды разработки и внешнее оформление редактора. Но так ли этот консерватизм полезен?

Многие годы являясь ярым поклонником текстового редактора Sublime Text, я провела небольшой эксперимент, в ходе которого пользовалась несколькими популярными редакторами и IDE (Atom, Visual Studio Code и Web Storm), и хочу поделиться своими впечатлениями от работы в каждом из них. Я сравню их функциональные возможности, расскажу об их особенностях для различных проектов и технологий, кратко коснусь производительности этих редакторов для больших и сложных проектов. А в конце я подведу итог, чем же простые текстовые редакторы могут быть лучше интегрированных сред разработки.

Войны о необходимости статической типизации в мире JavaScript не утихают ни на минуту. Автор и сам регулярно выступает с одной из баррикад, распекая TypeScript за их слабый вывод типов, Flow - за отсутствие экосистемы, а обычный JS - за то, что он еще существует. Но что, если отставить вопросы веры и задаться простым вопросом - а позволяют ли типы работать продуктивнее? Существующее исследования говорят, что нет. Интуиция и личный опыт автора - что да.

Этот доклад - анализ статистики, накопленной 40 разработчиками из 6 стран мира в течение полугода. В докладе я приведу очевидные, неочевидные и совсем контр-интуитивные выводы про пользу типизации в мире JavaScript.

Удаление неиспользуемого CSS-кода – одна из задач Frontend-оптимизации на сайте Booking.com. Суммарно по всем пользовательским сценариям и их вариациям – на сайте более 50K различных CSS-селекторов. Определить, какие из них актуальные, просто проанализировав кодовую базу – невозможно. А ввиду большого количества сценариев/вариаций (более 2000) с возможными динамическими изменениями страницы невозможен и вариант ручного тестирования.

Мы получили code coverage CSS-кода, используя crowd source-подход. Я расскажу, на чем основан выбор такого подхода, и как при его использовании мы минимизировали негативное воздействие на пользовательский опыт (а в некоторых случаях и избежали).

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

В качестве результата от такой работы можно видеть улучшение времени на Critical Rendering Path. А также повышение velocity нашей команды разработчиков.

У нас в Uploadcare основной сайт — монолит на Django. Разрабатывать клиентскую часть в экосистеме монолита было неэффективно, и мы приняли волевое решение сделать отдельное приложение для фронтенда на Node.js.

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

Спойлер: всё получилось хорошо, бэкендеры и фронтендеры счастливы!

Производительный сайт - одна из главных целей современного веб разработчика. И поэтому нам нужен инструмент, который позволит:
- определять «проблемные» места, чтобы понимать, где именно нужны оптимизации;
- искать баланс между количеством функционала и скоростью загрузки у клиентов;
- контролировать, что после релиза мы ничего не “сломали”.

В докладе поговорим о том, что такое RUM (real user monitoring), и как он может помочь современному веб-разработчику делать свою работу лучше, а именно:
- какие метрики измерять и мониторить;
- что нужно знать про агрегацию собранных данных;
- какие инструменты могут со всем этим помочь.

Первая мысль, приходящая на ум каждому программисту, который видит новый код: "Пора все переписывать". В этом докладе я расскажу, как бороться с такими мыслями, чем они плохи, какие есть подходы к рефакторингу, и чего им можно добиться на примере компьютерной игры.

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

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

Backbone, Knockout, Ember, React, Angular, Vue — количество фронтенд-фреймворков растёт каждый день. Но задумывались ли мы когда-либо над тем, что всё это время двигало вперёд их развитие?

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

Более того, эти проблемы специфичны не только для фронтенда и уходят корнями в эпоху становления computer science — 80-90-e годы прошлого века. В докладе вы узнаете, как вопросы реализации FRP и различных видов DSL связаны с тем, как сейчас устроены фреймворки и со способами оптимизации их работы.

От теории я перейду к практике: покажу различные практические способы оптимизации фронтенд приложений и проанализирую их преимущества и недостатки.

Приложения на стеке React-Redux стали уже одним из стандартов в современной фронтенд-разработке. Вместе с Redux в проектах используют redux-thunk, redux-saga или какой-нибудь другой похожий инструмент. Они позволяют общаться с API, обрабатывать сложные случаи. Эти решения объединяет то, что они все — middleware с определенным форматом. Middleware в Redux — это очень мощный инструмент, который позволяет решать любые задачи по построению бизнес-логики, разделить уровни MVC.

Мы поговорим о том, как кастомные middleware упрощают нашу жизнь в различных случаях и заменяют redux-thunk, sagas.

Загрузка, кэширование и обработка данных усложняет работу с состоянием приложения. Такие библиотеки, как Redux/MobX, помогают решить эту проблему, особенно, если вы работаете с REST API. Но что, если мы будем использовать GraphQL для общения с сервером? Нужны ли будут нам эти библиотеки, и какие мы преимущества от этого получим?

В докладе я расскажу о том, как можно контролировать сложность React-компонентов и повторно использовать логику с помощью компонентов высшего порядка (HOCs).

На примере небольшого e-commerce приложения будут рассмотрены распространенные причины распухания кода компонентов (управление перерисовкой, граничные условия и т.д.), а также предложены методы их устранения с использованием HOC.

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

Делаем open-source проект интуитивно привычным для разработчиков.

В частности, вы узнаете:
- Что обозначают все эти бейджи на проектах.
- Что такое code style и какой из них выбрать (standard, airnbnb и т.п.).
- Что такое code climate.
- License- and Contribution-файлы.
- Gitignore and npmignore.
- Продвижение проекта (как бесполезный компонент набрал больше 100 звёзд, и почему полезный плагин не набрал даже 30).

До того, как написанный нами код будет исполнен, он проходит довольно долгий путь. Мы рассмотрим каждый шаг на этом пути на примере движка V8 и поймём, что даёт нам понимание того, что происходит с кодом.

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

Вишенка на торте — разберёмся, где в схеме парсинг-исполнение место для WASM, и является ли он серебряной пулей для повышения производительности нашего кода.

CSS Secrets was a series of talks that were loved by audiences all around the globe and led to Lea's bestselling book “CSS Secrets”. The premise is simple: Ten surprising yet practical things you didn't know you could do in CSS, live-coded in Lea's trademark interactive presentation style. This third installment of the series will include new juicy secrets related to CSS Variables, grid layout, variable fonts, among other things. Prepare to be inspired again as Lea debuts ten all-new feats of advanced CSS wizardry, which will help you understand CSS at a much deeper level.

Знакомый js, инструменты и многое другое сделали Nodejs популярной платформой для разработки.

"Все что вы думаете о EventLoop в Nodejs неверно" — под таким заголовком вышла несколько месяцев назад статья о работе EventLoop в Nodejs. "Что они себе позволяют" — подумал я? Пришлось снова погрузиться в исходники Nodejs и разобраться, кто из них прав.

В докладе расскажу про архитектуру, событийный цикл, I/O, как работает загрузчик модулей и что происходит, когда выполняется js-код. Разбираемся с устройством платформы Nodejs.

Начать стоит с того, что было:
5 разных UI-китов, около 400 сайтов на shared-хостингах, битрикс, спагетти-код на jquery.

К чему хотелось прийти:
Сократить время разработки и поддержки UI-китов, добиться унификации компонентов. Все это в условиях отсутствия SSR и без потери в качестве SEO. А еще, чтобы эти самые киты можно было центрально обновлять.

Мы выбрали написание собственного самоката, с оглядкой на существующие фреймворки. Спустя год нам удалось перевести 2 из 5 китов на новые рельсы, выкатить новый дизайн на 150 сайтах, выработать подход по работе с компонентами, научить бэкендеров БЭМ-у, попробовать рендерить pug на node.js через битрикс (!), развернуть свой npm-сервер и систему сборки и деплоя.

У javascript насквозь асинхронная природа, но при этом один поток - как же так? Как пользоваться асинхронностью и не выстрелить себе в ногу?

Мы рассмотрим, что такое event loop, и с чем его едят, поглядим, чем таски отличаются от микротасок, как браузеры управляют приоритетами задач, и что говорит на этот счет спецификация. Также узнаем, в чем отличия в работе event loop в Node.js, и проведем параллели с браузерами.

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

В своём докладе я расскажу о процессе вынесения общего кода в библиотеку. На какие методы переиспользования кода мы обратили внимание, по примеру Angular Material. О проблемах, которые могут возникнуть из-за ограничений, накладываемых инструментами сборки библиотеки, при использовании существующего кода. А также сравню некоторые наши компоненты с компонентами из Angular Material, решающими похожие задачи, чтобы понять, можем ли мы их использовать и оправданы ли затраты на переписывание текущего кода на Angular Material CDK.

Мы потратили больше 100 часов на обсуждения, эксперименты и код. Если у вас есть похожая задача, вы сможете их сэкономить.

Статичная страница сайта, монументальная как памятник архитектуры n-го века или сайт с полным погружением и эффектом присутствия, а, может, кислотная дискотека мерцающих баннеров - что есть достаточная и необходимая анимация веб-страниц?

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

Редкий проект обходится сегодня без участия Babel или TypeScript в сборке. Оба можно расширять под свои нужды.

- Как работает транспиляция.
- Как написать свой плагин.
- Простой пример: assert'ы.
- Транспиляция ES2015-модулей в свою модульную систему.
- Автоматические понифилы при использовании TypeScript.

- Начну с обсуждения проблем, которые приходится решать при разработке больших проектов — выделение общих частей, работа с их версионированием и прочие способы контроля сложности проекта. Всё это — чтобы подвести к необходимости использования монорепозиториев в проекте;
- Перейду к монорепозиториям как способу организации проектов, который по дизайну способствует модульности проекта;
- Опишу возникающие проблемы при подобной структуре проекта и способы их решения, подведу к тому, что есть лакуны в инструментах, помогающих в разработке проектов, базирующихся на монорепах. А именно: интегрированность внутрь проекта и возможность быстрого расширения функционала за счет проекта;
- Затрону вопросы модульной сборки проекта на этапе его старта с возможностью набора необходимого функционала и физическим отключением и удалением всего ненужного;
- Расскажу про Rispa как один из способов решения данной задачи с точки зрения управления и работы с проектом.

Нативный CSS — это круто. За последние годы CSS действительно очень хорошо вырос в плане возможностей. Многие начинают задумываться, а стоит ли использовать лишнюю прослойку между нативным CSS и браузером в виде препроцессора? Если можно использовать все возможности препроцессоров в нативном CSS.

Разберемся, в каком состоянии сейчас CSS, что именно он может заменить от препроцессоров и ответим на главный вопрос — готов ли CSS заменить препроцессоры.

Headless-браузеры уже давно стали незаменимым инструментом разработчиков. С их помощью можно проводить тестирование кода, проверять качество и соответствие верстки и другое. Но проблема в том, что разработчики мало знают про то, как устроен и работает их инструмент. Расскажу про Headless Chrome, его компоненты, их устройство. Покажу интересные сценарии использования Headless Chrome. Вторая часть будет про Puppeteer - удобную Node.js-библиотеку для управления Headless-режимом в Google Chrome и Chromium.