Дуже гарна стаття! Дякую.

Карл Поппер казав, що кожен повинен бути філософом, а я кажу, що потрібно організувати таку команду, щоб кожен став лідером і був ним.

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

Я застосував іронію Сократа для того, щоб висвітлити деякі нюанси.

І ще, проміси абсолютно не годяться в функціональному програмуванні, бо вони мутабельні.
Їх не варто відносити до кілер фічей JavaScript.

І проміси можна було б реалізувати самому, використовуючи ООП патерн, та queueMicrotask.

Захотілося піци, але є декілька питань)

Ви пишете, що JavaScript однопоточний, а потім пишете про колбеки, проміси, асінк/авейт. Вони роблять JavaScript не однопоточним?

await блокує потік?

Проміси виконуються перед, між, чи після звичайного коду?

Для чого мені проміси, якщо є шаблон Monadic chaining?

Actor model, чи то патерн ООП, чи системне рішення у вигляді процесів, дозволяє обробляти асинхронні операції без callback hell, промісів та async/await.
Значить можна без промісів обійтися?

Можна додаткову статтю написати про це)

Захотілося піци, але є декілька питань)

Ви пишете, що JavaScript однопоточний, а потім пишете про колбеки, проміси, асінк/авейт. Вони роблять JavaScript не однопоточним?

await блокує потік?

Проміси виконуються перед, між, чи після звичайного коду?

Для чого мені проміси, якщо є шаблон Monadic chaining?

Actor model, чи то патерн ООП, чи системне рішення у вигляді процесів, дозволяє обробляти асинхронні операції без callback hell, промісів та async/await.
Значить можна без промісів обійтися?

Можна додаткову статтю написати про це)

Нє, не редагувалася. Сам хотів додати в дужках, що SPOF (Single point of failure), а RISK (Reduced instruction set computer
CPU). Ось ці всі трюки з load balancer, supervisor, watchdog, backup system, clusters, якраз для усунення SPOF. В ідеалі у вас має відмовити мінімум дві «точки» щоб щось перестало цілком працювати, а не якийсь один компонент (точка).

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

Ще варто згадати Design by Contract та мову Ada/Spark, які під військовим стандартом MIL-STD-1815.
І більше наголосити на відсутності динамічних масивів, які можуть вести до меморі ліків в критичних системах.

Причому такі мови як Ada/Spark та Elixir й Haskell пропонують різні стилі написання надійного коду. Я проти Design by Contract та підходу до типізації, який пропонується мовою Ada. Але воно працює.

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

:)

На щастя в багатьох випадках є.
Наприклад, код рев’ю, покриття автоматичними тестами, Blue-green deployment.

До речі, Elixir та віртуальна машина BEAM досягли дуже високого рівня відмовостійкості.

HTTPS гарантує, що дані, які ви отримали, прийшли саме з того доменного імені на яке ви звертаєтеся, принаймні, що відповідач надав відповідний сертифікат.

Тобто, він гарантує, що ви підключаєтесь до справжнього сайту, тому й захищає від Man in the middle attack.

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

А щодо цього:

Мова JavaScript стандартизована як ECMAScript, стандартом ECMA-262.

Воно сказано абсолютно коректно. Якщо ви любити специфікації, тоді прочитайте перші сторінки специфікації ECMA-262.

На практиці ECMA-262 та ECMAScript утотожнюють часто (зокрема Д.Фленеган), але формально це не точно.

Гарно сказано!

Точно

Дякую!

Він пише в книзі, що строга типізація, на його практиці, давала малу перевагу і зазвичай не рятувала від помилок, забирала час на те, щоб «гратися» з типами. А слабка типізація, навпаки, дала йому гнучкість і швидкість.
Гарне код рев’ю та тестування в багатьох випадках знімає необхідність в статичній та строгій типізації. На практиці я бачив код написаний на мові зі статичною типізацією, але при цьому не покритий юніт тестами.
Крім того, бачив часто хаки такі як слово «as», «any», «ts-ignore». Навіщо тоді така строга типізація?!!!

Строга і статична типізація при цьому мають своє місце як на практиці та й в теорії.

Теоретично весь код типізований, питання лише чи ці типи явно вказані.

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

Це помилка

Я зрозумів) Стаття супер. До речі я таки знайшов статтю як use працює під капотом і що це за звір. Виявляється це аналог await для клієнтський компонентів. Для серверних компонентів використовуємо async/await, а для клієнтський use, бо вони повинні бути синхронними. use розгортає значення проміса, при цьому наш компонент синхронний. Ось стаття де розказується хак під назвою use)
Кого мучив цей хук, може глянути як він працює під капотом.
github.com/...​s-support-for-promises.md

Виявляється, що хуки можна використовувати в if, наприклад новий хук «use» можна використовувати замість useContext. Також use можна в if обгортати. Якими ще трюками Реакт нас здивує?! Не думав що прийде час коли React змусе мене в сторону Angular дивитися, або WebComponents. На жаль в офіційній документації React дуже мало описано принципів реалізації.