ReactJS *

Недавно под постом в канале MoscowJS разгорелся спор — со мной и организатором насчёт смола. Даже не столько насчёт смола, сколько в целом: стоит ли выбирать новые технологии или нет. Думаю, это касается не только смола, а любых новых фреймворков и библиотек.

Претензии вроде бы логичные, чтож, давайте разберем их

После моей первой статьи про Pulse я не ожидал, честно говоря, примерно ничего. Но к моему удивлению увидел реакцию: немного поддержки, немного критики, несколько советов по UX.

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

Не так давно, я наконец выложил на github свой фреймворк cruzo – https://github.com/MaratBektemirov/cruzo. Сам фреймворк писался где-то с 2020г, в свободное от работы время. Причем большую часть времени я потратил на шаблонизатор с реактивными значениями.

Я хотел сделать минималистичный, но в то же время мощный инструмент для создания простых и сложных веб-приложений. Попытался взять хорошие идеи от разных фреймворков и собрать их в одном месте. Одна из таких идей - это RxBucket - контейнер состояний

Я обычный инженер-программист в банке. Вечерами, после работы и семьи, я начал эксперимент: смогу ли я один, с помощью нейросетей, сделать мессенджер таким, каким, как мне кажется, он должен быть? Не «убийцу Telegram» или кого-либо другого, а просто альтернативу - спокойное место для общения. Без шума, без бесконечных кружков, без ощущения, что ты должен читать каналы, на которые никогда не подписывался.

Знаете это чувство, когда подписки и личные чаты свалены в одну кучу? Да, папки есть, но эти вездесущие счётчики непрочитанного… они просто сводят с ума. Ты выходишь из канала, а тебя кто-то туда возвращает — и ты даже не понимаешь, как и кто это сделал.

Я хотел чёткого разделения контекстов: группы отдельно, контакты отдельно, скрытые диалоги — чтобы глаза отдыхали. И спокойного, мягкого интерфейса. Сидя целый день перед монитором, хочется смотреть на приятные цвета, плавные переходы, а не на очередной аляповатый дизайн.

В общем то немного покумекав, я подумал - если тебе что-то не нравится - сделай сам! И я начал делать.

Так родился Pulse.

Мы делаем чат-агрегатор, где в одном окне доступны GPT, Claude, Kimi и DeepSeek. Фронтенду нужно отдавать ответ в реальном времени — токен за токеном, как в ChatGPT. Бэкенд при этом ходит к четырём разным API, и стриминг у них устроен по-разному. Расскажу, как мы свели это к единому SSE-потоку наружу, и про две грабли, на которые наступили: рваные UTF-8 символы и парсинг чужих SSE.

Статья будет полезна всем, кто проксирует LLM через свой сервер.

Зачем вообще свой прокси

Фронтенд не должен знать ключи провайдеров и не должен ходить к ним напрямую. Все запросы идут через наш Node.js-бэкенд: он подставляет ключ, дёргает нужный API с stream: true, парсит входящий поток и отдаёт фронту унифицированные события. Плюс на бэкенде живут лимиты, учёт токенов и подмена провайдера.

Задача: «получить поток от провайдера X → распарсить → отдать фронту в едином формате».

Два разных формата стриминга

Провайдеры делятся на два лагеря.

Многие смотрят на это спустя рукава, но Google создавал AIStudio не для того, чтобы вы ежедневного пользовались им в качестве основного интерфейса для общения с LLM. Студия была создана с целью дать возможность разработчикам настраивать параметры инференса, тестировать, баловаться. И не нужно быть главным‑по‑aistudio, чтоб это понять — там есть тулинг, граундинг поиска, можно изменить системный промпт. Диалоги сохраняются в виде файлов на гугл диске, чтоб было можно их клонировать, бекапить, итд. Есть отдельная страница с рейт лимитами, с выпуском API токенов. Это — ворота к программному интерфейсу для разработчиков, а не удобный chatgpt‑like веб‑интерфейс.

AnkiAI-Cards - мобильное Android приложение с помощью ИИ генерирует карточки по шаблону и отправляет их напрямую в AnkiDroid внутри смартфона. Помогает изучать иностранные слова ассоциируя с контекстом фраз и предложений.

Фронтенд-разработка давно перестала быть просто «вёрсткой сайтов». Сегодня это сложная экосистема: фреймворки, state-менеджмент, TypeScript, оптимизация производительности, работа с API и постоянный поток новых инструментов. Но за всей этой технологической гонкой часто теряется главное: что на самом деле нужно знать начинающему разработчику, где проходит грань между джуном и сеньором, и почему умение проходить собеседования — такой же навык, как и писать код.

Я, Александр, автор телеграм-канала «Shulepov Code», поговорил с Александром Ламковым — фронтенд-разработчиком, основателем YouTube-канала Friendly Frontend (аудитория более 50 000 подписчиков) и телеграм-канала «Friendly Frontend», опытным наставником, который провёл более 200 персональных консультаций с разработчиками, помог прокачать их навыки. Александр успешно прошёл собеседования на позицию сеньора в нескольких крупных IT-компаниях России, а сейчас работает в компании ВК. В этом выпуске узнаем, что такое современная фронтенд-разработка, какие навыки нужны, чтобы войти в профессию, что выбрать (найм или фриланс), и сколько на самом деле зарабатывают фронтенд-разработчики.

IWANT - наш собственный fashion-магазин. Несколько лет он жил на InSales: на старте это правильный выбор: быстро, без разработки, всё из коробки. Но в какой-то момент мы уперлись в потолок платформы: каждый нужный модуль - это либо платное приложение, либо «так нельзя». Мы посчитали и решили перевезти магазин на собственный движок.

Это не история «платформы плохие, пишите своё». Это разбор конкретного переезда: что переносили, как устроен ETL из выгрузок InSales, на каком стеке собрали и почему именно на нём, какие модули пришлось писать самим, как прошёл катаут без простоя и кому такой переезд реально нужен, а кому нет.

Интернет полон историй безупречного успеха: «Мы взяли модный фреймворк, переписали систему с нуля, и всё стало летать». Но реальный мир корпоративной разработки – это legacy. Это системы вроде Redmine, которые живут десятилетиями, хранят в себе терабайты критических данных, и чья миграция обойдется бизнесу слишком дорого.

Мы в команде ArcFront решили, что хватит терпеть интерфейсы из 2006 года. Вместо того чтобы убегать на платные облачные трекеры, мы совершили хирургическую инъекцию. Мы внедрили молниеносный React SPA прямо в ядро старого Ruby-монолита. Без микросервисов. Без CORS.

Рассказываем, как мы заставили старого пса выучить новые трюки: от архитектуры инъекции и парсинга Textile до психологии интерфейсов и нашего официального перехода на бизнес-модель Open Core.

Когда продукт должен работать и на телефоне, и на планшете, и на ПК, и на маке, путей два. Первый по учебнику: нативка под iOS, нативка под Android, отдельный веб под десктоп, и дальше живёшь с тремя кодовыми базами, тремя релизными циклами и модерацией в сторах. Второй: одно сайт-приложение (SPA плюс PWA), которое ставится на домашний экран и работает везде одинаково.

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

Разбираю, почему нативного EventSource часто недостаточно для production SSE: авторизация через headers, контролируемый reconnect, backoff, race conditions, stale-stream watchdog и синхронизация нескольких вкладок через Web Locks + BroadcastChannel.

На базе этих проблем я вынес real-time слой из AI SaaS-продукта в open-source библиотеку sse-runtime и заменил ей самописную инфраструктуру: −3 455 строк кода в production PR, один useSSE-хук вместо ручного reconnect, leader election и отладочного boilerplate.

Представьте ситуацию: вы открываете какой-нибудь файл в проекте, которому уже года три (чаще всего это форма). И в голове всплывает мысль:  «А что тут вообще происходит?». Причём не в смысле «кто виноват», а в смысле «как мы вообще сюда пришли?».

Я фронтенд-разработчица, и за шесть лет в разработке такое случалось почти на каждом проекте, где мне удалось побывать. Я хочу сразу оговориться: это не статья из серии «как надо жить». Это скорее разговор по типу «смотрите, как все мы иногда делаем и даже не замечаем».

Здравствуйте, товарищи! Эта статья про state management во фронтенде, с непривычного угла. За два года я ни разу не написал ни одного редьюсера. Расскажу, как я к этому пришёл, что слышу со стороны про сторы, и почему вам, особенно если вы только заходите во фронтенд, не надо учить Redux в принципе.

Сначала немного о себе, потом про то, что такое стор и почему я считаю его антипаттерном. Затем покажу, как без него живёт моё реальное приложение. И разберем возражения

Привет, Хабр!

Меня зовут Сергей Волков, я фронтенд-разработчик в компании VK. Мы используем MobX для работы с реактивными значениями в веб-приложениях, поэтому я хочу познакомить вас с этим инструментом и показать, почему на него стоит обратить внимание.

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

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

Мы в стартапе ArcFront три недели двигались в совершенно неправильном направлении, пытаясь подружить современный React с 20-летним Redmine через сложный BFF-прокси. Рассказываем историю нашего провала, неожиданного архитектурного озарения и того, как мы выкинули две недели работы и заменили их 15 строками кода.

Привет, Хабр! Меня зовут Константин Шкурко, я ведущий разработчик мобильных приложений в РСХБ. Сегодня хочу рассказать историю о том, как всем известные обстоятельства заставили нас в сжатые сроки искать альтернат­ивные пути доставки нашего инвестиционного приложения «Свои инвестиции» пользователям iOS - и как это изменило наш технологический стек.

Когда Apple заблокировала российские банковские приложения в App Store, перед нами встала непростая задача. У нас были десятки тысяч активных пользователей на iOS, которые пользовались брокерским приложением для управления своими инвестициями. Торговля акциями, облигациями, аналитика портфеля, выставление заявок - всё это внезапно стало недоступно для значительной части клиентской базы.

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

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

Перед любой командой со стороны менеджмента и бизнеса стоит одна и та же задача «давайте быстрее — надо было еще вчера». Нас эта судьба также не миновала. Первое, с чего начинается оптимизация, своя дизайн‑система. У нас уже была своя дизайн‑система, она выручала нас во многих кейсах, но она была старая, подходы к разработке давно изменились, и UI Kit уже не отвечал требованиям. Поэтому было принято решение параллельно разрабатывать новую, с учетом всех последних требований и подходов.

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

Разработка имеет такую очередь: архитектурно наш UI Kit лежит в закрытом artifactory npm пакетом. Также есть шаблон со всеми необходимыми зависимостями и UI Kit«ом. Когда приходит время нового проекта, делается fork заготовки. Это дает быстрый старт.»

Начинаем

Давайте посмотрим, как бы начиналась разработка приложения. Возьмем для примера компонент Select. Не будем писать сами, возьмем Antd Select и через обертку emotion стилизуем его под корпоративные стили.

Структура получится такая:

В этой статье расскажу о свежем баге, который ронял один тип транзакций, пока остальные работали штатно. Если используете @formatjs/intl-durationformat для форматирования времени - этот кейс может сэкономить пару часов отладки.