Питали: чи хочу я займатися цією справою. Схоже, що я відповів дуже впевнено.

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

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

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

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

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

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

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

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

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

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

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

Без питань. Це залізо, можно постаивти різний сфот і зробити хакерським девайсом. Я розглядаю з точки зору де вже хард і софт готові з коробки і треба мінімум роботи руками. Cardputter теж дуже опосередковано можно віднести до «вбивці flipper zero», проте є магазин додатків і готові плати розширення, можно умовно придбати cardputer і rfid сканер і в пару кліків поставити софт для копіювання карток. З цим впорається людина без досвіду, що, як на мене, ближче до формату продукту, де фокус на «мінімум знань, максимум профіту».

Сама статя доречна і цікава, але список девайсів не сподобався. Одразу виникає питання «чому експерти рекомендують замінити девайс за 150$ урізанним девайсом за 300$?». В статі не вистачає згадки про ESP32 Cardputter, який має софт і плати розширення для хакінгу і набагато більше ніж під лілку. Спільнота і екосистема ширша. Хоча теж є більш іграшкою ніж професійним девайсом, і ціна відповідна.

Та й лілку туди можно занести опосередковано. Від самого початку там був фокус на ігри, тому вона і «консоль». Так можно і Cardputter занести, там набагато більше хакерськоро софту.

...

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

Есть куча других интересных вещей, чем выбор фреймверка. :) Начинайте решать бизнес-задачи и не лочьтесь на технологию.

>>Знаю людей, которые в такой ситуации начинают атаковать в ответ.

Здесь автор скорей всего имел ввиду, что если кто то накосячил (возможно ты, сказал что сделаешь работу), и к тебе пришли сверху и спросили «ну что сделал?», а ты в ответ защищаясь нагрубил и сделал 100% виноватым того кто спросил с тебя, то скорей всего никто с вами работать не будет, потому что вместо сделанной работы получаются испорченные отношения. Возможно, тут лучше без эмоций найти причину про*ба, согласившись с виной — если она действительно твоя, или найти проблему в поставленных сроках — так хотя бы, тот кто пришел будет знать, что нельзя занижать сроки.

Судя по посту, автор ответила, сказала свои ожидания, но утверждает, что ее начали гнобить. Разве это профессионально? Да послушай ожидания и вычеркни из списка, если оно вам не подходит. Люди разные и у всех разные ожидания, необходимо каждого опустить?

Может быть это чувак, который думает о работе кода на разных платформах и максимальной эффективности, а не о свистоперделках IDE и не ждет пока за него индусы напишут очередную либу...

Монстр — это когда 3.5 строки кода тянут за собой огромное количество классов.

Воу-воу, ущемили чувства верующих!

Конечно слыхали — и возвращаемся ко времени решения задачи и обучению начинающих. Толку от кодревью, если задача будет сильно тормозиться просто потому что человек не знает множества подводных камней и особенностей.
Да и для код-ревью нужно достаточное количество специалистов, которые эти бомбы могут видеть в коде.

Да в общем то мне не обязательно грузить все npm модули асинхронно, мне достаточно вынести React и парочку других библиотек в CDN и грузить их синхронно, потому что это действительно имеет значение при первом открытии страницы после нового релиза (они у нас очень часто).
Webpack мне кажется достаточно громоздким с избыточной конфигурацией. В случае с npmcdn мне кажется достаточно browserify плагина для того чтобы вынести подключение определенных модулей в CDN. Тем более это решение можно будет использовать в уже существующих архитектурах использующих browserify особенно ничего не меняя в логике построения билда.
Частично проблему можно решить при помощи www.npmjs.com/package/browserify-shim, но в этом случае каждую внешнюю зависимость прийдется прописывать ручками, да и подключать в тело документа тоже ручками.

Не подскажите, нельзя ли настроить package.json / browserify — чтобы вместо пакетов в папке node_modules/ был враппер для пакета с npmcdn или подобного сервиса... Спасибо за достаточно интересную наводку по npm.