State of JS 2024: повний розбір звіту та що дійсно питають на співбесідах

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

Привіт, DOU. Мене звати Микулич Олександр, і я Front-End & QA guild master у компанії TENTENS Tech. Власне у січні був спікером на вебінарі від СodeUA, де разом з колегою ми робили огляд на звіт State of JS 2024 про який сьогодні піде мова.

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

Робитиму акценти з двох позицій:

— наймаючого менеджера: які технології зараз важливі й що хочуть бачити на співбесідах;

— розробки: що з цього списку ми реально використовуємо і що варте уваги.

State of JS 2024 у цифрах. Фічі JavaScript 2024

Перше подібне опитування було ще у 2016 році.

Цього року у State of JS 2024 взяли участь 14 000 людей. Я подивився на демографію, щоб розуміти, хто ці люди. Найбільше учасників зі штатів та Європи. Якщо подивитися по роках досвіду, більшість має 5+ років у розробці.

Syntax Features

Перше, що відмітило найбільше респондентів у State of JS 2024 — це nullish coalescing. Це оператор, який дозволяє перевіряти значення тільки на null або undefined:

const value = null ?? 'default';
console.log(value); // 'default'

Якщо зліва null або undefined, повертається значення справа.

Друге, на що звернули увагу — Dynamic Import.

Замість того щоб імпортувати весь код одразу, ми можемо завантажити його тільки тоді, коли він реально потрібен. Ми часто використовуємо це для lazy loading у проєктах, коли не хочеться тягнути зайвий код одразу. Банальний кейс: налаштували роутер, тягнемо компоненти звичайними імпортами, і коли користувач заходить на одну сторінку, завантажується половина всього застосунку — це неприємно.

При хайрингу розробників рівня мідл і вище, якщо говоримо про перформанс, то динамічний імпорт — одна з важливих тем. Якщо кандидат каже, що стикався з проблемою великих бандлів і оптимізації завантаження, то я очікую, що він згадає про tree-shaking і dynamic imports.

String Features

ReplaceAll()

Значно полегшує заміну всіх входжень у рядку, на відміну від replace, який замінював лише перше входження.

Однозначно поділяю думку респондентів тут, оскільки сам робив і натикався на баги, коли поспішили й очікували replace заміну усіх входжень. На співбесіді рідко спускаюсь до питань про подібні фічі, хіба що у досвіді кандидата є цікавий кейс, тоді можемо це обговорити.

Array Features

Головне, що я тут для себе відзначив — фокус на немутуючі методи. Респонденти згадали такі методи масиву як: toSorted(), toReversed(), toSpliced().

Object Features

Object.groupBy().

Приємно, що нарешті є нативний groupBy, оскільки часто є потреба у використанні й щоразу приходиться підключати lodash чи писати самописне рішення.

Колись на співбесідах часто просили відсортувати масив бульбашкою. Вже давно такого не зустрічав — для нас же це не так критично. Якщо, для прикладу, ми проводимо співбесіду на позицію джуніора, то незнання подібних методів масиву чи об’єкта не впливає на враження від кандидата. Хоча, звичайно, це плюс, якщо він знає, оскільки показує глибину занурення в JS і у ті фічі, які він використовує.

Browser APIs

Дивлячись на список популярних Browser APIs, можна виділити кілька тих, які ми використовуємо, і тих, які в нашій роботі не потрібні.

Що використовуємо:

• WebSockets. У нас є внутрішній чат, де WebSockets використовуються для обміну повідомленнями в реальному часі.
• Progressive Web Apps (PWA). Ми не працюємо з мобільними застосунками, тому в певному сенсі тестуємо PWA як альтернативу.
• Web Animations API. Ми активно працюємо з анімаціями, але реалізуємо їх через бібліотеки, а не пишемо вручну.

Що не використовуємо або рідко зустрічаємо:

• Geolocation API — наразі в нашому проєкті немає потреби в отриманні геолокації.
• WebGL — поки що не було кейсів, де WebGL був би необхідний.
• WebRTC — раніше використовували WebRTC, але зараз він не актуальний на проєкті.
• Temporal API — наразі не використовуємо, але, можливо, зачепимо тему, коли будемо говорити про дати.

Якщо говорити про технічні співбесіди в контексті Browser API, то достатньо часто підіймаємо тему WebSockets. На рівні джуніора очікуємо приблизне розуміння, що це, а вже від мідла чи сіньйора — розуміння: як сокети працюють під капотом, які проблеми з ними можуть бути і які є альтернативи.

Web Animations API — якщо заходить тема про перформанс, то робота з анімаціями також спливає. Зазвичай розробники сіньйор рівня мають, що розповісти на цю тему. Тут цікавий досвід кандидата, і наскільки глибоко він занурився у тему.

PWA, WebRTC — рідко виносимо це на співбесіду, але були випадки, коли кандидати самі згадували про це і тоді ми проходились по цим темам також, занурюючись у деталі. Особливо цікаво в таких випадках, які рішення приймали кандидати й чому. Інші ж API майже ніколи не згадуються на наших співбесідах.

Language Pain Points

Цей графік для мене один із найцікавіших, бо він показує, що найбільше болить розробникам у JavaScript. Пройдемось по списку й розберемо, чи дійсно є проблема, а що не так і страшно.

1. Нативна статична типізація

Чи болить нам? Скоріше ні, ніж так.

Можу зрозуміти, чому респонденти поставили цей пункт на перше місце. У нашому ж випадку покладаємось на альтернативи:

• TypeScript — сьогодні вже не просто тренд, а стандарт для багатьох проєктів.
• Автотести різного рівня — юніти, інтеграційні, e2e. На поточний момент левова частка саме інтеграційних.
• Строгість контрактів з бекендом — переїжджаємо на gRPC.

Чи все це може замінити нам рантайм типи — ні, але в більшості випадків це дозволяє нам тримати баланс між швидкістю і якістю. У тих місцях, де все ж критично важливими є перевірки в runtime, використовуємо Zod, але дуже обережно.

На співбесідах це чудова тема до обговорення з мідл чи сіньйор спеціалістами. Тут не так важливо, якої думки дотримується кандидат, як його роздуми, глибина аргументів і розуміння, що не існує єдиної срібної кулі.

2. Браузерна підтримка

Тут я бачу два типи людей:

• Новачки, які тільки входять у фронтенд і вперше стикаються з Safari. Для них це біль, бо щось працює не так, як у Chrome, Firefox або Edge.
• «Старички», які ще застали Internet Explorer. Якщо ти працював з IE 6-11, то Safari здається легким викликом. Я відношу себе до цього типу. Так, Safari інколи підкидає сюрпризи, але якщо порівнювати з тим, що було раніше, то це взагалі не проблема.

Справжній біль — це верстка email-листів. Outlook дотепер залишається диким середньовіччям для верстки. Тут уже ніякий Safari не страшний.

Так чи інакше цю тему на співбесідах підіймаємо достатньо часто, і тут є де розвернутись, щоб зрозуміти ширину експертизи кандидата. Версії ECMAScript, компілятори/транспілятори, babel, поліфіли, css і так далі.

3. Дати — постійне джерело проблем

У мене завжди виникали якісь баги, пов’язані з датами, незалежно від середовища:

• JavaScript у браузері.
• C# на бекенді.
• Робота з базами даних.

Завжди є шанс напоротися на якусь помилку:

• Часові пояси (UTC vs локальний час).
• Неправильне збереження формату у базі.
• Неочікувані зміни при перетворенні.
• Відсутність стандартизованого підходу до зберігання.

Цікаво, що на більшості курсів програмування дати взагалі не вчать. Це занадто нудна тема для теоретичного вивчення, тому зазвичай досвід з’являється лише тоді, коли доводиться розгрібати реальні проблеми. Хто працював із датами — моя повага.

Люди, які мали серйозний досвід роботи з датами, часто дуже добре розуміють біль продакшену. Це такий собі «бойовий досвід» і він дуже цінний.

4. TypeScript Support

Це питання залишилося для нас незрозумілим. Є два можливі варіанти:

1. Чи використовується TypeScript в компанії чи проєкті?
2. Чи є вбудована підтримка TypeScript у браузерах?

У контексті першого варіанту, то TS — це зараз дефолтний вибір на ринку, тому на співбесіді будь-якого рівня копаємо в сторону розуміння TypeScript.

Огляд бібліотек у звіті State of JS 2024

Фронтенд-фреймворки

У світі фронтенд-фреймворків особливих сюрпризів немає — React залишається беззаперечним лідером, його використовують 81% розробників. Vue.js і Angular традиційно слідують за ним, і загалом ця трійка вже багато років займає верхні позиції.

Щодо особистого вибору, то я надаю перевагу Vue. Не те щоб інші фреймворки не дозволяли досягти тих самих результатів — загалом усі вони дають схожі можливості, просто кожен має свою специфіку. Мені імпонує Vue, і радує, що у звіті він має досить низький рівень негативних відгуків. Це свідчить про стабільний імідж і позитивні перспективи розвитку.

Чи хотілося б мені, щоб Vue випередив React? Безумовно. Але варто визнати, що кожен розробник вибирає інструменти під свої потреби, і React це потужна бібліотека, яка має свою аудиторію і яку так просто не зрушити.

Angular, своєю чергою, теж не здає позицій і продовжує активно розвиватися. Особливо цікаво спостерігати, як його використовують у великих компаніях і банках. Зі свого досвіду бачу, що там він відчуває себе впевнено завдяки схожості з C#, що робить його зручним для розробників, які працюють з .NET. Vue чи React у такому середовищі сприймаються як щось надто «вільне» і «ненадійне», тоді як строгість Angular добре вписується в корпоративні стандарти.

В контексті найму часто вважають, що якщо в компанії пишуть на Vue, це означає, що на співбесіді в основному будуть питати про Vue. У нашому ж випадку ми дуже рідко підіймаємо тему фреймворків і на то є дві причини:

• все ж більшість ринку — це React-розробники й логічно, що вони не знають про Vue. Для нас важливо, щоб вони були відкриті до використання інших фреймворків/бібліотек і не зациклилися на цьому.
• з нашого досвіду onboarding на Vue проходить дуже швидко, тому й на самій співбесіді концентруємося на інших речах.

Метафреймворки

Якщо говорити про метафреймворки, то тут ситуація цікавіша. Next.js залишається найпопулярнішим, але, судячи з тенденцій, не всім він подобається. Його рівень задоволеності досить високий, але не абсолютний. Водночас якщо дивитися на фреймворки з найбільш позитивними відгуками, то на першому місці Astro. Після нього йдуть Next.js, SvelteKit та Nuxt.

А ось Gatsby відверто втрачає довіру. Якщо сортувати за рівнем негативу, то він опиняється на першому місці серед антипатій розробників. Це, мабуть, найсильніший контраст у цьому звіті.

Щодо Next.js, то цікаво, чому його показники не такі виняткові, як можна було б очікувати. Здається, зараз розробники розділилися на два табори: хтось дуже задоволений, а хтось, навпаки, відчуває, що фреймворк рухається не в тому напрямку. Ця змішаність вражень робить тренд ще цікавішим, і варто буде глибше подивитися, як змінювалася популярність фреймворків і метафреймворків за останні роки.

В нашому контексті актуальний саме Nuxt, але знову ж таки, рідко говоримо саме про нього. Більше про концепції, такі як: SPA, SSR, SSG, ISR.

Testing

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

Основні інструменти, згадані в цьому розділі, — це Jest, Storybook, Vitest, Cypress, Playwright.

Якщо запитати мене, що обрати для тестування зараз, я без вагань відповім: Vitest — для юнітів, Playwright — для компонентних інтеграційних тестів. І це ті технології, які ми використовуємо у себе. Також вважаю, що Playwright наразі реальний претендент на статус нового стандарту в e2e-тестуванні.

Особисто мені Playwright подобається більше за Cypress:

• по-перше, швидкість — все літає, немає проблем з паралелізацією;
• по-друге — класні дефолти, з коробки все працює.

Додатково крута фіча, яку вніс Playwright (як мінімум тут я це вперше побачив) — це механізм фікстур. Цікаво, що Vitest теж скопіював собі цей механізм.

На співбесідах цікавить не так знання технологій тестування, як загальних практик і підходів. Відношення до QA-процесу і також бачення, і відповідь на питання «хто має тестувати: розробник чи QA?»

Build Tools

Webpack

Звісно, першим у списку білд-інструментів хочеться згадати Webpack. Webpack зробив дуже багато для екосистеми JavaScript, і свого часу він став справжнім проривом. В міру того, як зростали вимоги до DX (developer experience) та швидкості, Webpack почав здаватися надто важким, особливо через складність конфігурації.

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

Поява нових білд-інструментів

Rust почав проникати у front-end tooling. Все більше інструментів тепер пишуться не на JS, а на мовах — Rust і Go: esbuild, swc, vite, oxlint, ts-go.

Void Zero, Rolldown та нова генерація білдерів

Тим часом з’являються нові ініціативи, наприклад, Void Zero — нова компанія від Evan You, автора Vue. Їхня мета — будувати альтернативу наявним інструментам на сучасних принципах. Серед прикладів може бути Rolldown, який вже з’явився у звіті, попри те, що ще майже не має продакшн-використання. Це показує, наскільки швидко спільнота підхоплює нові ідеї, якщо вони розв’язують актуальні проблеми.

В цілому усе рухається в бік легких, дуже швидких, low-config інструментів. Навіть якщо вони ще не зрілі, тренд очевидний: ми рухаємося геть від складних та важких тулів на кшталт Webpack.

У мене часто запитують, наскільки глибоко потрібно знати білд-систему на співбесіді. І тут усе залежить від ролі. Основна думка — треба розуміти, що відбувається з твоїм кодом до того, як він потрапляє у браузер.

Інколи я запитую не «яким плагіном ти користуєшся», а «навіщо він взагалі існує». Як працює Babel, що таке поліфіли, як виглядає chain трансформацій, чим Babel відрізняється від SWC — ці речі багато кажуть про інженерний рівень.

Monorepo

Я повністю згоден із думкою, що монорепозиторії — це точно не для джуніорів. Якщо ти тільки заходиш у світ розробки, краще почати з чогось простішого: один репозиторій — один проєкт.

Коли людина без досвіду намагається розібратись з monorepo, вона зазвичай зіштовхується з великою кількістю проблем, плутається в інструментах, пакетах, залежностях — і зрештою просто починає ненавидіти сам підхід. І це шкода, бо сам по собі він дуже потужний.

У нашому випадку більшість репозиторіїв живуть у форматі polyrepo і не так давно ми почали впровадження monorepo підходу в одному з проєктів. Вибором задоволені.

Якщо ж конкретніше, що використовуємо ми в монорепі, то:

• pnpm + pnpm workspaces;
• nx — як оркестратор;
• vite — відповідає за білд пакетів;
• nuxt — застосунки.

Ось тут пишу більше про монорепу на прикладах пет-проєкту.

На співбесідах не часто розмовляємо про монорепозиторій, оскільки не так багато кандидатів мали з ним досвід. Та й взагалі все, що про FrontOps не так сильно розвинуто на ринку і це крута точка для зростання.

Other Tools

У звіті State of JS 2024 серед бібліотек, які розробники регулярно використовують, можна побачити як класичних ветеранів екосистеми, так і нові, більш сучасні інструменти. Розглянемо ключові позиції та коментарі щодо них.

1. Lodash (43%)

Lodash і досі утримує перше місце — і не дарма. Це зручна утилітна бібліотека, яка вирішує безліч повсякденних задач і залишається актуальною. Її популярність пояснюється стабільністю та передбачуваністю API.

2. date-fns (37%)

Це сучасний конкурент Moment, який добре працює з датами, підтримує tree-shaking і при цьому достатньо гнучкий.

3. Zod (36%)

Zod стрімко набирає популярність як runtime-альтернатива TypeScript.

Хоча зараз придивляюсь до альтернативи у вигляді ArkType, тому хто його зна, чи Zod-у вдасться втриматися в топі серед ts runtime валідаторів найближчі роки.

4. Moment.js (27%)

Найбільш неочікуване ім’я в топі. Хоча бібліотека офіційно deprecated, вона все ще активно використовується через велику кількість старих проєктів, які досі залежать від неї.

5. Day.js (24%)

Day.js позиціює себе як «мінімалістичний Moment», має схожий API, але компактніший і без внутрішніх side-effect. Його обирають ті, кому треба швидко замінити Moment без значного рефакторингу.

6. jQuery (17%)

Попри все, jQuery тримається в списку. Причина проста: велика кількість legacy-проєктів. Бібліотека пережила десятки змін екосистеми й заслуговує поваги, хоча нові проєкти вже не будуються на ній. Цікаво, що нещодавно навіть вийшла нова версія jQuery.

AI TOOLS

AI перестає бути просто «допоміжним тулом» і все більше інтегрується в саму суть фронтенд-процесів — від автогенерації шаблонів до пошуку рішень для edge-case-ів.

Обговорення того, як розробники використовують AI на співбесідах, викликало дискусію. Якщо кандидат вміє швидко, критично й ефективно використовувати AI — це більше плюс, показник вміння розв’язувати проблеми. Тестові завдання зараз втратили свою цінність, бо AI чудово генерує boilerplate-код. У нас і раніше не було тестових завдань, а в еру AI, ми закріпились у думці, що реальних знань тестове не покаже.

Щодо інструментів: зараз найбільш поширеними залишаються Copilot, ChatGPT і Cursor. З боку Google — Gemini як частина Google Cloud Platform. Для прикладу Cursor і CodeRabbit — це ті тули, які ми зараз активно тестуємо у себе. Хочемо зрозуміти, де вони справді допомагають, а де роблять навпаки гірше і що ми з цим можемо зробити. Загалом, AI в екосистемі JavaScript уже не «тренд», а частина реальності, яка формує новий рівень вимог до інженерної культури.

Питання про AI також потихеньку входять у співбесіди. Поки у нас немає якихось конкретних очікувань від кандидатів, скоріше дивимось, у яких кейсах і як саме використовується той чи інший AI-інструмент і чи це щось говорить про рівень кандидата, і його спроможність розв’язання проблем.

JavaScript Pain Points

Болі розробників як індикатори реальних проблем, які визначають зрілість екосистеми:

Архітектура коду — ключова складність фронтенду. Його легко почати писати, але надзвичайно важко написати правильно. Прості речі вимагають найвищого рівня досвіду: чітких кордонів між модулями, прозорої структури та передбачуваної логіки. Погана архітектура не завжди зупиняє проєкт, але вона завжди уповільнює його.

State Management — зона нестабільності у фронтенді. У vue-екосистемі з цим трохи краще, оскільки є єдиний стандарт, яким усі користуються. В React усе складніше і тут роблю висновок з досвіду інших компаній, які не раз обпікалися, пробуючи все підряд: Redux, MobX, Recoil, Zustand, XState.

Дебагінг як недооцінена навичка. У фронтенді ми маємо потужні інструменти діагностики й відладки, але більшість не вміє ними користуватись. Більшість вміють у console.log, що вже непогано, але іншими базовими інструментами не володіють. Вміти швидко локалізувати проблему — фактор продуктивності.

Часто на співбесідах, коли питаю «Як ти шукаєш у чому проблема?», зазвичай чую у відповідь: «використовую console.log і більше нічого». А можливість ставити брейкпойнти, змінювати код на льоту, перевіряти мережеві запити — це ті навички, які варто вивчити, щоб бути справді продуктивним.

На завершення

Звіт State of JS 2024 — зріз професійної свідомості спільноти. Мене тішить, що в топі проблем — архітектура, зрозумілість коду, тестування, продуктивність і відповідальне використання AI. Там, де зараз проблеми, незабаром будуть рішення.

Якщо ж говорити про найм, то як можна зрозуміти з моїх коментарів вище, знання технологій — це добре, але не головне для нас. Важлива загальна технічна культура, як кандидат навчається, як підходить до розв’язання проблем, наскільки відкритий до змін і не зав’язується на єдиний підхід чи бібліотеку. І технології тут це скоріше привід, щоб копнути в одну з цих тем, які насправді цікавлять.

Якщо ж говорити конкретніше в розрізі грейдів, то:

• у Junior-спеціаліста очікуємо побачити потенціал. Хорошим його підтвердженням будуть різного роду успішні намагання вивчити щось нове і вирости. Це може бути прочитана технічна книга, пет-проєкт, участь в хакатоні чи конференції.
• Middle: очікування, як і до джуніора + реальні кейси розв’язання бізнесових проблем.
• Senior: ті ж очікування, що й до мідла + скейл проблем, які вирішував, більші й нерідко вимірюються у півріччях чи роках.