Мы начинаем текстовую трансляцию Fronteers 2013, двухдневной конференции в Амстердаме — http://t.co/QB5SYQ3cMx
Пол Айриш из Google открывает шестую конференцию Fronteers. Россия на шестом месте по количеству участников, например.
На сцене Стив Саудерс с докладом «Pre-browsing» http://t.co/AuqI08mSjX
Сетевые проблемы замедляют веб. Медленные сотовые сети и даже перегруженный WiFi. Мы часто видим белый экран без индикации загрузки.
Заголовок: отдавайте браузеру нужное ещё до того, как он за этим обратится.
Кэш не всегда спасает: он может пока не существовать (первый заход), устареть или не соответствовать нужной версии.
Дело разработчика: <link rel="dns-prefetch… prefetch… prerender. Дело браузера: DNS pre-resolution, TCP pre-connect, prefresh, preload
Предсказывание действий пользователя: искал Adventure Time, вероятно кликнешь по ссылке. Зашёл на Facebook, значит откроешь новостную ленту.
Как это работает: <link rel="dns-prefetch" href="//catroonnetwork.com”>, дёшево, открывает TCP-соединения.
Это работает в Chrome 22+, Chrome Mobile, Firefox, Firefox Mobile.
Спецификация <link rel="prefetch" href="//example.com/script.js"> для подгрузки ресурсов не слишком подробно описана.
Работает в: Android 4, Chrome 31, Firefox 23, Firefox Mobile 24, Opera 15+
Firefox префетчит только один ресурс одновременно, Android 6, Chrome и Opera 10 (6 с одного домена).
Если во время префетча перейти на другую страницу, то браузер — внезапно! — отменит процедуру. Справедливо для всех браузеров. И странно.
Это исправляется с помощью Accept-Ranges: bytes, тогда браузер подхватит разорванную предзагрузку. Если конечно это поддерживается сервером.
Сделать <link rel="prerender" href="//catroonnetwork.com"> это как загрузить страницу в фоновом табе. Рисково, тратит ресурсы и трафик.
С prerender легко ошибиться, но можно вставлять <link> динамически, что добавляет гибкости.
С момента нажатия на ссылку до первых байтов ответа, браузер не делает ничего, кроме вытягивания ресурсов, а разработчик не может ничего.
Chrome в этот момент начинает DNS-prefetch для всех возможных ресурсов, упомянутых на новой странице. Ещё до её отрисовки.
Аналогичная вещь происходит в тот же момент: TCP-preconnect для избавления от сетевых задержек.
Кое-что новое: Prefresh™. Когда Chrome начинает предзагружать нужные ресурсы (нужную версию jQuery) сайта, который он уже видел и запомнил.
Это избавляет от медленных ответов 200, 304 и времени чтения/записи на диск.
Prefresh включается параметром для запуска Chrome --specual-resource-prefetching
Если использовать техники адаптивных картинок с помощью JS, то предгазгрузчик браузера не найдёт <img src="…">, т.к. работает до работы с JS
Лучше положить картинки для вытягивания вручную через JS на другой домен, чтобы они не конфликтовали с автоматикой браузера.
Этим летом Chrome изменил логику подгрузки JS. Раньше он повышал приоритет JS-файлов внизу страницы, не в пользу ресурсов в начале страницы.
Рекомендованная книга: «High Performance Browser Networking» Ilya Grigorik http://t.co/Rd3yaR8uof
После каждого доклада Пол Айриш будет задавать вопросы докладчику. Задать свой вопрос можно @FronteersConf и есть шанс, что его озвучат.
Пол Айриш озвучил идею положить все популярные JS-библиотеки прямо в браузер, не просто в кэш. Стив сомневается в эффективности решения.
В: Так класть ли все скрипты в конец страницы? О: Это что-то из 2007 года, сегодня важно правильно применять атрибуты async и defer.
Следующий доклад «Putting Flexbox into practice» Zoe Mickley Gillenwater (мы пока думаем как написать это по-русски) http://t.co/ALXOgs5q4k
Зоуи признаётся, что верстала таблицами http://t.co/yJTssEDs24
Демо-сайт для презентации: http://t.co/qfTmsZmwRa
Батарея префиксов для работы Flexbox http://t.co/GKYDJ992ti
Чтобы справляться с префиксами, можно генерировать их на http://t.co/L58z0BYu69 или прямо в SASS https://t.co/wz0i6q6Nd7
Firefox всё ещё не поддерживает flex-wrap для многострочного Flexbox. Так что это значение пока использовать не стоит.
Также для работы flex-wrap важно иметь поддержку break-before, break-after, которые поддеживаются только в IE10 и Opera 12.x
Как свёрстана галерея на http://t.co/qfTmsZmwRa http://t.co/sxosKEhKWN
Flexbox, в отличие от привычной модели, позволяет удобно и предсказуемо смешивать различные единицы изменения: px, em и проценты.
Если flex-basis не равен нулю, то могут возникать неочевидные ситуации, когда ширина элемента умножается на flex:N, об этом мало говорят.
Свойства align-items и align-self исполнили мечту верстальщиков о вертикальном выравнивании.
Выравнивание с помощью Flexbox с фолбеком для старых браузеров http://t.co/dWCM1shSzx
Flexbox и фолбеки для старых обычно не конфликтуют, но иногда их лучше разделять с помощью Modernizr, например.
При использовании выравнивания с помощью justify-content, можно легко делать фолбек на инлайн-блоки, даже не разделяя код.
Повторимся: всё, о чём идёт речь в докладе Зоуи про Flexbox, проиллюстрировано кодом на сайте http://t.co/qfTmsZmwRa
@h4 принимаются идеи
Изменение порядка следования блоков с помощью order из Flexbox может дезориентировать при навигации по элементам с помощью фокуса.
Одна из важных возможностей Flexbox позволяет растягивать один (или несколько) блоков по высоте родителя без указанной высоты.
Стоит ли вообще использовать Flexbox? Да, говорит Зоуи:
- Спецификация не поменяется и Flexbox станет мощным инструментом для построения раскладки и никуда не денется.
- Можно начать с небольших демо-сайтов, чтобы понять как Flexbox работает. И начать использовать его для небольших косметических вещей.
- Flexbox это весело! Он сильно меняет представление о возможностях раскладки.
Ссылки и ресуры для презентации по Flexbox: http://t.co/nToGPs98fS
В: Как с поддержкой Flexbox на мобильных? О: Поддержка отличная, кроме мобильного IE.
В: Насколько быстро работает Flexbox? О: Новая спецификация (2012) значительно быстрее старой (2009).
Следующий на сцене: Питер ван дер Зи с докладом «Real-time recompilation of running JavaScript» http://t.co/aoWCaxLXa6
Питер начал сразу с демо http://t.co/P95swx2pBI
В этой демке Питер меняет параметры скрипта для Canvas и изменения становятся видны сразу без перезагрузки кода. Даже не мелькает картинка.
Питер в Твитере @kuvos
Дальше идёт опасный лайв-кодинг, кстати в WebStorm на Linux.
Компиляция в случае JS — это подготовка кода для исполнения. И дальше исполнение динамически созданного кода.
Код для демо http://t.co/r0hs9CQOrt
Функция возвращает функцию, которая… http://t.co/dYwYm01e96
Таким образом, мы изменяем код без перезапуска приложения.
Проблемы подхода http://t.co/aDXwe4bCSP
Становится всё страшнее http://t.co/aHvwsfsjxB
Прямой и непрямой eval различаются потерей или сохранением контекста в исполняемой функции http://t.co/eHCRxfnX0s
Оказалось сложно транслировать текстом лайв-кодинг Питера, поэтому вот вам ссылка на все показанные демо и слайды: https://t.co/geVnxk3kYq
Следующий Robert Jan Verkade и «On power & responsibility» http://t.co/3JKuARTqns — ни строчки кода в презентации, обещает докладчик.
@Anton_Diaz, старый был внедрён (и распространён) в основном в WebKit, отсюда и сравнение.
«Никакого нытья по профессиональным вопросам», — предлагает Роберт http://t.co/JNkCabHhBa
@SelenIT2, Opera 12.x и IE10
Дизайнеры или «веб-декораторы» категорически не понимают веб, его принципы работы и жизни.
Так ли открыт мир фронтенда, как это кажется? Мы, вроде бы, находим решение и тут же делимся им.
Делится знаниями лишь небольшая группа, так называемая, «элита» любой группы.
Фронтенд в большинстве — это белые мужчины 25-35 лет с техническим образованием. Нам стоит расширить рамки и пригласить людей других групп.
Всегда ли мы говорим с коллегами вне нашей группы на одном языке? http://t.co/arMYsstNFq
Иногда стоит расчехлить PowerPoint, набросать пару диаграмм и графиков и поговорить с менеджером на его языке.
Внешний вид не только то, как нас принимают с первого взгляда, но и отражение нашей индивидуальности http://t.co/jIPEcdeEj8
Роберт причисляет себя к творческому поколению Зельдмана и Мейера и противопоставляет его современной тенденции к роботизации разработки.
Фронтендеры, тоже дизайнеры. Вы анализируете проблему, придумываете решение и создаёте воплощение в реальности. Это сложно роботизировать.
Традиция визуального дизайна включает способность выслушать потребности клиента, не просто делать красиво что попало.
Если дизайнер не понимает веб, то может быть эта ваша вина в том, что вы не показали ему простой CSS-файл, не объяснили технологии?
Никто не знает, что будет через 5 лет. Но нужно не просто быть готовым к переменам, а быть готовым к неожиданным переменам.
Бывали ли вы на UX-конференции, слушали ли вы внимательно вашего менеджера? Нельзя быть достаточно всезнающим, всегда есть пути дальше.
Не просто создавайте адаптивные и отзывчивые сайты. Будьте адаптивны и отзывчивы сами!
«Фронтендеры, хватит ныть. У вас отличная работа, вас никто не лупит по затылку. Это важный шаг», — советует Роберт.
Дальше: перерыв на обед, 1 час. Поешьте.
Следующий на сцене Алекс МакКау «Faster JavaScript web apps» http://t.co/DhEw6UcAGF
Кажущаяся скорость работы приложения или сайта столь же важна, как и реальная.
Где-то после 1 секунды загрузки сайта пользователь переключается в режим «оно зависло» и уходит или переключается на что-то другое.
Каскад ресурсов позволяет понять, что скорость зависит от сети и отрисовки http://t.co/Jskfd74Yop
Что можно сделать для ускорения сетевой части:
- Быстрый ответ сервера;
- Используйте KeepAlive;
- Не используйте редиректы;
- CDN
- Уменьшайте кол-во ресурсов;
- Минифицируйте JS/CSS;
- Собирайте ресурсы вместе;
- GZip;
- Кэш, отдельная статика;
- Кэширование Ajax-запросов;
- Удаление дублирующего кода;
- Минификация и сжатие картинок;
Ускорение на стороне клиента:
- Режим стандартов IE, переключение X-UA-Comp заголовком сервера;
- Подключение стилей как можно выше;
- Избегать блокирующего JS, async/defer;
- Отложенная загрузка некритичного JS.
Модуль ngx_pagspeed для Nginx — http://t.co/x1421Tn7EH
Снова звучит совет динамически вставлять <link rel="prefetch" href="…"> в <head> с помощью JS.
Меняйте классы у элементов как можно глубже по DOM, чтобы это оказывало как можно меньшее воздействие на перерисовку.
Использование createDocumentFragment для хранения DOM-эл. во время динамического создания быстрее для отрисовки, чем постоянная вставка.
События, связ. с прокруткой можно оборачивать в буферные функции-замедлители, которые будут запускаться каждые 300мс, а не постоянно.
Используйте перекл. классов, а не инлайн-стили. Не делайте ресайз картинок в CSS. Группируйте изменения в DOM.
@sapegin, ты отдаёшь себе отчёт, что разговариваешь с трансляцией?
Сервис PageSpeed Insights, включая API на 25 000 запросов в день — https://t.co/00u7CCtvo7
Как выглядит утечка памяти в инспекторе http://t.co/OqbbNubpDe
Сайт Алекса http://t.co/oN5tmjyFhj и он в Твитере @maccaw. Дальше вопросы и ответы.
Следующий: Пол Льюис из Chrome DevRel «A developer's guide to rendering performance» http://t.co/NtUndpMJFx
Хотите поговорить про быстродействие? Упоминайте тег #perfmatters, тогда вас услышат и другие.
Все говорят про загрузку страницы, а я хочу поговорить про то, что происходит потом — как пиксели попадают на экран. То есть про отрисовку.
После получения ресурсов и построения дерева DOM, происходит комбинация DOM + CSS = дерево отрисовки. Потом создаётся раскладка, aka layout.
Все фигуры, которые рисует браузер — векторные. Их нужно растеризировать, обрезать и прочее, то есть операция «paint» в инспекторе.
Все картинки (JPG, GIF, etc) нужно декодировать из форматов и тоже попиксельно нарисовать.
Подход «инструменты вместо советов» лучше, поскольку советы устаревают, а инструменты просто считают и показывают что оптимизировать.
«Рифмуется — значит правда», как говорит Джейк Арчибальд (про «tools not rools»)
Стили, влияющие на перерисовку (и голова Пола). Почти что все http://t.co/25iHYCNlbO
Библиотека fastdom для ускорения работы с DOM — https://t.co/n6McJ9qtaX В примере она повысила скорость с 9 до 58 fps.
Если нажать клавишу «h» в инспекторе Chrome, то выбранный элемент спрячется. И можно будет увидеть, как он влиял на быстродействие.
Если нужно что-то двигать, то убедитесь, что это «что-то» лежит в собственном слое отрисовки. Да-да, тот самый translate3d и другие.
Обработка и отрисовка картинок — самое тяжёлое и проблемное для быстродействия. Вот бы нам модификатор для «отложенных» картинок, но нет.
jQuery.animate до сих пор работает через таймауты (неэффективно), а не requestAnimationFrame (лучше), но есть патч, который это включает.
Тач-обработчики:
- Уменьшайте количество обработчиков событий;
- Подключайте событие как можно ближе (по дереву) к целевому элементу.
- Подключайте обработчики как можно позднее.
Прокрутка естественно вызыват перерисовку. Избегайте изменений во время прокрутки. Да, параллакс — это убийство браузера.
Если вы вставили анимир. GIF-спиннер, то не забудьте не просто прикрыть его загруженным, а выключить, иначе он продолжит отрисовываться.
Выводы:
- Быстродействие — это фича, а не юнит-тест.
- Вы контролируете то, что получает браузе (отключите box-shadow, у нас флэт-дизайн)
- Сначала профилируйте, потом исправляйте (это нельзя предсказать).
- Профилируйте раньше и чаще.
Следующий на сцене Лукас де Грут «On designing typefaces» http://t.co/I9p3d7hmwB
Первая мировая война шрифтов: (Adobe) PS vs. TT (Microsoft). Adobe проиграла и была вынуждена раскрыть секреты PostScript.
Непростой процесс хинтинга шрифтов http://t.co/fCGU1tskWJ
Хинтинг — это кропотливый ручной процесс искажения оригинальных кривых шрифта для каждого размера, чтобы они ложились на пиксельную сетку.
Хинтинг в VTT, софте от Microsoft http://t.co/8uCDVT53KA
Типы хинтинга: ч/б, серый, clear type и самый лучший — комбинация серого и clear type.
Иногда шрифты хинтуются не под целые пиксели, вроде 1 или 2, а например под 1,3 — такой шрифт Лукас сделал для дисплеев навигаторов Audi.
Старинная кернинговая пара http://t.co/J4sljhcrvs
Лукас сделал шрифты Calibri и Consolas для Microsoft.
Для эффективного кернинга нужны таблицы самых частых буквенных пар для каждого языка.
Кернинговые просветы между буквами создают своё впечатление для каждого языка. Те же буквы, но разный кернинг: сравните «dog» и «god».
На ретиновых экранах хинтинг не нужен.
В LucasFonts только над хинтингом работает целая команда, в частности, один программист и один русский.
Информация о поддержке и работе веб-шрифтах на сайте компании Лукаса — http://t.co/RQksYmWsJe
Сложнее всего локализовывать шрифты. Лукас потратил по 6 лет на греческий и кириллицу и арабский. Так что хинтинг — это ерунда, в сравнении.
Можно определять какое устройство запрашивает шрифт и отдавать его без хинтинга, например, для iOS и OS X.
Первые буквы Лукас сделал в 6 лет. В туалете. (цитата, со слов его матери)
Секция примеров из реальной практики: Эд Соуден рассказывает про разработку GOV.UK http://t.co/2qpSCTNq12
Сайт https://t.co/MukTVJpGK2 построен по принципу «сначала мобильные». Они поддерживают не браузеры, а пользователей. То есть IE6.
Набор инструментов (SASS и JS), созданный для разработки https://t.co/MukTVJpGK2 — https://t.co/BXaUydHG4m
Для IE6 сайт отдаётся как для мобильных в одну колонку, чтобы избежать возни с багами, но всё же донести информацию.
На сайте 7 базовых размеров шрифта, содержащихся в SASS-переменных. Эти переменные реагируют на размер вьюпорта и соотв. изменяются.
Всё, о чём шла речь, повторимся, на Гитхабе: https://t.co/BXaUydHG4m
Следующий: Антон Ванхаук рассказывает про сайт планирования транспорта http://t.co/gI2Ksw3DRa http://t.co/2qpSCTNq12
Его компанию попросили только «немного освежить дизайн», они переделали весь сайт до неузнаваемости.
Они попытались сделать из сайта не робота «доброе время суток», а попутчика «привет, куда едешь?»
Новые иконки, эмоциональные фотографии, идея «9292 путешествует с тобой».
Вместо кучи полей — умное выпадающее поле с подсказками, которое угадывает запрос http://t.co/njG8YAMG90
Следующая: Элани Оливьер про музей Rijksmuseum http://t.co/2qpSCTNq12
Сайт музея https://t.co/36UC0Qb0JV
Все картины музея доступны бесплатно на сайте для загрузки в высоком разрешении.
Терабайт картин, разбитых на тайлы http://t.co/m63L54QNcU
Целевая аудитория сайта музея — двое вечером на диване с Айпадом. Идея: не тащить людей в музей, а принести музей в их дом.
Задача была: сайт для десктопа (IE8+) и мобильных (от телефона до планшета). Всё это под большим контролем за качеством со стороны клиента.
С проектом торопились, поэтому не тестировали на Андроиде. О чём жалеют, но уповают на сроки.
Работали по Аджайлу, было проще с приоритетами http://t.co/WVLD6sGBM0
Разработали в процессе свой CSS-фреймворк, что значительно ускорило разработку после начального этапа.
Разработали даже API для работы с материалами сайта, должны выпустить скоро.
В: Как вам удалось выложить все картины бесплатно? О: Цель — привлечь внимание к картинам, чтобы пришли посмотреть на оригинал. Это работает
На сцене Oliver Reichenstein и «Responsive typography» http://t.co/pAcSBRp0sD
Доброе утро! Мы начинаем http://t.co/EFE0ElXvM6
Первая версия сайта iA http://t.co/1QtIA4X9LO
В вебе всегда было шумно, поэтому Оливер начал первый сайт агентства почти без CSS.
Всё началось со статьи «Web Design is 95% Typography» в 2006 году http://t.co/3A9gq8cYDU
Оливер изучал философию и совсем не дизайнер, тем более не специалист по типографике.
Неужели так сложно выбрать шрифт для брендинга компании? Это кажется таким простым делом.
Веб был полон Верданой и Ариалом. Потом появилась Джорджия! В 2005 году она выглядела чем-то новым.
Типографика не о том, как выбирать шрифты, а о том, как именно их использовать.
Как же начать разбираться? Можно прочитать несколько книг, но они довольно сложные.
Оливер начал с выбора размера шрифта. Шрифт в вебе слишком мелкий. Всё потому, что веб-дизайнеры скрючены над экраном и напряжены.
Обычные люди читают текст в вебе расслабленно, на некотором расстоянии от экрана. Им не нужно выискивать пискели.
Оливер взял книгу, поместил её на комфортное расстояние от глаз и сравнил с экраном. Экран обычно гораздо дальше.
Оптимальным размером оказались 16 пикселей Джорджией. В 2005 году это звучало полным безумием, особенно на небольших экранах тех лет.
«Этот человек безумен, как он может заставлять нас читать такой огромный текст?» — говорили многие.
Для экранов с подсветкой для того, чтобы избежать «эффекта зебры» пришлось также увеличить высоту строки.
Также было принято, что шрифты с засечками не работают на экране, основанное на каком-то исследовании 1992 года.
В исследовании сравнивали что-то вроде 10-пиксельного Таймса с Верданой на плохом экране и конечно Вердана выигрывала.
Ситуация усложнилась: появились телефоны, планшеты, ретина, макбуки с крошечными пикселями.
Вьюпорт, то есть ширина экрана, это не главное. Крайне важно расстояние до экрана. Поэтому даже формула «16 пикселей» не работает.
Шрифтовики не сразу поняли, зачем изменять шрифты для экрана. «Ты меняешь высоту строки, которую я установил для шрифта?».
Первое впечатление от ретины: мы можем просто использовать обычные шрифты, как на бумаге и не париться. Но всё не так, это по-прежнему экран
Приходится напрягать воображение, чтобы представлять, что справа всё ещё Джорджия http://t.co/d3LKvPtCgz
Оливер ссылается на статью «Font Hinting and the Future of Responsive Typography» http://t.co/Xnm1TdJM6u
Даже сглаживание на экране делает шрифт чуть жирнее, чем он есть на самом деле, несмотря на огромные усилия по хинтингу.
На ретине тонкие шрифты слишком тонкие, на обычном экране чуть толще, чем нужно.
Так было и раньше: для разной бумаги, разных размеров шрифта нужно было применять разные литеры.
Чем меньше шрифт, тем жирнее должна быть форма буквы http://t.co/qKgmyoM71X
Уж не говоря про ловушки для краски на острых стыках кривых.
Усилия по выбору правильной насыщенности стоят того, хоть и не всегда заметны с первого взгляда http://t.co/uvjX1xqw5I
Причём от экрана к экрану нужна разная насыщенность. Что сложно объяснить традиционным шрифтовикам.
Оливер решил воссоздать шрифт из старой книги и так и провалился в кроличью нору http://t.co/2fDwk4nT67
Одним из первых экспериментов был шрифт iABC http://t.co/YUdoZMz9uZ
«Ты сделал шрифт за год? Молодец, только не показывай никому», — сказали маститые шрифтовики.
Сайт iA с отзывчивой типографикой, хотя маститые шрифтовики всё равно видят множество проблем — http://t.co/HwPTLkOo8y
Оливер опасается открывать шрифтовые программы, чтобы не его снова не засосала эта пучина.
Следующая на сцене Garann Means «How to rewrite your JS app (at least) 10 times» http://t.co/IxcpS3vWy1
Гэран написала книгу про Node.js для фронтендеров http://t.co/Gs0JsRegtA
Писать код просто — планировать его сложно.
Но мы привыкли слишком приотизировать часть работы, связанную с кодом и забывать про планирование.
Но если ты переписываешь что-то, то возникают другие проблемы http://t.co/4cwgzWiHVe
Но есть много причин, чтобы переписать код: новые технологии, апгрейд инфраструктуры, рост бизнеса, рефакторинг или просто ВСЁ СЛОМАЛОСЬ.
Плохой вариант, когда у вас есть 20% приложения и тут вы понимаете, что всё неправильно и выбрасываете код. Лучше так не делать.
Плохие идеи по переписыванию чего-то:
"1." Давайте используем новый фреймворк! Куча постов о нём, кто-то его пробовал на хакатоне, это 100% MVC — чем не причина.
И вы такой пишете пару строк и фреймворк делает инициализацию за вас. И модели, и данные… И тут вас всё-таки приходится писать что-то самому
Так и работают фреймворки: решают простые проблемы, предлагают абстракции, но не помогают организовать именно ваше приложение.
Выбирайте фреймворк последним. Это не должно быть причиной для написания приложения. Он должен оставаться инструментом.
Другой вариант: "2." Давайте напишем наш собственный фреймворк! Весь код будет знаком, специально для вашего приложения, только нужное внутри.
В итоге вы переписываете уже знакомые вам фреймворки, только с блекджеком и прочим. С минимальной разницей и на это уходит слишком много сил
Правило: пишите одновременно только одно приложение. Как бы ни круто было писать пять штук сразу.
Пишите API сразу и сразу сквозь всё приложение, для всех вещей.
Или так: "3." Так может сделаем всё не на JS, а на сервере… на PHP?
Когда позже что-то нужно отладить, исправить, дописать — выходит, что было проще использовать один и тот же язык для клиента и сервера.
Или вот: "4." Давайте перепишем всё сами, даже браузерый DOM.
Или загрузчик файлов: сделаем его умным, красивым, с прогресс-баром… и Flash-роликом, который всё загружает.
И тут в JS появляются всякие Flash-привязки. А потом фолбек на обычный загрузчик, а потом ещё и на XHR, а потом…
Так может сразу стоило начать с базовых вещей, которые есть в браузере и сделать их лучше поверх существующего?
DOM — плохое место для хранения данных. Это дорого и сложно. Данные заслуживают отдельного, настоящего хранилища.
Или так: есть плагин или модуль для решения нашей задачи! Кто-то его написал, кому-то он помог. Давайте его возьмём.
В итоге вам приходится подстраиваться под то, что плагин возвращает, чистить его от лишних классов и кода.
И в итоге вы его переписываете. Точнее, дописываете на основе существующего. Но это уже не плагин, это кусок чужого кода.
Так может стоило сразу написать самому, не делая кривые решения на основе чужих ошибок?
Бывает и так: раз это MVC, то не нужно никакой системы зависимостей.
Отсутств. модульности приводит к бардаку в коде. Полагаться на глобальные переменные опасно. Приходится следить за порядком подкл. завис-тей
Или даже: у вас есть ужасный движок и вы находите инструмент или фреймворк, совместимый с этим ужасным. И вы радостно его используете.
Переписывание внешних мелочей приведёт вас к такому же плохому коду, который у вас есть в основном коде.
Или так: мы нашли крутую штуку, которая всё решает. Давайте её использовать. Так, что у нас за проблема?
Но решает ли эта штука проблему? Нужно сначала сформулировать проблему, а потом искать решение.
Сложно избежать полного переписывания. И лучше конечно сделать так, чтобы переписать всё только один раз, а не делать это постоянно.
Не начинайте писать код до тех пор, пока у вас нет плана разработки.
Хорошее план спасёт вас от десятка переписываний приложения.
Сайт http://t.co/yQ8b19cz4b и Твитер @garannm Гэран.
Следующий после перерыва: «The importance of Firefox OS» Sergi Mansilla http://t.co/jjbP4YZ8vm
Мозилла на сцене http://t.co/bo4ER4XBEO
Сайт Сергия http://t.co/SFYNtl6wmr
Сергий работает в норвежском телекоме Telenor над Firefox OS
Проблема: написал один раз… запустил один раз. (На одной платформе). http://t.co/ty9DA9YYkN
Несовместимые API платформ, плата за разработку, различные инструменты для каждой, ограничения апсторов.
Пользователи страдают http://t.co/48fNBNp8fK
Решение — HTML5. Речь о наборе технологий, а не о модном бессмысленном словечке
WebRTC, IndexedDB, ASM.js, etc.
Среди современных устройств разве что тостеры не поддерживают HTML5.
Но мы снова и снова не используем общую платформу в виде HTML5 и пишем разных код для разных устройств.
HTML5 API одинаковы на всех устройствах, где есть браузеры, совместимые с веб-стандартами.
Конечно на каждой платформе есть отличия в HTML5, но веб-разработчики привыкли к такому и знают, что с этим делать.
Backbone, Knockout, Angular, etc. — нет никаких ограничений по использованию подходов к разработке, в отличие от нативных платформ.
Аргумент про быстродействие веб-приложений — ерунда. Ответ Sencha на заявление про «медленный HTML5» от Facebook http://t.co/Nwqae41IOg
Конечно это потребовало трюков: <iframe> для каждой из частей приложения, что рендерило их в отдельных процессах.
Unreal Engine 3 in Firefox with asm.js — http://t.co/TFDQafy1jr
Ещё аргумент про ужасный JS, как язык. Но JS меняется к лучшему: классы, модульность.
Кроме того, есть десяток языков, компилирующихся в JS: от CoffeScript до Dart, LiveScript, Objective-J.
Список вариантов «Web coding beyond JavaScript» http://t.co/RAxf75Geo4
Другой аргумент: сайты выглядят плохо, незаконченно по сравнению с приложениями. Но дело исключительно в количестве вложенных усилий.
Первый нормальный аргумент: API к железу устройств. То есть отсутствие доступа к ним из JS.
Но ситуация улучшается благодаря: Appcelerator, PhoneGap (особенно версия 2).
Поначалу вещи вроде PhoneGap были даже запрещены в App Store http://t.co/yQSLYjEIxo
Мозилла помогла разрушить монополию IE в начале нулевых. То же делает и Firefox OS, чтобы освободить разработчиков от рамок платформ.
Мозилла работает над стандартизацией API для железа устройств. Вы не обязаны пользоваться апстором Мозиллы, хотя он есть.
Начать делать приложение для Firefox OS просто http://t.co/b0Df8xfI34
Плюс манифест http://t.co/gizaq7rb0S
Главная фича Firefox OS — отладка прямо в браузере. Это удобнее, чем всё, что есть на других платформах.
Есть расширение App Manager для Firefox, которое упрощает разработку и тестирование https://t.co/kzU60lxzPR
Расширение может подключаться к телефону и получать доступ к приложениям, установленным на телефоне и отлаживать их
Связь отладчик — телефон двусторонняя.
Другое расширение: симулятор Firefox OS https://t.co/ZRu6Uf8RBw
Brick http://t.co/OueTaRov2I — UI-компоненты для современных веб-приложений.
Набор шаблонов для веб-приложений: https://t.co/Y4NODE22sN Материалы для обучения: https://t.co/xzc1w8IOcX
В магазине приложений для Firefox OS простой процесс одобрения, без лишних ограничений — https://t.co/Mm3oO1UiOr
Следующий на сцене Гарри Робертс «Rationalising designs for better quality code» http://t.co/YSQiGrQ1o5
Второе название доклада; Рационализация дизайна для лучшего качества CSS http://t.co/zy83bFu5Kz
Третье, честное, название: Почему дизайнеры ненавидят меня.
Если вы не согласны с идеями Гарри, пишите ваши мнения с тегом #DesignersHateHim
Разработчики жалуются про плохой PSD не дизайнерам, а коллегам. Много нытья и расстроенных верстальщиков.
Гарри работает в большой британский медиакомпании Sky http://t.co/q5nVa13Xcd
Как фронтенд-разрабочик, Гарри связывает программистов с дизайнерами и часто принимает решения по оптимизации дизайна для лучшего соотв.
Я не анти-дизайнер, как может показаться. Этот подход может не сработать в некоторых ситуациях (для крошечных и огромных сайтов).
Компромисс — это хорошо: для поддержания хороших отношений с дизайнерами, для совместной эффективной работы, но «нет» значит «нет».
В Sky до сих пор существует процесс PSD — разработка — и т.д. Но большая организация не меняется в один день.
PSD — это идея, а не контракт. И он обязательно изменится: сам или уже в коде.
Типичная фраза «Это возможно, но…» Почти всё можно сделать, но это не значит, что это нужно делать и это хорошая идея в целом.
Быстродействие — прежде всего. Особенно когда об этом думают даже дизайнеры. И у нас в Sky так и происходит.
Если можно достичь 80% дизайна используя 20% кода — это именно то, что нужно сделать.
Это правило называется «80:20», запомните его.
Интересный вопрос: «Хм, я думал ты хороший разработчик? Почему ты не можешь это реализовать?»
Работа фронтендера гораздо важнее, чем просто воссоздать PSD в HTML и CSS. Ответственность гораздо выше.
Чем лучше, ты пишешь код, тем меньше тебе хочется делать это.
Лучше не писать код, который можно не писать. Перерабатывайте, переиспользуйте, нормализуйте, добавляется абстракций.
Когда дизайнер делает отступ снизу то 20px, то 22px, то 18px — пользователь не заметит разницы. Это стоит нормализовать до 20px
Вместо написания селекторов через запятую и 20px для них, лучше использовать переменную $padding: 20px и препроцессор.
Использовали что-то 3 раза и больше? Вынесите это в абстракцию, переиспользуйте.
CSS это язык, основанный на правилах (rules). Но если дизан не основан на правилах, то его крайне сложно передать в правилах.
Стоит помочь дизайнеру начать думать правилами, что не отменяет творчества.
Правила — это то, что не стоит нарушать, иначе одно потянет за собой другое и от системы ничего не останется.
Начало обычного проекта: html { font-size:16px; line-height:24px } В итоге 24px становится ключевым размером для отступов всего проекта.
Случайные числа в отступах и размерах ведут к непониманию. Лучше выбирать базовую величину и считать многое от неё. Например, те же l-h:24px
Стоит нормализовать и рационализировать решения в дизайне: если уменьшать или увеличивать что-то, то ровно в 2 раза, например.
Не стоит реализовывать дизайн в лоб — картинка так картинка, можно использовать что угодно и сделать так, чтобы оно просто выглядело похоже.
Если вместо вставки картинки можно сделать пару рамочек, то лучше упростить её немного и реализовать проще.
Ищите альтернативы, меняйте дизайн, рационализируйте и нормализуйте его.
Наша задача не выпустить хороший дизайн, а сделать работающий продукт, который хорошо выглядит.
Чем сложнее код или конкретное решение, тем сложнее его понимать другим, тем оно более хрупкое.
Делайте удобные сайты, не статические картинки. Компромиссы для лучшего качества. Придерживайтесь правил. Будьте умнее, трюкуйте!
Клиент не должен знать ничего о коде. Но должен понимать, что он приобретёт от качественного кода — поддержка, стабильность, и т.д.
У нас часовой перерыв на обед. И вы не забудьте поесть.
Следующий Маркус Касэрас «Responsive images: ain't we there yet?» http://t.co/iG5K9OUUzM
Мы уже близко к отзывчивым картинкам? Да, мы почти уже там. По крайней мере ближе, чем когда либо.
Картинки занимают 60% от размера средней страницы. И процент растёт.
Так что такое отзывчивые картинки? Картинки, которые соответствуют ситуации и окружению.
Рекомендуемая статья: Responsive Images: What We Thought We Needed http://t.co/RESDaaSCWD
Важный документ для группы стандартизации отзывчивых картинок: Use Cases and Requirements for Standardizing http://t.co/xvc8ETKMiW
Картинка, которая хорошо сжата для порт. ориентации, может выглядеть плохо в ландш., т.к. становится больше http://t.co/4KbpROtJPz
Пока нет решения, которое покрывало бы все юзкейсы и нравилось бы всем.
Решение №1 <picture> (на манер <source> для <video>), предложенное Брюсом Лоусоном http://t.co/wmeQ1iI5WH
Минусы: несколько элементов; расширяет использование <source> в спец. контекстах (не только для <video>); смешивает MQ и разметку.
Решение номер 2, стрёмное http://t.co/glWn5cvvV2
Третье решение: атрибут и похожее свойство srcset, предложено в Apple.
Плюсы: нравится браузерам, уже внедрено в Safari. Минусы: не решает проблему с кропом, сложный синтаксис, что значит «w»?
Комьюнити и W3C http://t.co/e8Newav6fz
Что же нам на самом деле нужно: <img src=“”path-to-image>. И всё.
Четвёртое решение: использует HTTP для т.н. «client hints», то есть подсказок для клиентской части.
Плюсы: не нужна доп. разметка; браузер может заявить, что он поддерживает и только тогда получит что-то от сервера.
Минус: вы не всегда можете управлять заголовками «своего» сервера: Github pages, CDN, дешёвые хостинги.
Ещё минусы: прокси могут резать непонятное; может потребовать SSL для стабильной работы.
Набрасываем идеальное решение на лету http://t.co/KoOjYYfCaj
Следующий шаг http://t.co/hexapNIPLO
В итоге, получается вариант с <img> элементом и атрибутами src-1, src-2, src-n.
Становится страшнее http://t.co/9HmmzDPrLa
Ещё вариант: новый умный формат для изображений.
Картинка делится по частям внутри: 1-100 кб — одна, 100-300 кб другая и т.д.
Благодаря этом очень удобно делать кропы, выбирая только часть картинки, делая его на лету.
Минусы: новый формат изображений; потребует изменений в браузерах и соотв. софте; должен быть стандартизирован.
Так что же будет?
Идеально будет внедрить несколько решений прямо сейчас и в итоге прийти к новому формату изображений.
Один из полифилов для отзывчивых картинок — Picturefill https://t.co/CXi7O6T4QD
Есть идеи? Присоединяйтесь к Responsive Images Community Group http://t.co/gso88IVX9O
Возможные расширения для будущего волшебного формата изображений: .ric (resp img community) или .mif (magic image format).
Следующая на сцене Анжелина Фабро «Return of Inspector Web: Web Components a year later» http://t.co/HMbwBNPY5F
«Web Components» — это не просто одна технология, но группа, вроде как HTML5.
Shadow DOM — это способ спрятать элементы внутри другого элемента так, что родительский документ ничего не будет знать о них.
Отрисовка вложенного Shadow DOM заменяет заменяет родительский элемент в основном DOM. Именно отрисовку, а не элемент в дереве.
Демка, работает в Chrome Canary: http://t.co/gKimBDlkoF
Новая @-конструкция в CSS: @host, которая позволяет подняться на уровень выше из вложенного документа. @host { border:red }
Псевдоэлемент ::part для Shadow DOM http://t.co/f8LxrcK00J
Поддержка Shadow DOM: Firefox скоро, Chrome да, IE пока никаких новостей, про Safari тоже не очень понятно.
Содержимое нового элемента <template> будет обработано, но не отрисовано. Он может содержать элементы, стили и т.п.
<template> это замена <script type="text/template">, которая не хак.
Есть уже даже такое <link rel="import" href="some-page.html"> Firefox: скоро; Chrome за флагами; про IE никто не знает.
Специальные элементы: var foo = document.register('my-widget‘); document.body.append(foo);
Создание нового элемента: <my-widget></my-widget> или <div is="my-widget"> — первый способ лучше.
my-widget { color:red } my-widget:unresolved { opacity:0 } — если элемент не зарегистрирован в документе, то он не будет виден.
Поддержка: Firefox и Chrome за флагами; про IE ничего не известно.
Элемент <element> пока убрали из спецификации. Но способ создавать специальные элементы пока остался.
Новая штука Dectorators, о ней мало информации и нет собств. спецификации.
<decorator> — это способ применения презентационной разметки через задание логики в CSS. Что-то вроде шаблонизации, управляемой через CSS.
Считанные люди понимают как это работает. Звучит сомнительно, но есть некоторые удачные юзкейсы. Хотя нет ни одной реализации и спеки.
В проектах Мозиллы X-Tags и Brick используются полифилы для реализации части расказанного в докладе.
Polymer Project — проект, построенный на основе веб-компонентов http://t.co/M2yhTg3aFS
Polymer 168 кб, Angular 81 кб, X-Tag 63 кб.
Пример на Polymer, он поддерживает большую часть веб-компонентов, в отл. от других http://t.co/f33kIxVWwY
То, что делает AngularJS крайне похоже на спецификации веб-компонентов.
Чем больше создаётся библиотек, чем больше пишется кода, тем ближе спецификации веб-компонентов становятся к стабилизации и внедрению.
Один человек с любимой фичей ничего не значит. Сообщество, которое использует фичу через трюки или полифилы — повод внедрить это в браузер.
Визуальный редактор для приложений, использующий веб-компоненты — http://t.co/OnEH5HN3ZX
Получасовой перерыв: подышим, разомнёмся.
Следующий Доменик Деникола «The state of JavaScript» http://t.co/FQqCIcOZIx
95-й ролловеры, валидация форм; 97-й ECMA-262 1, IE4, DHTML; 99-й ES3: function expressions, try/catch/finally/regexp.
2004: сформировалась WHATWG и сфокусировала внимание на веб-приложениях; 2005 Ajax aka XMLHttpRequest; 2006 jQuery 1.0 и JS в массы.
2008 V8, началась гонка за скоростью, вышла книга «JS Good Parts» Крокфорда; 2009 ES5, ServerJS, CommonJS, Node.js, PhoneGap, JSConf EU.
2009-й начало JS-бума; 2010 Backbone.js, RequireJS; 2012 Windows 8, Nodecopter; 2013 Nodebots, Ember, Angular, Ext. Web Manifesto; asm.js
2014 ES6 финал, ES7 начало, ???
JS на фронтенде сегодня
Началось всё с jQuery, потом Backbone.js, потом Angular (гл. фишка компонентная система) и Ember (гл. фишка мультистраничные приложения).
Почему всё веселье доступно только с библиотеками?
Потому, что спека Web Components (Веб-компоненты) пока не готова, но будет. Сейчас можно использовать Polymer вместо неё.
Идею веб-компонентов сначала подхватил Angular.
Дальше: http://t.co/05Bjg6Ad1s
Неофиц. лого лучше передаёт мощь Node.js http://t.co/Wr1e0lw4nN
JS с помощью Node.js можно завести на любом устройстве.
Windows 8 была этапом, когда крупнейшая компания предложила писать приложения для ОС на JS.
js-git — http://t.co/n5lwr2FrBI
PDF через JS (осн. движок PDF в Firefox) — https://t.co/4B4JwhYBKw
Но мы пошли дальше: Shumway SWF (Flash) через JS — http://t.co/y1UWe5WcrE
Browserify — способ заставить работать большинство пакетов из npm в браузере http://t.co/L6S16snYVr
http://t.co/vwQQBeuAck — что-то вроде Minecraft в браузере
asm.js — это крайне оптимизированное подмножество JS, работающее с нативной скоростью http://t.co/slhZstS3U8
Идея JS как виртуальной машины для веба. Писать можно на чём угодно, но компилировать в JS.
.NET, JVM, Ruby, Python, Haskel — всё это можно скомпилировать в JS и запустить в браузере.
CoffeScript — это конечно круто, но круче компилировать ES6 в обычный JS.
ES6 в JS? См. traceur https://t.co/jkQFPGLFcw и es6ify https://t.co/GH0M9eVIvw
Новое в ES6, синтакс: class, extends, super — синтаксический сахар, вместо JS-библиотек; Arrow functions arr.map(x => x*x);
Destructuring: var {x,y} = getPoint(); Rest/spread: var [first, …rest] = els; Math.max(…myArray);
Извините, трансляция перегрелась от ES6.
Изменения в ES6 проходят под лозунгом: мы не можем ничего удалить или исправить из-за совместимости, но можем добавить новое и лучшее.
Доминик, помимо прочего, автор спецификации промисов (promises), которая вошла в ES6.
И такое можно будет делать в JS '<a href="${url}">${text}</a>'
ES7 будет ещё круче.
Что будет в ES7: Weak references; Async/await function^() {var res = await promise }; Object.observe; Типы значений: встроенные (int) и спец
И ещё оператор байндинга: var method = ::obj.foo
Firefox (OS) обычно не прячет новые фичи из ES6 за флагами (многое уже доступно в нём), в отличие от Chrome.
И закрывает конференцию Брюс Лоусон «HTML.future — what the web needs next» http://t.co/NMyvryz579
@thebits, Firefox (OS) — это Firefox и Firefox OS
@fetis26, будут, обычно к ноябрю
IndexedDB = Index Douchebag
Веб по всем цифрам проигрывает приложениям (20/80%) и приложения совсем не переходная технология, какой были плагины.
Брюс поражает аудиторию дизайнерскими способностями http://t.co/m8jjdVqf7m
DRM для веба продвигают Google и Microsoft — и вряд ли для того, чтобы погубить веб.
Помимо главных DRM-жупелов, технологию продвигает медиа-гигант BBC, по понятным причинам.
Если не будет DRM, то медиаконтент будет похоронен из апсторах и исчезнет из веба.
Большая цель PhoneGap — стать ненужным. Чтобы фронтенд мог появиться на платформах без его помощи.
Blink и соотв. браузеры внедряет автоматичекую фичу Lazy Layout, которая анализирует раскладку сайта и рисует её быстрее, чем остальное.
Или <img lazyload src=“…”>, новый способ отложенной загрузки изображений.
Opera работала над спецификацией W3C Widgets, но спека не выжила. По многим причинам, кроме глупого названия.
Очень похожие творится в Chrome App Store и даже на Windows 8. Было бы хорошо объединить все хорошие идеи под одним API.
Та же идея для браузерных расширений: Opera предложила независимый формат для расширений NEX (на основе CRX для Chrome).
«Мир переходит на смартфоны» местами большой миф, поскольку на плохой сети люди всё равно пользуются Opera Mini.
Fronteers всё. Спасибо, что читали трансляцию, следите за анонсами следующих включений http://t.co/2G1SzYJ2H5