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

З точки зору «кастомера» — будь-яка плата це недолік, але він таки платить більше тим, хто пише на TypeScript.

Дотнет теж так вміє

Не сумніваюсь. А PHP не вміє.

А що ви кажете про Java?

Те саме — це мова програмування.

Я працював з типізованим PHP

* PHP — вона, бо це мова (а не язик).

Мені в tRPC ще подобається, що я навіть і не писав типи. Багато речей визначаються автоматично. По факту, типи написані тільки для моделей в Prisma. Валідація даних відбувається за допомогою zod (одночасно валідація + типізація). Тип, який повертається з ендпоїнта, теж визначається автоматично.

А документація OpenAPI (раніше відомий як Swager) генерується по тим типам?

Проте для маленьких-середніх проєктів з типовими завданнями JS справляється чудово

Навпаки — чим більший проект, тим більша ймовірність що у ньому потрібно робити загальну (не залежну від роутів) початкову ініціалізацію різних файлів, конфігів і т.д. А із цим значно краще справляється JS у порівнянні із PHP, бо PHP приходиться за кожним запитом робити цю роботу, тоді як JS може робити це єдиний раз під час старту веб-сервера.

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

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

Це залежить не від NestJS, це залежить від того проекту, який ви використовуєте. Я використовую монорепозиторій, в якому якраз можна один раз написати тип, а потім посилатись на нього і на фронтенді, і на бекенді.

З дурнем спорити — себе не поважати. Тому я з тобою не буду спорити, чувак.

Більш точне обговорення буде якщо ви наведете конкретну задачу

Хто вам сказав, що не можна використовувати абстракції? Чи ви не розумієте як можна конкретну задачу показувати із певним рівнем абстракції?

Ви вмієте мислити абстрактно взагалі?

Так.

Наведіть конкретний приклад, бо без цього ми один-одного не зрозуміємо.

Зразу відчувається що питає РНР-шник, в якого підгорає від того, що JavaScript/TypeScript поступово витісняє РНР із бекенда. А ще якщо порівняти середні зарплати розробників хто пише на PHP, із зарплатами розробників, хто пише на TypeScript, то виявиться що другі заробляють на $1000 більше щомісяця. Як це пояснити?

Що стосується перформенсу, то РНР може виграти хіба що у випадку великої кількості паралельних запитів, при умові що оперативна пам’ять необмежена. Але підозрюю, що в такому проекті тоді вже буде краще використати якийсь Go.

Що стосується взагалі бібліотек для TypeScript, то не переживайте, їх мабуть більше, ніж для РНР.

Як я і написав вище, в контексті Angular немає сенсу використовувати Redux, бо у нього є сервіси + DI для управління станом. Думаю його затягують в Angular ті техліди, які добре знають Redux, бо працювали із React, наприклад, і які погано знають Angular.

Більш точне обговорення буде якщо ви наведете конкретну задачу, яку буде важко вирішити без згаданого вами Vuex.

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

Якщо взяти сучасні фреймворки, типу React, Angular, і порівняти їх із jQuery, то вони не просто так ускладнюють код проектів, а ще й дають неабиякі переваги. Що раніше писалось на jQuery? — Форми, що відправляються на Ajax, чи кнопочки, які змінюють текст після натискання, чи ще якісь дрібниці. Якщо писати такі самі дрібниці на сучасних фреймворках, то дуже навряд чи код у них буде складним.

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

Зараз NestJS мабуть є найпопулярнішим NodeJS-фреймворком, написаним на TypeScript. От він — модульний, і також має CLI, завдяки якому можна будувати блоки вашого застосунку з командного рядка. Він має ще й Dependency Injection (скорочено — DI), який дає відчутну перевагу над фремворками без DI. До речі, NestJS досить часто використовують для мікросервісів.

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

Вважаю свій фреймворк Ditsmod досить перспективним. На мою думку, він значно краще спроектований за NestJS, також має модульну архітектуру, має DI, інтерсептори, routes guards, та ще й розширення (тобто плагіни, чого у NestJS поки що немає).

Ви ж розумієте, що «можливість» має на увазі «хочете кажіть, хочете — ні».

Так це правильна поведінка людини яка хоч трохи думає.

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

Так а де ви побачили питання про «куди ви від нас йдете?». Можна ж розпитати: «Що вам у нас не сподобалось, які рекомендації ви можете надати нам, щоб покращити умови праці наших співробітників?».