Клиентская оптимизация *

Каждый раз начиная писать React приложение, вы так или иначе выберите какой-то вариант:

• копи-паст вашего предыдущего проекта
• какой-то бойлерплейт или даже генератор (типа Yeoman)
• готовый фреймворк не требующий конфигурации
• пишете сами все с нуля

Каждый из способов имеет свои сильные и слабые стороны, как на длинной, так и на короткой дистанции.

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

Это вторая статья о Server Side Rendering и изоморфных/универсальных приложениях на React. Первая под названием "Упрощаем универсальное/изоморфное приложение на React + Router + Redux + Express" была больше про кастомное решение, эта же статья нацелена больше на тех, кому не хочется заморачиваться, а хочется готовое решение, с коммьюнити, и вообще поменьше головной боли с настройкой, отладкой, подбором библиотек и т.д.

+

В данной статье будем рассматривать Next.JS, который обладает преимуществами в виде отсутствия конфигурации, серверного рендеринга и готовой экосистемы.

Из коробки Next.JS не умеет работать с Redux, поэтому в процессе написания пробного проекта я выделил получившийся общий код в отдельный репозиторий next-redux-wrapper, с помощью которого в этой статье мы и соберем приложение-пример на Next.JS + Redux.

На Хабре уже было предостаточно статей про то, как делать универсальное (изоморфное) приложение на стеке React + Redux + Router + Koa/Express (Google в помощь), однако я заметил, что все они содержат повторяющийся код для серверного рендеринга. Я решил упростить задачу и выделить этот общий код в библиотеку, так и появился на свет Create React Server, работает примерно так:

import Express from "express";
import config from "./webpack.config";
import createRouter from "./src/createRouter";
import createStore from "./src/createStore";
import {createExpressServer} from "create-react-server";

createExpressServer({
  createRouter: (history) => (createRouter(history)),
  createStore: ({req, res}) => (createStore()),
  port: 3000
}));

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

Изображения в формате JPEG, помимо собственно файлов с расширением .jpg, можно встретить внутри PDF-файлов и TIFF-файлов.

Стейкхолдеров технологии JPEG можно, наверное, разделить на следующие группы:

• разработчики фотоаппаратов и сканеров;
• фотографы (большие фотографии в хорошем разрешении с высокими требованиями к качеству);
• соцсети и CDN'ы типа imgix, которые раздают залитые фоточки неконтролируемого UGC-происхождения, количества и размера в пережатом виде;
• вебмастеры, которые управляют умеренным количеством не-UGC картинок с контролируемым качеством;
• любители отсканированных бумажных книг и прочих исторических источников;

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

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

И тогда приходит он, рефакторинг платежного процесса. Но мы решили сделать процесс еще интереснее, добавив к рефакторингу идеи IDEF-0.

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

В прошлом году Яндекс провел образовательный экспериментальный проект, который получил название «Мобилизация». Наша цель была в том, чтобы участники поработали в настоящей команде и создали настоящий продукт — причём продукт мобильный. «Мобилизация» объединила Школу мобильной разработки, Школу менеджеров, Школу мобильного дизайна и Школу разработки интерфейсов.

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

Лекции студентам читали сотрудники Яндекса, которые каждый день сталкиваются с реальными задачами и делают приложения для миллионов пользователей. Специально для читателей Хабра мы собрали полную программу курса по мотивам лекций «Мобилизации».

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

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

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

Анатолий Орлов ( anatolix ), Денис Нагорнов ( Яндекс )

Анатолий Орлов: Всем привет! Меня зовут Анатолий. Я последние 10 лет работал в Яндексе. В Яндексе я занимался разными вещами, но, так получилось, что на HighLoad я всегда доклады делаю про скорость разного вида. У меня есть содокладчик — Денис Нагорнов, он и сейчас работает в Яндексе и занимается, помимо всего прочего, не поверите, тоже скоростью.

Доклад называется «Скорость с доставкой до пользователя». Как вы знаете, огромное количество компаний пытаются оптимизировать загрузку своих страничек. Некоторые компании так гордятся достигнутыми результатами, что они эти результаты пишут на своих страничках, причем даже не внизу, а вверху.

Например, скриншот с сайта Google:

Денис Измайлов ( DenisIzmaylov )

Всем привет! Вкратце расскажу о себе. Я — Денис Измайлов. Последние 5 лет сосредоточился на JS-разработке, делал много Single Page Application, highload, React, выступал на MoscowJS несколько раз, каммитил webpack и т.д.

Сегодня хотел бы поговорить вот о чем: почему от Single Page Application в его классическом виде стоит отказаться; как изоморфные приложения отразятся на Вашей зарплате; и что вы будете делать на этих выходных?

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

Приложение Камера для iPhone / iPad очень удобно в использовании. Пользователь легко может переключаться из режима фотографирования на видеосъемку. В режиме видеосъемки показывается время съемки и всего одна кнопка (Старт / Стоп). К сожалению, при использовании стандартного UIImagePickerController’а нет возможности контролировать количество кадров в секунду и некоторые другие параметры. Я покажу, как, используя AVFoundation framework, получить доступ к более тонким настройкам камеры, таким как, количество кадров в секунду, качество видео, длительность записи, размер видео файла. Пользователь сразу будет видеть на экране видео в том качестве, в котором оно будет сохранено.

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

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

Думаю, все уже знают, что современные браузеры умеют рисовать некоторые части страницы на GPU. Особенно это заметно на анимациях. Например, анимация, сделанная с помощью CSS-свойства transform выглядит гораздо приятнее и плавнее, чем анимация, сделанная через top/left. Однако на вопрос «как правильно делать анимации на GPU?» обычно отвечают что-то вроде «используй transform: translateZ(0) или will-change: transform». Эти свойства уже стали чем-то вроде zoom: 1 для IE6 (если вы понимаете, о чём я ;) для подготовки слоя для анимации на GPU или композиции (compositing), как это предпочитают называть разработчики браузеров.

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

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

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

CSS-шлюзом (CSS-lock) называется методика из адаптивного веб-дизайна, позволяющая не перепрыгивать от одного значения к другому, а переходить плавно, в зависимости от текущего размера области просмотра (viewport). Идею и одну из реализаций предложил Тим Браун в статье Flexible typography with CSS locks. Когда я пытался разобраться с его реализацией и создать свои варианты, мне с трудом удавалось понять, что именно происходит. Я выполнил много вычислений и подумал, что полезно будет объяснить другим всю эту математику.

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

Введение

В рамках “Дизайна госсистем” мы создали для вас (разработчиков всех видов) чек-лист доступности сайта для людей с ограниченными возможностями, который нужно прибить над рабочим столом каждого дизайнера и фронтендера. Он подходит к любым проектам (совсем не только государственным) в нем нет ничего лишнего. В нем только исключительно важная, критичная и полезная информация.
Так что печатайте, читайте и делитесь со своими коллегами.
Это крайне необходимые текст и знания.

Магазин приложений Google Play Store, знакомый пользователям мобильной операционной системы Android, теперь способен распознавать и отфильтровывать установки мошеннических приложений. О расширении функциональности сообщили представители самой компании Google Казуси Нагаяма, аналитик качества поиска и Эндрю Ан, менеджер по продукту. Усовершенствование было представлено в последний день октября.

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

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

Прочитав заголовок, вы, наверное, подумаете «Избитая тема, да сколько можно об это писать», но всё равно не смог не поделиться своими велосипедами с костылями наработками.

Введение

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