JavaScript *

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

Привет! Я Незар, фронтенд-разработчик в Т-Банке. Наш Angular-проект достаточно крупный, и со временем в нем накопился неиспользуемый код. Это замедляет разработку, усложняет рефакторинг и вводит в заблуждение новых членов команды. А ручная очистка такого «мертвого» кода требует огромных трудозатрат и быстро перестает быть эффективной.

Поэтому мы решили автоматизировать этот процесс с помощью Knip — статического анализатора для TypeScript. В статье я расскажу, как мы его настроили, интегрировали в pre‑commit и CI/CD и какие результаты получили.

Казалось бы, что может пойти не так с легковесными векторными анимациями? Вектор в Lottie, JSON весит копейки. Но тестирование на реальном телефоне закончилось фиаско: через пару минут скролла чип раскалился до 42 °C, а интерфейс ушёл в троттлинг.

Оказалось, что покадровый пересчёт кривых Безье в JS на мобильных экранах быстро превращает телефон в печку.

В кейсе разбор того, как мы перешли на аппаратно декодируемые видео‑спрайты, почему IntersectionObserver втихую крутил видео под непрозрачными модалками и как в итоге удалось сбить температуру обратно до стабильных 30 °C.

Разумеется, в виду имеются старые игры. Игры детства. В какой-то момент, захотелось их вспомнить. Многие скажут, что есть DOS Zone и будут правы, но что может сравниться с тем, чтобы запустить любимую игру у себя на компьютере, локально, пусть даже и внутри Internet-браузера. Ну и сама возможность разобраться, пусть даже и довольно поверхностно, со всеми этими JS-DOS технологиями дорогого стоит.

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

В статье рассказываю, как оставил всё окружение в Kubernetes, а локальную сборку начал синхронизировать прямо в pod через DevSpace.

Задача была на полчаса: пройтись по списку из 216 адресов вида t.me/имя и понять, какие живы и что это — канал, группа или аккаунт. Ушёл день, и почти весь на то, чтобы перестать верить собственному коду. Ни одна из пяти ошибок не выглядела как ошибка: HTTP 200, валидный HTML, разбор без исключений.

Представьте типичную ситуацию. У вас есть сервер на каком-то языке (сейчас какой именно для нас не важно, но допустим, это Rust). И в нём по каким-то причинам нужно исполнить JavaScript-код. Например, фронтенд написан на React, и вы хотите рендерить HTML на сервере (SSR). Или есть бизнес-логика, которая проще пишется на JS. Или библиотека, которая существует только в npm, и переписывать её на Rust нет ни сил, ни желания. Таких примеров можно привести множество: markdown, dompurify, highlight.js и т.д.

Всем привет! Меня зовут Евгений, я фронтенд‑инженер с большой экспертизой в разработке современных веб‑приложений. Сегодня хочу рассказать про свой очередной open‑source проект для построения веб‑приложений на основе Angular.

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

Итак, встречайте Centrifugal. Посмотрите официальный сайт проекта, там очень много крутых примеров использования!

Проект разрабатывался изначально, чтобы создать набор высокопроизводительных, гибких инструментов и компонентов для построения веб‑приложений. Но на одной из итераций разработки я решил обеспечить поддержку для построения All‑in‑One интерфейсов, то есть добавил режим standalone‑приложений с отображением собственной виртуальной клавиатуры, которую можно полностью кастомизировать. Тем самым обеспечил полноценную поддержку создания пользовательских интерфейсов, например, под киоски самообслуживания и тому подобное.

Когда Next.js перешел с Pages Router на App Router и убрал встроенную поддержку i18n‑роутинга, библиотека next-intl стала стандартом по умолчанию для большинства команд. Ян Аманн проделал отличную работу по ее поддержке, и долгое время это был самый надежный выбор для мультиязычных проектов.

Ставил утилиту по инструкции с сайта проекта: блок с командой, кнопка «скопировать», вставка в терминал. Перед Enter посмотрел на строку — вставилось не то, что было в блоке.

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

«👋».length === 2 — это знают все. Дальше все пишут честную функцию, которая ходит по строке по символам, а не по кодовым единицам UTF-16. И почти всегда она получается квадратичной: и длина, и обращение по индексу проходят строку с начала, поэтому обычный цикл по ним — это n²/2 шагов без единого вложенного цикла в коде.

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

Внутри: замеры роста, починка через один вопрос «есть ли в строке суррогатная пара», и почему тест на время здесь бесполезен, а тест на показатель роста — нет.

Теперь можно говорить без всяких прикрас: мы выпустили анализатор для языков JavaScript и TypeScript. А значит, это повод испытать его в полевых условиях и посмотреть, что он найдёт в исходном коде хорошо знакомого многим Open Source проекта Visual Studio Code. Если вам интересно узнать, какие ошибки и подозрительные фрагменты кода обнаружил анализатор, — добро пожаловать в статью.

Если вы пишете на JavaScript или TypeScript, выбор инструмента обычно начинается с двух знакомых вариантов: VSCode или WebStorm.

Сегодня расскажу вам про третий вариант: OpenIDE. Это готовая IDE на базе той же платформы, которую использует WebStorm.

Философия также схожа: вам не нужно собирать рабочий инструмент из десятка расширений. В одном дистрибутиве комфортно и легко настроить и менять версии Node.js, npm, yarn и pnpm, TypeScript, React и Angular, линтеров, Git и HTTP-клиенты. Можно открыть проект и сразу заниматься делом.

Прочтя недавний перевод про запаковку БД в exe, решил рассказать об идеи, которую реализовал лет 6 назад в своем домашнем проекте. Сам проект недоделал, но речь в статье об архитектуре файлов и их запаковке.

Почему исправные 20-мс аудиопакеты всё равно превращались в щелчки? В БОЛТУНе каждый пакет запускался как отдельный AudioBufferSourceNode — до 50 мини-плееров в секунду на одного говорящего. Мы заменили это расписание одним непрерывным AudioWorklet с кольцевым буфером и проверили новую схему тестами.

Что поисковики и ИИ предлагают учить перед собеседованиями? Чаще всего — что-то в духе списка вопросов с гитхаба.

И как это учить? Тупо нажимать на каждый ответ и заучивать разницу в синтаксисе?

А на собесе потом:

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

В статье рассмотрю проблемы синхронной отрисовки и переход к новой архитектуре,  почему пришлось отказаться от методов жизненного цикла с приставкой *will, что такое Fiber, почему первый вариант приоритизации с ExpirationTime не сработал и как пришли к React Lanes.

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

Один и тот же JavaScript-код в браузере, Node.js, Deno и Bun должен показывать примерно одинаковую скорость – по крайней мере, так кажется до первых замеров. Я взял четыре прикладные задачи, добавил к сравнению Python и измерил не только время выполнения, но и потребление памяти, причём отдельно посмотрел, как результат меняется вместе с границами замера. Оказалось, что у каждой среды своё представление о быстродействии, а лидер зависит не только от алгоритма, но и от того, входят ли в задачу чтение файлов, парсинг или обработка изображений. Все примеры и исходные данные можно запустить локально и сравнить результаты со своей машиной.

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