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

S>Верно, первый, "старый" подход рулит. Браузеру даже никакого кода исполнять не надо. Тупо рендерить хтмл+цсс.

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

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

S>Верно, первый, "старый" подход рулит. Браузеру даже никакого кода исполнять не надо. Тупо рендерить хтмл+цсс.

Думаю, ты слишком категоричен.
Тупой рендеринг, должен я заметить, не самая простая задача. К тому же энергоемкий. Что имеет значение на мобильных устройствах.
В старые добрые времена разработчики сайтов строго следили, чтобы размер страниц не превышал определенного лимита. Один мой приятель всегда старался уложиться в 30 К. Сегодня такого ограничения нет. Но мобильный Интернет пока еще безлимитный не у всех. И шансов исчерпать лимиты при полной перезагрузке страниц довольно много.

С другой стороны клиентские скрипты — дело тонкое. В прошлом прокете соседи — web-разработчики, говорили, что скриптом браузер положить — как два байта переслать. Браузер просто перестает реагировать на любые раздражители. Деталей я не помню. В вебе не так, чтобы совсем гуманитарий, но теоретик.

Я тоже был бы сторонником первого подхода. Мне иногда приходится забирать с некоторых сайтов определенные страницы и доставать из них данные. И бывает так, что если просто выдать запрос, то в ответ приезжает куча клиентских скриптов. Приходится тогда WebBrowser задействовать, чтобы он их отработал. А с ним мне тоже не все ясно. ТО есть оно раюотает, но есть вопросы. Говорю же — теорерик я в вебе.

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

P>Думаю, ты слишком категоричен.
P>Тупой рендеринг, должен я заметить, не самая простая задача. К тому же энергоемкий. Что имеет значение на мобильных устройствах.
P>В старые добрые времена разработчики сайтов строго следили, чтобы размер страниц не превышал определенного лимита. Один мой приятель всегда старался уложиться в 30 К. Сегодня такого ограничения нет. Но мобильный Интернет пока еще безлимитный не у всех. И шансов исчерпать лимиты при полной перезагрузке страниц довольно много.

Дело даже не в безлимитности мобильного интернета, просто пользователь может находиться в зоне неустойчивого покрытия с низкой скоростью доступа (на даче, в горах, в метро, да мало ли где).

P>С другой стороны клиентские скрипты — дело тонкое. В прошлом прокете соседи — web-разработчики, говорили, что скриптом браузер положить — как два байта переслать. Браузер просто перестает реагировать на любые раздражители. Деталей я не помню. В вебе не так, чтобы совсем гуманитарий, но теоретик.

Я даже видел такие сайты. Правда, было это несколько лет назад, адреса сайтов не помню.

P>Я тоже был бы сторонником первого подхода. Мне иногда приходится забирать с некоторых сайтов определенные страницы и доставать из них данные. И бывает так, что если просто выдать запрос, то в ответ приезжает куча клиентских скриптов. Приходится тогда WebBrowser задействовать, чтобы он их отработал. А с ним мне тоже не все ясно. ТО есть оно раюотает, но есть вопросы. Говорю же — теорерик я в вебе.

Гугловский puppeteer для Node.js рулит. Но это только на мой дилетантский взгляд, поскольку есть еще Selenium.

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

S>>Верно, первый, "старый" подход рулит. Браузеру даже никакого кода исполнять не надо. Тупо рендерить хтмл+цсс.
P>Тупой рендеринг, должен я заметить, не самая простая задача. К тому же энергоемкий. Что имеет значение на мобильных устройствах.
И поэтому его надо заменить на рендеринг+скрипты, да.

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

S>И поэтому его надо заменить на рендеринг+скрипты, да.

Одно другому не мешает. Надо ли говорить, что дешевле обновить часть веб-страницы, чем всю веб-страницу? Я-то думал, крутые спецы лучше меня знают об этом.

AN>>Что в нём прорывного?

L>Event loop?

L>https://en.wikipedia.org/wiki/Node.js#Technical_details

А что прорывного в Event Loop? Идее Event Loop наверное лет 70 скоро будет. А в случае node.js это еще достаточно ограниченная реализация, недоступная из клиентского кода. То есть I/O нода еще худо-бедно передаст в асинхронные потоки (тоже ограниченное количество), а все остальное будет болтаться в одном потоке.

L>

Node.js operates on a single-thread event loop, using non-blocking I/O calls, allowing it to support tens of thousands of concurrent connections

Они смогли «десятки тысяч соединений» хорошо, если лет пять тому назад. В 2012-м, например, 10k был для них недостижимой мечтой: https://github.com/ericmoritz/wsdemo/blob/results-v1/results.md

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

M>А что прорывного в Event Loop? Идее Event Loop наверное лет 70 скоро будет. А в случае node.js это еще достаточно ограниченная реализация, недоступная из клиентского кода. То есть I/O нода еще худо-бедно передаст в асинхронные потоки (тоже ограниченное количество), а все остальное будет болтаться в одном потоке.
M>Они смогли «десятки тысяч соединений» хорошо, если лет пять тому назад. В 2012-м, например, 10k был для них недостижимой мечтой: https://github.com/ericmoritz/wsdemo/blob/results-v1/results.md

А какие были альтернативы на момент выходы Node.js? И почему тогда серверные решения на базе Node.js стали популярными? (Извиняюсь, если задаю бестолковые вопросы. Информацию в основном черпаю из видеолекций.)

L>А какие были альтернативы на момент выходы Node.js?

Абсолютно все остальное: от C# и Java до Erlang'а, Питона и даже PHP.

L>И почему тогда серверные решения на базе Node.js стали популярными? (Извиняюсь, если задаю бестолковые вопросы. Информацию в основном черпаю из видеолекций.)

Потому что «теперь фронтенд и бэкенд можно писать на одном и том же языке». Нода взлетела на популярности среди фронтендщиков в первую очередь, мне кажется. Ну и, справедливости ради, их базовый принцип «пиши код, жди коллбэки» действительно очень простой. А то, что он выливается в ужасную кашу — так это уже потом, когда народ уже инвестировал силы и деньги в развитие проекта с использованием ноды

Ну и да, достаточно аггресивный и нечестный маркетинг тоже присутсвовал. Они в этом с MongoDB, кстати, схожи.

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

S>>И поэтому его надо заменить на рендеринг+скрипты, да.
L>Одно другому не мешает. Надо ли говорить, что дешевле обновить часть веб-страницы, чем всю веб-страницу? Я-то думал, крутые спецы лучше меня знают об этом.
Это можно сделать и без ноды. Скрипт буквально в десяток строк. К тому же будет ли это дешевле — вопрос спорный.

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

L>>Насколько я понимаю, Node.js в свое время был технологическим прорывом в серверных технологиях.

AN>Что в нём прорывного?

Node.js позволил изменить структуру разработки веб приложений.

1 зоны ответственности между фронтами и бакендами

Типичная разработка с .Net или Java бакендом — фронты нихрена не понимают в бакенде, бакенды думают, что понимают во фронте. бОльшая часть JS-чудовищ написана теми самыми бакенд-девелоперами. Эти товарищи могут изобрести и менеджер пакетов, и формат пакетов, и даже свой репозиторий и тд и тд.

С ноджээсом получилось выделить промежуточный слой, АПИ, за который отвечают и те и другие. Особых знаний не требуется, кроме хттп — надо представлять HTTP протокол. Соответсвенно, обязанности фронтов это от верстки до этого АПИ, обязанности бакендов от этого АПИ до стораджа. АПИ — общий.

Более того, польза от бакендов на фронте, фронтов на беке стала гораздо больше — проще разгребать мелочевку, которой пруд пруди.

2 изоморфные приложений

1. фронт — жээс
2. бек — жээс
3. апи — жээс
4. инфраструктура, автоматизация, билды — жээс
5. тесты — жээс
6. нагрузочные — жээс
7. QA тоже используют жээс

Соответсвенно, проще работать с командой. Чем меньше требуется всяких особо хитрых баззвордов, тем проще.

AN>Что в нём прорывного?

Весь код асинхронный был с самого начала. Затем сделали async/await и избавились от лесенок callback'ов.

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

L>Оказывается, сделать простейший HTTP-сервер на Node.js не сложнее, чем на Flask (который считается простым).

Угу. А теперь сделай HTTP-сервер на Node.js, который получает запросы не из TCP-порта, а из условного COM-порта. При этом предположим, что поддержка самого COM-порта в виде объекта, из которого можно читать и писать, у тебя уже есть. Осталось только склеить ее с HTTP-сервером.

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

L>Оказывается, сделать простейший HTTP-сервер на Node.js не сложнее, чем на Flask (который считается простым).

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>

L>P.S. Господа смайликующие, вас не затруднит пояснить, что тут смешного?

Это не смешно, а даже как-то обидно, вот вам пример еще более крутой(т.к. зависимости подтянутся автоматом, в nodejs сначала надо установить руками пакет):

#!/usr/bin/env dub
/+ dub.sdl:
dependency "vibe-d" version="~>0.8.0"
+/
void main()
{
    import vibe.d;
    listenHTTP(":8080", (req, res) {
        res.writeBody("Hello, World: " ~ req.path);
    });
    runApplication();
}

Да еще и отношение используемой памяти будет космическим.
Но, так то да, прелесть js в том, что не нода, а в том что это слаботипизрованный лисп с синтаксом java(си).

Pzz>Угу. А теперь сделай HTTP-сервер на Node.js, который получает запросы не из TCP-порта, а из условного COM-порта. При этом предположим, что поддержка самого COM-порта в виде объекта, из которого можно читать и писать, у тебя уже есть. Осталось только склеить ее с HTTP-сервером.

К сожалению, у меня пока недостаточно опыта для того, чтобы сделать это, какая бы технология при этом ни использовалась. Пока что весь мой опыт с Node.js сводится к созданию одного простенького приложения, притом даже не HTTP-сервера. COM-портов там и близко не было.

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

AA>Это не смешно, а даже как-то обидно, вот вам пример еще более крутой(т.к. зависимости подтянутся автоматом, в nodejs сначала надо установить руками пакет):
[skip]
AA>Да еще и отношение используемой памяти будет космическим.
AA>Но, так то да, прелесть js в том, что не нода, а в том что это слаботипизрованный лисп с синтаксом java(си).

Вспомнил про еще один нишевый ЯП, Forth. Оказывается, на нем тоже можно сделать HTTP-сервер:

https://github.com/Payphone/F-HTTP/blob/master/http.fs

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

I>С ноджээсом получилось выделить промежуточный слой, АПИ, за который отвечают и те и другие. Особых знаний не требуется, кроме хттп — надо представлять HTTP протокол. Соответсвенно, обязанности фронтов это от верстки до этого АПИ, обязанности бакендов от этого АПИ до стораджа. АПИ — общий.

Как API с языком связан? В любом случае, когда в системе есть несколько взаимодействующих частей, нужно сначала подумать о протоколе и форматах данных для взаимодействия и о разделении зон ответственности. Тут полезен будет подход API first. Можно для описания API через HTTP использовать инструменты типа swagger или RAML.

L>Вспомнил про еще один нишевый ЯП, Forth. Оказывается, на нем тоже можно сделать HTTP-сервер:

HTTP-сервер можно сделать на любом языке с I/O.

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

L>>Оказывается, сделать простейший HTTP-сервер на Node.js не сложнее, чем на Flask (который считается простым).

scf>Я больше скажу — nodejs для скриптописания ничем не хуже питона, может даже лучше.

Питон незаслуженно обласкан, на деле говно намного хуже js. Это если на всю экосистему смотреть вцелом (c pip/npm, тулами сборки, библиотекамии тд). Да и на уровне языва у питона достаточно проблем.

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

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

M>>А что прорывного в Event Loop? Идее Event Loop наверное лет 70 скоро будет. А в случае node.js это еще достаточно ограниченная реализация, недоступная из клиентского кода. То есть I/O нода еще худо-бедно передаст в асинхронные потоки (тоже ограниченное количество), а все остальное будет болтаться в одном потоке.
M>>Они смогли «десятки тысяч соединений» хорошо, если лет пять тому назад. В 2012-м, например, 10k был для них недостижимой мечтой: https://github.com/ericmoritz/wsdemo/blob/results-v1/results.md

L>А какие были альтернативы на момент выходы Node.js? И почему тогда серверные решения на базе Node.js стали популярными? (Извиняюсь, если задаю бестолковые вопросы. Информацию в основном черпаю из видеолекций.)

Альтернативные инструменты для создания сервера с event loop?

Их много. Node.JS использует библиотеку libuv, написанную на C. У этой библиотеки есть обёртки на других языках.

Похожие библиотеки — libevent, libev. Тоже написаны на C и имеющие обёртки на других языках.
Ещё есть NIO в Java. В C# тоже вроде имеется что-то похожее.

Задача и инструменты для её решения появились задолго до появления Node.JS.
Популярность Node.JS, видимо, связана с тем, что удобно, когда в команде все знают один язык.

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

L>>Оказывается, сделать простейший HTTP-сервер на Node.js не сложнее, чем на Flask (который считается простым).

Pzz>Угу. А теперь сделай HTTP-сервер на Node.js, который получает запросы не из TCP-порта, а из условного COM-порта. При этом предположим, что поддержка самого COM-порта в виде объекта, из которого можно читать и писать, у тебя уже есть. Осталось только склеить ее с HTTP-сервером.

Можно и рельсу бензопилой пробовать пилить...