JavaScript *

Когда VPN на телефоне уже не спасает, а DPI провайдера научился резать WireGuard за секунды, приходит время переносить обфускацию на роутер. В этой статье расскажу, как я сделал полноценный аддон для Asuswrt-Merlin с веб-интерфейсом, выборочной маршрутизацией и поддержкой AmneziaWG 2.0. И почему пришлось отказаться от kernel module.

Проблема:

У меня ASUS GT-AX11000 с прошивкой Asuswrt-Merlin. Обычный WireGuard на роутере через встроенный клиент Merlin работает, но провайдер его видит и режет. AmneziaWG решает эту проблему за счёт обфускации, DPI не может отличить трафик от обычного UDP.

На телефоне и ПК есть клиент Amnezia VPN, и там всё работает. Но есть нюанс...

На дворе 2026-й, и за это время как React, так и Vue сделали гигантский скачок в развитии и создании экосистемы вокруг себя. Но статистика до сих пор беспощадна к Vue. На React в два раза больше вакансий, чем на Vue. Сколько я ни спрашивал React-инженеров, ответ был всегда один и тот же: «React для серьезных проектов, а Vue так уж».. Серьезно? Почему вы до сих пор так думаете?? Ну хоть один пример приведите, что нельзя сделать во Vue. Хотя бы потратьте 1 день на изучение экосистемы Vue 3 Composition API, Vue Router, Pinia - да вы после этого забудете про свой React. А про различные useState я вообще молчу, Vue тут вообще вас всех обошел с обычными ref. Это вы еще не слышали про keep-alive.

Я считаю, что такое мнение построилось из-за простой причины: люди просто поставили свою карьеру на React, вот почему они его защищают, а компании продолжают его использовать.

Если кратко - да все с ними ТАК. Это замечательный набор современных браузерных технологий, для решения реальных задач веб-разработки. Веб-компоненты позволяют делать очень многое, более просто и элегантно, чем это было бы без них. А главное, они позволяют, с потрясающей гибкостью, решать задачи “со звездочкой” - те, которые немного выходят за рамки и требуют более творческого подхода от разработчика.

Почему-же тогда по Хабру гуляют, кхм… некие одиозные личности (не будем показывать пальцем) и рассказывают нам про то, что веб-компоненты это ужас-ужас и полный провал? Давайте разберемся.

31 марта из npm source maps утёк исходный код Claude Code. Через часы появился OpenClaude — форк с OpenAI-совместимым шимом, который позволяет подключить GPT-4o, DeepSeek, Llama через Ollama или любую модель. Разбираю, как это устроено, что реально работает, что нет, и почему «бесплатный Claude Code» — не совсем то, чем кажется.

Привет! Я Никита, Staff-инженер в крупном финтехе. В этой статье я хочу поделиться нашим опытом построения системы observability. Мы прошли путь от простых логов до сквозной трассировки, и я покажу, как это работает на фронтенде.

TL;DR: В статье разбираем опыт внедрения OpenTelemetry в крупном финтех-проекте.
Проблема: Логи без контекста не позволяют быстро найти причину 500-й ошибки в распределенной системе.
Решение: Сквозная трассировка (Distributed Tracing) от фронтенда до бэкенда.
Что внутри: Реализация CompositeLogger на TypeScript, патчинг fetch для сохранения контекста и примеры того, как превратить технические трейсы в карту бизнес-процесса. А именно - frontend реализация и практические детали интеграции.

В экосистеме JavaScript произошёл серьёзный инцидент, который хорошо показывает, насколько опасными стали атаки на open source и цепочки поставок. Исследователи StepSecurity сообщили о компрометации axios — одной из самых популярных HTTP-библиотек в npm (~83 миллионов загрузок в неделю). Злоумышленник получил доступ к аккаунту одного из ведущих мейнтейнеров проекта и опубликовал две вредоносные версии пакета: axios@1.14.1 и axios@0.30.4.

На первый взгляд это выглядит как обычное обновление зависимости. Но на деле установка этих версий могла привести к заражению системы трояном удалённого доступа.

BIP39 вместо номера телефона, ECDH P-256 + AES-256-GCM, non-extractable CryptoKey, трафик неотличимый от HTTPS. Как это устроено, что сломалось в процессе и почему некоторые решения были болезненными.

Мне нравится писать тесты. Написание теста и последующее обновление кода для его прохождения — всегда увлекательный процесс.

Но нет ничего хуже, чем выяснение того, что проверяют существующие тесты (раньше я сам часто был автором таких тестов).

Представляю вашему вниманию мои советы по написанию высококачественных тестов для фронтенда.

Когда меня просят подсказать, как структурировать веб-сервис, я всегда начинаю с одного и того же: напишите сервер, который в ответ на HTTP-запросы выдаёт текст в формате HTML.

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

Выслушав меня, веб-разработчики часто отвечают: «о, так вам нравится рендеринг на стороне сервера», на что я обычно, поморщившись, парирую — «да, в какой-то мере». Не распыляйтесь по пустякам, если собеседника отделяет от вас десятилетие невежества. Хотя бы они понимают, о чём я. 

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

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

Недавно в Амстердаме прошла конференция Vue.js Amsterdam 2026 — ежегодное мероприятие, посвящённое экосистеме Vite и современным инструментам фронтенд-разработки.

В этом году программа оказалась особенно насыщенной. Команда экосистемы показала сразу несколько направлений развития: обновления ключевых инструментов, новые эксперименты в архитектуре фронтенд-фреймворков и попытку собрать полноценную платформу разработки вокруг Vite.

В этой статье разберём основные анонсы конференции: Vite 8, Vite+, Void Cloud, а также обновления Vue и Nuxt.

Современные браузеры тихо съедают экосистему JavaScript живьем.

За последние несколько лет основные браузеры выпустили нативные веб-API, которые заменяют удивительно большое количество утилит, которые мы до сих пор устанавливаем по привычке. Тем не менее, многие разработчики продолжают использовать уже ненужные, но привычные библиотеки. Если зависимость всегда работала, она остается в стеке, даже если браузер уже умеет выполнять ту же работу.

Такой подход обходится дороже, чем кажется. Каждый дополнительный пакет увеличивает вес сборки, затраты на обслуживание, частоту обновления версий и риск отказа от проекта в долгосрочной перспективе. Нативные API-интерфейсы стоят пользователям 0 КБ данных, работают глубоко в движке (часто вне основного потока (main thread)) и используют оптимизации, недоступные библиотекам.

Изначально проект планировался как простенький 3D-редактор, а-ля Tinkercad, но на стероидах, с чертежами, фасками и другими продвинутыми операциями.

После предыдущей статьи вектор разработки немного сменился. Народ захотел полноценный САПР, прямо в браузере, прям как onshape. Правда onshape работает не совсем в браузере, это тонкий клиент, который работает на серверах ..., а пользователю выводит просто картинку.

У меня на данный момент сервера нет :) Для работы моего редактора он практически не нужен. Но об этом чуть позже.

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

Excel не единственный, кто любит превращать любые данные в даты.

Если вы работаете с датами в JavaScript, то, вероятно, рано или поздно пользовались new Date(someString). Это удобно: передаём строку, получаем объект Date. Но привыкнув к Python, я был удивлён тем, насколько свободно JavaScript обращается с форматами дат. Позвольте мне проиллюстрировать это примерами.

Я 10 лет пишу на JavaScript и публично заявляю: я его не знаю. Но почему-то уверен, что закрою любую задачу из вашего бэклога. Разбираю манипулятивную схему, которой грешит весь рынок найма, особенно сейчас, во время кризиса.

Последнюю пару лет мы наблюдали существенный рост сообщества e18e и связанного с этим увеличения количества коммитов, направленных на повышение производительности. Во многом причиной этого стала инициатива по «очистке»: сообщество избавлялось от избыточных, устаревших или неподдерживаемых пакетов.

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

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

Привет!

Это девятый выпуск Frontend Status — дайджеста по фронтенд-разработке.

В этом выпуске:

📺 Разговор с Машей Кондрашиной из Авито о том, что в IT больше не спорят из-за технологий.

🤖 VS Code переходит на еженедельные релизы благодаря AI-агентам, Chrome объясняет разницу между MCP и WebMCP, а Эдди Османи вводит термин «comprehension debt».

⚛️ React получает shadcn/cli v4 с режимом для агентов, SvelteKit ловит FOWL, Astro v6 подтягивает данные из API прямо в content collections.

🌎 Chrome 146, Mozilla за анонимность в вебе.

🎨 Брэд Фрост о дизайне в эпоху AI.

📦 Эмпирическое исследование утечек памяти на 500 репозиториях.

...и многое другое.

Недавно, когда писал статью про «Тетрис», я поймал себя на мысли, что вспоминаю не только падающие блоки, но и другой культовый проект — жёлтый кругляш, вечно убегающий от призраков. А потом в памяти всплыл фильм «Пиксели» (2015). Там есть сцена, которая одновременно смешная — жутковатая: создатель Пакмана, Тору Иватани, выходит к гигантскому Пакмену и пытается с ним поговорить по-отечески: 

«Пакман, я сделал тебя. Ты такой голодный, я знаю. Не надо больше есть. Хороший мальчик» — актёр Денис Акияма (Тору Иватани).

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

В 2025 году JavaScript исполнилось 30 лет — хороший повод попытаться объять необъятное разобраться, как он меняется и в каком направлении развивается. За три десятилетия язык переживал периоды скепсиса и бурного роста, обрастал экосистемой и стандартами, и в итоге вышел далеко за пределы браузера, охватив серверную и кросс‑платформенную разработку.

Всем привет! Меня зовут Владимир, я разработчик СберБанк Онлайн в канале «веб», и в этой статье я хотел бы затронуть этапы эволюции JavaScript, зафиксировать нововведения спецификации ECMAScript 2025, разобрать наиболее значимые предложения для будущих версий стандарта и попытаться понять его место в эпоху стремительного развития ИИ.

Случайно увидел результат работы функции RegExp.escape() и был удивлен, потому что она заэкранировала пробелы, все спецсимволы, а также цифры и латинские буквы в начале строки. До появления RegExp.escape() (а она стала доступна в популярных браузерах лишь в 2025 году) я, как и многие другие, писал аналогичную функцию сам, но без экранировки вышеперечисленных символов. Получается, что я ошибался, и нужно бросать все дела, рыться в старых исходниках и переписывать функцию? И да, и нет.

Как меняется JavaScript?

JavaScript уникален тем, что работает во всех браузерах. У него нет какого-то одного «владельца», поэтому нельзя внести изолированное изменение и ждать, что оно будет применено везде. Эволюция происходит через TC39 — Технический комитет, отвечающий за ECMAScript.

Предложения должны пройти последовательность этапов развития:

• Этап 0: идея.

• Этап 1: принято пространство задач.

• Этап 2: выбрана архитектура драфта, но работа продолжится.

• Этап 2.7: предложение одобрено в принципе; ожидает тестирования и обратной связи.

• Этап 3: реализация и обратная связь.

• Этап 4: предложение стандартизовано.

В 2018 году, когда я впервые изучал Temporal, он находился на Этапе 1. Комитет TC39 был убеждён, что проблема реальна. Это было радикальное предложение по добавлению в JavaScript новой библиотеки дат и времени. Она должна была:

• Стать заменой Date.

• Добавить новые типы DateTime (вместо единого API).

• Стать неизменяемой.

• Добавить поддержку часовых поясов и календаря.

Но как мы к этому пришли? Почему Date вызывает столько проблем? Чтобы ответить на эти вопросы, нужно вернуться назад.