JavaScript *

Давайте немножечко поговорим о творчестве в целом, создании собственных проектов в принципе, и дальнейшем развитии мобильного приложения для домашних питомцев DogPlanner (доступно в Google Play, RuStore и других известных площадках) в частности. Мы уже говорили, что когда человек начинает заниматься каким-либо собственным проектом, он не задумывается насколько это занятие может растянуться. Мы сейчас говорим не о бизнес проекте, в котором изначально чётко описываются цель и средства её достижения, определяется команда и сроки, и поехали... Нет.

Привет, Хабр! Меня зовут SlywerX, я студент 3 курса кафедры Программной инженерии МТУ (Алматы) и fullstack-разработчик. Несколько месяцев назад я задался вопросом: а как вообще работают языки программирования изнутри? Лучший способ разобраться — написать свой. Так появился SWX (Shadow Web eXploit) — скриптовый язык на базе Node.js с собственным синтаксисом, криптографией и даже HTML-рендерингом.

Сейчас SWX на версии 7.0.0. В этой статье расскажу как всё устроено, что было сложно и зачем это вообще нужно было делать.

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

Замыкание существует пока, есть хоть одна ссылка на функцию создавшую его. Если быть неосторожным, это может привести к утечкам памяти: когда объект уже не используется в программе, но сборщик мусора не может его удалить. Такие ссылки могут быть неочевидными...

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

Playwright — фреймворк от Microsoft для E2E-тестирования — был построен с нуля, чтобы решить именно эту проблемкую. В нем есть автоматические ожидания, изоляция через Browser Contexts и встроенный тест-раннер. Разберём, чем он отличается от Selenium и Cypress, и как писать тесты, которые не падают от ветра.

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

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

Привет, 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) — и готово. Пока модалка одна, в одном месте, с одним набором данных — проблем нет.

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

Если у вас одна платформа, фронтенд работает стабильно и предсказуемо. Но стоит добавить десктоп, мобильное приложение, 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 (или константном объекте)

На дворе 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 умерло, джуны никому не нужны, нейросети уже пишут код, а дальше будет только хуже.