7–8 апреля прошла самая крупная в РФ IT‑конференция, просвещённая JavaScript development и всему с ней связанному.
Итак, HolyJS — пожалуй самая крупная «семья» во всем сообществе javascript‑разработчиков, продуктивности и дружелюбности которой можно бесконечно поражаться и восхищаться! Ребята собирают под своим крылом лучших экспертов‑спикеров со всей России...
В статье — о том, как мы решили отказаться от PropTypes в пользу TypeScript для автоматического извлечения типов пропсов React-компонентов.
Наши разработчики давно просили эту возможность, справедливо возмущаясь: «Зачем описывать типы дважды — в TypeScript и PropTypes?». Тем более, что аналогичный механизм уже работал в Storybook.
Если вы недовольны текущими решениями для организации библиотек компонентов или просто любите технические кейсы — добро пожаловать под кат!
Я начал этот небольшой проект под названием isomorphic-validation, как эксперимент, в основном в образовательных целях. Несмотря на то, что существует множество других библиотек валидации, я решил все равно изобрести велосипед. Это была попытка скрыть все сложности, связанные с условными операторами и асинхронностью при создании пользовательского интерфейса...
Всем привет, меня зовут Александр, я являюсь фронтенд разработчиком более 4-х лет. В этой статье хочу поделится с вами почему решил перейти с горячо любимого и удобного и комфортного vscode в новый редактор neovim. Что из этого получилось давайте посмотрим дальше.
Что такое neovim и причины перехода на него
Думаю, что все сталкивались с этими текстовыми редакторами, когда решали мердж конфликты или рибейзили ветки в своих проектах. Да, это были редакторы nano или vim. Так вот, редактор neovim — это форк от редактора vim с улучшенными доработками. Если кого-то интересует более подробное описание — вы можете найти его на сайте самого редактора neovim.
Причины перехода на neovim?
В данный момент я использую в качестве основного редактора VsCode для работы во frontend разработке и редактор заточен чисто под нее. Работе с ним я столкнулся со следующими проблемами: долго грузит обновление маппингов между переключениями в ветках гитхаба, когда что-то меняешь в файле юай компонента, то также долго обновляется информация об изменении в файле; если это длится целый день — то тратится много времени в пустую на ожидаение. Еще одной проблемой стала — это работа с микросервисами: при наличии в проекте более одного typescript файла, то редактору тяжело их различить и он может не успевать анализировать информацию пока пишется код, а это пропущенные ошибки, и тяжелая проверка кода на глаз. Да, можно каким-то образом это настроить, но зачем с этим связываться, если есть доступные решения, которые легко с этим справляются. Чтобы устранить вышеупомянутую проблему с микросервисами приходится после каждого переключения между проектами перезагружать редактор.
Когда мы решили вывести на прод Telegram‑мини‑приложение для «капельных» (drip) TON‑платежей, довольно быстро стало ясно: обычный CRUD‑фронт тут не выживет. Сразу накрыла волна специфичных задач — от гранулярного онбординга в Web‑App до борьбы с ограничениями API‑ключей и тонкостей работы с TON SDK во встроенном браузере Telegram. Каждый шаг требовал не только кода, но и аккуратного выбора архитектурных приёмов, иначе продукту грозили дубли запросов, «белые экраны» и несогласованность состояний.
В этой статье я разобрал пятнадцать самых характерных «боевых» сложностей, показал, каким паттерном мы их укрощали, и какой антипаттерн поджидал за поворотом. Это не академический список, а выжимка из коммитов и ночных дебаг‑сессий, которая поможет тем, кто строит похожие интеграции между Telegram, TON и React.
С приходом ИИ сильно вырос соблазн заниматься простым человеческим вайб-кодингом: пишешь себе промпты, копируешь готовый код, вставляешь в проект - и готово! И бизнес рад, и времени меньше уходит… В чем подвох? Пожалуй, в том, что таким образом все меньше полезной информации оседает в голове.
В этой статье я хочу поделиться своим методом, с помощью которого я внедряю новые фичи в проект, над которым работаю, при этом получая новые знания и опыт (как в старые добрые времена), затрачивая гораздо меньше времени.
Ранее на Piccalilli Сэм Роуз поделился реальными примерами использования вспомогательных типов (utility types) TypeScript. Сегодня я хочу продолжить эту тему и поделиться несколькими продвинутыми возможностями TypeScript для работы с типами, которые, на мой взгляд, особенно полезны и применимы в реальных проектах.
Цель этой статьи — дать общее представление о каждой из возможностей, а также привести пример ее использования, чтобы вы могли лучше ориентироваться в том, какие инструменты можно использовать при создании типов.
Если вы когда-нибудь, запуская рабочую станцию с операционной системой Windows, обнаруживали, что ваш Full HD монитор показывает лишь изображение с разрешением не более 1024x768 и определяется как «Стандартный не Plug-n-Play монитор», и по какой-то причине вы не имеете возможности переключить монитор на другой видеовход, не поленитесь заглянуть под кат, где я растолкую, как «временно» выкрутиться минимальными усилиями.
Ещё несколько лет назад принципы SOLID были неотъемлемой частью собеседований для разработчиков любого уровня. Вопросы вроде «Расскажите, что означает каждая буква в SOLID» звучали так же часто, как «Что такое замыкание в JavaScript?». Это считалось своеобразной классикой, обязательной для понимания любого уважающего себя программиста.
Однако в последнее время, особенно во фронтенд-разработке и в мире React, акцент на SOLID заметно снизился и, например, вопросы о нем на собеседованиях встречаются всё реже. В первую очередь, это связано с переходом к функциональному стилю программирования, широким использованием хуков и отказом от классовых компонентов, что отодвигает принципы ООП на второй план.
Тем не менее, я убеждён, что принципы SOLID по-прежнему актуальны и полезны, даже в контексте функционального подхода. JavaScript и React не запрещают применять лучшие практики из ООП — наоборот, они предоставляют гибкость для использования различных парадигм.
В этой статье я хочу поделиться своим взглядом на то, как каждый из принципов SOLID может быть применен в разработке React-приложений. Здесь не будет революционных идей, особенно для опытных разработчиков, но, возможно, эта информация окажется полезной для начинающих разработчиков, стремящихся писать более качественный и поддерживаемый код.
Ускорьте разработку React-компонентов! Эта статья о создании шаблонов для автоматизации рутинных задач: генерация папок, файлов, управление экспортами. Экономьте время и фокусируйтесь на главном.
Фронтендеры, постоянно в поиске идеальной архитектуры. Слои, фича-слайсы, атомарный дизайн, фрактальность... Все эти подходы имеют право на жизнь. Но сегодня я хочу поделиться способом мышления, который сделает любой ваш код лучше, а любую архитектуру – яснее.
Как известно, у Solid довольно скудная экосистема, поэтому для сложных проектов я беру React+MobX. Однако недавно подвернулся небольшой mobile-only проект, в котором разве что маскированные инпуты и кастомные селекты, которых для Solid предостаточно. При этом требования к размеру выходных файлов и перфомансу были высокие.
Очевидным решением посчитал взять Solid, заодно и сравнить его по всем параметрам (размер, перфоманс, возможности реактивности, удобство настройки) в реальном проекте. Никаких синтетических тестов с рендерингом больших таблиц и хранением в сторе нескольких мегабайт данных не будет, зато приведу замеры из реального приложения. Бонусом — репозиторий с универсальной архитектурой для Solid+Preact+React, где замена фреймворка (набора стейт‑менеджер + рендеринг UI) производится одной строчкой кода.
Я давний пользователь GitHub. Можно сказать, что на моих глазах он вырос из самобытного GIT-хостинга до внушительной экосистемы для разработчиков под патронажем само́й Microsoft, и по факту стал индустриальным стандартом.
Со временем я стал задаваться вопросом — можем ли мы в своей стране своими силами создать аналогичную экосистему? В которой нет проблем с платежами, не удаляют репозитории и аккаунты из-за поездки в Крым, где российские компании заказчики не опасаются хостить свои коммерческие проекты. В 2023 году я попробовал GitFlic, но не смог им пользоваться из-за нестабильной работы репозиториев. В 2025 году я решил попробовать GitVerse. Проекту уже больше года, и, скорее всего, он созрел для реального применения. В первую очередь меня интересует, есть ли у GitVerse потенциал стать не просто надёжным хостингом для GIT-репозиториев, а развиться в мощную экосистему, не просто повторить функционал GitHub в масштабе 1:43, а реализовать новое поколение индустриальных стандартов для совместного творчества разработчиков и других IT-специалистов.
Всем привет! 👋
Я — Дмитрий, автор Sury — самой быстрой библиотеки для работы со схемами. Если вы фанат Zod (а кто не фанат?), эта статья для вас. Сегодня я поделюсь неожиданными результатами тестов производительности Zod v4, расскажу, что это значит для вас, и как избежать подводных камней.
Zod v4: Стал в 17 раз медленнее и никто этого не заметил 🙈
Начнём с небольшого кликбейта.
Это действительно так, но, конечно, не вся правда. Давайте разберёмся.
Покрытие UI-тестами — вещь, о которой все говорят, но почти никто не измеряет. А если и измеряет, то по старинке, через Excel, TMS или на глаз. Это как считать шаги, не надевая шагомер.
ui-coverage-scenario-tool — это как шагомер, но для UI-тестов. Он показывает, с чем именно взаимодействуют ваши тесты, что осталось в тени, и главное — делает это автоматически. Без ручного труда, без вымышленных цифр, без «по ощущениям».
Это не очередной инструмент ради красивого дашборда. Это инструмент, который ставит зеркало перед вашим UI-покрытием — и показывает, есть ли там что-то, кроме отражения.
Я написала свой ESLint-плагин для доступности. Вот как и зачем.
Я люблю автоматизацию: если что-то можно доверить инструменту, это стоит делать. Особенно то, что повторяется из проекта в проект: aria-label, alt, tabIndex.
Линтер - это как фоновый напарник: один раз настроил - и он работает. Не устает, не отвлекается, не забывает. А в контексте доступности, где многое завязано на деталях, это особенно важно.
Привет, друзья!
В этой серии статей мы разбираем структуры данных и алгоритмы, представленные в этом замечательном репозитории. Это одиннадцатая часть серии.
Сегодня мы рассмотрим несколько простых, но интересных алгоритмов машинного обучения, а также один весьма любопытный статистический алгоритм.
Код, представленный в этой и других статьях серии, можно найти в этом репозитории.
Интересно? Тогда прошу под кат.
Привет, Хабр (и просто случайные читатели, зашедшие сюда в поисках истины или интересной статейки на пару минут)!
Так вышло, что последние полгода я провёл в тесных объятиях «Личного кабинета сотрудника» на Элементе — новом языке программирования от 1С. За это время я успел его изучить, полюбить, возненавидеть, снова полюбить и, наконец, написать эту статью, чтобы поделиться своими впечатлениями, страданиями и неожиданными открытиями.
Вопрос перенаправлений кажется простым или не особо серьезным для обдумывания, но в будущем может вызвать проблемы при слишком халатном подходе.
Я хочу сравнить самые популярные методы для редиректов в браузере с помощью JavaScript, а так же способы как их сделать безопаснее и продуманнее.
