JavaScript *

Что делать, когда твой ребёнок признает только это приложение? Вот не хочет пользоваться аналогами, и всё тут! Как убрать недостатки в такой ситуации и добавить достоинств? Об этом и поговорим.

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

Привет, Хабр! (И тебе, случайный читатель, который зашёл сюда просто потому, что заскучал в корпоративном чате.)

Сегодня я расскажу вам историю о том, какая задача посетила меня на этот раз и как я сделал «корпоративного бота с возможностью оценки сотрудников» — казалось бы, простая задача, но…

solidjs-hook-form — библиотека для удобной и быстрой работы с формами в SolidJS. Использует Zod для мощной валидации и встроенную реактивность SolidJS для высокой производительности. Легковесная, не навязывает стили и дает полный контроль над UI. Идеальна для разработчиков, которые хотят меньше возиться с формами и больше фокусироваться на логике приложения. Попробуйте, если работаете с SolidJS — возможно, это то, что вам нужно!

Привет, Хабр. Давайте о больном. У вас 5+ лет опыта, вы уверенно решаете сложные задачи, менторите джунов и знаете свой стек досконально. Вы чувствуете себя сеньором. Но раз за разом на собеседованиях вам либо предлагают позицию Middle+, либо дают оффер с зарплатой, которая явно не дотягивает до сеньорской.

В чем проблема?

Проблема в том, что вы пытаетесь измерить свой уровень одномерной линейкой «знания технологий». А в голове у адекватного нанимающего менеджера — многомерная система координат.

Как бывший рекрутер, я видел десятки таких «матриц компетенций» в разных IT‑компаниях. И сейчас я вскрою этот черный ящик и покажу, по каким на самом деле осям вас оценивают.

Думаю, многие из вас публиковали 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).