JavaScript *

Если спустя время у вас происходило такое, что компонент-стор разрастался, а каждое добавление или исправление логики уже пугало, то эта статья для вас.

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

Привет, Habr!

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

Сказать, что заниматся творческой деятельностью в виде написания кода в таких условиях сложно - ничего не сказать.

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

Идея этой статьи родилась из коментария одного комментария @Xregn к статье Как меньше отвлекаться и прокрастинировать..., где ребята обсуждали идею Pomodoro-таймера для spotify.

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

Я фронтенд-разработчик, в основном работаю с React. И в одном из своих пет-проектов я столкнулся с задачей, где нужно автоматически извлекать доминирующие цвета из изображения — для генерации палитры. Начал разбираться, какие подходы вообще существуют, как это делают другие инструменты и что из этого можно реализовать прямо в браузере без тяжёлых зависимостей и серверной обработки.

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

Во многих fullstack-проектах на Next.js и Django авторизация разваливается в одном и том же месте. На фронте удобно использовать NextAuth, потому что он закрывает формы входа, OAuth, серверную сессию и клиентские хуки. На бэкенде хочется иметь обычный JWT-контур на Django REST Framework, чтобы защищать API, работать с access и refresh токенами и не привязывать бизнес-логику к фронту. В итоге часто получается неприятная схема: пользователь логинится через NextAuth, потом отдельно логинится в Django, потом где-то вручную перекладываются токены, а через пару недель вся эта связка начинает ломаться на refresh, logout и OAuth.

Что делаем. Пользователь проходит один вход на фронте, а дальше фронт уже работает с токенами Django как с единственным источником доступа к API. Без второй формы входа, без ручного хранения access token в localStorage, без отдельного костыля под Google OAuth.

Разберем рабочую схему, в которой NextAuth отвечает за пользовательскую сессию на фронте, а Django остается владельцем API-авторизации и выдает JWT. На credentials-входе NextAuth сразу получает access и refresh от Django. На Google OAuth фронт сначала пускает пользователя через провайдера, потом синхронизирует его с Django и тоже получает пару токенов. После этого все запросы идут через один axios-клиент, который сам подставляет access token, сам обновляет его через refresh и сам завершает сессию, если refresh уже недействителен.

Модальные окна — один из самых недооценённых слоёв UI-архитектуры. Формы, подтверждения, панели действий — в любом крупном проекте их десятки. И почти в каждом проекте их управление со временем превращается в хаос.

Не потому что разработчики ленивые. А потому что модалки обманчиво просты. useState(false) — и готово. Пока модалка одна, в одном месте, с одним набором данных — проблем нет.

Я учитель информатики. Одна из самых раздражающих частей работы — не уроки и не подготовка, а заполнение Дневник.ру. Копировать, вставлять, копировать, вставлять — урок за уроком. Я сделал для себя небольшой инструмент, который это упрощает. И заодно хочу спросить сообщество про вторую боль — проверку домашнего задания. Как бы вы это решали?

В дашборде было 83 успешных engagement’а. В аналитике X — 16 настоящих ответов. Пять к одному. Неделю я этого не замечал.

Контекст: у меня автономный AI-агент, который пишет комментарии в X (Twitter) от имени клиентов. Находит релевантные треды, генерирует ответ, публикует через браузер. Без моего участия. Ну, предполагается что без моего участия.

Если у вас одна платформа, фронтенд работает стабильно и предсказуемо. Но стоит добавить десктоп, мобильное приложение, PWA — и простая логика превращается в гору if-ов.

Меня зовут Денис Кондратьев, я фронтенд-разработчик Точка Банк. В статье расскажу, как мы интегрировали наш мессенджер на четыре разные платформы (браузер, Electron, Capacitor, PWA) и сократили время адаптации новых фич в три раза.

Всем привет! Около года назад я публиковал здесь свои первые шаги в разработке — прототип редактора заметок. Тогда я получил много фидбека: и позитивного (+7 кармы), и критического. Признаю, второй мой пост был излишне эмоциональным и малоинформативным. Я сделал выводы, подтянул навыки и готов показать, во что вырос мой проект FocusMind.

В чем идея? Я по-прежнему считаю, что современные инструменты вроде Notion перегружены. Моя цель — создать максимально быстрый инструмент для тех, кто ценит фокус. Что уже реализовано в новом прототипе:

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

Скорость: Никаких тяжелых фреймворков, тормозящих загрузку. Приложение стартует мгновенно.

Локальность: База данных на JSON-сервере. Ваши мысли принадлежат вам и доступны даже без интернета (Offline-first).

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

Мои ошибки — мой опыт Раньше я гнался за одобрением, теперь гонюсь за качеством кода. Я понял, что пользователю не важны мои эмоции, ему важен инструмент, который не подведёт.

Что дальше? Мой план — за 5 месяцев довести FocusMind до идеального MVP. Впереди переход на IndexedDB для работы с огромными массивами данных и внедрение PWA.Буду рад, если вы заглянете в обновленный прототип FocusMind и дадите технический совет. Особенно интересует ваше мнение по реализации синхронизации локальных данных.

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

Проблема:

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

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

Господа, продолжаем разбиратся в тонкостях веб компонент. Сделал тут бенч - сравнениe фреймворков ( $mol/lit/symbiot ) по todomcv. Вроде говорим об одном, а бенч о другом, разве не так ? Ан-нет, что бы разобраться с веб компонентами нужны фреймворки которые ставят их во главу угла, те, кто "сделал на них ставку".

Вот что мне удалось понять:

Первое. Память: 124 байта на веб-компонент, и 16 байт на JS object. Разница на порядок, это много, и без виртуализации интерфейс скорее всего будет лагать

Речь пойдёт о реализации реакции веб-интерфейса на наклон устройства, смещение бликов, теней, для придания ему таким образом интерактивности и объёма.

Device Orientation API существует уже давно. Мобильные устройства с гироскопом стали пожалуй основным окном для приложений и сайтов. Всевозможные эффекты "блеска" / градиентов в дизайне встречаются регулярно, тренд на эмоциональный дизайн и кажется пора это всё объединить!
И ведь Apple выкатили эту фишку в liquid glass! Но... лично по моему мнению, как-то не "дожали" или она померкла на фоне других нововведений... а жаль, я считаю реакцию ui на положение устройства гораздо более перспективной темой чем новая прозрачность с крутой физикой преломлений которую тут же все побежали повторять. В отличии от преломления фона, адекватная реакция на наклон устройства это не графон ради графона, а микро‑взаимодействие дающее ощущение контроля, отзывчивости, даже "живости" интерфейса. Ведь даже если пользователь не тапает по экрану - он очень даже взаимодействует с интерфейсом(смотрит/читает) и слегка "покачивает" телефон в руке, и UI на эти микродвижения уже чуть-чуть отвечает, маленькая физика (свет/тень/глубина), как будто элементы не нарисованы, а существуют как объекты... Ну это моё субъективное восприятие... тут есть похожие мысли про роль микровзаимодействий и баланс эмоций.
Знаю что некоторых людей "лишние" анимации наоборот нервируют, или даже "укачивают", чтож... прекрасно что для них есть опция reduce-motion, для меня такой замечательной обратной опции "сделать красиво" нет )))
Если всё ещё не понятно о чём я, можете глянуть это видео:

Как правильно называть маршруты в Vue Router: два простых правила, которые спасут ваш проект:

1. Первое правило: всегда задавайте name

2. Второе правило: храните имена в enum (или константном объекте)

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

Создать расширение, которое отрезает этот хвост с помощью регулярного выражения — задача на 10 минут. Но сделать так, чтобы это расширение не сломало работу сайтов, не убило поисковики и не вызвало бесконечные циклы переадресации в современных реалиях Manifest V3 — уже интереснее.

Недавно я завершил работу над расширением ZeroTail и хочу поделиться несколькими неочевидными подводными камнями, с которыми столкнулся при реализации авто-очистки URL.

На дворе 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, вот почему они его защищают, а компании продолжают его использовать.

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

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

Предлагаю открыть портал в ад и задать вопрос, который сейчас, кажется, витает в воздухе у всех, кто связан с разработкой: фронтенд вообще еще жив? Или логичнее уже сейчас срочно переучиваться, пока через пару лет не пришлось делать это в панике?

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

От уравнений до верификации: как мы сравнивали разработанный веб-модуль для анализа потерь в НКУ (низковольтных комплектных устройствах) с нормативной базой

А можно ли рассчитать потери и нагрев шин для оценки тепловыделения в НКУ быстро, точно и прямо в браузере?

Мы решили проверить — и разработали веб-ориентированное расчётное ядро, которое затем сравнили с требованиями ГОСТ.

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

Шины, при протекании по ним тока, нагреваются из-за Джоулевых потерь, и если температура выходит за рамки нормы, последствия предсказуемы: ускоренное старение изоляции, рост потерь энергии, а в критическом сценарии — перегрев и выход из строя оборудования.

На практике инженеры часто оказываются перед выбором:

Нормативные таблицы — надёжно и консервативно;

Дорогие CAE-пакеты (COMSOL, ANSYS) — сложно, точность требует времени и бюджета;

Упрощённые ручные расчёты — быстро, но менее точно.

А что, если объединить скорость, точность и прозрачность в одном веб-инструменте?

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

Привет!

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

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

📺 Плейлист по отладке Next.js с Sentry.

🤖 Рэйчел Эндрю и Эдди Османи — два взгляда на AI: когда использовать, а когда координировать целый оркестр агентов.

🛡️ GlassWorm: атака через невидимые Unicode-символы в npm-пакетах и расширениях VS Code.

🎨 CSS Anchor Positioning: два круга, стрелка и ноль строк JS от Темани Афифа.

⚛️ Storybook MCP для React, data-testid как признак недоступности и пошаговые туры через React Joyride.

👁️ Vue Devtools не работает в продакшене? QA-инженер написал свой инспектор.

🌎 Chrome 147 с scoped view transitions, Safari TP 240 и дайджест веб-платформы за март.

🖌️ Осмысленное трение в UX, ARIA-роли для дизайнеров и тест масштабирования шрифтов в Figma.

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

Привет, Хабр. Расскажу, как устроен мой сайд-проект — пиксельная аркада Прикольня, где у каждой компании друзей своя 3D-квартира с мебелью, аватарами и контентом на стенах. Под капотом — Next.js 16, Three.js через React Three Fiber, WebSocket-мультиплеер и PWA. Без единого .glTF файла — вся мебель процедурная.