JavaScript *

По данным сразу нескольких вышедших в 2025 году отчётов исследователей, объём генерируемого ботами трафика в интернете впервые превысил человеческий. Боты теперь составляют более половины интернета, из них 3/4 — вредоносные.

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

Во-первых, иногда требуется специфический софт, который доступен только под Windows. Да, в других ОС могут быть аналоги, но зачастую они менее удобны или требуют дополнительной настройки.

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

Наконец, есть и субъективный фактор — привычка. Я с самого начала работал с Windows, и, несмотря на все преимущества Linux, полностью перестроить рабочий процесс оказалось сложно. WSL в этом плане — идеальный компромисс: Linux-окружение под рукой, но без необходимости отказываться от удобств Windows.

Привет, Хабр! Меня зовут Евгений, я работаю разработчиком в Университете Кембриджа (UK). В начале апреля я запустил llm7.io - полностью бесплатный LLM-провайдер, совместимый с популярными библиотеками chat completion. Цель была простая: проверить, насколько эффективно можно построить отказоустойчивую архитектуру под настоящую high-load-нагрузку, и при этом дать всем желающим доступ к мощным языковым моделям - без регистрации, API-токенов, смс и прочих барьеров.

Всем привет!

Cypress — это современный инструмент для автоматизации тестирования веб-приложений на базе JavaScript. С помощью него можно создавать unit, e2e и интеграционные тесты.

В статье вы узнаете:
Преимущества инструмента и когда его можно использовать;
Как установить, настроить Cypress и написать с помощью него первый тест;
О хуках, кастомных командах, создании запросов, заглушках и другом...

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 раз медленнее и никто этого не заметил 🙈

Начнём с небольшого кликбейта.

Это действительно так, но, конечно, не вся правда. Давайте разберёмся.