Каждые пять лет я слышу одно и то же: фронтенд больше не нужен, ему остался последний год. Сначала говорили про визуальные конструкторы - Wix, Tilda, все дела. Потом, когда ИИ выстрелил, начали хоронить разработчиков под флагом «AI напишет тебе кнопку за секунду». А сейчас новая мода - фулстекеры. Приходят такие ребята и говорят: «Да зачем нам отдельный фронт, я сам и бэк, и фронт на коленке соберу, проект сэкономит, все будут счастливы».
Давай просто выдохнем и разберемся, что на самом деле происходит, без паники и хайпа.
Первое и самое очевидное - рынок
Начнем с самого очевидного факта, о котором все знают, но почему-то забывают при первых признаках паники. Когда компании затягивают пояса, они не открывают новые проекты и не расширяют штат. Логично, что новые вакансии перестают появляться, и рынок найма замирает.
Это абсолютно нормальное явление. Не нужно придумывать конспирологические теории или искать виноватых. Экономические циклы существовали всегда, и IT-сфера - не исключение. Да, сейчас сложнее найти работу. Да, это напрягает. Но это временно, и это не имеет никакого отношения к тому, нужны ли фронтенд-разработчики как таковые.
Второе - ИИ
По поводу искусственного интеллекта уже написаны тонны статей, но повторю еще раз для тех, кто в танке. Если разработчик писал плохой код до появления ИИ, с помощью ИИ он продолжит писать плохой код - только быстрее. Инструмент не заменяет понимание. ChatGPT может выдать вам кусок кода, но он не объяснит, почему этот код работает именно так, где он сломается в продакшене и как его правильно интегрировать в существующую архитектуру.
Шах и мат всем вайбкодерам, которые думают, что можно стать разработчиком, просто умея формулировать промпты.
Миф о всемогущем фулстекере :)
А вот здесь я хочу остановиться подробнее, потому что именно эта тема сейчас вызывает больше всего шума. Говорят, фронтенд-разработчики больше не нужны, потому что фулстекеры могут делать всё сами. Давайте разберемся, почему это не совсем так.
Мой путь в разработке строился и на беке, и на фронте, так что я видел обе стороны медали. И вот что я могу сказать: как фронтенд бывает предельно простым, так и бекенд может быть элементарным до безобразия.
Проблема в том, что многие люди, рассуждающие о фронтенде, сводят его к примитивным формулировкам: “Фронтенд - это разместить кнопку, покрасить её в нужный цвет, ну и всё в принципе”. По такой логике можно упростить любую профессию: “Бекенд - это два запроса сделать, на чтение и на запись”, “Программист - это тот, кто просто пишет код без ошибок”.
Звучит легко, в это действительно легко поверить. И знаете что? У меня самого были простые проекты, где действительно справился бы любой джуниор. Но чем больше я получал опыта, чем сложнее становились проекты, тем шире раскрывалось мое понимание того, насколько глубока эта кроличья нора.
Когда простота оправдана
Давайте будем честными: если ваш проект можно собрать на готовом конструкторе, причем там еще есть поддержка бекенда, - используйте конструктор. Зачем усложнять себе жизнь, если у вас минимальные требования?
Если ваш фронтенд только читает данные и отображает их в простом виде, то да, можете даже попробовать сгенерировать его с помощью ИИ и особо не париться. Особенно если компания понимает риски и готова мириться с возможными ошибками.
Но это работает только для определенного класса задач.
Почему фронтенд бывает сложнее бекенда
А теперь плавно перейдем к тому, почему я считаю фронтенд достаточно сложной областью - иногда даже сложнее бекенда. Как бы смешно это ни звучало, но на беке практически всё можно сделать красиво и архитектурно правильно. Или, может быть, это моё наивное заблуждение.
На фронтенде же, чем серьезнее проект (и почему-то все про это забывают), тем больше приходится устраивать танцы с бубном. Давайте разберу несколько реальных кейсов из практики, чтобы было понятнее.
Кейс первый: Форма-франкенштейн
Приходит задача доработать готовую форму из 20 полей. Звучит просто? А теперь внимание: нужно сделать новую форму, которая включает 10 старых полей со сложной взаимосвязанной логикой плюс 10 новых полей. При этом все поля зависят друг от друга.
Если вы мечтаете найти идеальную документацию по этой форме - забудьте, её нигде нет. Единственный человек, который действительно может ответить на вопросы по проекту, - это сам разработчик, который это писал. И если ему повезло уйти в отпуск или сменить работу, вы остаётесь один на один с кодом.
Вам придётся провести полный рефакторинг формы, правильно реализовать новую логику, протестировать все возможные сценарии, продумать граничные случаи и согласовать все нюансы, если вы написали какое-то своё решение, которое изначально не было предусмотрено в архитектуре.
Думаете, я преувеличиваю? Тогда вот вам ещё примеры.
Кейс второй: Когда бекенд забыл про пагинацию
Да, фронтенд-разработчики попадают на разные проекты и работают с бекенд-разработчиками разного уровня. И вот задача: нужно отобразить таблицу с 1000 элементами. А теперь усложним: не просто отобразить, а дать возможность редактировать данные прямо в таблице.
Кто сталкивался с подобным, поймёт проблему. Даже с готовыми решениями вроде ag-grid возникают баги, для которых нет универсальной формулы исправления. Приходится искать компромиссы.
А это невероятно тяжело, потому что вам нужно убедить вышестоящее руководство в том, что иногда даже самое простое на первый взгляд требование технически невыполнимо или требует кардинально других подходов.
Кейс третий: Универсальное решение на все времена
Обожаю поддерживать код от разработчиков, которые вместо того, чтобы просто решить задачу, пытаются изобрести супер-универсальное решение на 10 лет вперёд для виджета, который больше никогда не будет изменяться в течение года.
Почему-то у многих разработчиков вызывает наслаждение писать универсальные конструкторы с кучей абстрактной логики. И это всё работает нормально ровно до того момента, пока не нужно ввести какое-то исключение в эту безупречную логику.
Вот тут начинается кошмар. А если в проекте ещё и TypeScript используется (что правильно и необходимо), то страдания обеспечены. Потому что типизация универсального решения превращается в головоломку уровня hard на LeetCode.
Кейс четвёртый: Конфликт в релизе
У вас настроены динамические стенды, всё красиво раскатывается, каждая задача отдельно тестируется от main-ветки. Идиллия. Но в один прекрасный вечер на вас падает задача на сборку релиза.
И в рамках этого релиза вы вдруг понимаете, что в корневом компоненте (например, main.vue) возникают такие конфликты, что одновременно выпустить две задачи невозможно - они просто противоречат друг другу на уровне логики.
Как так вышло, спросите вы? Если у вас большой проект, невозможно на 100% контролировать весь конвейер, даже если вы устроите сотню созвонов, даже если лично будете контролировать каждую задачу. Шанс человеческого фактора всегда остаётся.
У меня за годы работы таких кейсов накопилась целая коллекция. И у меня язык не поворачивается назвать фронтенд лёгким направлением. Какие только задачи не приходилось решать. При этом я не могу назвать свои проекты самыми сложными и инновационными во всем мире.
Чем больше набираешься опыта и насмотренности, тем внимательнее и серьёзнее начинаешь относиться даже к обычной задаче “покрасить кнопку”. Потому что понимаешь: за этой простой формулировкой может скрываться что угодно.
Фронтенд усложняется до бесконечности
Давайте перейдём ко второму важному моменту. Фронтенд-разработка постоянно усложняется, и требования растут как на дрожжах.
Может, это только в моих проектах, но из-за того, что мобильные приложения могут заблокировать в любой момент, веб-приложения должны быть на уровне нативных мобильных приложений или даже выше.
Не знаю, приходилось ли вам решать задачи, которые обычно доступны только в мобильных приложениях, но реализовать их любыми доступными способами через PWA - это тот ещё дремучий лес. А если ещё сравнивать PWA конкурентов, изучать их функционал и понимать, что они первопроходцы, а вы должны догнать и перегнать, - бессонные ночи обеспечены.
PWA, дизайн и верстальщики нового поколения
Конечно, PWA нужны не всем, тут спорить не буду. Что касается дизайна - вроде бы давно не было таких сильных революционных изменений, всё более-менее устаканилось. Большинство решений уже давно гуглится.
До сих пор существует роль верстальщика, но их нужно немного по-другому воспринимать. Это не люди, которые просто режут макеты. Современные верстальщики - это специалисты, которые знают вёрстку вдоль и поперёк и способны реализовать любую, даже самую безумную идею дизайнера. Это отдельное мастерство.
Бизнес-логика на фронте
Ещё одна проблема - бизнес-логику всё чаще выносят на фронтенд, а сами компоненты усложняются с каждым спринтом. Я уже давно не помню момента, чтобы компонент отвечал за простой вывод данных.
Типичный сценарий сейчас: прочитать данные, занести информацию о событии в логи, проверить внутренние условия отображения, добавить возможность показывать данные по разной логике в зависимости от прав пользователя или состояния приложения. А потом через месяц приходят с новыми требованиями, и количество проблем увеличивается вдвое.
Глубина против ширины
Третий и последний момент, который хочу подчеркнуть. Одновременно весь IT вы не сможете охватить, все языки программирования - тоже нет. Изучая и прогрессируя в одном направлении, вы будете становиться всё сильнее. Нужно копать вглубь, а не пытаться изучить всё на свете на 10%.
На сложные проекты нужны специалисты, которые изучили свою технологию на 80%, а не разработчик, который умеет делать фронтенд на 20%, бекенд на 5%, мобилку на 3%.
Чем глубже вы будете понимать правильность написания кода, нюансы взаимодействия с бекендом, с заказчиками, с дизайнерами, тем больше вы будете осознавать, что фронтенд - это намного больше, чем кнопки.
НО есть важное противоречие
Если вы сейчас ищете работу, хотите поменять место или думаете, что делать дальше, - в условиях, когда все экономят, делайте всё возможное, чтобы не остаться за бортом.
Если вы изучите бекенд хотя бы на 5% и сможете откликаться на вакансии фулстек-разработчика - делайте это обязательно. Если вы знаете React, изучите ещё и Vue хотя бы на 10% - застрахуйте себя от опасных моментов.
Всегда думайте о том, что вы будете делать, если через полгода ваш проект закроется. Будете ли вы востребованы на рынке? Сможете ли пройти собеседование? Когда вы в последний раз получали офферы? Что вообще сейчас спрашивают на собесах?
Эти вопросы нужно задавать себе регулярно, а не когда уже припекло.
Что в итоге?
Если вы фулстек-разработчик - круто, продолжайте изучать технологии, не останавливайтесь, пытайтесь решать всё более сложные задачи. И главное - ищите сильных специалистов вокруг себя. Окружение определяет ваш рост.
Если вы фронтенд-разработчик - можете для подстраховки изучить бекенд, а можете глубже погрузиться в свою область: освоить и React, и Vue, разобраться в глубинах JavaScript и TypeScript, понять, как на самом деле работает фронтенд под капотом.
Какое бы решение вы ни приняли, оно будет верным, потому что неверных решений не бывает - есть только те, которые вы не довели до конца. Даже если вы решите стать вайбкодером, кто знает - может, через месяц вы уйдёте на 3x зарплату в Google и будете писать код для самых крутых продуктов мира.
Главное - не паниковать
Самый страшный враг для человека - это паника. Холодный разум и взвешенные действия - вот залог успеха в любой ситуации, особенно в кризисные времена.
Фронтенд не умрёт. Он эволюционирует, усложняется, меняется - но он никуда не денется. Потому что пока люди пользуются интерфейсами, кто-то должен их создавать. И делать это качественно могут только те, кто по-настоящему понимает, что происходит на фронтенде.
Так что выдохните, составьте план развития и продолжайте двигаться вперёд. Всё будет хорошо.
P.S. И напоследок, чтобы ни у кого не возникло желания накинуться с критикой: это не истина в последней инстанции, не практическое руководство и не научное исследование. Это исключительно мои мысли, основанные на моём опыте, наблюдениях и чувствах. Я не претендую на то, чтобы переубедить всех. Моё мнение - всего лишь одно из многих, но оно имеет полное право на существование, как и ваше. Если у вас иначе - замечательно, делитесь в комментариях конструктивно. Но без негатива, пожалуйста)
