Шаблонизация основанная на работе с DOM становится трендом: React, Ractive, Basis.js уже используют этот подход, другие идут в эту сторону. Главным преимуществом подхода считается скорость, но оно далеко не единственное!
В докладе немного рассказано о возможностях, что дает DOM подход.
В последнее время во фронтенде появляется столько нового и внедряется настолько быстро, что не все успевают осознать последствия. Хорошо это или плохо? Рассмотрим некоторые новинки с точки зрения «за», а главное – «против».
Конференция FrontTalks, Екатеринбург, 19 сентября
Видео: https://vimeo.com/107694664
С ростом кодовой базы становится все более очевидной необходимость использования компонентного подхода, когда каждая логическая часть обособлена. Если говорить про JavaScript, то в нем есть области видимости, опираясь на которые можно соорудить изолированные компоненты. Но в CSS нет подобных механизмов, поэтому и придумываются Shadow DOM (Web Components) и различные методики вроде БЭМ.
Но что если взглянуть на проблему под другим углом? Адаптируя подходы, что уже используются для других задач, можно получить куда больше выгоды, чем просто изолированные стили!
FrontendConf, Москва, 21 мая 2015
WSD, Санкт-Петербург, 20 июня 2015
Запись трансляции: https://youtu.be/V7bnSOwuO4M?t=1h31m33s
Не бойся, это всего лишь данные... просто их многоRoman Dvornov
За последние 15 лет веб сильно изменился и ускорился. Но большинство по-прежнему боится большого количества данных и сложной логики на клиенте. Потому что "тормозит".
Я хочу сломать стереотипы и показать, как начать делать крутые штуки на client-side. Тысячи и сотни тысяч объектов, разные типы, зависимые вычисляемые свойства, агрегация, множество вариантов отображения. Все это в вашем браузере. Без тормозов, регистраций, смс.
Видео этого доклада на конференции DUMP, Екатеринбург, 14 марта 2014: https://vimeo.com/90836493
Шаблонизаторы упрощают процесс формирования HTML и только. Но браузеру нужен совсем не HTML, а DOM. Необходимо преобразование. И вот тут начинается самое интересное: танцы с бубном и стрельба по ногам. В докладе пойдёт речь об общепринятом подходе получения DOM фрагмента, постпроцессинге и альтернативах. Сравним, измерим и узнаем как это делать быстрее всего.
Basis.js - почему я не бросил разрабатывать свой фреймворк (extended)Roman Dvornov
Опенсорсный JavaScript-фреймворк с нестандартными подходами, ориентированный на разработку одностраничных приложений. Обновление шаблонов и стилей без перезагрузки страницы, развитые механизмы работы с данными, высокая производительность, инструменты разработчика и многое другое.
Доклад с конференции WSD, Санкт-Петербург, 8 июня 2013
Видео: http://www.youtube.com/watch?v=cVbbkwkhNQg
В последнее время во фронтенде появляется столько нового и внедряется настолько быстро, что не все успевают осознать последствия. Хорошо это или плохо? Рассмотрим некоторые новинки с точки зрения «за», а главное – «против».
Конференция FrontTalks, Екатеринбург, 19 сентября
Видео: https://vimeo.com/107694664
С ростом кодовой базы становится все более очевидной необходимость использования компонентного подхода, когда каждая логическая часть обособлена. Если говорить про JavaScript, то в нем есть области видимости, опираясь на которые можно соорудить изолированные компоненты. Но в CSS нет подобных механизмов, поэтому и придумываются Shadow DOM (Web Components) и различные методики вроде БЭМ.
Но что если взглянуть на проблему под другим углом? Адаптируя подходы, что уже используются для других задач, можно получить куда больше выгоды, чем просто изолированные стили!
FrontendConf, Москва, 21 мая 2015
WSD, Санкт-Петербург, 20 июня 2015
Запись трансляции: https://youtu.be/V7bnSOwuO4M?t=1h31m33s
Не бойся, это всего лишь данные... просто их многоRoman Dvornov
За последние 15 лет веб сильно изменился и ускорился. Но большинство по-прежнему боится большого количества данных и сложной логики на клиенте. Потому что "тормозит".
Я хочу сломать стереотипы и показать, как начать делать крутые штуки на client-side. Тысячи и сотни тысяч объектов, разные типы, зависимые вычисляемые свойства, агрегация, множество вариантов отображения. Все это в вашем браузере. Без тормозов, регистраций, смс.
Видео этого доклада на конференции DUMP, Екатеринбург, 14 марта 2014: https://vimeo.com/90836493
Шаблонизаторы упрощают процесс формирования HTML и только. Но браузеру нужен совсем не HTML, а DOM. Необходимо преобразование. И вот тут начинается самое интересное: танцы с бубном и стрельба по ногам. В докладе пойдёт речь об общепринятом подходе получения DOM фрагмента, постпроцессинге и альтернативах. Сравним, измерим и узнаем как это делать быстрее всего.
Basis.js - почему я не бросил разрабатывать свой фреймворк (extended)Roman Dvornov
Опенсорсный JavaScript-фреймворк с нестандартными подходами, ориентированный на разработку одностраничных приложений. Обновление шаблонов и стилей без перезагрузки страницы, развитые механизмы работы с данными, высокая производительность, инструменты разработчика и многое другое.
Доклад с конференции WSD, Санкт-Петербург, 8 июня 2013
Видео: http://www.youtube.com/watch?v=cVbbkwkhNQg
Использование компонентного подхода это тяжеловесно, медленно, не гибко. Так ли это?
Доклад с фестиваля 404, Самара, 13 октября 2013
Видео: https://www.youtube.com/watch?v=QpZy0WW0Ig4
Инструменты разные нужны, инструменты разные важныRoman Dvornov
В мире фронтенда уже существует большое количество инструментов: как браузерных, так и консольных. Но достаточно ли этих инструментов? Мне кажется, что нет. Веб-приложения становятся все больше и сложнее, и многое остается вне нашего поля зрения. Потому фреймворки и приложения должны предоставлять дополнительные инструменты, упрощающие разработку и улучшающие понимание того, что же происходит у них там — «под капотом». В ходе доклада я расскажу о таких инструментах: какими они могут быть, какие задачи могут решать, что необходимо для их создания.
CodeFest, Новосибирск, 28 марта 2015
http://www.youtube.com/watch?v=HMTc3DERw5c
Видео: https://www.youtube.com/watch?v=IUtbbN9aevU
Веб-приложения становятся все больше и сложнее, так что многое остается вне нашего поля зрения. Поэтому фреймворки и приложения должны предоставлять дополнительные инструменты, упрощающие разработку и понимание того, что же происходит у них там — «под капотом». В ходе доклада я расскажу о таких инструментах: какими они могут быть, какие задачи решать, что необходимо для их создания.
SPA Meetup, 28 февраля 2015, Москва, Авито
Есть такая штука как инструментирование кода. Мало кто знает о ней, даже пользуясь результатами ее применения. Между тем, с инструментированием можно делать много всего интересного и, главное, полезного. Например, это может вам помочь лучше понять код или сделать процесс разработки более эффективным. Примеры инструментирования кода и принципы его работы.
Тестировать регресс верстки скриншотами модно, этим никого не удивишь. Мы давно хотели внедрить этот вид тестирования у себя. Все время смущали вопросы простоты поддержки и применения, но в большей степени вопрос пропускной способности решений (производительности). Хотелось решения, простого в использовании и быстрого в работе. Готовые решения не подошли, и мы взялись делать свое.
В докладе расскажем, что из этого вышло, какие задачи решали и как мы добились того, чтобы тестирование скриншотами практически не влияло на общее время прохождения тестов.
Видео: https://youtu.be/ULwdj_Vr_WA
Радости и гадости регрессионного тестирования вёрстки / Алексей Малейков (HTM...Ontico
Совместно с университетом ИТМО мы запустили курс, посвященный основам HTML и CSS. Уже на момент регистрации на этот курс записалось более 12 тысяч студентов. Перед нами стояла задача разработать систему, которая будет автоматически проверять итоговые проекты на соответствие заранее подготовленному макету. В качестве основной техники для проверки было выбрано регрессионное тестирование.
В каждом проекте мы проверяли разметку, сетку и стилевое оформление не только страницы целиком, но и отдельных блоков. Одной из главных проблем был поиск этих самых блоков, так как о том, какой будет верстка студентов, мы не знали ничего — ни какие теги они использовали, ни какие классы и идентификаторы были задействованы. Имели только общее представление о структуре.
В докладе я расскажу, от чего мы отталкивались при построении этой системы, как мы разбирали и анализировали проекты. Какие инструменты и технологии мы для этого использовали и почему. Какие подводные камни вылезали, и какие возникали проблемы.
«Организация Frontend-разработки на крупном проекте» — Дмитрий Кузнецов2ГИС Технологии
Как создать Front End-команду для высоконагруженного проекта? Спикер расскажет, как можно выстроить эффективный процесс фронтенд-разработки с упором на технические аспекты: — Команда фронтенд-разработчиков. Зоны ответственности между теми, кто программирует UI (верстальщики), и теми, кто отвечает за бизнес-логику (Javascript-программисты). Идеальный состав команды. — Настроенный технологический процесс. Модульная организация (подготовка дизайна → разработка формата данных → создание шаблона → навешивание событий → тесты). — Разработка вместе с тестированием Unit-/DOM-тесты и подход PixelPerfect. — Вёрстка независимыми блоками и встроенный в приложение режим для вёрстки блоков.
Доклад о подходе к отслеживанию потоков данных, формирующих окружение, в котором пользователь решает свои задачи.
На примере реализации для конкретного фреймворка будет озвучена идея, как сделать инструмент для отслеживания изменений данных на странице приложения для вашего технологического стека.
Целевая аудитория
Разработчики крупных web-приложений, регулярно сталкивающиеся с проблемой, как уследить за изменением большого количества данных, формирующих интерфейс пользователя, решающих задачу эффективно разобраться с потоками данных для устранения неполадок приложения.
Человеческий организм устроен сложно. Если с ним что-то не так, то для диагностики используют магнитно-резонансный томограф.
Большие одностраничные приложения тоже устроены сложно. Чтобы их починить или обвесить новым функционалом, требуется вникнуть в их устройство. Для этого нередко приходится засучивать рукава и с головой погружаться в самую глубь проекта. И немалая часть проблем связана именно с бизнес логикой и потоками данных. Но что если у нас будет возможность проникнуть в структуру данных, способ увидеть связи между ними и отслеживать то, как они влияют друг на друга? Такой способ, чтобы не требовалось вскрытия скальпелем - все как с МРТ.
В докладе речь пойдет о собственных разработках в этой области.
Для того чтобы охватывать широкую аудиторию, WebGL приложение должно быть не только быстрым, но и стабильным.
В этом докладе мы обсудим проблемы, которые возникли у нас при разработке API панорам, и как мы их решали. Также затронем опыт других компаний и посмотрим, как помогают разработчику в достижении стабильности популярные открытые библиотеки.
Talk is about CSS minification problem, how minifiers work, new advanced optimisations, how minification influences on performance, CSSO reborn and future plans.
Использование компонентного подхода это тяжеловесно, медленно, не гибко. Так ли это?
Доклад с фестиваля 404, Самара, 13 октября 2013
Видео: https://www.youtube.com/watch?v=QpZy0WW0Ig4
Инструменты разные нужны, инструменты разные важныRoman Dvornov
В мире фронтенда уже существует большое количество инструментов: как браузерных, так и консольных. Но достаточно ли этих инструментов? Мне кажется, что нет. Веб-приложения становятся все больше и сложнее, и многое остается вне нашего поля зрения. Потому фреймворки и приложения должны предоставлять дополнительные инструменты, упрощающие разработку и улучшающие понимание того, что же происходит у них там — «под капотом». В ходе доклада я расскажу о таких инструментах: какими они могут быть, какие задачи могут решать, что необходимо для их создания.
CodeFest, Новосибирск, 28 марта 2015
http://www.youtube.com/watch?v=HMTc3DERw5c
Видео: https://www.youtube.com/watch?v=IUtbbN9aevU
Веб-приложения становятся все больше и сложнее, так что многое остается вне нашего поля зрения. Поэтому фреймворки и приложения должны предоставлять дополнительные инструменты, упрощающие разработку и понимание того, что же происходит у них там — «под капотом». В ходе доклада я расскажу о таких инструментах: какими они могут быть, какие задачи решать, что необходимо для их создания.
SPA Meetup, 28 февраля 2015, Москва, Авито
Есть такая штука как инструментирование кода. Мало кто знает о ней, даже пользуясь результатами ее применения. Между тем, с инструментированием можно делать много всего интересного и, главное, полезного. Например, это может вам помочь лучше понять код или сделать процесс разработки более эффективным. Примеры инструментирования кода и принципы его работы.
Тестировать регресс верстки скриншотами модно, этим никого не удивишь. Мы давно хотели внедрить этот вид тестирования у себя. Все время смущали вопросы простоты поддержки и применения, но в большей степени вопрос пропускной способности решений (производительности). Хотелось решения, простого в использовании и быстрого в работе. Готовые решения не подошли, и мы взялись делать свое.
В докладе расскажем, что из этого вышло, какие задачи решали и как мы добились того, чтобы тестирование скриншотами практически не влияло на общее время прохождения тестов.
Видео: https://youtu.be/ULwdj_Vr_WA
Радости и гадости регрессионного тестирования вёрстки / Алексей Малейков (HTM...Ontico
Совместно с университетом ИТМО мы запустили курс, посвященный основам HTML и CSS. Уже на момент регистрации на этот курс записалось более 12 тысяч студентов. Перед нами стояла задача разработать систему, которая будет автоматически проверять итоговые проекты на соответствие заранее подготовленному макету. В качестве основной техники для проверки было выбрано регрессионное тестирование.
В каждом проекте мы проверяли разметку, сетку и стилевое оформление не только страницы целиком, но и отдельных блоков. Одной из главных проблем был поиск этих самых блоков, так как о том, какой будет верстка студентов, мы не знали ничего — ни какие теги они использовали, ни какие классы и идентификаторы были задействованы. Имели только общее представление о структуре.
В докладе я расскажу, от чего мы отталкивались при построении этой системы, как мы разбирали и анализировали проекты. Какие инструменты и технологии мы для этого использовали и почему. Какие подводные камни вылезали, и какие возникали проблемы.
«Организация Frontend-разработки на крупном проекте» — Дмитрий Кузнецов2ГИС Технологии
Как создать Front End-команду для высоконагруженного проекта? Спикер расскажет, как можно выстроить эффективный процесс фронтенд-разработки с упором на технические аспекты: — Команда фронтенд-разработчиков. Зоны ответственности между теми, кто программирует UI (верстальщики), и теми, кто отвечает за бизнес-логику (Javascript-программисты). Идеальный состав команды. — Настроенный технологический процесс. Модульная организация (подготовка дизайна → разработка формата данных → создание шаблона → навешивание событий → тесты). — Разработка вместе с тестированием Unit-/DOM-тесты и подход PixelPerfect. — Вёрстка независимыми блоками и встроенный в приложение режим для вёрстки блоков.
Доклад о подходе к отслеживанию потоков данных, формирующих окружение, в котором пользователь решает свои задачи.
На примере реализации для конкретного фреймворка будет озвучена идея, как сделать инструмент для отслеживания изменений данных на странице приложения для вашего технологического стека.
Целевая аудитория
Разработчики крупных web-приложений, регулярно сталкивающиеся с проблемой, как уследить за изменением большого количества данных, формирующих интерфейс пользователя, решающих задачу эффективно разобраться с потоками данных для устранения неполадок приложения.
Человеческий организм устроен сложно. Если с ним что-то не так, то для диагностики используют магнитно-резонансный томограф.
Большие одностраничные приложения тоже устроены сложно. Чтобы их починить или обвесить новым функционалом, требуется вникнуть в их устройство. Для этого нередко приходится засучивать рукава и с головой погружаться в самую глубь проекта. И немалая часть проблем связана именно с бизнес логикой и потоками данных. Но что если у нас будет возможность проникнуть в структуру данных, способ увидеть связи между ними и отслеживать то, как они влияют друг на друга? Такой способ, чтобы не требовалось вскрытия скальпелем - все как с МРТ.
В докладе речь пойдет о собственных разработках в этой области.
Для того чтобы охватывать широкую аудиторию, WebGL приложение должно быть не только быстрым, но и стабильным.
В этом докладе мы обсудим проблемы, которые возникли у нас при разработке API панорам, и как мы их решали. Также затронем опыт других компаний и посмотрим, как помогают разработчику в достижении стабильности популярные открытые библиотеки.
Talk is about CSS minification problem, how minifiers work, new advanced optimisations, how minification influences on performance, CSSO reborn and future plans.
Я занимаюсь CSSO. В ходе работы над ним мне пришлось погрузиться в процесс парсинга CSS. В результате парсер (тот, что в CSSO) был не раз переписан. Пришло время сделать его отдельным инструментом.
Новый быстрый детальный парсер CSS, его AST, области применения и кое-что ещё.
CSSO – инструмент для минификации CSS, который не так давно вернулся к активной разработке. Помимо исправленных багов и новых фич, он значительно ускорился и стал одним из самых быстрых структурных минификаторов CSS.
Доклад о том как это достигалось, оптимизациях, деоптимизациях, структурах данных и подходах.
Holy.js, Санкт-Петербург, 5 июня 2016
Видео: https://www.youtube.com/watch?v=8o3gKKD_J4A
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
С ростом количества CSS на клиенте, разработчики озаботились его минимизацией: сначала простыми заменами, а потом и структурной оптимизацией. Первым иструментом, где появилась такая оптимизация, был CSSO и он оставался лучшим, пока не был заброшен. Не так давно он снова вернулся к жизни. Принципы работы CSSO, новые идеи оптимизаций и изменения в последних релизах от нового мейнтейнера проекта.
Не так давно случился значимый прецедент в истории W3C. Были приняты две конфликтующие спецификации, решающие одну проблему: Touch Events и Pointer Events. Почему так получилось, что это значит и что с этим делать?
Конференция WSD, Минск, 26 октября 2014
Видео: http://www.youtube.com/watch?v=dQoz5KZUH2M
Mobile Frontend Meetup, Москва, 4 июля 2015
Рано или поздно возникает необходимость в собственных инструментах по разным причинам: либо не хватает готовых, либо есть какая-то особенность в проекте. Разработка инструментов, работающих в браузере, является непростой задачей. Самое сложное — чтобы они умели работать удаленно, вне страницы. Это многих пугает — нужно много сделать и во многом разобраться. Но если большая часть проблем уже решена, и можно сосредоточиться лишь на основной функции инструмента? Что если такие инструменты смогут работать в произвольном WebView, будь оно встроено в браузер, редактор или другое приложение на любом устройстве? Доклад про удалённые инструменты: какие есть сложности и как их обойти, как перестать бояться и начать делать инструменты под свои задачи и технологический стек.
С ростом кодовой базы становится все более очевидной необходимость использования компонентного подхода, когда каждая логическая часть обособлена. Если говорить про JavaScript, то в нем есть области видимости, опираясь на которые можно соорудить изолированные компоненты. Но в CSS нет подобных механизмов, поэтому и придумываются Shadow DOM (Web Components) и различные методики вроде БЭМ.
Но что если взглянуть на проблему под другим углом? Адаптируя подходы, что уже используются для других задач, можно получить куда больше выгоды, чем просто изолированные стили!
Javascript-фреймворки: должен остаться только одинSergey Xek
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
Javascript-фреймворки: должен остаться только один / Аверин Сергей (Acronis)Ontico
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
FrontTalks: Роман Дворнов (Ostrovok.ru), «Basis.js: почему я не бросил разраб...Yandex
Basis.js – open source JavaScript фреймворк с нестандартными подходами, ориентированный на разработку одностраничных приложений. В докладе будет рассказано про механизмы работы с данными в Basis.js, обновление шаблонов и стилей без перезагрузки страницы, производительность, инструменты разработчика и многое другое.
State of the Standardized Web
В 2014 году принципы Extensible Web начали воплощаться в новых стандартах. Поговорим о Web Crypto, Web Animations, Service Worker и других вещах, которые должны принципиально изменить веб-платформу в ближайшем будущем.
Сергей Константинов, Яндекс
Руководитель группы разработки API Яндекс.Карт. Окончил Южно-Уральский государственный университет. Разработкой API Яндекс.Карт занимается с 2008 года. С 2013 — участник Технической архитектурной группы Консорциума W3C.
SECON'2016. Сергей Аверин. Javascript-фреймворки: должен остаться только одинSECON
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет. В докладе пойдет речь о том, что хорошо работающий фронтенд — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но и циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
SECON'2016. Аверин Сергей, Javascript-фреймворки: должен остаться только одинSECON
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
Мастер-класс: Разрабатываем сайт с нуля на полном стеке БЭМ-технологий — Жека...Yandex
БЭМ упрощает разработку сайтов, которые нужно быстро создать и долго поддерживать. Эту технологию используют во фронтенде почти всех сервисов Яндекса, и она уже успела обрасти множеством библиотек и инструментов, которыми мы хотим с вами поделиться. С обширным арсеналом БЭМ, со всей его модульностью и мощью, вам останется «всего-то» придумать идею и реализовать её. На мастер-классе вы сможете вместе с нами создать то, что мы «только что» придумали. Вы узнаете, в чём преимущество вёрстки независимыми блоками и что такое уровни переопределения, познакомитесь с готовыми библиотеками блоков и инструментами для автоматизации сборки. Мы покажем, как разные инструменты — например, autoprefixer, css-препроцессор Roole или модульная система YModules — упрощают жизнь разработчика и создают по-настоящему удобную платформу, если встроить их в процесс разработки на БЭМ. На живом примере мы объясним, в чём польза декларативного подхода, когда одни и те же идеи можно использовать как для CSS, так и для JavaScript. Отдельная часть мастер-класса будет посвящена декларативным шаблонам BEMHTML и BEMTREE, которые позволяют преобразовывать сырые данные во view-ориентированный BEMJSON. Мы вместе напишем серверную часть приложения в БЭМ-методологии и используем данные от разных социальных и поисковых сервисов (RSS с Яндекс.Фоток, API Twitter и Instagram). В результате получится работающий сайт, а вы — на практике познакомитесь с полным стеком БЭМ-технологий. После мастер-класса мы сможем свободно пообщаться на профессиональные темы. Например, вы расскажете о трудностях, с которыми встретились при реализации проекта на БЭМ, и мы вместе подумаем, как воплотить вашу идею в жизнь.
Виталий Харисов "История создания БЭМ. Кратко, сбивчиво и неполно"Yandex
Как мы делали БЭМ. Почему некоторые места сделаны именно так. Что лежит в основе методологии. Что важно, а что можно менять по своему вкусу. Какие технологии мы используем и как они облегчают нам разработку.
Как развивать библиотеку компонентов, не ломая ее / Артур Удалов (Mail.Ru Group)Ontico
HighLoad++ 2017
Зал «Пекин + Шанхай», 8 ноября, 17:00
Тезисы:
http://www.highload.ru/2017/abstracts/2991.html
Нынче стало модно выделять UI-компоненты в отдельную библиотеку и использовать её в нескольких проектах. Мы в команде почты Mail.ru делаем так же, но столкнулись с проблемой: каждый разработчик, меняя библиотеку под свои нужды, обязательно ломает что-нибудь, что работало у других.
Я расскажу о том, как мы решили эту проблему, и о том, какие инструменты для этого можно использовать. Storybook, BackstopJS, Jest, Webdriver.io, TypeScript - в их числе.
Возможно многие из вас уже пишут по БЭМу, просто не догадываются об этом, ведь БЭМ на самом деле не требует даже классов вида .block__element, срыв покровов в блице.
Web Standards Days
Kyiv
28 ноября 2015
#wstdays
https://wsd.events/2015/11/28/
Видео: https://www.youtube.com/watch?v=_Sx5jvT0qEU&t=2h22m00s
Слайды: http://bit.ly/bem-in-the-wild
В лекции мы попробуем взглянуть на страницу глазами пользователей и понять, что можно сделать для ускорения ее загрузки. Рассмотрим основные оптимизации на стороне браузера, познакомимся с инструментами для измерения времени отображения.
Когда проект делает один разработчик — все просто. Когда над ним работает небольшая команда, можно синхронизироваться и договориться. А вот когда проектов (сайтов и приложений) становится много, и над ними трудится множество команд с перекрестной функциональностью и смежными зонами ответственности, все становится сложным и запутанным.
Я расскажу о своем виденье архитектуры фронтенда, какой она должна быть, чтобы обеспечить её масштабируемость. На основе своего опыта и проблем, с которыми сталкиваются большие проекты.
Видео: https://www.youtube.com/watch?list=PLknJ4Vr6efQFtZmsXmGG64Rz_PHrcXCBL&v=z9y6PNC2FL0
Большинство считает CSS чем-то простым и не заслуживающим внимания. Но за мнимой простотой кроется большая сложность и огромный пласт проблем, не имеющих пока решения. Современный CSS с его объёмами, новыми фичами, разной поддержкой и багами браузеров, уже почти не поддается анализу человеком. Для этого появляются программы, которые разбирают CSS на атомы, анализируют и помогают сделать его лучше. Как к этому прийти, где мы сейчас и что ещё предстоит сделать.
Rempl – крутая платформа для крутых инструментовRoman Dvornov
Фронтенд усложняется с каждым днем, и уже не представить жизнь разработчика без инструментов. Инструментов становится все больше, но нельзя сказать, что их достаточно. Если у вас собственный стек или технологическое решение, вам рано или поздно потребуется сделать свой инструмент. Это не так просто! Особенно если вы захотите интегрировать его интерфейс в браузерные Developer Tools, IDE, редакторы или открыть их на другом устройстве. Добавьте сюда проблему версионирования и другие сложности, и вам покажется, что задача неподъемная.
Но есть хорошая новость! Большинство из этих проблем решает Rempl — платформа для создания и использования удаленных инструментов (на самом деле не только инструментов). Сделаем небольшой обзор Rempl: что это, зачем нужно, какие проблемы решает. А также посмотрим примеры готовых решений, построенных на Rempl.
CodeFest, Новосибирск, 2017
CSSO — инструмент для минификации CSS, который недавно вернулся к активной разработке. Зачем?
Дело в том, что минификация CSS — задача сложная. Сейчас нет идеального минификатора: чтобы и эффективным был, и делал все правильно. Ведь нужно учитывать не только особенности CSS, который постоянно меняется, но и уровень его поддержки браузерами, их баги, префиксы, хаки и т.д. Все это требует решения ряда непростых задач. Поговорим об этом, а также о принципах работы CSS-минификаторов, новых идеях и развитии CSSO.
Занимаясь разработкой интерфейсов, мы постоянно разбираемся как и что устроено. Вы задумывались, сколько времени у вас уходит на то, чтобы найти нужный фрагмент кода, который отвечает за компонент на странице? В своем докладе я покажу как это можно сделать за один клик, а так же раскрою технические детали.
18. Пост-процессинг
• Получение ссылок на элементы
• Навешивание обработчиков событий
• Модификация DOM
(использование jQuery-like плагинов,
вставка DOM фрагментов etc)
• и т.д.
15
29. Знания о DOM структуре
позволяют использовать
оптимизации
25
30. Например
• cloneNode(true) – быстрое создание
DOM-фрагмента
• обработка событий через один глобальный
capture-обработчик на документе для
каждого уникального события
26
35. TodoMVC
31
100 items 1000 items
AngularJS 125 ms 1491 ms
Backbone 53 ms 510 ms
Knockout 39 ms 489 ms
jQuery 20 ms 184 ms
Backbone + basis.js templates 18 ms 202 ms
basis.js 8 ms 95 ms
92. Анализ и выявление проблем
• какие классы используются в разметке,
но их нет в стилях
• какие селекторы никогда не сработают
• конфликты стилей
• и т.д.
86