JavaScript *

Все вокруг стараются сделать мир лучше, пишут редакторы, используют нейросети. Скука! Я решил пойти другим путём и создал "Лабораторию Абсурда" — которая намеренно и с особым цинизмом превращает любой осмысленный текст в лингвистический бред.

Не спорю, существуют и другие генераторы бреда, но я дарю вам 50 (или что-то около того) разных способов издевательства над текстом и здравым смыслом! Никаких рекламных баннеров, только ванильный JS и словари на тысячи слов, только хардкор!

Мир веб‑разработки давно вышел за пределы простых проектов. Статьи про «Hello, world» больше не спасают, когда нужно собирать масштабируемые приложения для реальных пользователей. Что выбрать — монолит или микросервисы? REST или GraphQL? React, Vue или Angular? Node.js, Python или Go? Какая база данных лучше подойдёт — реляционная или NoSQL? Нужно ли кэширование? Как настроить CI/CD, контейнеризацию и мониторинг? И почему нельзя забывать о мобильной версии и SEO? В этой статье я делюсь опытом, описываю архитектурные подходы, сравниваю основные технологии и инструменты, рассказываю о бэкенд‑ и фронтенд‑best practices, базах данных, кэшировании, DevOps, мониторинге и оптимизации. Каждая тема подкреплена примерами и ссылками на источники. Материал рассчитан на тех, кто хочет уверенно руководить полным циклом разработки — от планирования до продакшна. Если вы давно ищете структурированное руководство по современному фулл‑стеку, оно перед вами. Из этого путеводителя вы также узнаете об оптимизации производительности Node.js (gzip, асинхронность, логирование), работе с графами данных и типизации GraphQL, особенностях React (hooks, SSR), Vue, Angular, Tailwind и shadcn/ui, выборе баз данных, настройке кэширования Redis, задачах CI/CD и Dockerfile, Kubernetes, а также об инструментах мониторинга и SEO, включая мобильную адаптивность и структурированные данные. Текст большой, но разбит на разделы и содержит кодовые примеры, так что вы сможете легко адаптировать идеи под свои задачи.

Всем привет!
Меня зовут Прокошкин Леонид, я Frontend-разработчик в компании DDPlanet.

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

В проекте было около 30 Lottie-анимаций, некоторые весили ~100 KB, и нам нужно было оптимизировать их загрузку.

Как снизить трафик и нагрузку? Правильно - кеширование. Мы выбрали кеширование на стороне Service Worker.

Как правило, обучающие материалы сводятся к показу одного «правильного» решения. Такие решения можно попробовать запомнить, но они быстро забываются и не помогают по-настоящему понять алгоритм.

Меня интригует вопрос: возможно ли объяснение, которое позволит не просто заучивать формулы, а понять саму логику? И если такое объяснение существует, даст ли оно возможность решать похожие задачи — или даже помогает становиться лучшим программистом?

Сразу оговорюсь: мы не будем останавливаться на тривиальных проверках,
вроде пустого массива или некорректных параметров. Фокус статьи — на сути алгоритма.

В этой статье мы не просто посмотрим на готовый код. Вместо этого мы:

1. Разберем ключевую идею алгоритма на простом примере.
2. Сконцентрируемся на крайнем случае, в котором ошибается большинство.
3. Сравним два подхода к реализации — с закрытым и полуоткрытым диапазоном.
4. Увидим, как небольшие изменения в коде позволяют решать целый класс задач.

Недавно мне понадобилось реализовать автоматическую генерацию QR для личного проекта. Идея простая: пользователь нажимает на кнопку «Пригласить друга», а небольшая функция на JavaScript закидывает в буфер обмена реферальную ссылку.

Все было бы хорошо, но нужно было добавить попап с QR-кодом, который при сканировании перекидывает по ранее полученной ссылке. И так как писать собственное решение было сомнительной идеей, пришлось использовать библиотеку — QRious. В этой статье расскажу, как с ней работать.

Привет, Хабр!

URLPattern дорос до того, чтобы его можно было использовать как нормальный «роутер без фреймворка». В браузерах API уже поддерживается широким набором движков, а в Node 24 он доступен глобально без импортов. Один и тот же паттерн можно матчить и в Service Worker, и в HTTP-сервере на Node.

URLPattern — это примитив платформы для сопоставления URLам по удобному паттерну. Он матчится по компонентам: protocol, hostname, port, pathname, search, hash. Есть test и exec, named groups и опции вроде ignoreCase. Важный плюс в том, что у нас есть одинаковая семантика в браузере и в рантаймах, которые его тащат из той же спеки.

В Node 24 объект доступен глобально, как URL, без require('node:url'). Сам класс появился в 23.8, в 24-й ветке он отмечен как experimental, но доступ из коробки.

По поддержке в браузерах ситуация здоровая. По Can I use, URLPattern работает в актуальных ветках Chrome, Firefox, Safari, Edge, включая мобильные.

По крайней мере так сказал блогер Demimurych у меня в комментариях: 

Дальше была беседа в комментариях, из который я вынес два хороших замечания:

Тему замыканий в языках программирования стоит рассказывать с проблемы функционального аргумента. 

Реализация этой проблемы наиболее и единственно полно описана в ECMAScript спецификации. 

Я потратил время и покажу, что нашёл!

Более 50 % приложений вызывают высокорисковые API браузера, что может быть признаком наличия вредоносного кода. Почти 64 % загружают скрипты с хостов за пределами РФ. Более 70% компаний рискуют получить штрафы от 1 до 18 млн. руб. за сбор ПД с использованием баз данных, размещенных за пределами РФ.

Разбираем результаты исследования безопасности frontend-приложений 3000 крупнейших российских компаний за первое полугодие 2025 года.

История о создании Telegram Miniapp с нуля: боль, костыли и необычные решения.

- Как превратить обычный сайт в миниапп малыми усилиями
- Как передавать данные в миниапп чтобы ничего не сломалось.
- Как реализовать версионирование в миниапп

Привет, Хабр!

А вы интересуетесь современными возможностями CSS и HTML? Может, некоторые из вас думают, что нового там ничего не появится или что свежие фишки не поддерживаются браузерами? Это мнение давно устарело. Современные HTML и CSS позволяют реализовывать интерактивные элементы, которые раньше были доступны только с помощью JavaScript. Можно сказать, что границы между разметкой, стилями и программированием постепенно стираются.

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

Я собрал компиляцию полезных практик и оформил их в сокращённом текстовом виде.

Команда JavaScript for Devs подготовила перевод статьи о SolidJS — реактивной UI-библиотеке, которая выглядит знакомо для React-разработчиков, но работает совсем иначе. Автор разбирает ключевые отличия: почему в Solid нет виртуального DOM, как устроены сигналы, эффекты и прокси-хранилища, а также какие привычки из React ломают реактивность. Если вы давно хотели понять, как SolidJS работает под капотом, эта статья — отличный старт.

Angular Signals 101 Это не поверхностный обзор, а полное погружение в мир сигналов. Мы разберем всё: от публичного API до внутреннего устройства планировщика в Zoneless.

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

Она о том, как должно меняться мышление у middle-разработчика в сторону senior-разработчика. Автор в частности поясняет, что «цель этой книги — дать вам справочник для работы с новыми и legacy-проектами во фронтенде и бэкенде, а также для работы по их развертыванию». 

Автор приводит приемы senior-разработчиков, чтобы «работать скорее на уровне системы, чем отдельных строк кода» и находить оптимальные/компромиссные решения.

Привет, Хабр! IEEE Spectrum опубликовал ежегодный рейтинг языков программирования за 2025 год. Там много всего интересного, на что стоит обратить внимание. Давайте разберемся, как формируется этот список, какие языки пока что удерживают лидерство, кто теряет позиции и почему, а также как ИИ все (ну или почти все) меняет. Поехали!

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

React больше не побеждает за счёт своих технических достоинств. Сегодня его выбирают по умолчанию. И именно это «по умолчанию» теперь тормозит инновации во всей фронтенд-экосистеме.

Когда командам нужен новый фронтенд, разговор редко начинается с вопроса: «Каковы ограничения и какой инструмент лучше всего под них подходит?» Чаще всё звучит так: «Давайте возьмём React — его все знают». Такой рефлекс запускает самоподдерживающийся цикл, в котором архитектуру определяют сетевые эффекты, а не техническая уместность.

Команда JavaScript for Devs подготовила перевод статьи о том, сколько трафика реально выдерживает сайт на Next.js. Автор провёл нагрузочные тесты, сравнил VPS и выделенный сервер, проверил разницу между предрендерингом и SSR и сделал вывод: для сайтов с потенциальными всплесками трафика предрендеринг — спасение, а SSR может стать бутылочным горлышком.

Привет, Хабр!

С вами снова Дмитрий. В первой части мы с головой окунулись в философию Headless CMS и разобрали, почему Strapi стал глотком свежего воздуха для разработчиков, уставших от рамок монолитных систем. Мы увидели, как контент освобождается от шаблонов, получая возможность жить на любых платформах и устройствах.

Но мощный и гибкий бэкенд - только половина уравнения. Без современного, умного и производительного фронтенда вся эта свобода рискует остаться просто красивой теорией. Где же тот самый «идеальный фронтенд», который раскроет потенциал Headless на все 100%?

Опыты кодирования с ИИ в команде.

Написать эту статью меня сподвигла дилогия уважаемого Александра Антипина aka @alexantipin «Использование нейросетей в разработке игр» и попробовать поделится собственным опытом ИИ — геймдева. Это не совсем геймдев, это про разработку музыкального приложения, осложненное двумя маниакальными идеями: ни строчки кода руками и веб‑прриложение генератор музыки в реалтайм. Сам по себе проект, как законченное приложение, вряд ли представляет интерес, потому что это попытка переосмысления автопилота из другого приложения EtherMusic, тоже написанного ИИ. Там мне так и не удалось победить проблемы производительности на слабых устройствах типа смартфона.

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

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

Многие мои собеседники "стопроцентно" уверяли меня, что сама суть функционального программирования заключается в повсеместном использовании map, filter и reduce; что эти функции превосходят циклы for во всём, настолько, что их нужно запихнуть в каждый возможный язык безо всякого анализа затрат и выгод, потому что выгоды настолько несравненно потрясающие, что затраты просто не могут иметь значения. А само сомнение в этих затратах уже доказывает, что я ничего не понял. Поэтому пора задать главный вопрос: действительно ли именно они (map, filter и reduce) и есть ядро функционального программирования?

К чёрту теорию; давайте посмотрим на практику. Давайте взглянем на реальный проект на Haskell. Я знаю два крупных проекта на Haskell, которые вышли за пределы хаскель-экосистемы и стали полезными программами, которые люди скачивают: xmonad и pandoc. Но xmonad - странная программа: она делает массу привязок к библиотекам C и взаимодействует со всевозможными системными сервисами…Что, конечно, неплохо, как говорится, но из-за этого она не очень типична. А вот pandoc - это чистейший Haskell: парсинг, работа с абстрактным синтаксическим деревом, его трансформация и генерация; т.е., по сути, огромный компилятор для документов. Более «хаскельским» код быть не может. Давайте посмотрим на него.

Привет, на связи снова я – React-разработчик Дмитрий. Сегодня отвлечемся от теории и разберем конкретный случай и какое решение для него использовалось.

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

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

Собственно, выглядит компонент загрузки файла вот так: