Привет, Хабр! Меня зовут Владислав, мне 13 лет, и я создал язык программирования VladX. В этой статье расскажу, как устроен его интерпретатор, почему я выбрал русский синтаксис и как можно попробовать язык в действии.
Привет, друзья!
В этой небольшой статье мы вместе с вами немного пощупаем новый Web API - Anchor Positioning.
Anchor Positioning API предоставляет новые возможности для связывания элементов между собой. Одни элементы являются якорями (якорными, anchor elements), другие - позиционируемыми относительно якорей (закрепленными, anchor-positioned elements). Размер и положение позиционируемого элемента может определяться размером и положением якорного элемента.
Кроме того, с помощью CSS можно:
определять альтернативные позиции закрепленного элемента, которые будут применяться браузером, например, при выходе такого элемента за пределы экрана
определять условия видимости закрепленного элемента, например, скрывать такой элемент при выходе за пределы экрана
На сегодняшний день этот API поддерживается всеми основными браузерами (в Safari пока только в качестве экспериментальной возможности).
В компаниях с несколькими продуктами знания о коде и архитектуре почти неизбежно расползаются. Часть живёт в репозиториях, часть — в статьях с архитектурными решениями, часть — в корпоративной базе знаний (в нашем случае — Confluence). На небольшом масштабе это выглядит как порядок. Но по мере роста начинают проявляться системные эффекты.
Появляется дублирование функционала с разными подходами. Сложнее становится погружаться в новый продукт при кросс-командных переходах. Поиск по каждому репозиторию и каждому пространству документации по отдельности — медленный и утомительный. В итоге вопросы уходят к «знающим людям», которые постепенно превращаются в узкое горлышко.
Мы столкнулись с этим в явном виде и сформулировали задачу так: дать разработчикам и системным аналитикам быстрый и актуальный поиск по всей кодовой базе компании с возможностью диалога через универсального агента.
В этой статье я расскажу, как мы построили локальный RAG-сервис, оформили его как MCP-сервер и подключили к IDE. Подход будет полезен командам с большим количеством репозиториев, внутренней документацией и требованиями к безопасности.
В современных фронтенд-приложениях работа с файлами встречается постоянно: загрузка изображений, экспорт CSV, превью и интерактивные редакторы. Но когда файлы увеличиваются в размере или их количество растет, начинаются проблемы: интерфейс подвисает, расход памяти увеличивается, а браузер иногда просто падает.
В этом руководстве мы разберем шесть практических приемов работы с Blob, которые помогают обрабатывать файлы эффективно и безопасно:
правильное создание Blob
разбивка больших файлов на части (chunks)
сжатие и конвертация изображений
реализация надежных превью файлов
экспорт данных в виде загружаемых файлов
управление памятью во избежание утечек Blob URL
Цель руководства — сделать работу с файлами быстрой, стабильной и готовой к продакшну.
Base64 — это схема кодирования двоичных значений в текст, преобразующая произвольные двоичные данные (например, изображения, файлы или любые байтовые последовательности) в безопасную печатную ASCII-строку, состоящую из 64-символьного алфавита (A–Z, a–z, 0–9, +, /). Браузеры применяют эту схему в JavaScript для встраивания двоичных данных непосредственно в код/HTML или для передачи двоичных данных в виде текста.
Недавно в браузерах появились удобные и безопасные функции для обработки Base64: Uint8Array.toBase64() и Uint8Array.fromBase64(). Хоть у них и есть множество параметров, смысл их сводится к кодированию и декодированию.
При кодировании они берут 24 бита из входных данных и разделяют их на четыре сегмента по 6 бит, и каждое 6-битное значение (в интервале от 0 до 63) соотносится с конкретным символом из алфавита Base64: первые 26 символов — это буквы A-Z в верхнем регистре, следующие 26 — a-z в нижнем, затем идут цифры 0-9 и, наконец, символы «+» и «/» в качестве 62-го и 63-го символов. Если длина входных данных не кратна трём байтам, то в качестве заполнителя используется знак «=».
Насколько же быстро могут работать эти функции?
Опишу пример, демонстрирующий, насколько важна декларативность в вопросах управления поведением «аппки» (за этим стоят вопросы сохранения высокого уровня абстракции и, как следствие, масштабируемости приложения). Задача - сделать управление мутациями DOM более декларативным и, как заявлено в заголовке, использовать реактивность на примере управления состоянием.
С Новым годом, Хабр. Меня зовут Илья, я работаю Frontend разработчиком в компании Бастион. Январские выходные в самом разгаре, но уже многие, включая меня, наобещав себе свернуть горы в этом году, находятся в поиске полезной для мозга информации. Тогда присаживайтесь поудобнее, ибо сейчас мы будем разговаривать о такой замечательной технологии для разработки гибридных мобильных приложений, как Capacitor.
Привет, я Александр Дудукало, фронтенд-разработчик. Сегодня я расскажу об обработчиках событий. Если коротко, вы узнаете о самом удобном способе управлять откликом на действия пользователя или браузера.
Эта статья — часть базового курса, где я простым и доступным языком рассказываю о том, как научиться писать свои первые сайты и веб-приложения на JavaScript. Все детали под катом.
Привет, Хабр! Новый год — хороший повод научиться чему-то новому. Длинные каникулы позволяют выйти из рутины, выспаться и наконец разобраться с тем, на что в обычные дни не хватает времени. В подборке собрали семь полезных курсов, которые помогут освоить нужные навыки. И главное — все бесплатно.
Странный заголовок, не правда ли?
А зачем вообще обходиться без id? Даже не знаю, но это вполне возможно, и приложение будет живым и вполне себе «реактивным». А всю «магию» при этом творит функция, которую я назвал tokenize.
Конечно же я, ни в коем случае, не настаиваю на отказе от id. "Элементарные" id никому не мешают и tokenize`у тоже. Но если обходиться без id, то как же получать ссылки на DOM элементы, для обращения к ним? Вот для этого и нужна функция tokenize, которая собирает референсы в удобную структуру с ветками, подветками и листьями (ссылками на DOM элементы). А вот как она это делает, мы с Вами сейчас и разберём.
3 декабря 2025 года критическая уязвимость в серверных компонентах React (React Server Components, RSC) потрясла сообщество веб-разработчиков. Была обнаружена уязвимость React2Shell/React4Shell (CVE-2025-55182) с оценкой CVSS 10.0, что является максимальным баллом для уязвимостей. Ошибка позволяет удаленно выполнять код (Remote Code Execution, RCE) на любом сервере, работающем с RSC. В течение нескольких часов после обнаружения уязвимости китайские государственные группы и криптомайнинговые компании начали взламывать уязвимые серверы.
В этой статье подробно разбирается, что и почему произошло, а также как незначительное, на первый взгляд, проектное решение в протоколе React Flight превратилось в одну из самых серьезных уязвимостей React в 2025 году.
Мы также обсудим, как защитить себя и как эта уязвимость подчеркивает важнейшие принципы безопасности.
Мне очень нравится идея потоков данных в Node.js - data streams. Они используются всюду: чтение файлов, сетевые запросы, архивирование файлов.
Не путать с потоками выполнения процессов - threads! Это совсем другое!
Есть много хороших статей по философии, теории и применении потоков, Хабр не стал исключением:
Ментальная модель потоков в Node.js
Много раз я сталкивался с необходимостью реализовывать свои потоки данных. И каждый раз я путался с кучей методов: write, push, _write, _read, с кучей событий - end, close, finish. В чем отличие write от _write?! Буквально почти все время, когда я имею дело с потоками у меня открыты доки Node.js - https://nodejs.org/api/stream.html.
Недавно, в моей статье про кастомный транспорт для ShadowSocks мне потребовался функционал передачи разных потоков данных по одному потоку (каналу)данных. Это задача мультиплексирования данных.
Я думаю, что эта задача является хорошей практикой для новичков в Node.js и программистов, любящих кодить всякие алгоритмы.
Во время программирования я встретился с несколькими "программистскими задачами" aka "подводными камнями", которые мне пришлось решить, и это было увлекательно, что и вылилось в данную статью.
В работе над React-проектами код почти всегда живёт дольше, чем кажется на старте: требования меняются, команда растёт, появляются новые сценарии и интеграции. В таких условиях выигрывает не тот, кто «быстрее собрал», а тот, кто оставил после себя понятную структуру — с предсказуемой логикой, прозрачными зависимостями и минимальным количеством скрытых допущений.
В данной статье мы расскажем о принципах «чистого кода» в React, которые используем в повседневной разработке, и покажем их на коротких примерах.
Здравствуйте, товарищи! Меня зовут Валентин, и сегодня мы снова поговорим про Atomic CSS! Обсудим имеющиеся проблемы в верстке и посмотрим, как атомарный подход их решает (или не решает). Разберем основные мифы, посмотрим на лучшие практики этого подхода и сделаем выводы.
Эту статью можно отчасти считать продолжением моей предыдущей, по данной теме, хотя напрямую они не связанны. Но если там был хардкор и технические детали, то здесь уже разберем прикладные вопросы: как верстать в Atomic CSS, чтобы получить заявленный эффект.
Уже многие годы JavaScript остаётся «рабочей лошадкой» веба. Если вам нужно сделать то, что невозможно реализовать средствами HTML и CSS, то обычно найти решение помогает JS. И это замечательно! JS помог расширить возможности пользователей, а также стимулировал прогресс HTML и CSS!
Но время идёт, функции HTML и CSS расширяются, поэтому мы должны начать заменять старые и привычные решения на JS новыми, требующими меньше JS.
Я ничего не имею против JS, но у него есть иные задачи, кроме как управление аккордеонами и внеэкранными меню навигации... Кроме того, JS нужно скачивать, распаковывать, обрабатывать, после чего он ещё часто тратит память на мониторинг и поддержку фич. Если мы сможем перенести какую-то функциональность JS в нативный HTML или CSS, тогда пользователям придётся скачивать меньше данных, а оставшийся JS сможет уделить внимание более важным задачам, с которыми (пока) не справляются HTML и CSS.
В этой статье я приведу несколько примеров; сможете придумать свои?
Знаете это чувство, когда открываешь контроллер в Express проекте, чтобы поправить одну строчку логики, и видишь ЭТО? Бесконечная вложенность, проверки на существование полей, ручной парсинг ошибок от базы данных и, конечно же, его величество try-catch, который занимает 80% файла.
Я тоже через это проходил. В каждом новом микросервисе я копипастил одни и те же функции обработки ошибок. В одном проекте я ловил ошибки Mongoose через err.name === 'ValidationError', в другом — через instanceof. Где-то мы отдавали { error: "message" }, где-то { status: "fail", msg: "..." }.
В какой-то момент мне это надоело. Мне захотелось инструмент, который я могу просто подключить одной строкой, и он сам поймет, что "E11000" от Mongo — это 409 Conflict, а ошибка Zod — это 400 Bad Request. При этом я не хотел тянуть в проект тяжелые зависимости.
Так родилась библиотека ds-express-errors. Сегодня я расскажу, зачем я ее написал и почему она может сэкономить вам кучу нервов.
Представление чисел в IT сфере - одна из самых простых вещей, которую интуитивно знает каждый разработчик, аналитик, тестировщик, админ (нужное подчеркнуть).
Еще из школы мы помним: Округление — замена числа на его приближённое значение (с определённой точностью), записанное с меньшим количеством значащих цифр.
Точные определения и механизмы легко гуглятся.
Элементарные математические операции производятся в уме, мы даже не замечаем, как в разговорной речи мы округляем любые числа.
Привет, Хабр! Меня зовут Андрей Слесаренко — frontend‑разработчик с опытом работы более 8 лет. Прошёл путь от джуна до тимлида, работал над разными высоко‑нагруженными проектами. В начале этого года начал активно использовать LLM‑агентов в повседневной работе — и за это время набил немало шишек.
В этой статье хочу поделиться своим опытом, где мои ожидания разошлись с результатом, а также рассказать об основных «шишках», которые я набил при работе с агентами.
Опыт одиночной разработки и поддержки долгоживущего веб-приложения: отказ от фронтенд-фреймворков, использование нативных возможностей браузера, работа с Core Web Vitals и влияние AI-поиска на трафик реального проекта.
TL;DR Автор в прошлой статье настроил Telegram-чат, куда несколько смартфонов скидывают пуши с помощью MacroDroid и/или Tasker. Проблема в том, что смартфоны брали на себя слишком много работы. Что, если они будут тонкими клиентами, которые шлют сырые данные на сервер, где уже происходит вся обработка и рассылка? Автор делится workflow и конфигурацией для n8n, которые позволяют это реализовать в режиме "Быстрого старта".
