NestJS is bad: чому фреймворк критикують і чи актуальний він у 2025?

Побачила на Reddit цікаву дискусію під назвою «NestJS is bad, change my mind», де автор досить різко висловився про фреймворк:

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

А як ви ставитесь до NestJS і його ролі у сучасному бекенд-стеку?
Чи використовуєте його у своїх проєктах і наскільки він виправдовує себе в реальній роботі?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Теми: back-end, NestJS, node.js, обговорення

Ctrl + Enter

Nazar Rybitskyi SSE 15.12.2025 20:04

Nestjs — кал гімна пса.
Багато з ним працював, кожен раз люто ненавидів.
Згідно моїх спостережень розробка і підтримка з застосуванням nestjs коштує бізнесу дорожче ніж не юзати взагалі ніяких фреймворків.
Більше всього бісила incompatibility цього фреймворків з багатьма стандартними, простими тулзами|підходами і тонни бойлералейт гімна

Відповісти

Підтримати

Jeremy Walter 14.12.2025 12:14

Чудовий фреймворк. Але дійсно для середніх проектів краще наприклад Fastify взяти бо де пан Матео Коліна — там якість.

Pavlo Vuiko Senior Node.js Engineer в EPAM 14.12.2025 18:29

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

Jeremy Walter

Yevhen Klimov 14.12.2025 11:59

Для 90% випадків:
Bun + Hono + Typescript.
Воно швидше, однаково безпечне та читаєме.

NestJS для важчіх випадків, і в основному на гігантських проектах. Але якщо брати круди, або апку з малим функціоналом, я не знаю нащо брати цього прожорливого та неповоротливого слона

Pavlo Vuiko Senior Node.js Engineer в EPAM 14.12.2025 18:39

Але якщо брати круди, або апку з малим функціоналом, я не знаю нащо брати цього прожорливого та неповоротливого слона

Повністю з вами тут погоджуюся, але подібного роду апки це аж ніяк не 90% випадків, це лише тестові, навчальні, або супер базові проєкти. Якщо ми говоримо про щось більш серйозне, то на Hono, чи скажімо Fastify звісно можна їхати, але тут добре треба розуміти що ми робимо і як це розумно зробити, з мого особистого досвіду, не всі це вміють і знають, але очі зробити щось простіше горять) і на ділі виходять апки в яких складно орієнтуватися, розширювати і т.д., хотілося простіше, а вийшло значно складніше. Тому навіщо придумувати велосипеди, якщо вони вже всі є в NestJS з коробки?
Щодо пункту «швидше» я не до кінця погоджуюся, Node.js можна зробити наближеною по швидкості до Bun, просто це йде не з коробки і потребує деяких додаткових знань

Yevhen Klimov

Yevhen Klimov 15.12.2025 16:50

Знання, освіта, час, фінанси, кадри і малі ризики — так. Це коли мова йде про середній та великий бізнес.

А якщо ми говоримо про — приватну особу, стартап, неприбудкова організація та малий бізнес?
З рештою все одно можна переписати з Hono або Addonis або які тут ще ліби згадувалися на іншу.

Окей, тут я і справді трішки поторопився, бо дивлюся з власної перспективи, як людина яка з нульовим ресурсом, спробує піднятися якщо придумає щось круте.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 15.12.2025 18:56

А якщо ми говоримо про — приватну особу, стартап, неприбудкова організація та малий бізнес?

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

Pavlo Vuiko Senior Node.js Engineer в EPAM 13.12.2025 15:36

Зазвичай з тієї критики NestJS, що бачу є це «ой Боо, як складно, я візму Express.js (підставте будь-яку мінімалістичну лібу) і напишу TODO апку в якої буде менше коду, АБСОЛЮТНА ПЕРЕМОГА». Це такий крінж, що я не можу, до людей не доходить банальний факт, що комплексний застосунок потребує комплексного підходу в його реалізації, тому краще обрати гарний фреймворк з чудовим функціоналом з коробки і чудовою можливістю до розширення, тобто NestJS, ніж die trying написати цей фреймворк самому.
У NestJS звісно є деякі мінуси, у вигляді того самого DI, який як мені здається можна було б зробити трохи зручнішим, але це не критично.
Там бачу на скріншоті про webpack у production dependencies, що власне є неправдою, видно що автора поста з Reddit прокачений факт чекінг))

Alexander Maslakov Full-stack web developer 13.12.2025 12:34

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

Якщо JS, краще звернути увагу на AdonisJS.

Pavlo Vuiko Senior Node.js Engineer в EPAM 13.12.2025 15:54

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

Які по вашому переваги AdonisJS над NestJS?

Alexander Maslakov

Alexander Maslakov Full-stack web developer 14.12.2025 02:01

Я використовую Laravel, а AdonisJS це Laravel/RoR-like фреймворк, який притримується тих самих принцепів, які зарекомендовали себе з позитивної сторони. Це спрощує світч між фреймворками з різних мов, тому вважаю це загалом сильною стороною Adonis. Можна онбордити людей, котрі прийшли з Laravel, а не тільки в рамках фреймворка.

Pavlo Vuiko Senior Node.js Engineer в EPAM 14.12.2025 18:12

А якщо людина прийшла не з Laravel? Такий собі аргумент, якщо чесно.

Можна онбордити людей, котрі прийшли з Laravel, а не тільки в рамках фреймворка.

І вам не здається що ви собі тут трохи протиречите? Або я вас не так зрозумів, що означає «а не тільки в рамках фреймворка»? У рамках якого фреймворка? NestJS використовує старий добрий Layered Architecure, це не привʼязано ні до якого фреймворку, це база архітектури бекенд апки, це мають знати абсолютно всі бекенд розробники. То все ж будуть ще якісь переваги AdonisJS над NestJS окрім того, що перший близький для представників PHP?

Зайшов на сайт AdonisJS, там пропонуєтся всі контролери і т.д. складати в одну папку і називають це «thoughtful file structure» ну це просто крінж, така файлова структура працює лише в мікросервісах (справжніх маленьних мікросервісах) і тестових застосунках які в 100% випадках приводяться як приклад в новомодних лібах/фреймворках, які кажуть «нащо використовувати підхід, який добре працює десятиліттями, коли можна зробити „простіше“», а на ділі цей підхід не вивозить застосунки принаймні середнього масштабу

Alexander Maslakov Full-stack web developer 15.12.2025 03:41

Головне вам підходить. Я лише звернув увагу на те, що в JS є RoR-like фреймворк. Якщо вам більше підходить NestJS, це не означає що іншим він теж обовʼязково повинен підходити. Проте краще мати декілька альтернативних фреймворків з різними поглядами. Це конкуренція і це робить екосистему краще.

То все ж будуть ще якісь переваги AdonisJS над NestJS окрім того, що перший близький для представників PHP?

Я навіть не натякав, що збираюся шукати переваги AdonisJS над NestJS. Я негативно ставлюся до NestJS, через те що він здався мені многословним суто по документації. Для мене AdonisJS зрозімілійший, тому що RoR-like (плюс документація близька до Laravel). RoR-like — це доволі поширена когорта фреймфорків, котрі використовують риси RoR. Ці фреймвокри мені здаються зручними, логічними, простими. Суто з практичного досвіду.

Щодо контроллерів в одній папці. Не певен, що це догма і забороняється створювати під-папки. ;)

У мене повинен бути такий самий сет знань щодо «Layered Architecure», що й у вас, щоб вести конструктивну дискусію.

Pavlo Vuiko Senior Node.js Engineer в EPAM 15.12.2025 18:52

тобто ви у своєму першому коментарі сказали, що ставитеся до NestJS негативно і радите Adonis.js, але при цьому не можете назвати переваг другого над першим, окрім того, що вам звичніший його підхід?

Alexander Maslakov Full-stack web developer 15.12.2025 19:30

Саме так, я ставлюся негативно — це відповідь на питання у кінці статі «А як ви ставитесь до NestJS і його ролі у сучасному бекенд-стеку?», та я пропоную звернути увагу, а не ~~раджу~~. Я не формулюю свою позицію, що вам неодмінно треба відмовитися від NestJS і пересісти на Adonis, радше «дивіться тут є ще й такий фреймворк, і мені здається, реалізація більш чиста, зрозуміла, доступна».

Моє негативне ставлення обумволене тим, що мені NestJS не сподобався в плані документації. Як приклад, наявність конкуруючих архітектурних елементів Middleware та Interceptor, що трохи збиває з пантилику. Нащо мати два схожих механізма? В Laravel/Adonis кешування і всі перехоплення Request/Response робляться в Middleware. Це натякає на те, що треба враховувати архітектуру ExpressJS-like мідлвар і більш потужну реалізацію NestJS Interceptor. Мені це не сподобалося, бо більше речей треба тримати в увазі, а значить меньше уваги приділяти бізнес-логіці. Можна апелювати, що немов так гнучкіше, але ні, це просто многослівність. Та мені, як працюючому з Laravel, доступнішим є AdonisJS (архітектурні елементи ті самі, означають і роблять те саме).

Буде нагода ознайомитися з NestJS ближче, можливо, зміню своє ставлення.

Yevhen Klimov 14.12.2025 12:04

Все ж, для багатьох випадків ця структура просто не потрібна. Дуже часто доводиться писати велику купу нових гейтів по одній строці в модулі, контролері та сервісі, що могло було легко замінено одним методом де і буде вся логіка з цих трьох строк коду.
Це окей десь умовно в С# або Java робити, але в JS є можливість писати без цього, для чого JS і створювалася спочатку — написати швидкий та малий код(скриптова мова)

Pavlo Vuiko Senior Node.js Engineer в EPAM 14.12.2025 18:25

Мені цікаво почути для яких таких випадків ця структура не потрібна? Знаю лише мікросервіси, і тестові апки по типу крудів TODO списку. А що робити коли апка серйозна, хоча б середнього масштабу коли є багато бізнес сутностей (модулів) і зон відповідальності? От на цьому моменті використання «простішого підходу» дуже сильно все ускладнює, а підхід NestJS (який не сам придумав цю структуру, а взяв те, що добре працює десятиліттями) дозволяє логічно і зрозуміло розділяти зони відповідальності різних бізнес сутностей, а також відділяти бізнес логіку, транспорт, валідацію, авторизацію і data-access layer роблячи їх модульними і незалежними.

Це окей десь умовно в С# або Java робити, але в JS є можливість писати без цього, для чого JS і створювалася спочатку — написати швидкий та малий код(скриптова мова)

JS вже давним давно не використовується для того, для чого він створювався на початку це раз, два — комплексна задача, буде вимагати комплексного рішення, це ніяк не обійдеш «простими підходами». Тому Layered Architecure і розділення бізнес сутностей (модулів) це база в бекенд розробці, яка працює як годинник, спроби упростити це, що і так насправді є простим ні до чого доброго в проєктах хочаб середнього масштабу ні до чого доброго не підходять. Я погоджуюся, що JS/TS дозволяє писати код простіше за Java/C# але треба розуміти де спрощення використовувати має місце, а де не має.

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

Не зрозумів що ви маєте на увазі, можете, будь ласка, привести приклади, чи пояснити іншими словами?

NestJS is bad: чому фреймворк критикують і чи актуальний він у 2025?

17 коментарів

Підписатись на коментарі