JavaScript *

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

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

Минификация: помогает или мешает?

Транспиляция: как не перестараться?

Полифиллы: да, но нет.

Сорсмапы: кому они вообще нужны?

Бандлить или не бандлить?

Многие начинающие разработчики учат то, что никогда не пригодится на первой работе. В этой статье — 7 навыков, которые junior-фронтендеру можно смело отложить: от юнит-тестов до глубокого погружения в паттерны проектирования.

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

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

Привет, Хабаровчане! Во второй статье, хочу поделиться наблюдениями из документации V8 и немного нудной информацией для многих :-)

Если вы видите эту ошибку — вы не одиноки:

Access to fetch at 'https://api.site.com' from origin 'http://localhost:3000' has been blocked by CORS policy.

Разберем, почему это происходит и как это починить. Что такое CORS и для чего он нужен. Кратко, понятно.

Я потратил 6 часов на этот эксперимент и спешу обрадовать, новая модель от chatgpt не готова заменить программистов и сейчас я коротко напишу почему (бонус: короткое видео).

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

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

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

Angular долгое время ассоциировался с RxJS. Даже слишком: многие разработчики ощущали, что без Observable ничего не работает. Но вот в Angular 17 появляются Signals — синхронная реактивность прямо из коробки. В 17+ — они становятся мейнстримом. Возникает вопрос: а что делать с RxJS? Выбрасывать?

Signals и RxJS — не конкуренты, а два мощных инструмента для решения разных задач. И если их правильно сочетать, можно построить удобную, масштабируемую и эффективную архитектуру.

Я часто вижу, как веб-разработчики используют CustomEvent в коде своих компонентов. Настолько часто, что у многих складывается впечатление, будто CustomEvent — единственный способ создавать custom события (с маленькой "c"), а то и вообще единственный способ генерировать собственные события.

Это понятно. Это прямо указано в названии: "Пользовательское" событие. Создается впечатление, что это идеальный инструмент для этой задачи. Это даже звучит созвучно с "пользовательским компонентом". Но я всегда говорю разработчикам, не использовать CustomEvent. Нет ни одной причины это делать. Почему?

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

В этой статье мы рассмотрим два популярных подхода к документированию фронтенд-кода: JSDoc и Storybook. Они решают схожие задачи, но совершенно разными способами и с разным фокусом.

История о том, как гуманитарий себе сайт навайбкодил. Внутри - примеры промптов, код и размышления на тему RLHF.

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

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

Пример ожидаемой ошибки, обусловленной бизнес-логикой — попытка получить объект из хранилища больших неструктурированных данных (blob storage) с последующей необходимостью обработать случай «объект не найден». Другой пример связан с регистрацией пользователя, когда клиент пытается взять себе логин, который уже занят. В принципе, это ожидаемая ситуация и, если она произойдёт, мы вернем пользователю качественное сообщение об ошибке.

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

Привет. Я Дима Рагозин, фронтенд-разработчик в KTS. Эту статью я хочу начать с предыстории.

Полтора года назад на проекте для одного крупного клиента мы получили задачу — ускорить главную страницу. К тому моменту в кодовой базе уже жили два отдельных фронтенд-приложения под две разные платформы — CSR-версия (Client Side Rendering) и SSR‑версия (Server Side Rendering), — а MobX‑сторы все время жизни проекта разрастались вместе с функциональностью.

Каждый новый экран приносил еще один класс (а то и несколько), еще кучу связей, и в какой‑то момент мы стали замечать снижение воспринимаемой скорости приложения, избыточные HTTP‑запросы, сложности с поддерживаемостью и другие проблемы, которые становились критичнее по мере роста проекта. В статье я расскажу о том, как мы шаг за шагом перевели такие сторы на React Query, сократили код вокруг запросов на ≈50 % и практически избавились от повторных GET‑ов. Попутно поведаю о наших граблях и поделюсь советами по миграции.

Сколько лет уже кто-то говорит: «А можно, чтобы оно работало без интернета и ставилось на домашний экран?» И каждый раз после этой фразы начинается медленный спуск в персональный ад — ты лезешь в документацию по PWA, где всё разваливается на ровном месте, service worker живёт своей жизнью, кеш то работает, то ломается, App Router рушит весь твой кастомный пайплайн, а пользователи сидят на старых версиях, потому что вручную обновлять им, конечно, влом.

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

Так и появился next-pwa-pack — дроп-ин пакет, который превращает любой Next.js-проект в полноценное PWA, буквально одной строкой. Да, даже с App Router. Просто заворачиваешь свой layout в PWAProvider, и всё: приложение можно установить, оно кэширует страницы, работает оффлайн, синхронизирует вкладки и даже показывает отладочную панель, чтобы не гадать, сработало ли что-нибудь. Воткнул — и живи дальше.

А то:

Сервис-воркер? Напиши вручную.
Кешировать HTML? Сам придумай как.
Синхронизация вкладок? Ну это уже магия, удачи.
Обновление кеша после деплоя? Ну ты ж senior, сам справишься. 🤡

И ты сидишь, как идиот, с 300 вкладками про Workbox, cache-first, network-only, костылями из Stack Overflow 2019 года, и потеешь.

Если раньше каждый запрос «сделай оффлайн» вызывал у меня флэшбэк на тему next-pwa, неподдерживаемых версий, кривого кеша и плясок с бубном вокруг обновлений — теперь всё это ушло. Я хотел простой setup, который просто работает: предзагрузка, нормальные TTL, понятное обновление и синхронизация. Без фокусов, без багов, без “подожди, сейчас DevTools открою”.

Привет! Я — Александр Дудукало, автор базового курса по 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 является его простота. Благодаря инкапсуляции сложной логики, необходимой для доступа к геолокации и ее обработки, этот хук обеспечивает чистое и многократно используемое решение. Хук автоматически обрабатывает состояние загрузки, обновляя его при загрузке данных геолокации, и устанавливает состояние ошибки, если в процессе возникают какие-либо проблемы.

Интернационализация (i18n) и локализация (l10n) часто кажутся проблемами “на потом” — пока внезапно не становятся срочными.

Как разработчики, мы все делали что-то вроде:

<button>Order now</button>

Или в шаблоне:

<p>Welcome back, {{ user.name }}!</p>

Всё работает — пока команда не говорит:
«Мы выходим на рынок Узбекистана, Казахстана и Ближнего Востока в следующем квартале.»

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

Вот тогда и наступает момент задаться вопросом: что такое i18n и l10n — и почему это важно?