Давно хотел попробовать Prolog, и вот появился удобный случай. Пришла идея логической игры, смесь шахмат, шашек и нашествия зомби. Prolog - логический язык программирования, говорят, на нём удобно решать комбинаторные задачи, что может пойти не так!
Пробуем собрать свой минималистичный starter-kit.
Комедия в трех действиях. Туториал из трех частей.
Создадим причудливый конфиг на webpack + собственный роутинг в первой части. Реализуем реактивные хранилища во второй и уменьшим сложность с помощью веб-компонентов в третьей.
Всем привет!
Самостоятельное создание ноды HTTP Request может быть сложной задачей. Нужно самостоятельно искать и указывать эндпоинт, прописывать body для запроса и проставлять нестандартный заголовок авторизации, что совершенно неудобно и сложно для многих пользователей.
По вышеописанной причине мы решили разобраться в этой проблеме, и опубликовать собственную комьюнити-ноду n8n-nodes-amvera-inference, которая сможет помочь пользователям, без сложностей, работать с нашим Inference API нужной модели.
В статье мы расскажем и про саму разработку комьюнити-ноды, и про её установку с настройкой.
Команда JavaScript for Devs подготовила перевод статьи о том, почему 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 может стать бутылочным горлышком.
