JavaScript *

Привет! Я — Александр Дудукало, автор базового курса по JavaScript. Если вы читаете эту статью, значит, вероятно, уже знакомы с одной из основных логических конструкций в JavaScript — if-else. Если нет, рекомендую сначала прочитать предыдущий материал, где я подробно разобрал эту тему.

В этой же статье мы поговорим о других способах управления логикой в коде — тернарном операторе и конструкции switch. Да, звучит сложно и, возможно, пугающе. Но я уверяю, все очень просто. В итоге вы узнаете, когда их стоит использовать и чем они могут быть полезнее привычного if-else. Поехали?

Всем привет! Меня зовут Дмитрий, и я руководитель фронтенд-разработки в компании Интелси.

Сегодня хочу рассказать о принципе единственной ответственности (Single Responsibility Principle) — первом из пяти принципов SOLID, сформулированных Робертом Мартином в его книге "Agile Software Development: Principles, Patterns, and Practices". Суть этого принципа звучит так: «Класс должен иметь только одну причину для изменения» (A class should have only one reason to change).

Как избавиться от проп-дриллинга, упростить тестирование и навести порядок в зависимостях React/JS‑приложения? В статье — зачем вообще нужен dependency injection в JavaScript, почему он редко используется и как это меняет @wroud/di. С кодом, примерами и без тяжёлой рефлексии.

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

Привет, Хабр! Меня зовут Виктор, я программирую на TypeScript/Java и это моя первая статья, в которой я хочу поделиться историей создания fsd-forge — CLI-инструмента для упрощения работы с архитектурой Feature-Sliced Design (FSD) в проектах на React и TypeScript. В этой статье я расскажу, почему решил создать этот инструмент, как он устроен, какие проблемы решает, и какие уроки я вынес из процесса разработки.

Что такое Feature-Sliced Design и зачем нужен CLI?

Feature-Sliced Design — это архитектурный подход для структурирования фронтенд-приложений, который помогает организовать код в масштабируемых проектах. FSD делит приложение на слои (app, pages, features, widgets, entities, shared), делая код модульным, читаемым и легким для поддержки. Однако создание новой структуры FSD или добавление сущностей (например, страниц или виджетов) вручную занимает время и чревато ошибками, особенно в больших командах.

Идея fsd-forge родилась из личной потребности. Работая над несколькими React-проектами, параллельно переписывая с Angular на React еще один, я заметил, что:

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

Используете Lodash в вашем проекте? При первом приближении - это удобная, знакомая всем библиотека, но если посмотреть внимательнее, то релиз мажорной версии был в 2016-м году, а последнее обновление в 2021-м. Библиотека имеет критические уязвимости и во многом дублирует нативные методы Javascript.

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

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

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

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

Недавно на проекте столкнулся с необычной задачей - сделать из готового React веб-приложения десктопную версию на Electron. Что же тут необычного? А то, что наше веб-приложение построено на микрофронтенд архитектуре и располагается в трёх отдельных репозиториях. А общение между микрофронтендами происходит в runtime через HTTP. И тут начинаются сложности, так как для создания дистрибутива, Electron'у нужен доступ к исходникам всего приложения. Хотя Electron легко подружить с Webpack, как это сделать с плагином Module Federation на первый взгляд не понятно.

Поиск готового решения в интернете ничего не дал, кроме повисших в воздухе вопросов на Stack Overflow. Пришлось придумать своё решение, которое я и опишу здесь.

Стек проекта типовой (React, Webpack Module Federation, Electron, Electron-forge), поэтому не буду подробно расписывать конфиги, лишь опишу ключевые моменты.

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

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

Как инкрементальная гидратация в Angular помогает сделать приложения действительно быстрыми

Если вы когда-либо запускали SSR в Angular, вы наверняка сталкивались с этим парадоксом: страница вроде бы загружается молниеносно, но ощущается медленной. Контент есть, кнопки на месте — а кликаешь по ним, и в ответ тишина. Почему? Потому что браузер всё ещё «оживляет» интерфейс — запускает JavaScript, подключает обработчики, восстанавливает состояние. Это и есть гидратация, и в классическом исполнении она не так уж и быстра.

Уже 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 году.

В ходе автоматизации тестирования пользовательских интерфейсов зачастую используется такой подход как визуальное тестирование. Он позволяет поддерживать стабильность и отсутствие ошибок в отображении страниц.  

Одним из инструментов, предоставляющих возможность автоматизации данного вида тестирования, является Playwright.

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

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

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

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

Да, я убрал из заголовка "за выходные", потому что проект чутка растянулся. Но идёт весело! У него и веб-версия теперь есть: https://mini.qyp.ai

Напомню: я давно хотел пощупать Tauri v2, и новомодные фреймворки для построения AI-агентов (ai-sdk / mastra / llamaindex).

Идея простая: десктопное приложение, дешборд на весь экран, справа интерфейс чата. Просим ИИ вывести на дешборд какую-то информацию в духе "сколько новых юзеров за последнюю неделю" - ИИ пишет код виджета, и размещает его на дешборде. Под капотом - runtime компиляция React.js + sql-коннекторы.
Полный open-source, весь код в репозитории: https://github.com/ElKornacio/qyp-mini

В данной статье я расскажу как добавить YandexGPT для использования с Siri с помощью приложений Shortcuts и Scriptable.

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

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

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

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

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

Это вторая статья из цикла про наш фреймворк Steroids, в которой мы расскажем об архитектурном подходе к построению UI-компонентов. Если вы ещё не читали первую статью — начните с неё. В ней мы объясняем, что такое Steroids и какие задачи он решает.