Здравствуйте, Lazytech, Вы писали:

I>>Time to market. Собтсвенно дальше ты рассказываешь истории в лучшем случае пятилетней давности.

L>Многие мелкие разработчики до сих пор jQuery используют, чего уж там...

Используют, но это уже уходящий тренд. Многие вещи проще и быстрее сделать на реакте, нежели колупаться с джиквери.

Здравствуйте, Ikemefula, Вы писали:

I>Наоборот, это вы месяцами согласуете вещи, которые делаются от силы за неделю.

С чего ты взял, что мы месяцами согласуем вещи, которые делаются от силы за неделю?

I>Автономность разработчика увеличивается, если он может залезть в смежную область и это ускоряет деливери.

1) Это требует бОльшей квалификации, и, как следствие, большей оплаты труда. Особенно в мире JS, где большинство программистов пишут в стиле "200 метров джаваскрипта грузят текста 300 байт", и найти нормального спеца — это как найти вишенку в куче известной субстанции.
2) Повторюсь, если есть четкое разделение на фронт\бэк — ситуация когда бэк лезет на фронт что-то подправить, или наоборот, фронт лезет в бэк что-то доделать — это нездоровая ситуация, скорее всего — результат неумелого менеджмента.

Здравствуйте, Klikujiskaaan, Вы писали:

I>>Автономность разработчика увеличивается, если он может залезть в смежную область и это ускоряет деливери.

K>1) Это требует бОльшей квалификации, и, как следствие, большей оплаты труда. Особенно в мире JS, где большинство программистов пишут в стиле "200 метров джаваскрипта грузят текста 300 байт", и найти нормального спеца — это как найти вишенку в куче известной субстанции.

Это называется технологический расизм В свое время сиплюсники писали такое и про дотнет, и про джаву.
На самом деле разделение по квалификации происходит от класса решаемых задач, а не от языка программирования. Собтсвенно, сложных задач в жээсе полно, люди которые ими занимаются, ничем не хуже дотнетчиков и джавистов. Есть определенные вещи, куда жээс проникает медленно, типа числодробилок, но это пока.
Скажем, в жээс гораздо проще найти того, кто понимает в функциональном, реактивном программировании, нежели в джаве-дотнете вместе взятых. Просто потому, что сейчас это основной тренд.

Отсюда ясно, что если фронт умеет редакс и fetch, то прикрутить еще один роут к имеющимся не составляет никакого труда. А это примерно минимальные требования к фронту на текущий момент.

K>2) Повторюсь, если есть четкое разделение на фронт\бэк — ситуация когда бэк лезет на фронт что-то подправить, или наоборот, фронт лезет в бэк что-то доделать — это нездоровая ситуация, скорее всего — результат неумелого менеджмента.

Четкое разделение на фронт и бек это слишком примитивный подход, слишком много зависимостей и связаных с ними ожидаданий.

Здравствуйте, Ikemefula, Вы писали:

I>Используют, но это уже уходящий тренд. Многие вещи проще и быстрее сделать на реакте, нежели колупаться с джиквери.

Я как раз переделываю один код с jQuery + Bootstrap на Svelte + Sveltestrap.

Здравствуйте, Reset, Вы писали:

R>Затем сделали async/await и избавились от лесенок callback'ов.

Так это сделали везде, от питона до C++/boost.

Здравствуйте, GarryIV, Вы писали:

GIV>Да и на уровне языва у питона достаточно проблем.

Например, какие?

Здравствуйте, Lazytech, Вы писали:

L>https://nodejs.org/en/knowledge/HTTP/servers/how-to-create-a-HTTP-server/
L>

const http = require('http');

L>const requestListener = function (req, res) {
L>  res.writeHead(200);
L>  res.end('Hello, World!');
L>}

L>const server = http.createServer(requestListener);
L>server.listen(8080);

L>

Чёт я не понял, а где написано, что функция requestListener выполняется только для запросов HTTP GET, а для других не выполняется?

Здравствуйте, Hobbes, Вы писали:

H>Здравствуйте, Lazytech, Вы писали:

L>>https://nodejs.org/en/knowledge/HTTP/servers/how-to-create-a-HTTP-server/
L>>

const http = require('http');

L>>const requestListener = function (req, res) {
L>>  res.writeHead(200);
L>>  res.end('Hello, World!');
L>>}

L>>const server = http.createServer(requestListener);
L>>server.listen(8080);

L>>

H>Чёт я не понял, а где написано, что функция requestListener выполняется только для запросов HTTP GET, а для других не выполняется?

В смысле? С чего вы решили, что только гет?

Здравствуйте, Hobbes, Вы писали:

H>Чёт я не понял, а где написано, что функция requestListener выполняется только для запросов HTTP GET, а для других не выполняется?

К сожалению, пока не знаю ответа на этот вопрос. Я еще не сделал ни одного HTTP-сервера на Node.js

Здравствуйте, varenikAA, Вы писали:

AA>В смысле? С чего вы решили, что только гет?

Из смысла протокола HTTP. Довольно странное отвечать такое на PUT или OPTONS.

AA>>В смысле? С чего вы решили, что только гет?

H>Из смысла протокола HTTP. Довольно странное отвечать такое на PUT или OPTONS.

Это демонстрационный пример. Странно от него ожидать то же, что и от production.

R>>Затем сделали async/await и избавились от лесенок callback'ов.

H>Так это сделали везде, от питона до C++/boost.

Чё, и в Java тоже? Про Kotlin я в курсе.

Бустовые корутины — они stackFull. Это хрень полная по сравнению со stackLess из C++20. Бустовые годятся только для legacy, потому что stackless по всем параметрам лучше.

Асинхронные фреймворки есть почти на всем, но в NodeJS асинхронщина изначально закладывалась как обязательная возможность. В результате она есть везде (сеть, диск, драйвера баз данных) в обязательном виде, а не опциональная возможность, которая в половине библиотек не реализована.

Здравствуйте, Hobbes, Вы писали:

H>Здравствуйте, varenikAA, Вы писали:

AA>>В смысле? С чего вы решили, что только гет?

H>Из смысла протокола HTTP. Довольно странное отвечать такое на PUT или OPTONS.
Тогда это бы был не хелоуворд. Код рассчитан на новичка — запустил и тут же в браузере увидел результат.
А что увидит новичок, если в примере будет "этот ваш" ПАТ или ОПШИНС?

Здравствуйте, Lazytech, Вы писали:

I>>Используют, но это уже уходящий тренд. Многие вещи проще и быстрее сделать на реакте, нежели колупаться с джиквери.

L>Я как раз переделываю один код с jQuery + Bootstrap на Svelte + Sveltestrap.

И как Svelte ?

Здравствуйте, Reset, Вы писали:

R>в NodeJS асинхронщина изначально закладывалась как обязательная возможность. В результате она есть везде (сеть, диск, драйвера баз данных) в обязательном виде, а не опциональная возможность, которая в половине библиотек не реализована.

Это интересно. А как там с многопоточностью, в движке ноды? Как разграничивается доступ к общему ресурсу из нескольких потоков?

Здравствуйте, varenikAA, Вы писали:

AA>Тогда это бы был не хелоуворд. Код рассчитан на новичка — запустил и тут же в браузере увидел результат.
AA>А что увидит новичок, если в примере будет "этот ваш" ПАТ или ОПШИНС?

Как минимум должно быть где-то указано, что обработчик действителен только для метода GET. Фреймворк по умолчанию, незаметно для новичка, должен предусмотреть возврат 405 Method Not Allowed, если обработчик не определён.

Здравствуйте, Ikemefula, Вы писали:

I>И как Svelte ?

Намного проще, чем React (с которым я знаком только теоретически и крайне поверхностно), и, наверное, чуть проще, чем Vue.

Здравствуйте, Hobbes, Вы писали:

H>Здравствуйте, Reset, Вы писали:

R>>в NodeJS асинхронщина изначально закладывалась как обязательная возможность. В результате она есть везде (сеть, диск, драйвера баз данных) в обязательном виде, а не опциональная возможность, которая в половине библиотек не реализована.

H>Это интересно. А как там с многопоточностью, в движке ноды? Как разграничивается доступ к общему ресурсу из нескольких потоков?
Многопоточность есть, но не сильно нужна. Потому что есть асинхронность и в одном потоке вполне можно много чего делать.
Если использовать многопоточность, то у потоков нет общих ресурсов. Взаимодействие через сообщения.

Здравствуйте, Reset, Вы писали:

R>Бустовые корутины — они stackFull. Это хрень полная по сравнению со stackLess из C++20. Бустовые годятся только для legacy, потому что stackless по всем параметрам лучше.

Есть и те, и другие. https://www.boost.org/doc/libs/1_73_0/doc/html/boost_asio/overview/core/coroutine.html

Здравствуйте, Hobbes, Вы писали:

H>Это интересно. А как там с многопоточностью, в движке ноды? Как разграничивается доступ к общему ресурсу из нескольких потоков?

Он однопоточных и асинхронный. Доступ по идее будет сериализуемым.