Full-stack розробники — це міф, який вигадали менеджери для економії бюджету

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Давайте будемо чесними: формула «1 Full-stack розробник замість окремих Senior Backend та Senior Frontend» існує тільки в Excel-таблицях фінансових директорів. На папері бізнес робить геніальний хід: економить 40% бюджету на наймі та отримує універсального бійця, який і таблицю в PostgreSQL проіндексує, і форму в React зверстає.

Але в реальному житті ця ілюзія економії перетворюється на приховану катастрофу для продукту.

Поки менеджмент святкує закриття вакансії «універсалом», продукт платить потрійну ціну. Дослідження Google та Deloitte підтверджують: затримка завантаження мобільного інтерфейсу всього на 100 мс знижує конверсію в роздрібній торгівлі на 8.4%, а в сфері B2B — майже на 10%.

Більшість так званих full-stack фахівців — це бекендери, які навчилися повертати JSON і сяк-так збирати UI на стандартних бібліотеках. Для них фронтенд — це не інженерія, а просто «візуалізація даних з бази». Якщо запит повернув 200 OK, з їхньої точки зору фіча готова. Але з точки зору користувача та бізнесу продукт починає повільно вмирати через масові перерендери, важкий бандл та зганьблені метрики Core Web Vitals.

Купуючи одного фахівця «2 в 1», бізнес отримує не універсала, а Middle-в-усьому та Senior-ні-в-чому. За даними досліджень Harvard Business Review про втрату продуктивності, постійне перемикання контексту (Context Switching) між двома кардинально різними доменними областями — від складних браузерних API та стану клієнта до архітектури баз даних — зрізає до 40% робочого часу інженера.

Ера «заткнемо всі дірки одним full-stack’ом» створила веб, де 95.9% із мільйона найпопулярніших сайтів (за даними WebAIM) мають критичні помилки доступності та UX. Настав час визнати: спроба зекономити на наймі спеціалізованого Frontend-інженера — це найдорожча помилка, яку може зробити сучасний стартап.

Економічна пастка: Чому 1 + 1 = 0.5

Подивіться на типовий опис вакансії Full-stack розробника: «Шукаємо фахівця з 5+ роками досвіду в Node.js/PostgreSQL та React/Next.js».

З точки зору HR-директора це звучить раціонально. Але з точки зору інженерії це абсурд. Сучасний фронтенд давно перестав бути «просто версткою на CSS та кількома обробниками подій». Сьогодні це повноцінна клієнтська архітектура:

• Складні алгоритми управління станом (State Management).
• Паралельний та перериваємий рендеринг (Concurrent React, Suspense).
• Стратегії кешування на рівні браузера (Service Workers, IndexedDB).
• Оптимізація графічного потоку та мінімізація затримок головного потоку (Main Thread Execution).

Коли бекендер береться за React, він бачить у ньому лише інструмент для виводу JSON-даних у HTML. В результаті ми отримуємо код, який формально працює, але фактично вбиває інтерфейс. Спроба охопити дві глибокі дисципліни одночасно змушує інженера ставати Middle-в-усьому. А на рівні Senior це означає, що компанія купує компроміс замість експертизи.

Метрики, які бекендер просто не бачить в DevTools

У чому фундаментальна різниця між Senior Backend та Senior Frontend?

Для бекендера успіх вимірюється просто: база даних повертає запит за 20 мс, сервер віддає статус 200 OK, навантаження на CPU стабільне. Справу зроблено. Але що відбувається далі на боці клієнта?

1. Метрика INP (Interaction to Next Paint): З березня 2024 року Google зробив INP ключовим фактором SEO-ранжування. Якщо після кліку користувача на кнопку інтерфейс «замирає» більше ніж на 200 мс — сайт втрачає позиції в пошуковиках. Full-stack розробник часто навіть не знає, як виявити Long Tasks у вкладці Performance в Chrome DevTools.
2. Мем-ліки та витоки пам’яті: Неконтрольовані useEffect, відсутність мемоізації та нехтування DOM-деревом призводять до того, що веб-додаток починає споживати 2 ГБ оперативної пам’яті браузера після 10 хвилин роботи.
3. Блокування Main Thread: Поки Full-stack розробник радіє, що його складний розрахунок виконався в JavaScript, браузер користувача пропускає кадри (Drop Frames), роблячи анімацію та скролінг смиканими.

Справжня складність сучасних продуктів (на кшталт Notion, Figma чи Canva) перемістилася на клієнт. І якщо у вас немає інженера, який спеціалізується виключно на оптимізації цього клієнтського середовища, ваш бекенд із затримкою в 5 мс нікому не потрібен — користувач просто закриє вкладку.

Прихований UX-борг та 96% «зламаного» вебу

Технічний борг на бекенді видно одразу: падають сервери, ростуть логи помилок, розробники скаржаться на складнощі рефакторингу. Але UX-борг — це прихований кілер продукту. Він не відображається в Sentry, але прямо впливає на P&L компанії.

За даними аналізу WebAIM (1 000 000 найпопулярніших вебсайтів), 95.9% ресурсів мають критичні помилки доступності (a11y). Замість семантичних тегів ми бачимо безкінечні <div>-и з обробниками onClick, відсутність клавіатурної навігації та повний ігнор стандартам WCAG.

Чому це відбувається? Тому що Full-stack розробник, поспішаючи закрити таску в Jira, думає про логіку даних, а не про те:

• Як цей інтерфейс прочитає Screen Reader?
• Чи правильно обробляються стейти фокусу та помилок?
• Що станеться з макетом, якщо користувач змінить системний розмір шрифту?

В результаті бізнес втрачає мільйони користувачів з обмеженими можливостями або просто тих, хто очікує від сучасного веб-додатка рівня native app. Спроба зекономити на спеціалісті перетворює продукт на набір розрізнених форм і кнопок, які дратують з першої секунди.

Майбутнє за фахівцями, а не збирачами компромісів

Справа не в тому, що Full-stack розробники «погані інженери». Справа в тому, що сучасний веб досяг такого рівня складності, де спеціалізація — це єдиний спосіб робити якісний продукт.

Справжній Senior Frontend Developer сьогодні — це не той, хто просто «накинув верстку». Це архітектор клієнтської частини, який:

1. Захищає конверсію бізнесу через оптимізацію Web Vitals та INP.
2. Проектує стійкі до навантажень та помилок State Management системи.
3. Гарантує доступність та адаптивність сайту на будь-якому пристрої.

Якщо ваша ціль — створити пет-проєкт чи швидкий MVP для перевірки гіпотези, Full-stack інженер — чудовий вибір. Але якщо ви будуєте складний, масштабований B2C/B2B продукт, спроба замінити двох спеціалістів одним універсалом — це не економія. Це просто відстрочений штраф, який ви сплатите втраченими клієнтами.

Час припинити купувати ілюзію універсальності. Продукту потрібні сильні спеціалізовані юніти, де кожен грає на своїй позиції на максимумі.