Фронтенд

Не особо интересный пост.

Я все еще считаю, что стартап — это весело 🐙

Наша разработка hardware продукта напрямую связана с софтом. В нашем случае умный датчик качества воздуха Atmy, становится по настоящему “умным” в связке с целой экосистемой в виде интеграций ML моделей, системы подтверждения качества данных Atmy Trust Rating (хочу об этом написать отдельно позже), токенизации, веб-сайта и приложения для управления устройством.

Всю эту архитектуру приходиться менять практически в real-time. Поймал себя на ощущении, что уже немного вышел в пограничное состояние. Дни заканчиваются не вечером, а как-то плавно перетекают в следующий день. Иногда в голове уже слышен характерный «треск» старого жесткого диска. Но самое странное — мне это нравится. Потому что именно сейчас добрался до тех вещей, которые годами откладывал «на потом, когда будут ресурсы».

Спойлер 👀: ресурсов никогда не будет хватать. 

Приведу вам пример того, как мы работаем над платформой atmy.ai

Наша платформа раскладывается на три уровня:

↖️User product ← сейчас мы здесь

Какой воздух вокруг меня?

↖️Device management

Как живут мои станции?

↖️Data intelligence

Дай аналитику, API, выгрузки и объясни, что вообще происходит.

Объем большой. Мы реализуем функционал, которого еще не существует, поэтому выбрали работу по уровням и с быстрым тестированием:

накрутить идеи на максимум → быстро обкатать → выкинуть лишнее → остальное в прод и допиливать API

На практике это выглядит так:

появилась идея → накидываем проект в Figma (важно визуальное, так как делаем для людей) → дорабатываем за пару дней MPV через Cursor → тестируем → а далее либо удаляем без сожалений / либо сразу на git программистам.

Из того, что уже долетело до продакшна:

— Atmy Data Hub

Место, где наконец появилась нормальная аналитика по стране и миру. Скачивание графика по клику или скачать готовый csv файл. Графики, которых мне самому отчаянно не хватало в начале пути, когда заинтересовался экологией в своем городе.

— Режим “Мониторинг”

Внутри я его называю «око Саурона». По клику кнопки “Мониторинг” переходишь в этот режим сразу с карты, где “сейчас” находишься — и просто наблюдаешь за динамикой изменения воздуха в реальном времени. Все элементы в большем масштабе для удобного считывания с расстояния, обновление происходит практически real-time.

Есть ещё несколько фич, но их судьба пока под вопросом.

Например:

Мы тестируем гибридный режим (CAMS+AirMap Local) отображения глобального слоя pm2.5 CAMS совмещенный с локальными данными с земли, чтобы достичь максимальной актуальности данных. Здесь много математики и это тоже очень увлекательно.

И это всё — только первый слой.

В общем, путь, как обычно, не самый простой. Но, кажется, именно так и должно быть в любом стартапе

Больше картинок и общения в нашем маленьком чате разработки телеграм: https://t.me/atmyhub

Вместе с сообществом Moscow JS приготовили классную программу с двумя потоками докладов про:

• performance и масштабирование фронтенда,

• внедрение LLM в продукты и процессы,

• изменение инженерной практики и культуры

От X5 Tech — сразу два прикладных кейса:

• Как внедрять LLM в прод без перестройки архитектуры

• Web-First в мобильных приложениях: офлайн, файлы, Workbox и ключевые подводные камни

Для тех, кто хочет поучаствовать в дискуссии — круглый стол с холиварами про переход на «бигтех-рельсы».

📆 30 апреля, 18:30
Москва, Мясницкая, 13, с20

🔗 Регистрация по ссылке

Программа:

«Перформанс без головной боли: Системная оптимизация фронтенда в большой команде» (Мирзоев Руслан, Premier.one)

Доклад основан на реальном опыте команды из 24 разработчиков, столкнувшихся с критическими показателями LCP. Мы разберем комплексный подход к ускорению продукта: от «фундамента» (анализ бандла, Tree Shaking и борьба с циклическими зависимостями) до продвинутых стратегий рендеринга, таких как ISR и оптимизация внутренних запросов при SSR (перевод на internal hosts).

Вы получите набор готовых рецептов по работе с ассетами (SVG, шрифты, сжатие) и узнаете, как выстроить культуру производительности с помощью Performance Budgets, чтобы предотвратить регрессии в будущем

«Веб-компоненты: плохая реализация хорошей идеи» (Евгений Кучерявый, larana.tech)

Разберёмся, почему веб-копмоненты не прижились, что нужно сделать, чтобы это исправить, и есть ли им место в современной фронтенд-разработке.

«LLM в продакшене: от идеи до внедрения за неделю» (Артем Шкуренко, Х5 Tech)

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

В докладе — реальные кейсы: интеллектуальные таблицы, ассистенты и аналитика, а также разбор ключевых вызовов — контроль качества, предсказуемость результатов и стабильность работы.

«Вторая жизнь инженерных практик: как ИИ делает сложные подходы наконец-то удобными» (Вадим Царегородцев, Frontend Guild Lead в островке)

За последние годы индустрия накопила множество инженерных практик: ADR, Clean Architecture, TDD, архитектурные границы, строгие правила зависимостей.

Многие из них отличные на уровне идей, но на практике часто оказываются слишком дорогими и трудоёмкими: требуют много документации, boilerplate-кода и ручного контроля правил.

Появление LLM меняет эту ситуацию.

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

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

«А доки где? Пишем продуктовую документацию» (Егор Левченко, Wildberries & Russ)

У вас самый крутой уникальный продукт или сервис на рынке, вы знаете наверняка, что он делает и как им пользоваться. А понятен ли он вашему клиенту? Надо написать документацию, но как? Давайте разберёмся, чтобы потом не было больно.

«Секретная жизнь фотографий в Клубе Тайных Покупателей X5» (Артур Басак, Х5 Tech)

Поговорим о подходе Web-First в мобильных приложениях. В частности о том, как работать с файлами, про удобство и ограничения Workbox, нюансы оффлайн-режима и о какие подводные камни можно споткнуться.

Инженерная культура и переход на «бигтех-рельсы»

Круглый стол с экспертами: Глеб Михеев, Роман Троицкий (состав уточняется…)

Модератор: Иван Сизов, техлид фронтенд X5 Digital

5 демо-уроков апреля для тех, кто хочет роста в ИТ

Привет, Хабр. Эти уроки проводят преподаватели курсов Отус в преддверии старта новых потоков. На них можно узнать о формате обучения, пообщаться с экспертами и заодно закрыть пробелы в знаниях по интересующей теме. Участие бесплатное. Присоединяйтесь.

• 9 апреля, 20:00. Angular без RxJS? Пишем реактивные формы на сигналах
  ^{Открытый урок курса «Angular-разработчик»}

• 13 апреля, 20:00. Flutter GenUI: когда ИИ-агент собирает ваш интерфейс
  ^{Открытый урок курса «Flutter-разработчик»}

• 15 апреля, 18:00. Основы протокола HTTP
  ^{Открытый урок курса «Проектирование API»}

• 20 апреля, 20:00. От интерфейса до корзины: создаём мини интернет-магазин на языке JavaScript
  ^{Открытый урок курса «JavaScript-разработчик. Базовый уровень»}

• 21 апреля, 20:00. Архитектура Angular-приложения: как писать масштабируемый frontend
  ^{Открытый урок курса «Angular-разработчик»}

Полный список бесплатных уроков апреля смотрите в дайджесте.

Будет слишком по девчачьи сказать, что я плакала из-за код ревью?

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

Ничего такого, вроде все ок. Но я смотрела на него и зависла в моменте: а что именно не так то? Есть какие то правила в новой команде, о которых я еще не знаю? Нужно переименовать только эту переменную или мне нужно пройтись по всему файлу?

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

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

Мне захотелось поделиться своими мыслями на тему код-ревью, о том как формулировки влияют на скорость работы и состояния людей:

Ссылка на статью

Если хоть раз сидел и думал: «что от меня тут вообще хотят?» — ты точно поймёшь :)

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

Попросили Костю, frontend-разработчика Naumen, рассказать, какие возможности DevTools он использует в работе и на что стоит обращать внимание.

1️⃣ Как открыть DevTools, если F12 не сработал

Самый простой способ — клавиша F12 для Windows/Linux. На macOS сочетание отличается, но открыть DevTools можно не только с клавиатуры.

Например, через контекстное меню — нажать правой кнопкой мыши на элемент страницы и выбрать «Исследовать элемент». DevTools откроются сразу на нужном месте.

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

2️⃣ Как работать с версткой во вкладке Элементы

Вкладка Элементы показывает DOM-дерево страницы — структуру документа, из которого собран интерфейс. 

Здесь можно:

• навести курсор на элемент и посмотреть, где он находится на странице

• быстро найти нужный блок через селектор

• посмотреть размеры, фон и отступы


А еще можно посмотреть доступность — как элементы переключаются через Tab.

3️⃣ Как находить итоговые стили 

Если у элемента много CSS-правил, я перехожу во вкладку Вычисленные.

Там собраны все итоговые стили элемента — включая те, что пришли через наследование или заданы браузером. Можно быстро найти нужное свойство, например, border-radius, и понять, какое значение реально применяется.


4️⃣ Как проверять изменения без правок в коде

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

После обновления страницы все возвращается как было.

5️⃣ Как разбирать запросы во вкладке Сеть

Во вкладке Сеть видно, какие запросы отправляет страница и что приходит в ответ. А еще в этой вкладке есть не только список запросов, но и инструменты для фильтрации, поиска и просмотра этапов выполнения. Если нужно исключить что‑то из поиска, можно использовать инверсию или минус в строке фильтра.

Также можно сохранить HAR-файл и передать его разработчику — в нем будет вся история сетевых запросов. Но в HAR попадут только те запросы, которые видны с учетом текущих фильтров.

6️⃣ Как подменять ответ бэка

В DevTools можно изменить ответ запроса и посмотреть, как на него отреагирует интерфейс.

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

7️⃣ Как проверять работу при медленном интернете

DevTools позволяют проверить, как работает интерфейс при плохом соединении. Во вкладке Сеть можно:

• выбрать готовые профили — 3G, 4G

• настроить собственную скорость сети

• протестировать поведение приложения в режиме офлайн

8️⃣ Как работать с локальными данными

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

1. Локальное хранилище — данные, которые сохраняются надолго и не исчезают после перезагрузки страницы.

2. Сессионное хранилище — данные, которые живут только пока открыта вкладка.

3. Файлы cookie — похожи на локальное хранилище, но у них есть срок жизни и дополнительные ограничения по источнику.

Все это можно просматривать, изменять и очищать. 

9️⃣ Как менять геолокацию и часовой пояс

DevTools позволяют изменить геолокацию и часовой пояс, не меняя настройки операционной системы.

Можно выбрать готовую точку или указать координаты вручную. Полезно, когда нужно проверить поведение элементов в другом городе, регионе или стране.

🔟 Как записывать пользовательские сценарии

Инструмент Регистратор умеет записывать действия пользователя на странице — фиксируются шаги, например, клики и переходы по интерфейсу.

После записи сценарий можно воспроизвести, отредактировать, сохранить и отправить коллегам.

Всем хабровчанам удачной недели!

Хотел поинтересоваться такой темой как школа «Result/University». Кто обучался, как быстро удалось найти работу? Какова оценка по 5 шкале?

Смогут ли ребята ввести в данную тему с минимальными рисками?

Как стать тестировщиком?

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

Чтобы не тратить время на поиски курсов, заглядывайте на Хабр Карьеру — там уже собраны актуальные учебные программы по всем основным инструментам тестировщика:

— Chrome DevTools. Тестирование и оптимизация веб-страниц.

— Postman. Тестирование API.

— Grafana. Визуализация данных и мониторинг.

— Selenium WebDriver. Эмуляция действий пользователя.

— JUnit. Модульное тестирование.

— SQL. Работа с базами данных.

→ Учебные программы по выгодным ценам уже у нас

Solid.js должен был исправить React…но доказал, что React был прав

Все ругали React за массивы зависимостей, странные хуки и непонятные стадии рендеринга. Возникало чувство, что они усложнили фронтенд и добавили в него отложенную реакцию. Команда Solid.js решила это исправить: убрать лишние рендеры и магию по капоту. Идея была проста — использовать реактивность. Solid создавался, чтобы заменить React, но когда они работали над второй версией, тут они уперлись в проблему, которую невозможно решить — ассинхронность.

Представьте: одни данные загрузились, другие ещё нет. Что покажет интерфейс? Фейковый фронтенд, который обманывает пользователя. React решал это с помощью отложенного обновления. Тогда Solid решили встроить ассинхронность прямо в реактивность. Появилось управление загрузкой, ожиданием и обновлениями — реактивность как она есть. Становится понятно, что и та, и та команда приходят к одному выводу с разных сторон, но Solid делает ее частью системы, засовывает ассинхронность прямо в реактивность и внезапно оказывается, что React не был таким уж и плохим дизайном, просто команда React-а пришла к этой проблеме гораздо раньше, чем остальные.

И главный вопрос: что важнее — устоявшийся подход React или более чистая, но сложная реактивность Solid? Или дело вовсе не в фреймворке, а в том, как ты управляешь асинхронностью?

https://dev.to/playfulprogramming/two-react-design-choices-developers-dont-like-but-cant-avoid-d6g

Подписывайтесь: YouTube | VK | Twitter

Я так и не смог понять логику фильтра ленты (почему материалы скрытых авторов отображаются в «Другие новости» и «Другие статьи»?), поэтому с целью сохранения позитивного настроения написал свой фильтр для uBlockOrigin (добавлять в My filters, имена вымышлены, совпадения случайны — без сарказма):

habr.com##:is(article.tm-articles-list__item, li.tm-bordered-card):has(a.tm-user-info__username:is([href*="PropagandaTV"], [href*="SpammersInc"], [href*="AISlop"]))

В отличие от Stylus, uBO требует перезагрузки страницы после каждого изменения фильтров. Если же воспользоваться Stylus, то, понятное дело, надо дополнительно дописать к селектору тело { display: none; } и привязать правило к домену.

Во избежание коллизий для коротких имён рекомендуется заменять [href*="UserName"] на более длинный, но однозначный [href="/ru/users/UserName/"].

Какие навыки развивать, чтобы прокачиваться в английском языке?

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

Освоить язык проще, если учиться по структурированной программе — например, подобрав курс на Хабр Карьере под свои конкретные цели. Выбирайте направление и погнали учиться:

— Аудирование. Понимание речи на слух.

— Чтение. Расширение словарного запаса.

— Грамматика и лексика. Корректное построение предложений.

— Письмо. Структурирование языка.

— Говорение. Умение быстро формулировать мысли.

→ Больше курсов на нашей витрине

Приглашаем на вебинар по frontend разработке

26 марта эксперты AXENIX проведут вебинар, посвященный современной фронтенд архитектуре и гибким подходам к разработке.

🔘Разберем реализацию подхода Server Driven UI и рассмотрим, как эффективно интегрировать в него ИИ-агентов.
🔘Поговорим о долгосрочном здоровье проекта и преимуществах изоляции бизнес-логики от фреймворков на примере Feature-Sliced Design (FSD) и реальном опыте перехода на Effector.
🔘Проведем анализ гибридных решений: как из единой кодовой базы собирать и облачный сервис, и десктопное Electron-приложение с офлайн-режимом, преодолевая ограничения браузерной среды.

Участие в вебинаре бесплатное, необходимо только зарегистрироваться по этой сcылке и подключиться к нам 26 марта в 18:00.

Будет интересно!

Гибкое управление фокусом элемента

Chrome в 145 версии добавил параметр focusVisible в метод focus:

input.focus({ focusVisible: true });

Как вы уже, наверное, догадываетесь, это позволяет самостоятельно управлять тем, будет ли элемент при ручном вызове фокуса, помимо CSS-псевдокласса :focus, соответствовать ещё и :focus-visible.

Ранее без данного параметра браузер самостоятельно решал этот вопрос.

⚙️ Поддержка браузерами широкая
🔗 Мой телеграм канал

Сделал тут небольшое приложение для прослушивания музыки из сине белой соцсети

• бесплатно 
• без рекламы
• с офлайн режимом
• не нужно скачивать

Актуально больше всего для ios, так для андроидов есть всякие vkX, но при этом моё приложение не требует авторизации 

Написано на $mol

P.S. Закрепите на рабочем столе как веб приложение

P.P.S Если актуально и нужны новые функции, сделаю за небольшой Донати

🌟 505 звездочек на GitHub у российского Open Source-проекта 🌟

И ровно 505 участников в комьюнити. Друзья, спасибо, что вы с нами 💝

Gramax — это база знаний для ИТ-команда и платформа для документации. Присоединяйтесь к сообществу лучших практик документирования!

• Узнать о Gramax — https://gram.ax/ru

• Поставить звездочку на GitHub — https://github.com/Gram-ax/gramax

• Вступить в комьюнити — https://t.me/gramax_chat

Задача о сравнении чисел

Привет, Хабр! Как насчет небольшой задачи, чтобы вкатиться в рабочую неделю?

Условие

В IT-компанию N привезли экспериментальное устройство для автоматизации расчетов. Оно работает на урезанном интерпретаторе Python: никаких условий, сравнений или встроенных функций — только арифметика и битовые операции.

Знаки сравнения (>, < == и другие) использовать не получится, интерпретатор их не поймет и выдаст ошибку. Однако без них писать код довольно сложно. Придется реализовать базовую логику выбора большего из двух чисел.

Задача

Есть два числа: a и b. Найдите наибольшее из них, используя только сложение, вычитание, деление и умножение, а также битовые операции.

Нельзя использовать операторы сравнения (>, <, ==, != и т. д.), тернарный оператор, функции вроде max(), min() и прочее.

Попробуйте справиться с заданием. А один из вариантов решения показываем в Академии Selectel.

Как я оптимизировала фронт на 40% и никто не заметил

Предыстория

Когда я помогала с поиском сотрудника и просматривала резюме на фронтенд разработчика, очень часто встречала фразу - "Оптимизировал(а) размер бандла на 30% / 40% / 50%, что увеличило ..." как под копирку от ИИ, а у меня из достижений в резюме - "делаю задачи и фикшу баги" 

Ну что ж, возьмем свое приложение и оптимизируем его

О приложении

Это небольшое SPA на Vue 3 для администрирования справочников. Ничего особенного, но это приложение экономит время программистам, которые не лезут в БД, и, как мне кажется, полезно для аналитиков и QA - это позволяет лучше понять, как устроена база, и почему иногда что-то не работает как ожидается.

Начнем оптимизацию

Запускаем npx vite-bundle-visualizer и получаем вот такую красивую розовую визуализацию (прикрепила бы скрин, на то что получилось, но в пост можно одну картинку добавить)

Смотрим роутинг у приложения... Все роуты импортируются сразу. Применяем легкий фикс:

• Оставляем синхронный импорт только для страниц, которые первыми открываются у пользователей

• Остальные подгружаем отдельно с помощью lazy import

// Было:
import PaymentTypes from '@/views/Directories/PaymentType/PaymentTypes.vue';
import OrderTypes from '@/views/Directories/OrderType/OrderTypes.vue';
import Configurations from '@/views/Directories/Configuration/Configurations.vue';
import NewConfiguration from '@/views/Directories/Configuration/NewConfiguration.vue';
import ConfigurationPage from '@/views/Directories/Configuration/ConfigurationPage.vue';
import Source from '@/views/Directories/Source/Source.vue';
import City from '@/views/Directories/City/City.vue';
import Brand from '@/views/Directories/Brand/Brand.vue';
import CloseReason from '@/views/Directories/CloseReason/CloseReason.vue';
import ChangeReason from '@/views/Directories/ChangeReason/ChangeReason.vue';
import Restaurants from '@/views/Directories/Restaurants/Restaurants.vue';
import RestaurantPage from '@/views/Directories/Restaurants/RestaurantPage.vue';
import NewRestaurant from '@/views/Directories/Restaurants/NewRestaurant.vue';
import Discounts from '@/views/Directories/Discounts/Discounts.vue';
import PriceTypes from '@/views/Directories/PriceType/PriceTypes.vue';

// Стало:
  children: [
            {
                path: 'brand',
                name: 'Бренды',
                component: () =>
                    import('@/views/Directories/Brand/Brand.vue'), // <--тут
                meta: {
                    breadcrumbs: ['Справочники', 'Бренды'],
                    requiresAuth: true,
                    permissions: ['admin.admin'],
                    title: 'Бренды',
                    section: 'directories',
                },
            },
...
]

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

Итоги оптимизации:

Уменьшили основной бандл с 245 kB до 148 kB (gzip) — это минус 39%

Что получили:

• ✅ Оптимизировала размер бандла на 40%

• ✅ Улучшила First Contentful Paint

• ✅ Внедрила code splitting

• ✅ Повысила производительность

• ✅ Уменьшила основной JavaScript-файл почти на 40% (в gzip)

• ✅ Уменьшила сырой размер на 46%

• ✅ Теперь загружается только то, что нужно для текущей страницы

Реальность:

• ❌ Съэкономил ли бизнес деньги? - Нет

• ❌ Выросла ли конверсия? - Как? 🌝 это внутренний админ-интерфейс

• ❌ Применили ли чудо-технологию? - Нет, добавили lazy import из коробки фреймворка и рекомендацией из документации

• ❌ Кто-то это заметил? - Только я в отчете, "на глаз" даже мне не заметно

• ❌ Заметил ли пользователь? - Нет, потому что основное время все равно уходит на получение данных с backend

Мысли по этому поводу

И так, мы теперь можем добавить заветную строчку в резюме!

А вы встречаете эту строчку в резюме?

• Какие чувства она у вас вызывает?

• Красный флаг ли она для вас?

• Или наоборот - показатель того, что человек думает о производительности?

Мой канал о поиске работы (ничего не продаю и не рекламирую, только себя)

Выбор вакансии: как я кинулась во всё — и это не дало результата.

Есть разработчики, у которых развитие идёт линейно и предсказуемо: верстальшик → джун фронтендер → мидл → мидл в сильной компании → сеньор/лид/уход в бэкенд

Красиво. Понятно. Логично.

Но у меня кривая черта развития сначала бэк на Java в закрытом предприятии. Потом фулстек в фудтехе: в основном Vue, но ещё и Go (и все сопутствующее), и CUBA Platform (lowcode на java, он же «Тезис»), и n8n.

Широко. Разнообразно. Интересно.

Как я начала откликаться - на всё, что блестит

И сейчас Когда я вышла на рынок, то сначала я откликалась на все что близко:

1. Frontend - Vue / React / Angular
   Ну фронт же. Есть мнение, что «не нужно учить конкретный фреймворк — важны принципы».

2. Go
   а почему бы нет? Знаю , умею , курсы закончены, писала на нем

3. Fullstack (Go или JDK + фронт)

4. N8N, автоматизаторы особенно с ИИ
   Интересно. Растущее направление.

5. Lowcode платформы CUBA, тезис, WebTutor - замаскированный под фронтенд Опыт есть. Почему не использовать?

И это фатал еrror

1. Ошибка №1. Переключение контекста
   Очень сложно переключать контекст и даже синтаксис языка - на первом собесе по TS я не смогла вспомнить синтаксис (на ум приходил только java, так как он изучался более долго и в закрытой среде, ирония: хоть я на нем и не пишу, но разбуди среди ночи - код напишу)

2. Ошибка №2. Рынок
   Рассматривать вакансии на Angular, React без опыта в продакшене - на данный момент наивно.
   
   Рынок перегрет:
   - Vue ~ 1000 откликов за неделю,
   - React - 4000 ,
   
   Неужели Арина (или тот кто читает эту статью) ты думаешь, что кто-то будет рассматривать ваше резюме со Vue? Каким бы в целом хорошим инженером вы не были. Рынок не покупает «в целом».

3. Ошибка №3. Fullstack со связкой Go + Vue или JDK + Vue
   Фуллстеки со связкой go или jdk - это бред вакансии, это карьерный тупик.
   - PHP + Vue - норм
   - Node + Vue - норм,
   но Go + Vue - это нонсенс, это только подработка для поддержания штанов. Чаще это небольшие команды, поддержка, нестабильные проекты.

4. Ошибка №4. n8n — нравится, но это уже не совсем разработка
   Автоматизация, интеграции, AI — это интересно. Но это больше аналитика и orchestration, чем классическая инженерия. Если хочешь быть разработчиком — нужно понимать, куда ты смещаешь фокус.

5. Ошибка №5. Low-code — карьерный тупик
   Проблем с окружением больше. Кода меньше. Рынок уже. Ты становишься зависимой от конкретной платформы. И выйти обратно в «чистую разработку» становится сложнее.

Мой Hotfix: Фокус

Я поняла, что на падающем рынке выживают либо "универсалы" c ИИ подбоком, либо эксперты

Моя новая стратегия:

• Vue 3 + TypeScript + Nuxt (как зона роста)

• n8n — как подработку и интересный дополнительный навык.

Иногда рост — это не добавить ещё стек. А убрать лишнее.

Фронтенд 2026: взлеты и падения

Открываешь проект 2020 года и видишь знакомые имена в package.json: create-react-app, enzyme, moment.js, axios. Пять лет назад это был золотой стандарт. Сегодня же эти технологии вызывают у коллег искреннее недоумение: «Зачем это тут?»

Подготовили для вас быстрый, но очень полезный срез того, как за 5 лет поменялась ментальная модель фронтендера. Внутри инструменты реально умерли, разберемся почему SSR/SSG снова в игре, а TypeScript теперь почти must-have, узнаем почему фронтенд всё чаще = full-stack и что с этим делать.

Главный урок 2015→2025: фронтенд развивается циклически. Каждый цикл — это не «прогресс», а перебалансировка компромиссов. Читайте на Хабр в статье «Фронтенд 2026: что умерло, что выжило и что взлетело неожиданно»

OAuth на практике: что оказалось удобным, а что отпугнуло пользователей

Мы запустили молодую платформу с двумя типами аккаунтов: обычные пользователи и разработчики (публикуют PWA и управляют приложениями).

Бренда и доверия пока нет, поэтому вопрос авторизации быстро стал не техническим, а психологическим.

С чего начали

Для обычных пользователей:
• Email / пароль
• Google
• GitHub

Для разработчиков — жёстче:
• Обязательная привязка Google
• Обязательная привязка GitHub

Логика казалась разумной:
«Разработчик = есть GitHub»
«Двойная верификация = меньше спама»

На практике это не сработало.

Первые тревожные сигналы

Регистрация разработчиков шла крайне медленно, несмотря на интерес к публикации приложений.

Сначала списывали на:
• новый продукт
• низкое доверие
• отсутствие аудитории

Но после общения с разработчиками (в том числе через Habr) картина прояснилась.

Что отпугивало разработчиков

1. Новый сервис → нежелание делиться данными

Даже если это «просто email», психологический барьер остаётся.

Когда с первого шага нужно:
• линковать внешние аккаунты
• проходить несколько этапов подтверждения
• подключать сторонние сервисы

это воспринимается как лишний фрикцион.

Особенно для соло-разработчиков и небольших команд.

2. Git ≠ GitHub

Ключевой инсайт.

Мы обнаружили, что:
• не все хотят логиниться через GitHub
• часть использует GitLab или Bitbucket
• некоторые принципиально не хотят связывать GitHub с новым сервисом

Обязательная привязка GitHub стала серьёзным барьером.

А мнение стандартных пользователей разделилось:

Часть говорила:

«Чем больше OAuth-кнопок, тем солиднее выглядит платформа».

Логика простая:
• если есть Google / Facebook / Discord — значит не ноунейм
• интеграции с крупными сервисами повышают доверие

Это не про безопасность — это про ощущение легитимности.

Другие говорили ровно противоположное:

«Слишком много кнопок — ощущение перегруженности».

И это тоже справедливый аргумент.

Что мы изменили

1. Упростили форму для пользователей

Оставили:
• Google
• Facebook
• Discord

Достаточно выбора для доверия, без визуального шума.

2. Git-провайдеры вынесли в отдельную группу

Под отдельной кнопкой:
• GitHub
• GitLab
• Bitbucket

Для разработчиков это стало понятнее и логичнее.

3. Убрали обязательный GitHub

Теперь для developer-аккаунта нужно подключить любой Git-аккаунт, если ни один не подключён.

Без принудительного GitHub.

Первые цифры (осторожно)

Прошла всего неделя, выборка маленькая, платформа всё ещё молодая.

Тем не менее:
• Зарегистрированные пользователи: +13%
(было 0–6% в неделю)
• Зарегистрированные разработчики: +16%
(было 0–3%)

Похоже, это те разработчики, которые знали о платформе, но их останавливало требование GitHub.

Выводы (пока не финальные)
• OAuth — это не только безопасность, но и психология доверия
• Жёсткие требования на старте почти всегда бьют по росту
• Git ≠ GitHub — и это важно
• Много провайдеров могут как повышать доверие, так и перегружать UI

Для молодой платформы даже такие ранние сигналы уже показательны.

Интересно услышать опыт коллег:
добавляли ли вы OAuth-провайдеров после запуска?
были ли случаи, когда обязательная авторизация через конкретный сервис тормозила рост?

Привет, Хабр! Задали насущные вопросы про технологии и команду Александру Сырцову, Head of Frontend клиентского сайта Wildberries. Первая часть — здесь. А мы продолжаем.

Какое главное качество отличает хорошего фронтенд-разработчика в крупной команде?

Системное мышление — умение видеть не только свою текущую задачу, но и то, как она соотносится с предыдущими решениями команды и как повлияет на реализацию следующих задач. Инженеры с таким мышлением способны строить гибкие системы, готовые к трансформации и масштабированию.

Как выбрать правильный стек технологий для нового большого проекта?

Всё начинается ещё до разработки. Необходимо понимать две базовые вещи: текущий технологический ландшафт и ситуацию на рынке.

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

Далее следует анализ бизнес-требований: нужен ли серверный рендеринг для SEO, какая требуется интерактивность, какие браузеры необходимо поддерживать. Если проект нужно запустить в сжатые сроки, критичным фактором становится совместимость с существующей инфраструктурой: будет ли выбранная технология работать с текущими CI/CD-процессами, мониторингом и бэкендом.

И, наконец, ключевой вопрос — экспертиза команды. Есть ли внутри необходимые компетенции? Если нет, готовы ли мы инвестировать в обучение и дополнительный найм?

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

Какие методы применяют в твоей команде для поддержания высокопроизводительного фронтенда?

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

В продакшене — постоянно мониторим Core Web Vitals (LCP, FCP, CLS и другие) в реальном времени и на всех типах устройств. Мы не ориентируемся исключительно на показатели Lighthouse, поэтому особое внимание уделяем телеметрии с реальных пользовательских устройств.

Как ты мотивируешь команду оставаться креативной и находить нестандартные решения?

В компании выстроена культура, в которой разумный эксперимент, даже если он не привёл к ожидаемому результату, воспринимается не как провал, а как ценный опыт. Ключевое — уметь быстро откатиться и сделать выводы.

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

Ещё больше про технологии — в нашем телеграм-канале.