Здравствуйте, 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.
Здравствуйте, Hobbes, Вы писали:
H>Чёт я не понял, а где написано, что функция requestListener выполняется только для запросов HTTP GET, а для других не выполняется?
К сожалению, пока не знаю ответа на этот вопрос. Я еще не сделал ни одного HTTP-сервера на Node.js
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.
Здравствуйте, Reset, Вы писали:
R>в NodeJS асинхронщина изначально закладывалась как обязательная возможность. В результате она есть везде (сеть, диск, драйвера баз данных) в обязательном виде, а не опциональная возможность, которая в половине библиотек не реализована.
Это интересно. А как там с многопоточностью, в движке ноды? Как разграничивается доступ к общему ресурсу из нескольких потоков?
Здравствуйте, varenikAA, Вы писали:
AA>Тогда это бы был не хелоуворд. Код рассчитан на новичка — запустил и тут же в браузере увидел результат. AA>А что увидит новичок, если в примере будет "этот ваш" ПАТ или ОПШИНС?
Как минимум должно быть где-то указано, что обработчик действителен только для метода GET. Фреймворк по умолчанию, незаметно для новичка, должен предусмотреть возврат 405 Method Not Allowed, если обработчик не определён.
Здравствуйте, Hobbes, Вы писали:
H>Здравствуйте, Reset, Вы писали:
R>>в NodeJS асинхронщина изначально закладывалась как обязательная возможность. В результате она есть везде (сеть, диск, драйвера баз данных) в обязательном виде, а не опциональная возможность, которая в половине библиотек не реализована.
H>Это интересно. А как там с многопоточностью, в движке ноды? Как разграничивается доступ к общему ресурсу из нескольких потоков?
Многопоточность есть, но не сильно нужна. Потому что есть асинхронность и в одном потоке вполне можно много чего делать.
Если использовать многопоточность, то у потоков нет общих ресурсов. Взаимодействие через сообщения.
Здравствуйте, Reset, Вы писали:
R>Бустовые корутины — они stackFull. Это хрень полная по сравнению со stackLess из C++20. Бустовые годятся только для legacy, потому что stackless по всем параметрам лучше.
Здравствуйте, Hobbes, Вы писали:
H>Это интересно. А как там с многопоточностью, в движке ноды? Как разграничивается доступ к общему ресурсу из нескольких потоков?
Он однопоточных и асинхронный. Доступ по идее будет сериализуемым.