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

Проблема в том, что до сих пор нет хорошего механизма управления кэшем ресурсов и результатов сетевых запросов. В своей статье я хочу рассказать как Service Worker (SW) может помочь в решении этой задачи. Объясню в формате рецептов — какие элементы и в какой пропорции смешать, чтобы получить нужный результат, исходя из задачи и требований.

Тормозящий сайт — это боль не только пользователя, но и разработчика. Как можно исправить ситуацию, в каких случаях нужно делать ставку на кэширование, а где можно довериться процессору, и как все это может помочь оптимизировать производительность сложного фронтенд-приложения, на практике готов объяснить эксперт по JS и преподаватель Академии HTML Игорь Алексеенко (@iamo0). Под катом — расшифровка его доклада с Frontend Conf 2017.

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Ускорить доставку элементов фронтенда на устройство пользователя можно несколькими способами. Разработчик Артём Белов из самарского офиса норвежской компании Cxense попробовал самые многообещающие: HTTP/2, Server Push, Service Worker, а также оптимизацию в процессе сборки и на стороне клиента. Итак, что же нужно сделать, чтобы сократить время отклика приложения до минимума?

Выясняется, что алгоритмы сжатия существуют уже давно. Это произошло где-то в июне — видимо, где-то над Самарой пролетал метеорит и идея проверить новые алгоритмы сжатия, Zopfli и Brotli, пришла мне и парню из соседней компании. Больше чем уверен, вы читали его статью, это Александр Субботин. Статья разошлась на Medium, и он известен, а я нет.

Предыстория

Начинается новый проект, собрана смышленая команда человек так из 7, намечен roadmap, согласованы сроки и бюджет ,- вроде бы все идет по плану, и счастью разработчиков нет предела. Так и слышны фразы: “Наконец-то не придется писать на (подставить angular 1, jquery, vanilla js) и можно будет использовать по-настоящему современные, модные и быстрые фреймворки! Вот в этом проекте все точно будет как надо: каждый метод будет задокументирован, 100% code coverage, CI интеграция, scrum с естимейтами, webpack, babel и стакан с реактовским смузи…” Все дружно хейтят старые глючные приложения, в которых никто толком не может разобраться, и восхваляют новое, которое, по их суждению, будет просто огонь. Знакомая ситуация, не правда ли? Но если вы хоть раз сталкивались с данным сценарием, то прекрасно и без меня знаете, что происходит через 3-4 месяца активной работы

Визуальное и текстовое программирование

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

Исторически сложилось, что алгоритмы в программах записываются в виде исходных текстов. Почти никто не ставит под сомнение, что текст — это и есть лучшее средство представления алгоритмов. Алгоритм кодируется внутри функций на языке программирования, например, C или JavaScript. Для тех, кто хочет разобраться в алгоритме с высоты птичьего полёта, предусмотрен псевдокод. Однако с текстом есть серьезные проблемы. Дело в том, что человек не оптимизирован под сплошной текст. Человек оптимизирован на восприятие графики. Текст — это относительно новое изобретение, а вот графическую информацию организмы обрабатывают уже миллионы лет.

Исходя из этого, логично было бы составлять алгоритмы в графическом виде. Посмотрите на инженеров. Они повсеместно используют чертежи. Чем же программисты хуже? Они тоже могли бы составлять чертежи алгоритмов. Некоторые здесь возразят: визуальное программирование якобы неэффективно. UML неудобен, а в блок-схемах легко запутаться. Уж лучше программировать традиционным способом — текстом. В структурном программировании есть хотя бы структура, и она обеспечивает порядок и единообразие. А кроме того, рисовать диаграммы долго и трудно. Печатать быстрее, чем рисовать.

Так что же, программисты обречены всю жизнь работать только с текстом?
Возможно, не всё так плохо. Существуют визуальные языки для представления алгоритмов, в которых тоже есть порядок и структура, например ДРАКОН, BPMN и LML Action Diagrams. Здесь мы рассмотрим визуальный алгоритмический язык ДРАКОН.

Как программировать на языке ДРАКОН

ДРАКОН не является самостоятельным языком программирования. Он работает в паре с

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

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

Оглавление серии «Производительность как восприятие»:

• Производительность как восприятие: восприятие времени;
• Производительность как восприятие: управление восприятием;
• Производительность как восприятие: управление терпением. (эта статья)

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

В прошлой статье я рассказал про новый бандлер Parcel, который не требует конфигурирования и готов к бою сразу после установки. Но что делать, если вдруг стандартного набора ассетов не хватает? Ответ прост — написать свой плагин.

Задача

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

Мне известно несколько способов решения этой проблемы:

1. набрать группу подопытных для usability-тестирования;
2. интегрировать на сайт сторонний сервис, записывающий действия пользователей;
3. написать свое решение.

Автор — Алекс Расселл, разработчик Chrome, Blink и веб-платформы в Google

TL;DR: бюджеты производительности — существенная, но недооценённая часть успешного продукта и здоровой команды. Большинство наших партнёров не осведомлены об условиях реального мира — и в результате выбирают не те технологии. Мы установили бюджет по времени пять и менее секунд до интерактивности сайта после первой загрузки, а также две или менее секунд при последующих загрузках. При соблюдении этих нормативов мы ограничены типичным устройством из реального мира и типичной сетевой конфигурацией. Это Android-смартфон за $200 на канале 400 Кбит/с, RTT 400 мс. Это означает бюджет ~130-170 КБ ресурсов критического пути, в зависимости от их состава: чем больше JS — тем меньше объём.

За последние несколько лет мы имели удовольствие работать с десятками команд. Работа оказалась просветляющей, иногда в очень неожиданных местах. Один из самых неожиданных результатов — частые случаи «западни JavaScript».


«Нам нужен новый термин для упущенных деловых возможностей из-за современного фронтенда. Может быть, “западня JavaScript”»?

Управленцы, которые дают добро на создание прогрессивных веб-приложений (PWA), часто основным мотивом называют практически беспроблемный охват новых пользователей. В то же время разработчики осваивают инструменты, которые делают возможной достижение такой цели. Никто не хотел плохого. Тем не менее, результаты «готового» проекта PWA часто требуют недель или месяцев болезненной переделки, чтобы обеспечить минимально приемлемую производительность.

Перевод. Оригинал по ссылке.

В версии Typescript 2.0 был добавлен модификатор readonly. Свойствам помеченным модификатором readonly значение может быть присвоено только в момент инициализации, или в конструкторе того же класса. Любые другие присваивания значении запрещены.

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

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


Возможно, вы думаете, что подобные заявления звучат слишком уж напыщенно. Однако, попробуйте поискать в Google, и вы столкнётесь с неистощимым источником бесконечных споров. Среди рассуждений не в пользу Node, которые могут вам встретиться, есть, например, такие, которые, вопрошая о том, что случилось с аксиомой об использовании лучшего из имеющихся инструментов для решения некоей задачи, указывают, что JS и рядом не стоял с правильным серверным инструментарием. Другие критические замечания о JS, вроде «Callback hell is real», призывающие поверить в реальность ада коллбэков, звучат как строчки из стихотворения. Некоторые из критиков Node выражаются более прямо и однозначно: «Node — это раковая опухоль».

Это текст доклада и видеозапись моего выступления с конференции rumeetup.ru приведённый в удобный для чтения вид. Так же я изъял часть вступления чтоб не отнимать время у читателей на лирические отступления о причинах побудивших меня начать разработку своего Open source комет сервера с нуля на C++.

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



Библиотека React, созданная Facebook, представляет собой мощный JavaScript-фреймворк, упрощающий работу программистов, занимающихся веб-разработкой. Однако, если вы работали какое-то время с React JS, вы согласитесь с тем, что для того, чтобы в полной мере раскрыть возможности этого фреймворка, не помешает ещё несколько дополнительных библиотек.

Автор материала, перевод которого мы сегодня публикуем, говорит о том, что из опыта знает о важности опенсорсных проектов в деле веб-разработки. Однако, из-за того, что на GitHub присутствует очень много библиотек для React, программисты оказываются избалованы выбором. Поэтому было бы неплохо сузить рассматриваемые варианты до буквально нескольких проектов. Перед вами — обзор первой десятки самых популярных библиотек для React с GitHub, ранжированных по количеству присвоенных им звёзд.

На первых этапах внедрения практик DevOps в программе ЕФС возникали сложности. Например, для выстраивания pipeline некоторых проектов требовалась автоматизация сквозных сценариев с использованием пластиковых карт и электронно-цифровой подписи, тогда как использование аппаратных средств, POS-терминал и Touch Memory — таблетка, накладывает значительные ограничения на автоматизацию проверок. С какими ограничениями столкнулись и как их решали, читайте под катом.

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

          

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

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

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

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

Приветствую вас, друзья!

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

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