Комментарии 31
Даже страницы с большими изображениями и объёмным контентом грузятся за 2,7 секунды.
Не очень понял, как скорость передачи статики (изображений) и контента связана с NodeJS? Они картинки с помощью NodeJS раздают? Ну и скорость загрузки страницы 2.7 секунд — это ж как-то не быстро, честно говоря.
Только мне одному показалось странным, что среди этих историй нет ни единой, где продукт изначально был написал на Node.js и всё получилось как нельзя хорошо?
Интересно, как на загрузку интерфейса node влияет? Или на сервере собирается готовый html что-ли?!
Если вопрос про SSR то да, нода позволяет изоморфно выполнять js-код и ряд фреймворков может компилироваться в готовый html. Асинхронные запросы за данными тоже могут выполняться на сервере, предоставляя в json-формате готовые структуры. Если бэк написан на другом языке в соседнем докере — то делать запросы к нему можно эффективней, чем с фронтенда, напрямую в его докер. Если он написан на ноде — то еще быстрей, фактически только в базу сходить. Сюда добавляется эффективное кеширование, и в итоге если раньше SPA делало 5 запросов на клиенте после обработки JS, то есть это время плюсовалось и стадия отрисовки и тем более интерактивности наступала с большой задержкой, то с подобной схемой при первом открытии страницы нужно 0 запросов и готовый html получается при первом запросе, соответственно значительное ускорение. В энтерпрайзе такая схема уже четвертый год используется, по крайней мере в тех проектах, в которых я участвовал — все метрики перфоманса действительно значительно улучшаются.
Минус — больше серверных ресурсов уходит на рендеринг, но это вполне горизонтально масштабируется. Количество запросов в секунду у ноды тоже стало приемлемым, при необходимости, опять же, балансируется. Но для хайлоада все же лучше оставить в ноде только веб-часть, а требовательные к перфомансу сервисы писать на более низкоуровневых и многопоточных платформах.
Ну не знаю, я полагал, что интерфейс это некий шаблон, скелет, куда данные "расставляются", чтобы с ними потом что-то делать: глазеть на них, работать с ними и т.д. Нода работает на сервере, кроме как собрать html, не знаю как нода может ускорить клиентский интерфейс. А собрать html могут все северные языки и скорость примерно одинаковая
И как же другие серверные языки могут выполнить js-код, на котором написан клиент, чтобы сформировать html? Разве что с помощью виртуальной node-среды, так это то же самое. Я сейчас говорю про SPA, а не про древнюю схему, когда на сервере хранятся html-темплейты и реплейсом заменяются какие-то части, а соответственно при переходе на новую страницу делается полный рефреш страницы либо по аяксу загружаются куски готового html и заменяются — эта схема давно устарела, у нее громадное количество недостатков.
Хоть SPA, хоть чёрт в ступе, на сервере скрипт может отдать данные например в виде json'а и на клиенте эти данные клиентский скрипт должен разместить как надо. И хоть нода, хоть asp, php, python и т.д. сделают это примерно одинаково по времени. Поэтому неуместно спорить о том, что серверный язык поможет скорее загрузить клиентский интерфейс.
Похоже, вы не знакомы с концептами SPA и SSR — почитайте. На сервере делается выполнение js-кода и конвертация в html-строку со всем размещением данных, этот html отдается клиенту, и он "гидрирует" то, что получил от сервера и то, что ожидают скрипты, выполняющиеся на клиенте. Это достаточно новый концепт, но он действительно значительно ускоряет загрузку клиентского интерфейса — я описывал выше.
А что, нода быстрее соберёт готовый html? Где-то видел статью, где пробовали измерить эту скорость, примерно везде одинаковая, php или python, уже точно не вспомню, побыстрее на apache оказался
А я с вами и не спорил, читал внимательно — "Если вопрос про SSR то да", просто описал схему работы и показал, что это действительно ускоряет метрики загрузки интерфейса. Но в случае SPA, когда интерфейс описан на js, на сервере нужна среда, которая умеет его выполнять — так что нода практически без вариантов. Чтобы было более понятно, напишу пример:
Клиентский код:
export class App extends Component {
render() {
return (
<div className={styles.app}>
123
</div>
);
}
}Серверный код:
app.get('*', (req, res) => {
Promise.resolve()
.then(() => injectAppMarkup(template))
.then((modTemplate) => injectInitialStoreData(modTemplate))
.then((modTemplate) => res.send(modTemplate))
});
export function injectInitialStoreData(str: string) {
const storeEscaped = escapeAllStrings(store);
return str.replace('<!-- INITIAL_DATA -->', JSON.stringify(storeEscaped));
}
export function injectAppMarkup(str: string) {
return str.replace(`<!-- HTML -->`, renderToString(<App />));
}В итоге получаем соответствующий странице html-код в первом запросе + объект вида window.INITIAL_DATA = { someData: 'test' };, который можно отправить в клиентский js-код и чисто гидрироваться с выданной сервером разметкой. Еще раз повторюсь, что говорю про SPA, когда один и тот же js изоморфно выполняется на клиенте и сервере, а не когда клиентский js вручную навешивает какие-то события и триггеры на шаблон, отданный бэком. В других серверных языках выполнение React.renderToString может быть только в виртуальном окружении.
Нода не быстрее соберёт готовый HTML, но, в любом случае, если ваше приложение написано на каком-нибудь React/Angular/Vue, то для получения этого HTML нужно выполнить JS. Соответственно, это делается с помощью NodeJS. И, как Дмитрий верно заметил, кроме использования NodeJS, это никак иначе не сделать. То есть API можно написать, действительно, на любом языке программирования, но для SSR придётся завозить Ноду на сервер, хочется этого или нет. И так, к сожалению, будет всегда, пока браузеры не научатся поддерживать какие-то другие языки, кроме JS.
Возможно, это не правда, но звучит разумно.
Клоакинг, как много в этом слове… Когда поисковики еще обращали внимание на meta description и не обращали на opacity: 0; width: 0; или цепочку js-редиректов, можно было представить в поисковике сайт как угодно… Сейчас такие схемы только в даркнете работают ввиду отсутствия продуманности в краулерах сайтов. Но в лайтнете такое не работает уже лет 7.
Нафига нужен такой js что его надо на сервере преобразовать в html и потом отдать браузеру?
Выходит, что в таком виде js то и не нужен.
Помниться N лет назад стали кричать что зачем тратить ресурс сервера (он же денег стоит) на рендер html, типа пусть браузер на клиенте это делает. Только вот не учли что пользователи это не оценят. И пошла обратная волна, типа рендерить надо на сервере и отдавать готовый html.
Эммм. Просто отказаться от огорода, который нагородили и вернуться к тому, что было нельзя.
Потому то, что раньше делал один сервер правильно делать на двух – потому что сервер же копейки стоит.
Что я вообще запутался в такой дикой логике.
Нафига нужен такой js что его надо на сервере преобразовать в html и потом отдать браузеру?
Потому что речь идёт о SPA. Преимущества и недостатки подобных сайтов — отдельная тема.
Только вот не учли что пользователи это не оценят. И пошла обратная волна
Она пошла не из-за этого, а из-за того, что поисковики не научились на таких сайтах нормально контент распознавать, т.к. их краулеры плохо умеют выполнять js. Раньше вообще только гугл умел, да и то плохо.
Просто отказаться от огорода, который нагородили и вернуться к тому, что было нельзя
А вы пробовали для многостраничного сайта сделать нормально более-менее сложный фронтенд? С использованием npm, webpack и т.п. На самом деле, сомнительное удовольствие. Когда процветал многостраничный подход к разработке, тогда фронтенд был сильно другим: подключали jQuery, положив его скрипт руками в папку — и погнали писать тонны кода в виде неподдерживаемой лапши. Как обновлять? Хз. Как подключать пакеты — тоже хз. Неизвестно, что лучше.
Она пошла не из-за этого, а из-за того, что поисковики не научились на таких сайтах нормально контент распознавать, т.к. их краулеры плохо умеют выполнять js. Раньше вообще только гугл умел, да и то плохо.
Не сходится. С ваших же слов только гугль умел. Да плохо, но умел. Собственно, гугль а следом яндекс начали развивать возможность распознавания сайтов на js. И постепенно делали это лучше и лучше. Сейчас для них вообще нет такой проблемы. Так за каким вдруг рендер снова перешел на сервер?
Нет, тут все таки пользователи постарались. Именно их вопли, доколе, оказались решающими.
Кстати, тут на хабре было много статей на эту тему.
Потому что речь идёт о SPA.
И вот чем же так отличается SPA от обычного сайта? Ну кроме красивого названия.
С использованием npm, webpack и т.п
Ну и зачем писать сайт вот со всем этим если это такой геморрой? Зачем придумывать сложность там, где ее нет?
Как тут уже написали в коментах, использование языка/технологии не гарантирует отсутствие говнокода.
Тут вся ветка спора началась с замечания того, что такого сделал ноде что все прям так здорово стало. Так же было сказано, что нормально написать можно на любом языке и нода в данном случае совсем не обязательна.
С ваших же слов только гугль умел. Да плохо, но умел. Собственно, гугль а следом яндекс начали развивать возможность распознавания сайтов на js. И постепенно делали это лучше и лучше. Сейчас для них вообще нет такой проблемы
Это вы по личному опыту пришли к такому выводу или исходите из того, что говорят/пишут представители этих самых поисковых систем? Если второе, то советую проверить самостоятельно. На текущий момент не скажу, но год назад Гугл на части страниц мало того, что не видел контент почему-то (причём рандомно то видел, то нет и то выкидывал, то возвращал в выдачу), но и ранжировал SPA-сайты сильно хуже (это не только моё мнение). Яндекс так и вовсе контент на страницах не видел. Именно поэтому многие вынужденно используют, например, NextJS для реализации SSR.
Именно их вопли, доколе, оказались решающими.
Сильно сомневаюсь, учитывая, что подавляющее большинство пользователей не видит никакой разницы между SPA и MPA и знать не знают, что это.
И вот чем же так отличается SPA от обычного сайта? Ну кроме красивого названия.
В SPA роутинг сделан на фронтенде, а в MPA — на сервере. То есть SPA — это по сути 1 html-страница, внутри которой всякие переходы между «страницами» делаются прямо в браузере. А так на текущий момент SPA — это и есть обычный сайт, потому что новые проекты в виде MPA никто особо не начинает.
Ну и зачем писать сайт вот со всем этим если это такой геморрой
Действительно, зачем делать обфускацию js, зачем использовать typescript, зачем устанавливать библиотеки и иметь возможность обновлять их… Наверное, для ваших задач это, действительно, не нужно.
использование языка/технологии не гарантирует отсутствие говнокода
Вообще не понял, при чём тут это. Webpack и различные js-библиотеки не гарантируют отсутствие говнокода, безусловно, они лишь упрощают разработку. Вот надо вам валидатор формы сделать на фронтенде — руками писать будете? Примеров масса. Писать всё вручную обалдеете. Нужно иметь возможность переиспользовать код и использовать различные библиотеки, как это делается в бэкенде.
Так же было сказано, что нормально написать можно на любом языке и нода в данном случае совсем не обязательна.
Если вы делаете MPA (причём у вас для фронтенда нет никакой системы сборки и т.п.), то да. Если делаете SPA, то вам, скорее всего, придётся делать SSR (потому что см. начало сообщения), и без NodeJS вы никак JS на сервере рендерить, увы, не сможете.
Действительно, зачем делать обфускацию js, зачем использовать typescript, зачем устанавливать библиотеки и иметь возможность обновлять их… Наверное, для ваших задач это, действительно, не нужно.
Ну а собственно действительно зачем? Вам тут неоднократно пытаются донести мысль о том, что нет нужды исполнять на сервере js код. Вам это говорят именно из-за того, что статья выглядит так — было все плохо, но тут пришел ноде и все стало зсь.
С ваших же слов нода выплевывает в браузер сгенереный html и в таком случае какая разница что исполняется на сервере? Пых, питон, ява или асп все они точно так же умеют в html.
А вы снова про какие-то либы js`ные и прочую фигню.
и без NodeJS вы никак JS на сервере рендерить, увы, не сможете.
Вот опять двадцать пять.
Да зачем вообще на сервере рендерить js? Что бы что?
Html прекрасно могут сгенерить почти любые серверные языки. Ну и нода, конечно, один из серверных. Но она одна из многих, не более.
Вам тут неоднократно пытаются донести мысль о том, что нет нужды исполнять на сервере js код.
Пытаются? Кто именно, кроме Вас?
Проблема в том, что Вы просто не видите никакой разницы между SPA и MPA — отсюда и возникает наш спор. Если вы хотите сделать SPA, допустим, и при этом чтобы у вас не было проблем с поисковыми системами, то вам придётся на сервере рендерить html с помощью NodeJS (по-другому js на сервере не выполнить). Что бы что? Чтобы поисковики получали не пустую страницу с подключённым js, а готовый html с контентом. Подчеркну: речь идёт именно о SPA.
Если вы делаете обычный многостраничный сайт (MPA), то, да, выплёвывать html вы можете чем угодно. Вы же, судя по всему, говорите о MPA, написанных на NodeJS. В случае с MPA, конечно, без разницы, чем генерить html — это может делать любой язык для бэкенда. Но на MPA свет клином не сошёлся, и многие современные сайты — это SPA.
Вот надо вам валидатор формы сделать на фронтенде — руками писать будете?
А вот нафига козе баян? В том плане нафига делать валидацию там, где она нафиг никому не нужна?
Ни один нормальный бек, в своем уме, никогда не будет доверять тому, что прилетает с фронта.
Ну а две валидации, сначала на фронте потом на беке, для чего?
Ни один нормальный бек, в своем уме, никогда не будет доверять тому, что прилетает с фронта.
Так валидация на фронте и не отменяет валидацию на бэкенде. Это нужно для юзер-френдли так сказать, чтобы на каждый чих страницу не перезагружать. Я вообще про валидацию просто пример привёл, библиотек-то навалом разных.
Согласно последнему отчёту Node.jsКакая компания будет писать плохое в отчёте о своём продукте?
рост продуктивности разработчиков на 68%Каких именно? Фронтендеры перестали использовать jQuery и пересели на Vue/React/Angular, которые разворачивают свои конструкции в конечный код именно силами ноды — эти разработчики? Так если б инструментарий того же Реакта был написан на условном Ruby — Ruby точно так же ускорял создание фронта, нет? Или имеется в виду «раньше Джон делал фичи на C# три дня, а теперь шлёп-шлёп примерно то же самое за день, с перерывами на кофе»?
48% повышает производительность приложенийПо сравнению с чем, простите?
13% — качество обслуживания клиентов«Мы переписали код с языка_Х на Node и пользователям стало лучше»? Может, тут главное не «Node», а «переписали»?
Я недавно поставил попробовать Adobe Fresco на планшет. С ним вдовесок установилось пара десятков программ в фоне, среди которых два NodeJS сервера.
PS: вытер всё нафих.
На самом деле всё ради упоминания TechMagic (ну, помимо баннера внизу). Потому что странно что везде по сути от третьего лица описание, а там — от первого и ссылка. Плохо нативная интеграция прошла то :)
На самом популярном в мире языке
Самом популярном по какому рейтингу? Вот сравнение, где js лидирует только во фронтенде и фуллстеке (угадайте, почему), и то, на фронте его постепенно догоняет ts.
4/5 бэк- и фронт-разрабов выберут Node.js
Судя по этой статье, доля js — не больше трети. Также, немного субьективщины — из нескольких десяткоы моих знакомых только один решил писать бэк на ноде, но и то, он был фронтендер и в итоге всё равно ушёл в джанго. Статистические ошибчная субъективщина, но всё же.
Во-первых, с этой средой выполнения JavaScript легко работать, и она обеспечивает выполнение кода на стороне сервера. Во-вторых, она обеспечивает высокую масштабируемость, а также ускоряет циклы разработки. В-третьих, это одна из лучших технологий с развитым сообществом open source.
Обеспечивает выполнение кода на стороне сервера — конечно, блин, это же бэкенд, где ж ему ещё исполняться. Высокая масштабируемость, ускорение циклов разработки — абстрактные понятия, масштабируемее, быстрее чего? Скриптов на перле и десктопов на сишнике? Одна из лучших технологий с развитым опенсорс?
for pl in google.get('top 20 programming language') :
print(pl + ' - одна из лучших технологий с развитым опенсорс')10 компаний, которые используют ноду для работы
Где 100 компаний, которые не используют?
В них переход на ноду повлёк скорость разработки и скорость работы
А какую роль в этом сыграли разбиение на микросервисы, полный реактор кода и бизнес-логики, отказ от легаси, чистка/настройка баз/серверов?
перечислю других крупных игроков, использующих её в своей работе: Google, Yahoo, Mozilla, Microsoft и многие другие.
Кто их них использует где-то кроме фронта js как основной язык / ноду как основной инструмент?
И вообще
Не бывает лучшего инструмента, бывает лучший инструмент для чего-то в глазах кого-то
Время доступа снизилось на 300%, что позволило пользователям получать информацию за секунды, а не за часы;
Немного приукрашено.
И думаю, что почти каждая компания использует node.js — но для
- сборки
- внутренних проєктов
- маленьких частей (мини микросервисов :) )
А в статье так написано, будто весь paypal, netflix i linkedin работает на node.js (какие-то части да, но не вся система и уверен там очень много разных языков используется).
Если nodejs так крут что его использует сам Google то зачем ему было создавать Dart?
Я так и не понял что есть в nodejs такого что позволяет проектам на ней расширятся, чего нету в других языках?
К тому же на большую часть кодовой базы страшно смотреть.
Крупные компании, использующие Node.js