- Статистические данные на основе сайта tutmee.ru.
- Подтверждение важности и актуальности качественной адаптивной верстки (на основе статистики).
- Подходы при разработке иностранных и отечественных проектов. Преимущества и недостатки.

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

* История проекта Accelerated Mobile Pages.
* Как это работает.
* Западные кейсы и результаты.
* Отечественные кейсы и результаты.
* Как правильно внедрить AMP.
* Будущее технологии.

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

Тезисы:
* Ограничения и трудности - трансформация десктопа в мобайл (таблицы, картинки, видео и изображения).
* Оптимальное количество брейкпоинтов - какие значения самые важные и что делать с промежуточными?
* Удобные единицы измерения - вычисляемые значения в CSS3 (calc, vh, vw и прочие).
* Расположение навигации на экране - про пальцы.
* Best practice: простые способы снижения нагрузки.
* Worst practice - как делать не надо.
* Мультитач, тапы и свайпы - чтобы работало.
* Детали настройки - вендорные префиксы и прочие системные директивы.

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

Должны ли мы использовать CSS или WebGL для проброса приложения в VR?
Какие решения доступны на текущий момент, и каких ошибок стоит остерегаться?
Почему HTML так же хорош для разработки VR-интерфейсов, как и для обычного, плоского Web?
Как веб-разработчик может быть частью VR-революции?

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

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

- Как современные библиотеки (KnockOut, CellX, MobX, $mol_atom) и фреймворки (MeteorJS, VueJS) обеспечивают эффективное оркестрирование вычислений и берут на себя львиную долю рутины;
- какие проблемы есть у популярных паттернов коммуникации компонентов (Angular, FLUX), и как выглядят правильные двусторонние реактивные связи между компонентами;
- как и почему ОРП позволяет писать короткий, понятный, а следовательно и менее багоёмкий код по сравнению с ФРП и, уж тем более, с ручной актуализацией состояний приложения;
- как принцип тотальной ленивости в применении к загрузке, вычислениям и рендерингу позволяет создавать по-настоящему шустрые приложения, не жрущие батарейку и трафик;
- как писать неблокирующий автоматически распараллеливаемый код в синхронном стиле благодаря ОРП.

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

Более современная версия — server push, SSE, веб-сокеты — лучше, но всё еще на очень низком уровне абстракции. Это биты и байты, ассемблер распределенных систем. Однако давно хочется делать это и проще, и надежнее, и качественно лучше.

В этом докладе мы поднимемся на следующий уровень абстракции и посмотрим, как можно делать клиент-серверную коммуникацию нового поколения: расширенные модели данных, высокоуровневые API, логи событий и т.д. Мы рассмотрим сложные сценарии, проблемы, как их можно решать и какие для этого есть инструменты. Ключевые слова: event sourcing, операционные трансформации, CRDT, Meteor, Apollo, PouchDB, Firebase, Relay, Swarm.js, Logux.

Краткая история редактирования текста в браузерах. Родовые проблемы WYSIWYG-редакторов. Типы и функции современных веб-редакторов.

Обработка различных способов ввода (клавиатура, голос, copy&paste, autocomplete/autocorrect, gesture input). Проблемы с использованием contenteditable и execCommand. Браузерные API: Selection, Input Method Editor, Clipboard, MutationObserver, CompositionEvents. Спецификация W3C Input Events.

Хранение состояния документа (document state): модель данных, виды сущностей, рендеринг в разных форматах, семантика HTML-кода. Способы изоляции CSS в редакторе (iframe, БЭМ-нотация, CSS reset, Shadow DOM). Привычный UX: выделение текста, copy&paste, горячие клавиши, undo/redo. Адаптация контента под разные устройства и экраны. Многопользовательское редактирование и синхронизация изменений. Работа в оффлайн-режиме.

Public API редактора и подключение плагинов. Примеры современных редакторов: Quill от Salesforce, Trix от Basecamp, Draft.js от Facebook. Обзор крупных проектов: Google Docs, iCloud Pages, Office 365.

Будущее rich text editing.

1) Использование принципов SOLID для react-компонентов.
2) Использование stroybook для разработки react-компонентов.
3) Как мы бьем приложение на react-компоненты.
4) Тупые и умные react-компоненты.
5) React-компоненты и стили/

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

В своем докладе я расскажу, как мы преодолели рубеж в 100 тысяч строк в нашей платформе Vimbox (SPA для интерактивного взаимодействия учитель/ученик) без потери качества. Сейчас нам удается работать командой из 10 человек над одним приложением, улучшая код и проводя рефакторинг с небольшими накладными расходами на конфликты, коммуникацию и подключение новых разработчиков к проекту. Я расскажу, с какими проблемами мы столкнулись при увеличении сложности / размера нашего приложения и при увеличении команды.

Основная проблема, которая перед нами стояла, — это сложная система организации зависимостей и состояний в приложении, которая только ухудшалась / усложнялась со времени. Ее мы решили новым подходом — глубокой иерархией состояний вместо pubsub.

Также я отвечу на вопросы: как мы подключаем разработчика в команду за 1 день, расскажу о нашей инфраструктуре (в том числе о тестировании и CI) и о том, как мы за 10 дней сделали платформу для проведения олимпиады Skyeng Super Cup на 100.000 учеников.

Мы расскажем о построении работы действующей offline версии сайта на примере СМИ с миллионной аудиторией. О выборе стека технологий для решении поставленной задачи. О результатах эксплуатации с момента запуска.
В том числе: * Стратегия обновления данных в Service Worker * Проблемы и их решение при работе с оффлайн-средой * Сбор аналитики при отсутствии интернета

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

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

В рамках доклада будут рассмотрены основные аспекты работы с HTML5 Constraint Validation API:
- семантика полей форм;
- доступные методы API;
- прогрессивное улучшение валидации (CSS → JS);
- глубина и особенности реализации API в браузерах.

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

В докладе предлагается новый подход к написанию SPA с использованием библиотеки redux-saga. Будет много примеров, рецептов использования и демонстрация открывающихся возможностей.

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

Про Grid Layout сказано уже много. Большое количество статей, примеров, инструментов. Однако только сейчас мы можем начинать свободно пользоваться этой спецификацией. Пора заканчивать читать справочники и начинать использовать Гриды в реальном мире.

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

Разработка API/Framework/встраиваемого контента сильно отличается от разработки обычного frontend-приложения. На примере нашего API Яндекс.Карт я расскажу, чем именно.

+ Какие задачи обычно решают разработчики API?
+ С каким проблемами сталкиваются?
+ Какие есть ограничения в разработке?
+ Чем еще должен заниматься разработчик API, кроме непосредственно разработки?

— Почему типографика — это важно;
— принципы построения интерфейса и дизайн-систем, основанные на шрифте;
— дизайн, построенный на базовом размере шрифта, «из коробки» pixel perfect;
— модульная шкала для управления размерами;
— зачем нужны макетные сетки и вертикальный ритм;
— сколько компонентов нужно для «счастливой жизни».

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

Это история о том, как вести параллельную работу над дизайном и frontend нескольких десятков систем, представляющих из себя единую экосистему.

Как от “стихийной” разработки и уймы повторяющегося кода перейти к написанию библиотек для самих себя, сделать своими пользователями своих же разработчиков, а что-то даже выложить в open source. И почему выкладывать в open source важно, и вам тоже следует это делать.

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

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

Работая в одной из крупнейших IT-компаний в Европе, мы все время нуждаемся в крутых разработчиках.

В докладе я расскажу, как мы их ищем (и не находим), «выращиваем» вне компании, нанимаем, а затем продолжаем растить уже внутри.

Как писать тесты?
Как запускать тесты?
Кто все сломал?

Все три вопроса рассмотрены в докладе. Также будет демо интеграции проекта, покрытого тестами, и cloud-based-сервиса по запуску этих тестов (github+travis).

Кроме того, расскажу об опыте по сокращению времени прогона тестов; о том, как добавить тесты в случае, если у вас уже есть большое приложение, но все еще без тестов.

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

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

Каждый разработчик сталкивается с добавлением сторонних счетчиков и прочего чужого кода на сайт. А современный e-commerce хочет знать о пользователе все. Поэтому мы прошли путь от нескольких сторонних скриптов до сотни.

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

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

Нам постоянно нужно от CSS больше того, что в нём (или браузерах) есть прямо сейчас.

История, рассказывающая о том, какими способами мы решали(ем) проблемы недостающих нам возможностей (css frameworks, css polyfills, preproccessors, “post”-proccessors) и о Houdini, который должен положить конец этой ерунде, позволив описывать разработчикам с помощью JavaScript не просто полифилы, а полноценные реализации, не мешающие производительности.

Расскажу о том, что мы можем контролировать в CSS сейчас, что сможем с Houdini, и что в нем есть на текущий момент с примерами демок.

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

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

+ Реафакторинг - понятие.
+ Когда нужен, когда не нужен.
+ Как правильно ставить цели для рефакторинга.
+ Средства для рефакторинга в IDE и простейшие средства.
+ Рефакторинг из консоли.
+ Применяем JavaScript для того, что рефакторить JavaScript.
+ Подводные камни.

Очень много примеров.

Паразитизм — форма взаимоотношений между организмами различных видов, из которых один (паразит — aka Angular 4+) использует другого (хозяина — aka React) в качестве среды обитания и источника питания, нанося ему вред, но при этом не убивая.

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

Мы рассмотрим оба подхода — о том, как выживать в суровом мире Angular 4+ с помощью React-экосистемы (оставляя ее в живых), и о том, как в конечном счете "убить" своего "хозяина".

Из этого доклада вы узнаете, как работать с Redux, Mobx, GraphQL и рядом других основополагающих кирпичиков React-экосистемы.

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

Если у вас еще не дошли руки до react native, но всегда хотели разобраться - приходите обязательно! Из моего доклада вы сможете, как минимум, получить представление об этой технологии.

Angular 2 отрелижен, React и подавно. Копья поломаны, мечи перекованы на орала, страсти уже поутихли и, вроде как, статус кво восстановлен. Кто-то использует один инструмент, кто-то другой, разве что, иногда раздаются возгласы: "А у них...!"

Однако не всё так просто. В конце концов, мы не только пишем код, но и решаем однотипные проблемы:
* Как сделать наше приложение быстрым?
* Как писать понятнее и проще?
* Как писать быстрее?

Кто-то может сказать: "Эту тему уже миллион раз обсасывали, зачем опять?". Но, все же, если вы стартуете новый проект или решили переписать старый, перед вами всё равно встанет проблема выбора. И даже если вы считаете, что всё очевидно — это далеко не так.

Вот уже год как Wrike использует Angular 2 в бою. И вроде всё хорошо, но иногда закрадываются сомнения: “А вдруг мы свернули не туда?”

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

Мистер Красный (Евгений Гусев) и мистер Синий (Илья Таратухин) спорят, доказывают, демонстрируют примеры, пытаясь понять, что же лучше.

Будет боль, будет спор, будет вывод.