Крупные компании, использующие Node.js

Original author: TechMagic
  • Translation


Node.js — это серверная среда выполнения JavaScript, исполняющая код вне браузера. Эта технология идеально подходит для многих веб-сайтов, специализирующихся на стриминге, играх, тайм-трекерах, приложениях соцсетей и т.п. Она обеспечивает масштабируемое и быстрое решение для приложений реального времени.

Она написана на самом популярном в мире языке программирования JavaScript, поэтому открывает новые возможности для многих бизнесов. Неудивительно, что она стала высокоактуальной технологией, выбранной многими компаниями, в том числе такими крупными, как Netflix и PayPal. Какие компании используют технологию Node.js и какие выгоды она им даёт? Об этом мы расскажем в статье.

Действительно ли Node.js меняет рынок?


Согласно данным Stack Overflow, Node.js — абсолютный лидер в мире технологий, занимающий 50,4% рынка. Почему же он стал столь популярным?

Согласно последнему отчёту Node.js, эта технология оказывает на бизнес значительное влияние: она обеспечивает рост продуктивности разработчиков на 68%, на 48% повышает производительность приложений, и на 13% — качество обслуживания клиентов. Более того, похоже, что эти значения со временем растут:

image

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

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

Десять известных компаний, использующих Node.js для бэкенда


Учитывая длинный список преимуществ применения Node.js, легко поверить, что среди крупнейших компаний, использующих эту технологию, есть такие как НАСА, Uber и Twitter. Кто пользуется Node.js, почему они решили перейти на Node.js и чем это для них обернулось?

Netflix


Netflix — крупнейший поставщик потокового контента и видео с 93 миллионами пользователей по всему миру. Его путь к современному успеху начался в 2015 году, когда используемая в качестве бэкенд-технологии Java больше не могла справляться с такой быстрорастущей базой пользователей. Бэкенд-разработка не поспевала за фронтендом, что влекло за собой увеличение времени загрузки. Невозможно было реализовать настраиваемый дизайн UI, что снижало качество обслуживания клиентов. Кроме того, на сборку Java тратилось слишком много времени, поэтому процессы разработки и развёртывания были неэффективно медленными.

Преимущества, полученные Netflix:

  • После перехода на технологию Node.js время запуска снизилось на 70%. Раньше загрузка интерфейса Netflix занимала до десяти секунд, а теперь — всего секунду;
  • Node.js упростил интеграцию микросервисов и разбиение огромного блока информации на подробный интерфейс;
  • Переход от бэкенда к фронтенду был значительно ускорен, поскольку среда Node.js основана на JavaScript.

НАСА


НАСА — одна из самых известных в мире организаций. НАСА решила перейти на Node.js после инцидента, едва не повлёкшего фатальные последствия. Причиной инцидента стало долгое время доступа из-за неэффективного хранения данных между несколькими точками. Разработчики НАСА посчитали, что важно переместить данные в облачную базу данных для снижения времени доступа. Кроме того, большинство приложений НАСА было написано на JavaScript.

Преимущества для НАСА:

  • Время доступа снизилось на 300%, что позволило пользователям получать информацию за секунды, а не за часы;
  • НАСА успешно перенесла старые базы данных в облако и обеспечила доступ к ним через API;
  • Node.js сократил процесс работы с базами данных с 28 шагов всего до семи, что значительно упростило научные исследования.

Trello


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

Основные преимущества для Trello:

  • Node.js предоставил возможность создания чрезвычайно облегчённого одностраничного приложения;
  • Благодаря Node.js Trello может обрабатывать обновления с нулевыми задержками;
  • Архитектура Node.js позволила сократить затраты на разработку и прототипирование.

Переход компании PayPal на Node.js


Система PayPal, имеющая более 200 миллионов активных аккаунтов, является мировым лидером отрасли онлайн-платежей и переводов. В 2013 году компания столкнулась со сложностями, вызванными Java, которые плохо сочетались с фронтенд-разработкой. Java обеспечивала длительное время разработки, а также низкую производительность, поэтому PayPal стала одной из компаний, использующих Node.js.

Полученные PayPal результаты:

  • Меньшая по размерам команда разработчиков создала приложение Node.js за более короткое время;
  • Снизилось время отклика, что привело к уменьшению времени загрузки на 35%;
  • После внедрения технологии Node.js количество пользовательских запросов в секунду удвоилось.

LinkedIn


Ещё одна компания, использующая Node.js — это LinkedIn, крупнейшая социальная платформа для бизнеса и трудоустройства. Её популярность продолжает расти, а база составляет 467 миллионов пользователей из более чем 200 стран. После перехода с Ruby on Rails на Node.js компания создала приложение, работающее в десять раз быстрее старой версии. Решение было принято из-за синхронизации приложения на Ruby, которая приводила к повышению времени загрузки, особенно при увеличении объёма трафика.

Полученные LinkedIn преимущества:

  • Вся архитектура LinkedIn создавалась на JavaScript, что упростило обработку клиент-серверных взаимодействий;
  • Количество серверов сократили с тридцати до трёх, что удвоило пропускную способность по трафику.

Опыт Uber с Node.js


Uber — ещё одна активно развивающаяся компания, каждые полгода расширяющая пользовательскую базу и работающая в 68 странах. Из-за постоянно растущего количества подключений Uber пришлось создавать архитектуру реального времени. Кроме того, компания проводила сложный анализ хранящихся на платформе данных, для которого требовалась бесперебойная производительность сервисов. Именно поэтому теперь Uber стала одной из тех компаний, которые используют Node.js в продакшене.

Полученные Uber выгоды:

  • Node.js позволил Uber намного быстрее обрабатывать огромный объём данных и многочисленные запросы пользователей;
  • Благодаря технологии Node.js компания Uber способна ежедневно обслуживать 14 миллионов поездок;
  • Uber повысила связность системы и снизила затраты на управление, создав более 600 конечных точек без сохранения состояния.

Переход на Node.js — пример Twitter


Более 80% владельцев аккаунтов Twitter получают к ним доступ через смартфон, поэтому компания приняла решение о создании Twitter Lite — приложения с минимальными функциями, способного работать даже при плохом Интернет-соединении. Кроме того, веб-сайтная версия Twitter не была оптимизирована под плохие условия соединения. Всё это привело к тому, что Twitter стала одной из компаний, использующих Node.js.

Преимущества для Twitter:

  • Twitter Lite занимает мало места — от 1% до 3% памяти телефона, что удобно для пользователей мобильных устройств;
  • Приложение работает даже с подключениями 3G и 2G;
  • Затраты на поддержку Twitter Lite значительно ниже, чем у Twitter Desktop.

eBay


Ещё одним бизнесом, использующим Node.js, является eBay. Имеющий 183 миллионов пользователей eBay — это крупнейшая торговая площадка, предоставляющая услуги онлайн-продаж C2C и B2C. Раньше приложение eBay работало на Java, что приводило к долгой загрузке и низкой производительности. Так как eBay — это платформа с огромным объёмом трафика, ей требовалась технология, которая бы ускорила разработку, чтобы она поспевала за изменениями во фронтенде.

Выгода для eBay:

  • eBay создала при помощи Node.js микросервисы, которые выполняются в реальном времени и не перегружают инфраструктуру.
  • Node.js обеспечил масштабируемость, скорость и масштабируемость.

Groupon


Groupon — крупнейшая площадка, на которой представлены купоны, скидки и выгодные предложения, она имеет базу в 40 миллионов пользователей. Когда в 2019 году Groupon достиг отметки в 200 миллионов скачиваний, то столкнулся с проблемами масштабируемости. Именно тогда компания обратила внимание на Node.js и провела крупнейшее в мире развёртывание продукта на Node.js.

Преимущества, полученные Groupon:

  • Развёртывание Node.js обеспечило высокую масштабируемость, что позволило реализовать бесперебойную работу 3400 бэкенд-сервисов;
  • Скорость загрузки удвоилась;
  • Node.js упростил и ускорил миграцию на другую платформу.

Medium


Medium — это известная платформа для онлайн-публикаций с 85 миллионами пользователей, использующая Node.js. Достигнув в 2016 году планки в 7,5 миллионов постов, команда Medium ощутила потребность в управлении big data без превышения нагрузки на сервера. Кроме того, компании нужно было соответствовать постоянно растущим требованиям текстовых редакторов к публикации постов.

Преимущества для Medium:

  • Даже страницы с большими изображениями и объёмным контентом грузятся за 2,7 секунды.
  • Node.js повысил качество обслуживания пользователей и ускорил время развёртывания.

TechMagic


TechMagic — это компания, специализирующаяся в разработке ПО. Мы создаём приложения с нуля и внедряем своих специалистов в команды разработки стартапов, используем различные технологии фулл-стека, в том числе и Node.js.

Мы любим JavaScript, поэтому с радостью пользуемся Node.js для создания приложений различного уровня сложности. Кроме того, мы специалисты по архитектуре serverless, которая является наилучшим ингредиентом для платформ на основе Node.js.

Elements.cloud — это компания, помогающая другим бизнесам в визуализации и организации бизнес-процессов. Самой большой сложностью для Elements.cloud стала реализация инструментов настраиваемой привязки процессов и визуализации на фоне автоматизированной масштабируемости инфраструктуры бэкенда. TechMagic помогла Elements.cloud в создании высокомасштабируемого и экономичного приложения на основе инфраструктуры Node.js и AWS.

Заключение


Если вы всё ещё не уверены в том, что Node.js — это технология будущего, перечислю других крупных игроков, использующих её в своей работе: Google, Yahoo, Mozilla, Microsoft и многие другие. Благодаря её неограниченным возможностям всё больше компаний внедряет технологию Node.js. Однажды эта набирающая обороты технология завоюет рынок и станет лучшим фреймворком для каждой компании, от стартапов до крупных компаний. Если у вас есть задумка какого-то продукта, то подумайте над использованием Node.js в качестве его бэкенда.



На правах рекламы


Мощные виртуальные серверы с процессорами AMD EPYC для разработчиков. Частота ядра CPU до 3.4 GHz. Максимальная конфигурация позволит оторваться на полную — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe.

VDSina.ru
Серверы в Москве и Амстердаме

Comments 31

    +3
    Все используют nodejs для разработки и сборки фронта, так что можно было включить сюда почти любую компанию
      +6
      Даже страницы с большими изображениями и объёмным контентом грузятся за 2,7 секунды.

      Не очень понял, как скорость передачи статики (изображений) и контента связана с NodeJS? Они картинки с помощью NodeJS раздают? Ну и скорость загрузки страницы 2.7 секунд — это ж как-то не быстро, честно говоря.
        +1

        Только мне одному показалось странным, что среди этих историй нет ни единой, где продукт изначально был написал на Node.js и всё получилось как нельзя хорошо?

          0

          Интересно, как на загрузку интерфейса node влияет? Или на сервере собирается готовый html что-ли?!

            +4

            Если вопрос про SSR то да, нода позволяет изоморфно выполнять js-код и ряд фреймворков может компилироваться в готовый html. Асинхронные запросы за данными тоже могут выполняться на сервере, предоставляя в json-формате готовые структуры. Если бэк написан на другом языке в соседнем докере — то делать запросы к нему можно эффективней, чем с фронтенда, напрямую в его докер. Если он написан на ноде — то еще быстрей, фактически только в базу сходить. Сюда добавляется эффективное кеширование, и в итоге если раньше SPA делало 5 запросов на клиенте после обработки JS, то есть это время плюсовалось и стадия отрисовки и тем более интерактивности наступала с большой задержкой, то с подобной схемой при первом открытии страницы нужно 0 запросов и готовый html получается при первом запросе, соответственно значительное ускорение. В энтерпрайзе такая схема уже четвертый год используется, по крайней мере в тех проектах, в которых я участвовал — все метрики перфоманса действительно значительно улучшаются.


            Минус — больше серверных ресурсов уходит на рендеринг, но это вполне горизонтально масштабируется. Количество запросов в секунду у ноды тоже стало приемлемым, при необходимости, опять же, балансируется. Но для хайлоада все же лучше оставить в ноде только веб-часть, а требовательные к перфомансу сервисы писать на более низкоуровневых и многопоточных платформах.

              0

              Ну не знаю, я полагал, что интерфейс это некий шаблон, скелет, куда данные "расставляются", чтобы с ними потом что-то делать: глазеть на них, работать с ними и т.д. Нода работает на сервере, кроме как собрать html, не знаю как нода может ускорить клиентский интерфейс. А собрать html могут все северные языки и скорость примерно одинаковая

                +1

                И как же другие серверные языки могут выполнить js-код, на котором написан клиент, чтобы сформировать html? Разве что с помощью виртуальной node-среды, так это то же самое. Я сейчас говорю про SPA, а не про древнюю схему, когда на сервере хранятся html-темплейты и реплейсом заменяются какие-то части, а соответственно при переходе на новую страницу делается полный рефреш страницы либо по аяксу загружаются куски готового html и заменяются — эта схема давно устарела, у нее громадное количество недостатков.

                  –2
                  С чего это Вы взяли, что серверный язык должен выполнять js код?
                  Хоть SPA, хоть чёрт в ступе, на сервере скрипт может отдать данные например в виде json'а и на клиенте эти данные клиентский скрипт должен разместить как надо. И хоть нода, хоть asp, php, python и т.д. сделают это примерно одинаково по времени. Поэтому неуместно спорить о том, что серверный язык поможет скорее загрузить клиентский интерфейс.
                    +1

                    Похоже, вы не знакомы с концептами SPA и SSR — почитайте. На сервере делается выполнение js-кода и конвертация в html-строку со всем размещением данных, этот html отдается клиенту, и он "гидрирует" то, что получил от сервера и то, что ожидают скрипты, выполняющиеся на клиенте. Это достаточно новый концепт, но он действительно значительно ускоряет загрузку клиентского интерфейса — я описывал выше.

                      0
                      Хе-хе, так значит всё-таки отдаёт готовый html… Ну так я об этом в своём 1-м комментарии и писал "… на сервере собирается готовый html...", Вы просто невнимательно прочитали мой комментарий и сделали неправильный вывод, за уши притянув «концептами SPA и SSR».
                      А что, нода быстрее соберёт готовый html? Где-то видел статью, где пробовали измерить эту скорость, примерно везде одинаковая, php или python, уже точно не вспомню, побыстрее на apache оказался
                        +1

                        А я с вами и не спорил, читал внимательно — "Если вопрос про 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 может быть только в виртуальном окружении.

                      +1
                      Если так сделать, то многие поисковые системы (все, кроме Google, если не ошибаюсь) не будут видеть контент на вашей странице, т.к. они не могут выполнить JS, чтобы отрисовать интерфейс и выполнить http-запрос для получения json. То есть единственный вариант — это рендерить js-приложение прямо на сервере (SSR) — и выдавать поисковикам готовый html прямо с сервера.

                      Нода не быстрее соберёт готовый HTML, но, в любом случае, если ваше приложение написано на каком-нибудь React/Angular/Vue, то для получения этого HTML нужно выполнить JS. Соответственно, это делается с помощью NodeJS. И, как Дмитрий верно заметил, кроме использования NodeJS, это никак иначе не сделать. То есть API можно написать, действительно, на любом языке программирования, но для SSR придётся завозить Ноду на сервер, хочется этого или нет. И так, к сожалению, будет всегда, пока браузеры не научатся поддерживать какие-то другие языки, кроме JS.
                        0
                        Я где-то слышал, что поисковые системы не очень положительно относятся к сайтам, которые обычным пользователям и поисковикам возвращают разный контент, мол «натыкаете нам слов про котиков, мы и будем показывать это по запросам про котиков. А пользователь увидит другое, про абразивные материалы».
                        Возможно, это не правда, но звучит разумно.
                          0
                          В частности и по этой причине тоже SSR нужен. Тогда поисковик будет получать тот же html, что и пользователь. А вот без SSR краулер поисковика будет получать пустую страницу, а юзер будет видеть страницу с html, отрисованным с помощью js. Правда сейчас мода на «клоакинг» уже давно прошла, и поисковые роботы к этому нормально относятся.
                            0

                            Клоакинг, как много в этом слове… Когда поисковики еще обращали внимание на meta description и не обращали на opacity: 0; width: 0; или цепочку js-редиректов, можно было представить в поисковике сайт как угодно… Сейчас такие схемы только в даркнете работают ввиду отсутствия продуманности в краулерах сайтов. Но в лайтнете такое не работает уже лет 7.

                        +1
                        Вот тоже имею кучу непоняток.
                        Нафига нужен такой js что его надо на сервере преобразовать в html и потом отдать браузеру?
                        Выходит, что в таком виде js то и не нужен.

                        Помниться N лет назад стали кричать что зачем тратить ресурс сервера (он же денег стоит) на рендер html, типа пусть браузер на клиенте это делает. Только вот не учли что пользователи это не оценят. И пошла обратная волна, типа рендерить надо на сервере и отдавать готовый html.
                        Эммм. Просто отказаться от огорода, который нагородили и вернуться к тому, что было нельзя.
                        Потому то, что раньше делал один сервер правильно делать на двух – потому что сервер же копейки стоит.
                        Что я вообще запутался в такой дикой логике.
                          0
                          Нафига нужен такой js что его надо на сервере преобразовать в html и потом отдать браузеру?

                          Потому что речь идёт о SPA. Преимущества и недостатки подобных сайтов — отдельная тема.
                          Только вот не учли что пользователи это не оценят. И пошла обратная волна

                          Она пошла не из-за этого, а из-за того, что поисковики не научились на таких сайтах нормально контент распознавать, т.к. их краулеры плохо умеют выполнять js. Раньше вообще только гугл умел, да и то плохо.
                          Просто отказаться от огорода, который нагородили и вернуться к тому, что было нельзя

                          А вы пробовали для многостраничного сайта сделать нормально более-менее сложный фронтенд? С использованием npm, webpack и т.п. На самом деле, сомнительное удовольствие. Когда процветал многостраничный подход к разработке, тогда фронтенд был сильно другим: подключали jQuery, положив его скрипт руками в папку — и погнали писать тонны кода в виде неподдерживаемой лапши. Как обновлять? Хз. Как подключать пакеты — тоже хз. Неизвестно, что лучше.
                            0
                            Она пошла не из-за этого, а из-за того, что поисковики не научились на таких сайтах нормально контент распознавать, т.к. их краулеры плохо умеют выполнять js. Раньше вообще только гугл умел, да и то плохо.

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

                            Потому что речь идёт о SPA.

                            И вот чем же так отличается SPA от обычного сайта? Ну кроме красивого названия.

                            С использованием npm, webpack и т.п

                            Ну и зачем писать сайт вот со всем этим если это такой геморрой? Зачем придумывать сложность там, где ее нет?
                            Как тут уже написали в коментах, использование языка/технологии не гарантирует отсутствие говнокода.

                            Тут вся ветка спора началась с замечания того, что такого сделал ноде что все прям так здорово стало. Так же было сказано, что нормально написать можно на любом языке и нода в данном случае совсем не обязательна.
                              +2
                              С ваших же слов только гугль умел. Да плохо, но умел. Собственно, гугль а следом яндекс начали развивать возможность распознавания сайтов на js. И постепенно делали это лучше и лучше. Сейчас для них вообще нет такой проблемы

                              Это вы по личному опыту пришли к такому выводу или исходите из того, что говорят/пишут представители этих самых поисковых систем? Если второе, то советую проверить самостоятельно. На текущий момент не скажу, но год назад Гугл на части страниц мало того, что не видел контент почему-то (причём рандомно то видел, то нет и то выкидывал, то возвращал в выдачу), но и ранжировал SPA-сайты сильно хуже (это не только моё мнение). Яндекс так и вовсе контент на страницах не видел. Именно поэтому многие вынужденно используют, например, NextJS для реализации SSR.
                              Именно их вопли, доколе, оказались решающими.

                              Сильно сомневаюсь, учитывая, что подавляющее большинство пользователей не видит никакой разницы между SPA и MPA и знать не знают, что это.
                              И вот чем же так отличается SPA от обычного сайта? Ну кроме красивого названия.

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

                              Действительно, зачем делать обфускацию js, зачем использовать typescript, зачем устанавливать библиотеки и иметь возможность обновлять их… Наверное, для ваших задач это, действительно, не нужно.
                              использование языка/технологии не гарантирует отсутствие говнокода

                              Вообще не понял, при чём тут это. Webpack и различные js-библиотеки не гарантируют отсутствие говнокода, безусловно, они лишь упрощают разработку. Вот надо вам валидатор формы сделать на фронтенде — руками писать будете? Примеров масса. Писать всё вручную обалдеете. Нужно иметь возможность переиспользовать код и использовать различные библиотеки, как это делается в бэкенде.
                              Так же было сказано, что нормально написать можно на любом языке и нода в данном случае совсем не обязательна.

                              Если вы делаете MPA (причём у вас для фронтенда нет никакой системы сборки и т.п.), то да. Если делаете SPA, то вам, скорее всего, придётся делать SSR (потому что см. начало сообщения), и без NodeJS вы никак JS на сервере рендерить, увы, не сможете.
                                0
                                Действительно, зачем делать обфускацию js, зачем использовать typescript, зачем устанавливать библиотеки и иметь возможность обновлять их… Наверное, для ваших задач это, действительно, не нужно.

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

                                и без NodeJS вы никак JS на сервере рендерить, увы, не сможете.

                                Вот опять двадцать пять.
                                Да зачем вообще на сервере рендерить js? Что бы что?
                                Html прекрасно могут сгенерить почти любые серверные языки. Ну и нода, конечно, один из серверных. Но она одна из многих, не более.

                                  +1
                                  Вам тут неоднократно пытаются донести мысль о том, что нет нужды исполнять на сервере js код.

                                  Пытаются? Кто именно, кроме Вас?

                                  Проблема в том, что Вы просто не видите никакой разницы между SPA и MPA — отсюда и возникает наш спор. Если вы хотите сделать SPA, допустим, и при этом чтобы у вас не было проблем с поисковыми системами, то вам придётся на сервере рендерить html с помощью NodeJS (по-другому js на сервере не выполнить). Что бы что? Чтобы поисковики получали не пустую страницу с подключённым js, а готовый html с контентом. Подчеркну: речь идёт именно о SPA.

                                  Если вы делаете обычный многостраничный сайт (MPA), то, да, выплёвывать html вы можете чем угодно. Вы же, судя по всему, говорите о MPA, написанных на NodeJS. В случае с MPA, конечно, без разницы, чем генерить html — это может делать любой язык для бэкенда. Но на MPA свет клином не сошёлся, и многие современные сайты — это SPA.
                                  –1
                                  Вот надо вам валидатор формы сделать на фронтенде — руками писать будете?

                                  А вот нафига козе баян? В том плане нафига делать валидацию там, где она нафиг никому не нужна?
                                  Ни один нормальный бек, в своем уме, никогда не будет доверять тому, что прилетает с фронта.
                                  Ну а две валидации, сначала на фронте потом на беке, для чего?
                                    +1
                                    Ни один нормальный бек, в своем уме, никогда не будет доверять тому, что прилетает с фронта.

                                    Так валидация на фронте и не отменяет валидацию на бэкенде. Это нужно для юзер-френдли так сказать, чтобы на каждый чих страницу не перезагружать. Я вообще про валидацию просто пример привёл, библиотек-то навалом разных.
                  +1
                  Мне тоже кажется, что это какое-то «однобокое» сравнение. Как написали выше — именно переход с чего-то на Ноду: в этом случае у разработчиков есть мощный бекграунд понимания глубинных проблем текущей реализации. Выглядит так что можно подставить любое хайповую технологию (Rust/Go/и т.д.) и написать схожие выводы. Я ничего не имею против Ноды, мы её тоже немного используем, но пока совсем немного
                    +2
                    Согласно последнему отчёту Node.js
                    Какая компания будет писать плохое в отчёте о своём продукте?
                    рост продуктивности разработчиков на 68%
                    Каких именно? Фронтендеры перестали использовать jQuery и пересели на Vue/React/Angular, которые разворачивают свои конструкции в конечный код именно силами ноды — эти разработчики? Так если б инструментарий того же Реакта был написан на условном Ruby — Ruby точно так же ускорял создание фронта, нет? Или имеется в виду «раньше Джон делал фичи на C# три дня, а теперь шлёп-шлёп примерно то же самое за день, с перерывами на кофе»?
                    48% повышает производительность приложений
                    По сравнению с чем, простите?
                    13% — качество обслуживания клиентов
                    «Мы переписали код с языка_Х на Node и пользователям стало лучше»? Может, тут главное не «Node», а «переписали»?
                      +1
                      Можно добавить в список Adobe.
                      Я недавно поставил попробовать Adobe Fresco на планшет. С ним вдовесок установилось пара десятков программ в фоне, среди которых два NodeJS сервера.
                      PS: вытер всё нафих.
                        0

                        На самом деле всё ради упоминания TechMagic (ну, помимо баннера внизу). Потому что странно что везде по сути от третьего лица описание, а там — от первого и ссылка. Плохо нативная интеграция прошла то :)

                          +1
                          На самом популярном в мире языке

                          Самом популярном по какому рейтингу? Вот сравнение, где 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 как основной язык / ноду как основной инструмент?


                          И вообще


                          Не бывает лучшего инструмента, бывает лучший инструмент для чего-то в глазах кого-то
                            0
                            Время доступа снизилось на 300%, что позволило пользователям получать информацию за секунды, а не за часы;

                            Немного приукрашено.

                            И думаю, что почти каждая компания использует node.js — но для
                            • сборки
                            • внутренних проєктов
                            • маленьких частей (мини микросервисов :) )


                            А в статье так написано, будто весь paypal, netflix i linkedin работает на node.js (какие-то части да, но не вся система и уверен там очень много разных языков используется).
                              0
                              «Она написана на самом популярном в мире языке программирования JavaScript» — это как?
                                0

                                Если nodejs так крут что его использует сам Google то зачем ему было создавать Dart?
                                Я так и не понял что есть в nodejs такого что позволяет проектам на ней расширятся, чего нету в других языках?
                                К тому же на большую часть кодовой базы страшно смотреть.

                                Only users with full accounts can post comments. Log in, please.