JavaScript *

Привет, Хаброжители! Наверняка вы неоднократно сталкивались с ситуацией, когда начинали разработку фронтенд‑приложения на React и вроде всё было очевидно, но через некоторое время чувствовали, что уже запутались, где какой компонент. И в такой ситуации приходится вновь и вновь смотреть код, чтобы вспомнить, где в иерархии находится определенный компонент. Или, например, начинаете создавать компонент и задумываетесь на время: — «А с чего начать и какой должна быть реализация?», а реализовав компонент понимаете, что можно было бы сделать это по‑другому.

Книга «Разработка фронтенд‑приложений» предлагает решения, для подобных ситуаций, а также даст руководство по‑другому подойти к разработке. Совершенно по‑новому!

Почему стоит использовать Tagged Unions при разработке на TypeScript

👋 Привет! Меня зовут Александр, я работаю фронтенд-разработчиком в компании «МегаФон». Сегодня я хочу поговорить на тему Tagged Unions (размеченных объединений) и объяснить, почему они ваш секретный инструмент для написания надежного TypeScript-кода.

Уже 10 лет в JS-экосистеме воюют два формата модулей: CommonJS и ES Modules. Чтобы и получить плюшки ESM, и не распугать пользователей, npm-пакеты часто используют dual packaging: собирают код в оба формата. Это решает одну проблему, но создает несколько новых.

Сегодня расскажу

Какие проблемы пришли к dual packaging, и не пора ли от него отказаться.

В какой формат паковать npm-библиотеки в 2025 году.

Статься будет полезна и для опенсорса, и для внутренних библиотек, и для простых разработчиков (хотя бы чтобы понимать, откуда у вас в node_modules 2 Гб).

Node.js претерпел впечатляющее преобразование с момента своего появления. Если вы пишете на Node.js уже несколько лет, то, вероятно, сами наблюдали эту эволюцию - от эпохи колбэков и повсеместного использования CommonJS до современного, чистого и стандартизированного подхода к разработке.

Изменения затронули не только внешний вид - это фундаментальный сдвиг в самом подходе к серверной разработке на JavaScript. Современный Node.js опирается на веб-стандарты, снижает зависимость от внешних библиотек и предлагает более понятный и приятный опыт для разработчиков.

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

После пяти лет работы JavaScript-разработчиком, занимаясь как фронтендом, так и бэкендом, я провел последний год, осваивая Go для серверной разработки. За это время мне пришлось переосмыслить многие вещи. Различия в синтаксисе, базовых принципах, подходах к организации кода и, конечно, в средах выполнения — все это довольно сильно влияет не только на производительность приложения, но и на эффективность разработчика.

Интерес к Go в JavaScript-сообществе тоже заметно вырос. Особенно после новости от Microsoft о том, что они переписывают официальный компилятор TypeScript на Go — и обещают ускорение до 10 раз по сравнению с текущей реализацией.

Эта статья — своего рода путеводитель для JavaScript-разработчиков, которые задумываются о переходе на Go или просто хотят с ним познакомиться. Я постарался структурировать материал вокруг ключевых особенностей языка, сравнивая их с привычными концепциями из JavaScript/TypeScript. И, конечно, расскажу о "подводных камнях", с которыми столкнулся лично — с багажом мышления JS-разработчика.

Всем, привет, меня зовут Дмитрий, я React-разработчик, и я снова здесь и попробую сегодня рассказать про Web Workers.

Если вы хоть раз пробовали обрабатывать большой файл, парсить массив из сотен тысяч элементов или запускать сложные вычисления прямо в React-компоненте, то наверняка сталкивались с тем, что интерфейс подвисает, кнопки перестают реагировать, анимации застывают, и всё на секунду подвисает, пока скрипт не разлучит нас (ой, это не из этой сказки) завершит свою работу.

Почему так происходит? Всё дело в том, что React, как и JS, в браузере работает на одном основном потоке. Точнее, чтобы меня не закидали помидорами, React — это библиотека JS, и она полностью работает в основном потоке браузера, который однопоточен. Когда вы запускаете тяжёлую синхронную задачу, она полностью занимает этот поток и блокирует его, мешая браузеру рендерить интерфейс и обрабатывать события пользователя.

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

В этой статье мы разберём, как можно решить эту проблему одним из вариантов — с помощью Web Workers.

Ну кто не мечтает запустить стартап за одни выходные?
Давно хотел развеяться, и чутка отвлечься от рутины и работы.
А ещё давно хотел пощупать Tauri v2, и новомодные фреймворки для построения AI-агентов (ai-sdk / mastra / llamaindex.

Идея простая: десктопное приложение, внутри ИИ-агент, который подключается к БД, получает данные о структуре таблиц/вьюшек. Справа сайдбар: интерфейс чата с агентом, а основное пространство - холст, на котором агент размещает что хочет сам. А именно - виджеты, которые делают запросы к БД, и выводят их в приятном глазу виде.
Никакого удалённого бекенда, open-source, доступы к БД хранятся исключительно локально, всё секьюрно.

Так как весь код открытый, то процесс я буду логировать в репозитории: https://github.com/ElKornacio/qyp-mini

Визуализатор звука, в котором светящийся 3D-шар пульсирует и меняет цвет в такт музыке, а перетаскиваемые панели GSAP плавно перемещаются вокруг него по инерции.

Демо

Код

Звук — это волны, зрение — это волны, которые мы видим. Я всегда стремлюсь поймать момент, когда эти волны накладываются друг на друга. Для недавнего задания от сообщества Webflow и GSAP, посвященного плагинам GSAP Draggable и Inertia, я решил развить идею, создав футуристический визуализатор, реагирующий на звук. Идея заключалась в создании научно-фантастического интерфейса "детектора аномалий", который реагирует на музыку в реальном времени, совмещая атмосферные визуальные эффекты со звуком.

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

В этой статье мы рассмотрим 5 интересных функций и расширений VS Code, без которых, возможно, вы уже не сможете представить свою разработку.

За последние пару лет генеративные нейросети стали волшебной кисточкой для всего: концепт‑артов, иконок, иллюстраций, обложек, аватаров, спрайтов… Особенно — пиксель‑арта. В Midjourney, Stable Diffusion, Dall‑E, Image-1 и в других моделях можно просто вбить: «Pixel art goose with goggles in the style of SNES» — и получить шикарного пиксельного гуся за 10 секунд.

Но если ты пробовал вставить такого гуся в игру — ты уже знаешь боль.

Я решил вкопаться в эту тему поглубже и сделать open‑source‑инструмент, который автоматизирует превращение AI‑generated pixel art в pixel‑perfect pixel art.

Сегодня веб-приложения стали сложными интерактивными системами, напоминающими полноценные десктоп приложения. Однако за красивыми интерфейсами и богатым функционалом часто скрывается важный аспект, которому уделяется недостаточно внимания — доступность (accessibility). Для миллионов пользователей с ограниченными возможностями это означает, что они не могут полноценно взаимодействовать с сайтом, выполнить базовые действия или получить информацию.

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

SVG – одна из самых интересных технологий браузера. С его помощью можно делать массу полезных и интересных компонентов. Это неотъемлемая часть моего стека.

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

Для понимания этой статьи не требуется специальных знаний и опыта работы с SVG, но предполагается, что вы знакомы с основами HTML/CSS/JS.

Всем привет, хабровчане! Я (не)начинающий разработчик с относительно небольшим стажем, который пытается углубить свои знания в любимой технологии. В работе и повседневной жизни очень часто приходится работать с языком TypeScript, который мне очень нравится, но к своему стыду, сам очень плохо знаком с настройкой его конфигурации, поэтому решил восполнить этот пробел, ведя собственный Today I Learned. Некоторые опции tsconfig являются очень простыми и понятными. Другие же заставляют знатно напрячься. И даже если поверхностное назначение какой-то настройки является понятным, все равно возникает желание разобраться с принципом ее действия, понять, на какие структурные аспекты проекта она влияет, а также узнать, а как вообще людям жилось до ее появления.

Как раз об одном из них и пойдет разговор в этой статье, а именно об esModuleInterop. Действие опции проверялось при попытке подружить CommonJS-модуль с ES-модульным проектом. Поверхностная гуглешка не дала исчерпывающий ответ на ряд моих вопросов, поэтому приходилось обращаться к спецификации ES6, документации tsconfig (упаси боже читать документацию (шутка)), в личные блоги авторитетных дядек в сообществе и к описаниям модульных систем. На основе найденной информации я составил небольшое резюме, с попыткой собрать материал во едно. Надеюсь, кому-то он покажется интересным. Приятного чтения!

Недавно прошла 108-я встреча TC39, на которой было продвинуто 9 предложений на разные стадии стандартизации — от сырых идей (Стадия 0) до полностью утвержденных возможностей (Стадия 4).

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

Мы все чаще сталкиваемся с парадоксом: с одной стороны, растут требования к скорости вывода продукта на рынок, с другой — увеличивается сложность приложений. При этом, разработчики тратят большое количество времени на рутинные задачи, такие как интеграция с API и написание boilerplate-кода. Именно здесь на помощь приходит автоматизация рутинных задач во фронтенде на основе OpenAPI-спецификаций и она может очень сильно упростить нам, фронтендерам, жизнь!

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

Разработчики всё чаще полагаются на ИИ-помощников, чтобы ускорить повседневную работу с кодом. Эти инструменты умеют автозаполнять функции, предлагать исправления ошибок и даже генерировать целые модули или MVP. Тем не менее, как многие из нас убедились, качество вывода ИИ во многом зависит от качества предоставленного запроса. Плохо сформулированный промпт может привести к нерелевантным или общим ответам, в то время как хорошо составленный — дать продуманные, точные и даже креативные решения для кода.

Под катом Эдди Османи, ведущий инженер Google, выделяет ключевые шаблоны запросов, повторяемые фреймворки и запоминающиеся примеры, которые нашли отклик у разработчиков.

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

Знакомая ситуация? Неизвестный вам контакт пишет на LinkedIn, предлагает работу мечты... Но что‑то вас останавливает, вы уверены, что вас хотят обмануть! В этой статье я расскажу вам о новом способе атаки на разработчиков, под названием OtterCookie.

Привет, Хабр. Сегодня я хочу поделиться историей одного небольшого, но увлекательного расследования. Все началось, как обычно, с малого — с одного подозрительного IP-адреса. А закончилось вскрытием целой сетки фишинговых доменов и отправкой финального «письма счастья» хостинг-провайдеру.

Это не рассказ о взломе Пентагона с помощью 0-day. Это реальный кейс, показывающий, как с помощью базовых инструментов, OSINT и капельки терпения можно пресечь деятельность мошенников, которые, как выяснилось, работали с размахом.

Привет! Я Незар, фронтенд-разработчик Т-Банка в одном из продуктов Т-Бизнеса. Наша команда использует Angular, и мы следим за всеми изменениями, которые с ним происходят.

В статье разберу, как Angular эволюционировал от Zone.js к Zoneless-приложениям с современным реактивным подходом Signal API и почему это стало ключевым шагом для повышения производительности и упрощения реактивного программирования. 

На примерах и замерах производительности посмотрим, как переход к Zoneless-подходу с Signal API позволяет сократить избыточные перерисовки, ускорить отклик приложения и сделать код значительно чище и предсказуемее. Сделаем Angular-приложения быстрее и проще, добро пожаловать под кат!