Веб-разработка *

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

• Загрузка файла по сети.
• Парсинг и компиляция распакованного исходного кода после загрузки.
• Выполнение JavaScript-кода.
• Потребление памяти.

Эта комбинация оказывается очень дорогой.



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

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

Выяснить это мне помог проект HTTP Archive.

Улучшаем компрессию бандлов на 40% от размера файла, путём замены стандартного хеширования на однобуквенный префикс + хеш пути файла.

Доброго времени суток, друзья!

В этой статье, как следует из названия, мы займемся реализацией одного занимательного эффекта с использованием одной любопытной библиотеки (anime.js). Я не буду петь дифирамбы этой библиотеке, но тем, кто плотно занимается анимацией, определенно стоит обратить на нее внимание. Простой интерфейс + отличная документация, что еще нужно для творчества?

По материалам этой замечательной статьи.

Автор указанной статьи назвал свой эффект «Анимация следа из частиц» (Particle Trail Animation).



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

Во-первых, сделаем частицы разноцветными. Потому что один цвет — это скучно.

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

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

Мы не будем использовать холст (canvas). Анимироваться будет множество маленьких блоков (div).

Итак, поехали (как сказал Гагарин, отправляясь в космос).

Сегодняшняя статья будет посвящена разработке программы на Go, использующей API vk.com для авторизации и загрузки данных о пользователе.

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

Одним из наиболее фундаментальных правил разработки быстрых веб-сайтов является оптимизация их ресурсов. Если речь идёт о текстовых ресурсах — о коде, написанном на HTML, CSS и JavaScript, это значит, что мы говорим о сжатии данных.



Стандартом де-факто в деле сжатия текстовых ресурсов в веб является метод Gzip. А именно, около 80% сжатых ресурсов, получаемых при загрузках сайтов, сжаты с использованием Gzip. Для сжатия оставшихся 20% ресурсов используется гораздо более новый алгоритм — Brotli.

Перевод «Flexible layouts without media queries» Dannie Vinther

С момента появления в браузерах в 2017 году, CSS Grid дал веб-дизайнерам и разработчикам новую суперсилу. На данный момент существует множество статей / руководств, иллюстрирующий возможности и преимущества CSS Grid, описывающих всё – от вдохновлённых ASCII-синтаксисом способом разметки Grid-областей до автоматического размещения элементов, делающих медиа-запросы чем-то устаревшим. Тем не менее, медиа-запросы всё ещё играют важную роль и это не может не вызывать некоторые сложности – наверное.

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



Мы (Всеволод Брекелов и Дарья Манухина, программный комитет конференции Heisenbug) пообщались с Анной Чернышовой, разработчиком библиотеки Akita и нового инструмента Healenium (ее доклад про BDD), и Иваном Крутовым, разработчиком Selenoid. Иван занимается инфраструктурой для Selenium тестов не первый год (Один из его мастер классов). Обсудили:

• BDD подход в 2020;
• Selenium и его развитие;
• Карьерный рост;
• Машинное обучение и Selenium.

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

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

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

Лицензию назвали Cryptographic Autonomy License. Процесс одобрения был долгим и сопровождался жаркими дискуссиями внутри OSI. Часть сотрудников посчитала, что лицензия нарушает принципы открытого программного обеспечения. Из-за разногласий организацию даже покинул её сооснователь Брюс Перенс. Разбираемся, что к чему в этой в ситуации.

Что еще у нас есть на Хабре: материалы об истории DNS, регулировании ИТ и сетевом железе.

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


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

В этой статье хотел бы рассказать немного про библиотеку, первую версию которой я создал еще в конце прошлого года. Суть очень простая — расширить возможности языка HTML, чтобы можно было без JavaScript'а писать простые и рутинные вещи: отправка формы в json формате, загрузка HTML тимплейтов на определенную страницу(по сути модульная система для HTML через http/s запросы), турболинки(привет пользователям RoR), простая шаблонизация на основе ответов ajax запросов и немного еще.

Библиотека называется EHTML или Extended HTML. Основана она на небезызвестной идее веб компонентов. Она доступна на гитхабе, там довольно таки структурированная документация с примерами. В этой статье я просто опишу основные идеи, возможно кому-то это зайдет.

UPD 1: Статья устарела
Используйте feature-sliced.design
UPD 2: ещё у меня есть Telegram-канал, где я собираю ссылки на свои статьи про разработку, развитие SaaS-проектов и управление IT-проектами.

Добрый день, уважаемые читатели. В этой статье мы поговорим об архитектуре программного обеспечения в веб-разработке. Довольно долгое время я и мои коллеги используем вариацию The Clean Architecture для построения архитектуры в своих проектах Frontend проектах. Изначально я взял ее на вооружение с переходом на TypeScript, так как не нашел других подходящих общепринятых архитектурных подходов в мире разработки на React (а пришел я из Android-разработки, где давным-давно, еще до Kotlin, наделала шумихи статья от Fernando Cejas, на которую я до сих пор иногда ссылаюсь).

В данной статье я хочу рассказать вам о нашем опыте применения The Clean Architecture в React-приложениях с использованием TypeScript. Зачем я это рассказываю? — Иногда мне приходится разъяснять и обосновывать ее использование разработчикам, которые еще не знакомы с таким подходом. Поэтому здесь я сделаю детальный разбор с наглядными пояснениями на которое я смогу ссылаться в будущем.

Хотите подготовиться к собеседованию по JavaScript и ищете вопросы, на которых можно попрактиковаться? Если так — считайте, что ваши поиски окончены. Автор материала, перевод которого мы сегодня публикуем, говорит, что собрал более двух десятков вопросов по JavaScript, предназначенных для тех, кто хочет превратиться из джуниора в сеньора, для тех, кто стремится успешно пройти собеседование в сфере фронтенд-разработки и получить интересное предложение от работодателя.

Доброго времени суток, друзья!

Веб-сокеты и Socket.IO, вероятно, являются двумя наиболее распространенными средствами коммуникации в режиме реального времени (далее — живое общение). Но чем они отличаются?

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

Перевод «Practical CSS Scroll Snapping» Max Kohler

Спецификация CSS Scroll Snap позволяет привязывать положение прокрутки к определённым элементам или местоположению после того, как пользователь прокрутил страницу или элемент. Это отличный способ для реализации следующих решений:

Всем привет! Меня зовут Артур, я работаю frontend-разработчиком в Exness. Не так давно мы перевели один из наших проектов на веб-компоненты. Расскажу, с какими проблемами пришлось столкнуться, и о том, как многие концепции, к которым мы привыкли при работе с фреймворками, легко перекладываются на веб-компоненты.

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

Привет! Это доставка списка онлайн-митапов на следующую неделю.

Встречи разработчиков в сети становятся все более разнообразными по содержанию. Так что не докладами едиными живем с 24 по 30 апреля и подбираем развлечения для себя. Можно будет сходить на квиз с хардкорным раундом по Java, присоединится к посиделкам программного комитета конференции, ну, или собрать свой сервер на GO, если вы так развлекаетесь.

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

Что такое A/B-тестирование?

A/B тестирование (сплит-тестирование) разделяет трафик в соотношении 50/50 между разными версиями страницы. По сути, этот метод — новое название для старой техники, известной как «контролируемый эксперимент».

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

Вот и все. В качестве примера можно привести простое A/B-тестирование, при котором трафик в соотношении 50/50 делится между основной страницей и ее вариацией:

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

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

В статье четыре примера. Два на C++, один на TypeScript и один на Python. Способность быстро писать относительно простые алгоритмы без багов — общая необходимость, она не зависит от специализации разработчика.