TypeScript *

Андерс Хейлсберг — именно этого человека принято считать создателем TypeScript. Инженер-программист, который подарил миру такие языки как: Turbo Pascal, Delphi и C#.
Основным мотивом создания TypeScript было желание решить проблемы, связанные с разработкой крупных и сложных приложений на JavaScript.

Думаю, многие кто работал с большими проектами замечал, как порой бывает сложно рефакторить или даже просто понимать структуру данных , а чаще всего вообще невозможно. Именно этими проблемами и "занимается" TypeScript. На данном этапе стоит уточнить, что TypeScript представляет собой расширенную версию JavaScript, содержащую в себе все основные возможности языка JavaScript, дополненные некоторыми расширениями.

Основной причиной использования TypeScript является возможность добавления статической типизации к JavaScript. Переменные с статической типизацией имеют тип, который не может быть изменен после их объявления. Это позволяет предотвратить множество потенциальных ошибок.

Эта статья поможет вам создать приложение Express 5 с поддержкой TypeScript.

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

Настоятельно рекомендую писать код вместе со мной. Мы будем использовать подход "Разработка через тестирование" (test-driven development, TDD) для создания REST API, который может стать основой вашего следующего приложения Express.

В данной статье рассказывается о личном опыте переезда с JS на TS, как у меня получилось подружить Node.JS с TypeScript без сторонних инструментов.

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

Использование any небезопасно, поскольку таким образом вы отключаете многие проверки во время компиляции вашего кода в JavaScript, что по итогу ограничивает способность TypeScript помогать вам, отказываясь тем самым от преимуществ строгой типизации.

Линтеры — это не только важнейший инструмент для поддержания качества кода на высоком уровне, но и важный помощник в борьбе с any. Пакет typescript-eslint содержит несколько таких правил, которые помогают предотвратить небезопасные практики еще до начала компиляции, связанные с типом any. Эти правила обнаруживают как прямые использования any, так и целые паттерны кода, которые незаметно его допускают. В этой публикации мы разберемся с тем, что конкретного делают эти правила, а также рассмотрим несколько полезных способов предотвратить проникновение any в наш код.

Тема чистого кода — одна из самых обсуждаемых в сообществе разработчиков. Это не удивительно: от качества кода напрямую зависят скорость разработки, легкость поддержки и масштабирования проекта. В мире JavaScript и TypeScript, с их гибкостью и динамической природой, следование принципам чистого кода становится особенно важным.

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

Есть за мной такой грешок: если какая-то проблема мне долго досаждает, я в конце концов пишу библиотеку, которая её решает. На сей раз такая история возникла с кодом для валидации CLI.

Смотрите, я немало времени уделяю чтению кода, который написали другие люди. Это код опенсорсных проектов, всякий материал по работе, а также код из случайных репозиториев с GitHub, на которые, бывает, наткнёшься в два часа ночи. Причём, я то и дело замечаю одну и ту же проблему: в любом инструменте CLI найдётся одинаковый уродливый валидационный код, запрятанный поглубже. Знаете, в таком роде:

В данной статье будет предоставлена детальная информация по реализации высокопроизводительного вьюпорта мессенджера на Angular, который обеспечит высокую и плавную скорость работы и низкое потребление ресурсов с применением инструмента виртуализированных списков ng-virtual-list. А также представлен порт на React.

Zod-valid — это Typescript библиотека, зависимая от другой известной библиотеки zod, для безопасной валидации API данных. API редко гарантирует идеальные данные: поля могут быть пропущены, типы не совпадать, структуры меняться. Без проверки этих данных приложение рискует вызвать runtime-ошибки или ломать бизнес-логику. Валидировать данные заранее — значит обеспечить предсказуемое поведение и защитить приложение от неожиданных значений.

Эта статья — история эволюции. Она о том, как простое желание купить билеты в театр прошло путь от однофайлового скрипта на несколько строк до полноценного сервиса с Clean Architecture, CI/CD и деплоем на VPS. Я не стану показывать пошаговый гайд по программированию, а разберу на примерах, какие боли на каждом этапе заставляли меня усложнять архитектуру, и какие архитектурные решения эти боли закрывали. Это практический гайд по принятию решений для ваших пет-проектов.

Записки одного QA. Часть 2. Немного пожеланий и советов по автотестам на Playwright

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

ControlValueAccessor - это то, что отделяет профессиональную дизайн‑систему от набора костылей. Но как грамотно связать его с состоянием контрола (invalid, touched), не создав циклических зависимостей? Эта статья - не просто «ещё один туториал». Это пошаговое руководство по созданию универсального инпута на современном стеке: Signals, OnPush и безопасный инжект NgControl. Разбираем раз и навсегда.

Субагенты в Claude Code — обзор вопроса и немного деталей.

Расскажу про одну из самых примечательных фич Claude Code — инструмент Суб‑Агентов (Sub‑Agents), чем он отличается от обычного Task, и как его можно использовать для создания своих систем на базе ИИ агентов.

У нас в Точка Банк много продуктов, для которых нужны 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 существуют альтернативные способы работы с исключениями, с которыми дела обстоят получше; например, паттерн «контейнерный тип».

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