JavaScript *

Эта статья не претендует на создание полноценной замены Node.js EventEmitter или других готовых библиотек. Цель — разобраться, как устроен Event Bus и написать собственную минимальную реализацию.

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

И решил я написать свою систему коммуникации модулей.

В первую очередь нужно было определиться с сущностью. Было несколько вариантов: сделать один универсальный объект или, может, класс. Но подумав, решил написать всё одной функцией.

const Emitter = () => {}

Начало положено. Именно эта функция будет представлять всю систему.

Итак, как теперь реализовать коммуникацию? Нужно сделать так, чтобы модули могли подписываться на определённые события.

Например, у нас есть приложение todo list. У него есть кнопка "Добавить задачу". Нам нужно сделать так, чтобы при клике на неё:

Продолжая тему Крошечной Языковой Модели на Nodejs мы поймем где проходит граница ее возможностей. На примере Крошечной Языковой Модели (TLM) из 2 160 параметров мы проведём воспроизводимый эксперимент и увидим в цифрах: знакомый шаблон - 99,93%, перестановка токенов - 81,69%, неизвестная структура -?%.

localStorage существует только в браузере. App Router может подготовить HTML на сервере и для Client Component. Код с директивой use client получает состояние, эффекты и обработчики событий, но первый рендер всё ещё может пройти без window и localStorage. И возникают два сбоя. Прямое чтение localStorage падает на сервере. Проверка через typeof window возвращает разные данные на сервере и в браузере. Сервер строит пустое избранное, браузер видит сохранённые id, React получает разные деревья при hydration.

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

Всем привет. На днях моя техническая статья с open source кодом про написание нейросети с нуля на Node.js вышла из песочницы Хабра благодаря НЛО, набрала 8K+ просмотров и получила крутой фидбек. Но за 2 дня до этого я решил провести эксперимент и выложить этот же материал на VC.ru. Итог — моментальный пожизненный бан без объяснения причин в первые 15 минут…

Добавить на страницу новые функции, не трогая саму страницу, звучит как противоречие. Но альтернативу мы посчитали командой: полное переписывание заняло бы год, в течение которого страница не получила бы ни одной новой функции. Мост между старым кодом и новым занял два месяца, и строил его уже я один. Расскажу, как этот мост устроен, почему получился несимметричным, где чуть не зациклился и что в нём так и осталось кривым.

Полгода назад я закрывал технический долг по производительности на клиентском проекте. Обычная история: интернет‑магазин, мобильный Performance в PageSpeed — 29, владелец каждую неделю спрашивает, когда будет зелёная зона. Мы сделали всё, что делают в таких случаях. Перегнали изображения в WebP и AVIF, вынесли критический CSS в инлайн, убрали три подключения Google Fonts на self‑host, порезали неиспользуемый JavaScript, настроили кэширование на уровне Nginx, подключили CDN. Работы на два месяца.

Мобильный Performance стал 31.

Я открыл трейс в DevTools, развернул Main thread и минут пять просто смотрел. Больше половины длинных задач на главном потоке не имели никакого отношения к сайту. Это был чат.

Дальше начинается то, ради чего написана статья. Я задал себе вопрос, который до этого не задавал ни разу за десять лет работы: а сколько вообще стоит чат на сайте? Не в рублях в месяц — в миллисекундах. И обнаружил, что честного ответа нет ни у кого. Вендоры публикуют вес загрузочного скрипта, обычно 8–15 КБ, и это правда ровно настолько, насколько правдива фраза «билет на самолёт стоит 40 долларов» без учёта багажа, сборов и трансфера. Lighthouse показывает общий счёт по странице и не выставляет его отдельным подрядчикам. Владелец сайта видит красную цифру и не знает, чья она.

Поэтому я посчитал сам. Ниже — метод, который позволяет это сделать воспроизводимо, что из него получилось, и как в итоге выглядит архитектура виджета, который не съедает главный поток.

Я довольно долго был уверен, что понимаю, как работает call stack.

Ну а что там понимать? Положил кадр, снял кадр, LIFO.

Потом открыл спецификацию. Оказалось, за «стеком вызовов» стоит каркас из пяти сущностей, а половина привычных объяснений просто не совпадает с текстом стандарта.

Замыкание — не фича языка, а побочный эффект того, что окружение живёт отдельно от кадра. «Область видимости» — вообще не сущность: такого термина там нет. А слов event loop, microtask и task queue в ECMA-262 ровно ноль. Проверяется грепом за минуту.

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

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

Как следует из названия, эта книга в значительной степени посвящена системе аутентификации и авторизации для веб-приложений. Более общие вопросы безопасности см. в серии “Шпаргалки OWASP” .

Если у вас возникнут какие-либо вопросы, не стесняйтесь задавать их на сервере Discord или в обсуждениях на GitHub.

Разработано и поддерживается Pilcrow. Исходный код доступен на GitHub.

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

Я неизвестный автор. Над моими статьями нет плашки «Блог компании». И минусуют меня стабильно. Вот реальные причины, которые я собрал под своими статьями на Хабрахабре:

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

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

Но сотрудники всё равно продолжали пользоваться Excel.

Причина довольно простая: корпоративные системы хорошо решают заранее предусмотренные задачи, а Excel позволяет быстро сделать то, чего в них нет. Построить дополнительный расчёт, проверить данные, объединить несколько выгрузок или посмотреть на показатель под другим углом.

При этом у Excel есть проблема, которая особенно заметна в момент, когда результат работы нужно показать другим людям.

Мы создаем крошечную языковую модель с нуля на чистом Node.js без использования TensorFlow или PyTorch, реализуя нейроны, автоград, эмбеддинги, механизм самовнимания (self-attention), полносвязную сеть (FFN), обратное распространение ошибки и SFT, одновременно наблюдая за тем, как отдельные веса и целые матрицы изменяются в процессе обучения

Каждые пять лет я слышу одно и то же: фронтенд больше не нужен, ему остался последний год. Сначала говорили про визуальные конструкторы - Wix, Tilda, все дела. Потом, когда ИИ выстрелил, начали хоронить разработчиков под флагом «AI напишет тебе кнопку за секунду». А сейчас новая мода - фулстекеры. Приходят такие ребята и говорят: «Да зачем нам отдельный фронт, я сам и бэк, и фронт на коленке соберу, проект сэкономит, все будут счастливы».

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

Около двух лет я использую Obsidian как основное приложение для ведения заметок, планирования и написания статей. В этой статье я хочу поделиться своим полным workflow: от распределения заметок по папкам и горячих клавиш до детального Cheatsheet по хранилищу и организации метода Zettelkasten.

О чём будет статья:

Архитектура папок (где и что хранится, а также подробный Cheatsheet.md, который я составлял для себя).

Плагины, которые я использую.

Настройка Homepage и каталога книг.

Синхронизация ПК + телефон (плагин Git + Termux на телефоне, у меня репозиторий в Gitea).

Сразу уточню: Obsidian становится действительно удобным только тогда, когда человек сам собирает под себя хранилище и находить подходящий ему метод. Ниже я разбираю реализацию по частям, чтобы каждый мог изучить интересующий блок, взять полезные идеи или настроить всё аналогично у себя.

AI-агенты отлично решают локальные задачи, но часто теряют связи между частями большой кодовой базы. Из-за этого изменение одной функции может незаметно сломать frontend, backend-роут, сервис, repository, background task или тест.

В статье разбирается CodeSlicer — локальный CLI, MCP-сервер и визуальный анализатор, который строит проверяемый граф влияния проекта. Он связывает функции, классы, DI-провайдеры, HTTP-endpoint’ы, frontend-компоненты и тесты, сохраняя evidence chain, provenance, confidence и причины каждой связи.

Показывается полный pipeline: inventory, extraction, semantic resolution, support packs, unknown regions, mutation testing, runtime observation и impact analysis. Отдельно разобрано, почему система не должна превращать предположение AI в подтверждённое ребро.

На размеченных Python-сценариях протестированы 21 тестовый сценарий, 29 mutation-сценариев, 20 обязательных semantic edges, 0 false positive и 0 false negative. Для TypeScript и frontend-backend bridge проверены 12 сценариев, 15 мутаций и 4 cross-language цепочки с endpoint precision 1.0.

Также рассматриваются интеграции с AI-агентами через CLI, MCP и skills, отличие CodeSlicer от обычных графов кода и дальнейшее развитие проверенного registry библиотек

На планировании оценивают задачу: «добавить бейдж VIP на карточку клиента». Разработчик открывает CustomerCard.tsx, молчит и говорит: «Дня три». Никто не смеётся — все открывали этот файл. В нём почти семьсот строк, и он умеет всё: грузит клиента и его заказы, кэширует, валидирует форму, различает три роли, экспортирует CSV и не падает. Сцена собирательная, но файл — нет: для этой статьи я вырастил его сам, шаг за шагом, и каждый шаг сохранил.

Вопрос к такому файлу — не «почему он большой?». Вопрос — «сколько у него причин измениться и кто их считает, кроме ревьюера?»

За годы code review я много раз наблюдал рождение комбайна и ни разу — конкретный момент, когда обычный компонент становится неуправляемым. Такого момента нет: каждое отдельное изменение выглядит разумным, укладывается в дедлайн и проходит ревью. Поэтому статья устроена как хроника: один компонент, пятнадцать вредных советов, и после каждого — счёт, который выставляет машина.

Неуправляемость не измеряется строками — строки лишь симптом. Болезнь — число причин изменения, собранных в одном файле. Пока их никто не считает, комбайн растёт легально: каждый его шаг проходит code review.

Promise, setTimeout и async/await часто работают совсем не в том порядке, которого ждёшь по коду, а тяжёлая синхронная функция способна заморозить весь интерфейс. Разберём модель цикла событий, которая объясняет эти эффекты и помогает понимать, где возникают блокировки, гонки запросов и лишние задержки.

Вайб-кодинг уронил порог входа до плинтуса: Lovable, Bolt или v0 соберут лендинг за вечер. А потом сайт неделями болтается на дне выдачи, и даже ChatGPT про него не знает. Спрашиваешь у нейронки, почему SEO хромает, — она валит на «непродающие тексты». Причина обычно глубже: для поисковых роботов ваш сайт буквально пустая страница.

Внутри: почему нейронки по умолчанию лепят SPA, как на JavaScript смотрят Google и Яндекс, почему GPTBot и ClaudeBot скачивают ваши скрипты, но никогда их не запускают, работает ли llms. txt и какая одна строчка в промпте все чинит.

Вы разбили Angular‑приложение на ленивые модули, включили production‑сборку и всё равно получили main.js весом почти 2 МБ. Причина часто скрывается в общих модулях, тяжёлых зависимостях и импортах, которые мешают tree‑shaking.

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

Привет! В этой статье я - Антон Резников, Fullstack разработчик и Lead проекта из evilUnion, расскажу, как мы отказались от знакомого всем Next JS, не пожалели об этом и запустили один из самых крупных наших проектов на очень перспективном фреймворке - Astro JS.

В этой статье мы посмотрим, что из себя представляет Astro, чем он выделяется среди других метафреймворков, изучим его особенности, а далее на реальном примере пройдем весь путь построения мультиязычного сайта на 500+ тыс. страниц. Поехали 🚀