26 марта эксперты AXENIX проведут вебинар, посвященный современной фронтенд архитектуре и гибким подходам к разработке.
🔘Разберем реализацию подхода Server Driven UI и рассмотрим, как эффективно интегрировать в него ИИ-агентов. 🔘Поговорим о долгосрочном здоровье проекта и преимуществах изоляции бизнес-логики от фреймворков на примере Feature-Sliced Design (FSD) и реальном опыте перехода на Effector. 🔘Проведем анализ гибридных решений: как из единой кодовой базы собирать и облачный сервис, и десктопное Electron-приложение с офлайн-режимом, преодолевая ограничения браузерной среды.
Участие в вебинаре бесплатное, необходимо только зарегистрироваться по этой сcылке и подключиться к нам 26 марта в 18:00.
Как вы уже, наверное, догадываетесь, это позволяет самостоятельно управлять тем, будет ли элемент при ручном вызове фокуса, помимо CSS-псевдокласса :focus, соответствовать ещё и :focus-visible.
Ранее без данного параметра браузер самостоятельно решал этот вопрос.
Привет, Хабр! Как насчет небольшой задачи, чтобы вкатиться в рабочую неделю?
Условие
В 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';
Запускаем снова и уже получаем уже разбитый бандл. 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.
Широко. Разнообразно. Интересно.
Как я начала откликаться - на всё, что блестит
И сейчас Когда я вышла на рынок, то сначала я откликалась на все что близко:
Frontend - Vue / React / Angular Ну фронт же. Есть мнение, что «не нужно учить конкретный фреймворк — важны принципы».
Go а почему бы нет? Знаю , умею , курсы закончены, писала на нем
Fullstack (Go или JDK + фронт)
N8N, автоматизаторы особенно с ИИ Интересно. Растущее направление.
Lowcode платформы CUBA, тезис, WebTutor - замаскированный под фронтенд Опыт есть. Почему не использовать?
И это фатал еrror
Ошибка №1. Переключение контекста Очень сложно переключать контекст и даже синтаксис языка - на первом собесе по TS я не смогла вспомнить синтаксис (на ум приходил только java, так как он изучался более долго и в закрытой среде, ирония: хоть я на нем и не пишу, но разбуди среди ночи - код напишу)
Ошибка №2. Рынок Рассматривать вакансии на Angular, React без опыта в продакшене - на данный момент наивно.
Рынок перегрет: - Vue ~ 1000 откликов за неделю, - React - 4000 ,
Неужели Арина (или тот кто читает эту статью) ты думаешь, что кто-то будет рассматривать ваше резюме со Vue? Каким бы в целом хорошим инженером вы не были. Рынок не покупает «в целом».
Ошибка №3. Fullstack со связкой Go + Vue или JDK + Vue Фуллстеки со связкой go или jdk - это бред вакансии, это карьерный тупик. - PHP + Vue - норм - Node + Vue - норм, но Go + Vue - это нонсенс, это только подработка для поддержания штанов. Чаще это небольшие команды, поддержка, нестабильные проекты.
Ошибка №4. n8n — нравится, но это уже не совсем разработка Автоматизация, интеграции, AI — это интересно. Но это больше аналитика и orchestration, чем классическая инженерия. Если хочешь быть разработчиком — нужно понимать, куда ты смещаешь фокус.
Ошибка №5. Low-code — карьерный тупик Проблем с окружением больше. Кода меньше. Рынок уже. Ты становишься зависимой от конкретной платформы. И выйти обратно в «чистую разработку» становится сложнее.
Мой Hotfix: Фокус
Я поняла, что на падающем рынке выживают либо "универсалы" c ИИ подбоком, либо эксперты
Моя новая стратегия:
Vue 3 + TypeScript + Nuxt (как зона роста)
n8n — как подработку и интересный дополнительный навык.
Иногда рост — это не добавить ещё стек. А убрать лишнее.
Открываешь проект 2020 года и видишь знакомые имена в package.json: create-react-app, enzyme, moment.js, axios. Пять лет назад это был золотой стандарт. Сегодня же эти технологии вызывают у коллег искреннее недоумение: «Зачем это тут?»
Подготовили для вас быстрый, но очень полезный срез того, как за 5 лет поменялась ментальная модель фронтендера. Внутри инструменты реально умерли, разберемся почему SSR/SSG снова в игре, а TypeScript теперь почти must-have, узнаем почему фронтенд всё чаще = full-stack и что с этим делать.
OAuth на практике: что оказалось удобным, а что отпугнуло пользователей
Мы запустили молодую платформу с двумя типами аккаунтов: обычные пользователи и разработчики (публикуют PWA и управляют приложениями).
Бренда и доверия пока нет, поэтому вопрос авторизации быстро стал не техническим, а психологическим.
С чего начали
Для обычных пользователей: • Email / пароль • Google • GitHub
Для разработчиков — жёстче: • Обязательная привязка Google • Обязательная привязка GitHub
Логика казалась разумной: «Разработчик = есть GitHub» «Двойная верификация = меньше спама»
На практике это не сработало.
Первые тревожные сигналы
Регистрация разработчиков шла крайне медленно, несмотря на интерес к публикации приложений.
Сначала списывали на: • новый продукт • низкое доверие • отсутствие аудитории
Но после общения с разработчиками (в том числе через Habr) картина прояснилась.
Что отпугивало разработчиков
Новый сервис → нежелание делиться данными
Даже если это «просто email», психологический барьер остаётся.
Когда с первого шага нужно: • линковать внешние аккаунты • проходить несколько этапов подтверждения • подключать сторонние сервисы
это воспринимается как лишний фрикцион.
Особенно для соло-разработчиков и небольших команд.
Git ≠ GitHub
Ключевой инсайт.
Мы обнаружили, что: • не все хотят логиниться через GitHub • часть использует GitLab или Bitbucket • некоторые принципиально не хотят связывать GitHub с новым сервисом
Обязательная привязка GitHub стала серьёзным барьером.
А мнение стандартных пользователей разделилось:
Часть говорила:
«Чем больше OAuth-кнопок, тем солиднее выглядит платформа».
Логика простая: • если есть Google / Facebook / Discord — значит не ноунейм • интеграции с крупными сервисами повышают доверие
Это не про безопасность — это про ощущение легитимности.
Другие говорили ровно противоположное:
«Слишком много кнопок — ощущение перегруженности».
И это тоже справедливый аргумент.
Что мы изменили
Упростили форму для пользователей
Оставили: • Google • Facebook • Discord
Достаточно выбора для доверия, без визуального шума.
Git-провайдеры вынесли в отдельную группу
Под отдельной кнопкой: • GitHub • GitLab • Bitbucket
Для разработчиков это стало понятнее и логичнее.
Убрали обязательный 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, поэтому особое внимание уделяем телеметрии с реальных пользовательских устройств.
Как ты мотивируешь команду оставаться креативной и находить нестандартные решения?
В компании выстроена культура, в которой разумный эксперимент, даже если он не привёл к ожидаемому результату, воспринимается не как провал, а как ценный опыт. Ключевое — уметь быстро откатиться и сделать выводы.
Внутри команды создана среда, где каждый может предложить нестандартное решение или техническую инициативу — и быть услышанным. Мы регулярно проводим техновстречи: любой участник команды может выступить в роли спикера и поделиться своим опытом. При этом ключевые технические решения не принимаются в одиночку — их обсуждает коллегия наиболее опытных разработчиков, где идеи проходят совместное обсуждение и взвешенное принятие.
Привет, Хабр! Задали насущные вопросы про технологии и команду Александру Сырцову, Head of Frontend клиентского сайта Wildberries. Мини-интервью — ниже.
Какие самые большие мифы вокруг фронтенд-разработки тебе встречались?
Миф 1. Фронтенд обязательно должен быть «глупым». Получили данные — отрисовали, изменили — отправили обратно на сервер.
В масштабах маркетплейса Wildberries фронтенд, наоборот, должен быть «умным»: мы сознательно выносим часть бизнес-логики на устройства клиентов, чтобы снизить нагрузку на серверные мощности. При этом сами микросервисы стараемся упрощать.
На таких высоконагруженных проектах, как наш, фронтенд — это сложная инженерия: управление состоянием тысяч динамических элементов, оптимизация времени загрузки на медленных соединениях, построение архитектуры, которая масштабируется вместе с ростом бизнеса, а также прямое влияние на конверсию и Core Web Vitals.
Миф 2. Мобильная и десктопная версии могут сильно отличаться.
Для нас критически важна консистентность. Пользователь может начать покупку в приложении или мобильном браузере, а завершить её на десктопе. Поэтому единая логика, дизайн-система и API — это не nice to have, а обязательное требование.
Миф 3. Производительность фронтенда — это забота только фронтенд-разработчиков.
На практике — это командная работа. Бэкенд должен отдавать оптимальные данные, дизайнеры — учитывать производительность своих решений, менеджеры — закладывать время на оптимизацию.
Мы уделяем этому направлению много внимания, потому что наш фронтенд должен одинаково хорошо работать на самых разных устройствах и с самыми разными техническими характеристиками.
Какое самое необычное решение по оптимизации фронтенда тебе когда-либо приходилось применять?
Это была не моя идея, но эффект меня действительно удивил. В некоторых местах мы сознательно пошли против парадигмы SPA и стали заранее держать в DOM-дереве подготовленные в фоне части приложения. Смысл подхода в том, чтобы при переходе пользователя в раздел не начинать рендер с нуля, а как можно быстрее показать заготовленный контент.
Мы измерили метрики для обоих подходов — классического и «революционного» — и увидели, что пользователи значительно чаще совершают заказы, если могут максимально быстро увидеть страницу и начать с ней взаимодействовать.
Какие изменения произошли в экосистеме фронтенд-технологий за последнее десятилетие и как они повлияли на твою работу?
Десять лет для мира фронтенда — это целая вечность. Мы прошли путь от MVC-фреймворков к компонентному подходу, пережили расцвет TypeScript, серверного рендеринга и его эволюции к гибридным моделям. Вслед за бэкендом научились строить микросервисы на фронтенде — микрофронтенды, и это лишь часть изменений.
Существенно выросла кривая входа: сегодня уже нельзя сказать, что фронтенд — это просто вёрстка и кнопочки. При этом в самой работе радикальных изменений не произошло. Что-то стало удобнее и проще, где-то требуется больше знаний, чтобы понимать, как всё работает под капотом.
Я отношусь к новым технологиям как к инструментам. Здорово, когда у тебя есть удобный «мультитул» — молоток с фонариком и отвёрткой в одном устройстве. Но настоящий инженер должен уметь работать с любым инструментом и выбирать тот, который лучше всего подходит под конкретную задачу.
Открытый учебный проект JavaScript Mastery — Complete Learning Path — это курс для изучения языка программирования JavaScript. Энтузиасты собрали более 500 учебных материалов — репозиторий заменяет буквально 4 года учёбы в университете. Есть вся база от определения переменных до ООП, замыканий и других сложных, но функциональных концепций. Сотни упражнений для повторения материалов и закрепления знаний. Примеры кода, визуализация всех концепций, каждый учебный пример авторы разжёвывают до последней строчки. В конце есть идеи пет‑проектов, чтобы закрепить знания. В проекте есть гайд для подготовки к собеседованиям со всеми актуальными вопросами.
Gemini в Chrome. Google официально встроил Gemini прямо в браузер. Пару дней назад Firefox обьявила о том, что приостанавливает создание AI-браузера из-за недовольства пользователей. Google решила сделать наоборот и начинает Новую эру браузеров".
Вот несколько фичей которые они представили:
Постоянная боковая панель, которая видит все ваши открытые вкладки(максимально 112) и может отвечать по конкретной странице. Звучит на самом деле неплохо, так как меньше нужно будет думать и переключаться, однако есть вопросы с безопасностью. Для серфинга в интернете я думаю всем очень понравится.
Автоматический просмотр. Агент сам будет смотреть ваши вкладки, формы, инфу и будет реализовывать сложные цепочки шагов покупок или заполнения форм регистрации или чего-то еще за вас. Звучит немного фантазийно и сложно, но может в будущем так и будет.
Встроенный Nano Banana. Редактирование и создание изображений прямо в браузере без надобности их сохранять и запускать в Paint.
В целом, шаг в сторону умных браузеров многие предсказывали, но не было понятно как они будут менять на подход к работе в браузере. Одно понятно точно, скоро и разработчикам нужно будет менять свои приложения, верстку, роутинг, стейт-менеджмент, SEO и т.д. Нужно будет менять информационную архитектуру приложений. Об этом еще много напушут...
😍 ЕЩЕ НЕМНОГО ИНТЕРЕСНОГО
Bun ускоряет async/await на 35%. Bun v1.3.7 обновил JavaScriptCore и дал реальный прирост производительности для async/await операций. Для фронтенд-команд это означает более быстрые билды и CI/CD пайплайны, особенно если вы используете Bun для сборки Next.js или других фреймворков.
Yarn 6 переписывают на Rust. Yarn делает логичный ход: порт в Rust с фокусом на производительность. Если это действительно ускорит установку зависимостей, это сэкономит часы времени разработчиков в неделю, особенно в больших монорепозиториях. Но скорее всего, они просто не смогли победить pnpm, и решили добиться ускорения засчет нативности Rust. 💪
WSO2 публично прощается с Java, переходит на Go. Enterprise-компания, которая 20 лет строила middleware на Java, теперь говорит: "Java — не язык будущего для нашей инфраструктуры". Для фронтенд-команд это важно, потому что переход backend на Go означает более быстрые BFF и API, что напрямую влияет на UX наших приложений.
Ryan Carniato выпустил обзор JavaScript-фреймворков на 2026 год. Автор SolidJS делает традиционный "большой обзор" ландшафта фреймворков. Полезен не из-за "кто победит", а из-за того, как он раскладывает тенденции по направлениям — это помогает планировать, какие технологии изучать команде.
Cloudflare делает microfrontends частью своей платформы. Ещё один шаг к тому, чтобы "фронтенд как монолитное SPA" оставался больше в учебниках, чем в проде. Если инструменты для microfrontends становятся более доступными, это открывает возможности для разделения фронтенда на независимые части.
Представлен открытый проект PeerWeb — децентрализованного веб‑хостинга на базе WebTorrent. Решение обеспечивает децентрализованный, устойчивый к цензуре веб‑хостинг через пиринговые сети. «Загружайте свои статические веб‑сайты и делитесь ими по всему миру, не полагаясь на централизованные серверы и не оплачивая хостинг», — пояснили авторы решения.
Gemini представляет GenUI: Новый стандарт адаптивных интерфейсов
Google совершает очередной прорыв в области взаимодействия человека и ИИ, анонсируя Gemini GenUI (Generative User Interface). Это не просто обновление модели, а концептуальный сдвиг от статичных UI к интерфейсам, которые создаются «на лету» под конкретную задачу пользователя.
Что такое GenUI?
Основная идея GenUI заключается в том, что ИИ больше не ограничен текстовыми ответами или стандартными виджетами. Модель теперь способна генерировать динамические элементы интерфейса в реальном времени.
Если раньше вы получали список рейсов текстом, то с GenUI система отрисовывает интерактивную таблицу с фильтрами, карту маршрута и кнопки бронирования, оптимизированные именно под ваш запрос.
Ключевые возможности:
Контекстуальная верстка: Интерфейс перестраивается в зависимости от сложности задачи. Для простых вопросов — минимализм, для аналитики — дашборды с графиками.
Мультимодальная интеграция: Плавный переход между генерацией текста, изображений и функциональных UI-компонентов.
Интерактивность «из коробки»: Сгенерированные элементы не просто картинки. Это рабочие инструменты, с которыми можно взаимодействовать (двигать ползунки, сортировать данные, переключать режимы).
Адаптация под девайс: GenUI автоматически учитывает форм-фактор устройства, создавая удобный интерфейс как для десктопа, так и для мобильных платформ.
Почему это важно для разработчиков?
Для создателей приложений GenUI открывает путь к «бесформенному» дизайну. Вместо того чтобы прорисовывать тысячи сценариев (Edge Cases), разработчики могут предоставить Gemini набор высокоуровневых компонентов и правил, а модель сама решит, как лучше их скомпоновать для решения проблемы клиента.
«Мы переходим от эры, где пользователь учится понимать интерфейс, к эре, где интерфейс учится понимать пользователя».
Как говорилось в Герои3, астрологи объявили, что новых сеньоров не будет, мы последние
За 2023-2025 рынок entry-level позиций в программировании схлопнулся структурно, а не циклично.
• 🇺🇸 В США количество junior-вакансий упало на -67% за один год
• 🇪🇺 В Европе найм entry-level сократился на -73%, при том что весь рынок упал всего на –7%
• Занятость разработчиков 22-25 лет снизилась на –20% с конца 2022
• Безработица среди выпускников computer science в 2025 - 6.1%, хуже, чем у философов и биологов
• AI автоматизировал именно те задачи, на которых раньше учились juniors: boilerplate, тесты, базовую отладку
• Компании больше не могут позволить себе 6-12 месяцев обучения из-за высоких ставок
• ROI теперь нужен с первого дня, а не “когда-нибудь”
• Junior = расходы + менторинг + риск ухода через год
“Junior” вакансия сегодня = React + Backend + Google Cloud / AWS + CI/CD + 3-5 лет опыта
На одну позицию - сотни и тысячи кандидатов. Первый шаг в карьере фактически убрали, второй (мидл) скоро уберут.
Это не только из-за AI. Основная причина - экономика.
AI стала удобным оправданием, но настоящая проблема, это дорогой капитал и сокращенные бюджеты на обучения.
• Появляется новый вход: AI-augmented developer
• Ожидают готовые production-проекты, end-to-end системы, AI-фичи
• Спрос на таких “джунов” вырос на +143%, пока классические junior-роли падают
Если сейчас убрали 60-70% джунов, то в 2031-2036 рынок получит жесткий дефицит senior и tech lead. Кадровая яма уже заложена. А может и они/мы уже тоже не будут нужны
Старая карьерная лестница “учёба → junior → middle” больше не работает.
Для новичков вход в IT стал сложнее и дороже, а интерны вообще уходят в прошлое
Один из самых частых вопросов на собеседованиях для frontend разработчиков: Расскажите про событийный цикл? как выполняются таски? что такое микротаски и макротаски?
В архитектуре event loop вообще нет такого слова как макротаски(macrotasks). Я вообще не смог найти ни одной спецификации, где было бы написано слово macrotask. Кроме Promises/A+. Так в чем же разница между Promise и setTimeout? Почему Promise всегда(не всегда) будут исполняться в приоритете?
Браузер имеет несколько очередей задач (task queues) для разных типов тасок. Таска - это любой javascript код, запланированный стандартными механизмами, такие как запуск программы, запуск события или коллбэки. Помимо этого вы можете создать таску с помощью API, например WindowTimers(setTimeout, setInterval). Микротаски же в свою очередь такие же конструкции javascript, которые позволяют выполнять операции не дожидаясь запуска нового цикла event loop (process.nextTick, Promises, queueMicrotask). Так вот, так как setTimeout, setInterval относятся к браузерному API, то очередь микротасок, таких как Promise и т.д. всегда будет в приоритете выполнения, перед браузерным API.
При этом стоит учитывать, что браузерные API исполняют таски в разные очереди и по разному, например MutationObserver среагировавший после того, как в очередь микротасок попал успешный промис от функции fetch, будет выполнен раньше. То есть вставка в очередь тасок может быть не только как push. Таким образом то, что называют макротасками - это таски браузерного API, которые выполняются по одной на цикл движка браузера.
Понимаем чувство, когда хочется прокачивать свои скиллы, но кажется, что это сложно и долго. Всё становится заметно проще, когда обучение выстроено понятно и последовательно, а для этого надо подобрать полезный курс.
На Хабр Карьере таких курсов много: можно выбрать подходящий и проходить его в удобное время и своём темпе. Возвращаться к материалам, учиться по вечерам или на выходных и постепенно усиливать свои навыки без лишнего стресса. Например, сейчас особенно востребованы курсы по frontend-разработке — ниже собрали основные инструменты:
Павел Варнавский, руководитель группы разработки «ДАР» (Корус Консалтинг), рассказал, как их команда использует BI Magic в своих проектах для создания мощных аналитических решений.
Как внедрять CI/CD для дэшбордов и масштабировать решения под конкретные процессы, там, где стандартных «коробочных» решений не хватает
Два практических кейса, где кастомная разработка на Luxms BI решила нетипичные задачи
Будет интересно всем, кто работает с нестандартной аналитикой, сложными требованиями бизнеса и хочет понимать, как кастомная BI-разработка может быть управляемой и удобной
