TypeScript *

У нас в Точка Банк много продуктов, для которых нужны SEO-лендинги: онлайн бухгалтерия, эквайринг, электронный документооборот. Создание одного сайта — это несколько недель работы с участием редактора, дизайнера, разработчика, тестировщика, верстальщика. Не страшно, если нужен один сайт. Но когда их много, на их создание уходит колоссальное количество времени. 

Меня зовут Василий Полосухин — я фронтовый техлид в Точка Банк. В статье рассказываю, как мы сделали визуальный конструктор страниц и научились собирать сайты без кода.

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

На самом деле я не совсем новичок. Раньше у меня уже были попытки освоить разные языки программирования, но дальше пары строчек кода дело редко заходило. Умение «гуглить правильно» и искать ответы на StackOverflow пока давалось тяжело, поэтому довести что-то до результата было сложно.

В этот раз я решил пойти по трендам и подключить в процесс AI. Спасибо Хабру, что в нужный момент подкинул статью про Koda. С неё и начался мой эксперимент. А команде Koda хочу выразить респект за то, что всё бесплатно.

Продолжение статьи о safe-fetch — библиотеке без try/catch для HTTP.

Через день после первой публикации произошла эволюция: stable релиз 1.0 + экспериментальный адаптер для React Query.

Рассказываю, как фидбек сообщества превратил простую обертку в экосистему с монорепо.

Всем привет! На связи Сергей, ведущий фронтенд-разработчик в команде привлечения Центрального университета. Расскажу историю, как валидировал ссылку и попал впросак. Я использовал браузерный URL API для своих целей и думал, что знаю, как он работает. И прежде чем кидать в меня помидоры, как в разработчика, который не читает документацию, дайте шанс рассказать свою историю.

В теории типов вариантность описывает отношение между двумя обобщёнными типами (дженериками). Например, в каких обстоятельствах родительский тип может быть заменён дочерним, а в каких — нет, и так далее.

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

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

Давайте вспомним как мы строим роутинг в наших приложениях. В примере ниже – react-router-dom, но в других фреймворках/библиотеках все примерно также:

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

В данной статье мы рассмотрим пошаговую настройку ESLint и Prettier на примере нашего веб-приложения, построенного на Next.js и TypeScript.

Ситуация: пишешь код на JS, хочешь обработать исключение, пробрасываешь throw, ловишь его с помощью try‑catch. Но добавим нюанс: пусть это нужно сделать для setTimeout. Эта функция использует окружения браузера — не JS‑функция, асинхронная.

Загвоздка: catch не сможет поймать ошибку.

Этот пример — одна из нескольких особенностей JS, из‑за которых я считаю обработку исключений «из коробки» на этом языке неудобной. Но есть и хорошие новости — для JS существуют альтернативные способы работы с исключениями, с которыми дела обстоят получше; например, паттерн «контейнерный тип».

Давайте разбираться.

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

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

https://github.com/dergunovs/fit - исходный код приложения
https://vkvideo.ru/playlist/15313879_11 - видео про разработку

Frontend: Typescript, Vite, Vue, Tanstack Query, Vitest, Vue I18n, Tauri
Backend: Typescript, Fastify, Mongoose, MongoDB, Swagger

Публикация приложения в RuStore

С помощью Tauri добавил генерацию формата APK. Зарегистрировался в RuStore в качестве разработчика, заполнил поля с описанием, сделал скриншоты. Модерация прошла очень быстро. Теперь приложение можно удобно скачивать и обновлять. Сам APK файл весит около 10 мегабайт. За 4 месяца с момента публикации в RuStore оттуда было 65 установок приложения.

Каждый фронтендер знает эту боль: пишешь запрос через fetch - и автоматически добавляешь try/catch. Где-то ловишь TypeError, где-то 500-й статус, где-то подвисший запрос с AbortController. В итоге половина кода в проекте - это обработка ошибок, а не бизнес-логика.

Я прожил с этим годами. Чем больше становился проект, тем больше росла копипаста: таймауты, ретраи, проверки на res.ok, костыли для разных браузеров. Одно и то же, снова и снова.

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

Так появилась библиотека @asouei/safe-fetch. Маленькая (3kb), без зависимостей, но с тем, чего нет у самого fetch: общий таймаут, умные ретраи, нормализованные ошибки и поддержка Retry-After.

🌟 Библиотека добавлена в Awesome TypeScript — один из крупнейших мировых списков лучших TypeScript-проектов

Сегодня мы разработаем с 0 собственный геймтон и запустим соревнования среди хабравчан и всех желающих just for fun. А также дадим возможность запустить свой геймтон локально по своим правилам Под катом вас ждет разработка геймтона на стеке nodejs + prisma + vuejs + fastify. А также пример разработки фулстек приложения с различными тонкостями построения API.

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

Написал утилиту на Go для генерации структур файлов по шаблонам, которая, думаю, будет полезна многим.

Мы все видели и использовали поля типа boolean в базах данных как часть структуры данных.
На первый взгляд это удобно: два значения — «да» или «нет», просто и понятно.

Например, у пользователя может быть флаг is_active, который показывает, включён аккаунт или нет, или поле is_deleted, которое используется как мягкое удаление. Такие поля встречаются повсюду.

Но на практике хранение boolean в базе данных как элемента модели часто приводит к проблемам.

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

Записки одного QA. Вспомогательная часть автотестов: советы и практики (Playwright + Typescript)

В статье рассматриваются подходы к организации вспомогательной части для автотестов на Playwright: структура проекта, Page Object, helpers, constants и шаги. Приведены практические примеры того, какие решения помогают поддерживать автотесты читаемыми и масштабируемыми, а каких стоит избегать. Материал будет полезен QA-инженерам и разработчикам, начинающим работать с Playwright.

Паттерны типизации в TypeScript напрямую влияют на технический долг — накопление неоптимального кода (костылей), которое замедляет разработку, увеличивает риски ошибок и повышает затраты на поддержку. Осознанный выбор паттерна минимизирует эти проблемы, обеспечивая предсказуемость и масштабируемость кода, что ускоряет адаптацию новых разработчиков и сокращает время на отладку

Привет! Меня зовут Никита, я старший фронтенд-инженер в Ozon Tech и я разрабатываю кабинет рекламодателя. Однажды мы попытались обновить версию Node.js и нашли баг, который затянулся на два года и вовлёк в себя команды Jest, Node.js и V8.

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

Real-time системы и протоколы — тема, которая меня давно интересовала. В рамках эксперимента я решил попробовать свои силы:

Работа с WebSocket для двунаправленной связи в реальном времени

Масштабирование соединений и оптимизация производительности

Разработка собственного протокола/формата передачи данных для надёжности и скорости

Салют, Хабр! 

Меня зовут Паша, я вхожу в группу обеспечения производительности интерфейсов; неформально это команда «Скорость» SberDevices. Мы с коллегами отвечаем за то, чтобы сайты sberdevices.ru, giga.chat, developers.sber.ru и другие быстро работали и красиво выглядели. Если пользователю неудобно использовать сайт, он быстро с него уйдёт (и не станет ничего читать и покупать).

Как только потребовалась оценка качества веб-страниц, появилось и множество подходов к ним. Но в итоге индустриальным стандартом стали методы, предложенные Google и реализованные на уровне браузерных API. Чтобы понять, как сайты стоит оптимизировать и что влияет на их быстродействие, Google оперирует тремя метриками — Core Web Vitals. Две из них действуют с мая 2020 года, а третьей не исполнилось и года. Сегодня расскажу, как разработчик может оценить их и улучшить без консультации команды скорости (если она есть). А ещё благодаря оптимизации метрик Core Web Vitals сайт ранжируется в поисковиках выше. Поехали!

Автоматизация тестирования — это не только про стабильность и скорость, но и про понимание причин падений. В этой статье практические приёмы, которые помогут сделать Playwright-тесты не просто «зелёными», а по-настоящему надёжными и понятными. Разберём, как:

— подключить минимальный набор инструментов для диагностики;
— улучшить читаемость отчётов;
— использовать кастомные ассерты для более информативных ошибок;
— выбрать подходящие репортеры под разные роли в команде;
— и даже применить AI для автоматического анализа падений.

Материал будет полезен QA-инженерам и автоматизаторам, работающим с Playwright, а также разработчикам, тимлидам и менеджерам, которым важно получать прозрачную картину состояния автотестов.