.NET Core vs Node.js



    Цель данной статьи — не выбор лучшей из двух платформ, а поиск сильных и слабых сторон каждой из них. Обе технологии прочно зарекомендовали себя в мире веб-разработки. Каждая из них имеет своих фанатов, получивших хорошие результаты и делящиеся своими достижениями на просторах интернета. В сети имеются многочисленные отзывы о тех преимуществах, которые получили разработчики при переходе на .Net Core или Node.js. Попытаемся разобраться в этом.

    Немного контекста


    Я работаю в компании, которая занимается заказной разработкой с 2015 года, сначала мы писали на .NET, затем перешли на .NET Core и потом постепенно сменили стек на Node.JS. Основной причиной была скорость разработки.

    Общие сведения




    .Net Core

    .NET Core — фреймворк общего назначения с открытым кодом, предназначенной для создания кроссплатформенных приложений. Позволяет создавать приложения для различных операционных систем Windows, macOS и Linux. Поддерживает процессоры x64, x86, ARM32 и ARM64. Первый официальный релиз был выпущен 27 июня 2016 года.

    Node.js

    Согласно данным на официальном сайте, Node.js — это программная платформа, построенная на V8. V8 в свою очередь – разработанный Google движок JavaScript с открытым исходным кодом (написан на с++), транслирующий JavaScript в машинный код. Node.js позволяет создавать приложения на macOS, Linux, SmartOS, FreeBSD, Microsoft Windows, AIX и Android. Первый релиз был в 2009 году.

    Система обмена знаниями “Stackoverflow” опубликовала рейтинг популярности фреймворков за прошлый год на основе опроса более 90 тысяч разработчиков, результаты опроса следующие:


    Node.js более популярна согласно этому опросу. Однако, результаты могут измениться, когда будет выпущен .Net 5.0, в результате чего второе и третье место по сути объединятся, получив суммарное количество голосов, сравнимое с Node.js на текущий момент.

    Язык программирования




    Net Core

    В основном используется C# — объектно-ориентированный язык программирования, разработан Microsoft в 1998-2001 годах. Строгая типизация позволяет отлавливать ошибки на этапе компиляции, как результат получать более быстрый цикл обратной связи, и в более короткие сроки с меньшим числом ошибок разрабатывать приложения. По средствам ключевого слова “dynamic” позволяет эмулировать динамическую типизацию.

    Node.js

    JavaScript – это интерпретируемый, объектно-ориентированный язык с динамической типизацией. Так же обладает рядом особенностей присущих функциональным языкам.

    Стандартом языка JavaScript является ECMAScript. JavaScript прост в использовании, но многие ошибки приходится отлаживать во время исполнения, в отличие от C#. Для устранения этого недостатка можно воспользоваться TypeScript, представленный Microsoft в 2012 году. TypeScript является надстройкой над JavaScript, обратно совместим с JavaScript и компилируется в последний. Однако TypeScript так же не дает всю мощь строго типизированного объектно-ориентированного языка которую предлагает C#. TypeScript неразрывно связан с JavaScript, который имеет структурную типизацию, как результат может только имитировать работу с типами на подобии С#.

    Пример ошибки, которая не проявится на этапе сборки:

    interface A {
        x: number;
    }
     
    let a: A = {x: 5}
     
    let b: {x: number | string} = a; 
    b.x = "unsound";
     
    a.x.toFixed(0); // Not a function error occurs.

    Проблема в этом коде с тем, что в результате присваиваний тип у “a.x” будет строка, и ошибка будет только в рантайме.

    В заключении этой части представим рейтинг отражающий частоту запросов в Google касаемо интересующих языков:

    image

    Модули и инструменты




    Net Core

    Сообщество распространяет инструменты по средствам NuGet пакетов. На текущий момент насчитывается 205 000 пакетов. Для разработки наиболее распространены Visual Studio и Rider, которые упрощают и ускоряют создание приложений.

    Node.js

    Инструментарием является NPM, который насчитывает 1 298 879 пакетов. Официальной среды разработки не объявлено, но наиболее распространено использование Visual Studio Сode с плагинами для разработки под Node.js.
    В целом, выглядит так, что Node.js имеет более широкий выбор инструментов, альтернативных пакетов.

    Масштабируемость




    Рассмотрим только один вариант масштабируемости – горизонтальный т.е. добавление серверов для обработки увеличивающееся нагрузки.

    Net Core

    Платформа предоставляет возможность писать многопоточные приложения, поэтому задача загрузки отдельного сервера несколько проще, чем для Node.js. Для задач развертывания, масштабирование и обеспечения отказоустойчивости сервисов Microsoft выпустила “Azure Service Fabric SDK”. Можно использовать этот SDK на своих серверах, в Azure или AWS. Документация размещена тут.

    Node.js

    Одиночный инстанс использует только один поток, поэтому чтобы загрузить все ядра сервера придется воспользоваться модулем “Cluster” или внешним управлением процессами. Для масштабирования на несколько серверов понадобится балансировщик нагрузки (AWS ELB/NGINX). Так же имеются инструменты, предоставляющие возможность управления сервисами и трафиком, например, Istio.

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

    Производительность




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

    Во всех тестах ниже параметры едины и имеют такие значения: ОС – Linux, DB – Postgres, тип ORM – FULL (т.е. не микро ROM и не прямой доступ к DB).

    Одиночный запрос в БД

    В этом тесте каждый запрос извлекает одну строку из таблицы, далее эта строка сериализуется в JSON и отправляется ответ. Число конкурентных соединений от 16 до 512.



    Множественные запросы в БД

    В этом тесте каждый запрос выполняет несколько запросов в БД, при этом каждый из них извлекает множество строк. В этом тесте 512 конкурентных соединений.



    Обновление данных в БД

    Каждый запрос извлекает из БД множество строк, конвертирует их в объекты, изменяет объекты, сохраняет изменения в БД по одному. Далее сериализует обновленные объекты и отправляет их в ответе. В этом тесте 512 конкурентных соединений.



    Hello World тест

    На запрос получаем ответ в виде простого текста “Hello, World”.



    Согласно бенчмаркам, Net Core быстрее Node.js, но нужно всегда рассматривать конкретный сценарий и используемые технологии.

    Заключение


    Сводная таблица оценок по рассмотренным выше пунктам.



    Стоит еще раз отметить, что нет универсального инструмента на все случаи жизни. Если вы начинающий и хотите быстро создавать приложения, имеющие пользовательский интерфейс и серверный код, то Node.js будет отличным выбором. Достаточно разобраться с JavaScript, и он может стать единым языком для серверной и клиентской части.

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

    Only registered users can participate in poll. Log in, please.

    А какую платформу предпочитаешь ты, %username%?

    • 19.6%Node.js62
    • 80.4%.NET255

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 43

      +8
      В целом, выглядит так, что Node.js имеет более широкий выбор инструментов, альтернативных пакетов.

      А как вы пришли к этому выводу?

        +6
        Поддерживаю вопрос.

        У шарпа прекрасный инструментарий. Дебаггер шарпа на голову выше чем дебаг-возможности в Nodejs, например, а это тоже относится к инструментам.

        Ну и не забываем, что npm создаёт папку с двадцатью тысячами файлов (без шуток) для Hello-world проекта. При этом NuGet краток и лаконичен. Сборка в контейнере, опять же, на .NET идёт единицы секунд, а на npm единицы минут.
          –5

          У шарпа есть свой дебаггер? Или вы про что-то конкретное типа Visual Studio?

          +2

          Если клепаете Hello! World пачками, то возможно инструментарий VS Code лучше, чем тяжелые инструменты корпоративной разработки. Но если пишете большие кровавые корпоративные приложения, какие аналоги NDepend, или Resharper Architecture Diagramm и других инструментов этого вида есть в мире node.js? Я без иронии, в моем опыте из-за отсутствия инструментов подобного класса приходится отказывать от node.js по мере роста сложности приложений.

            0

            … вы не по адресу с этим вопросом.

              0

              спросоня промахнулся, вопрос адресовался автору статьи ))

              0

              Принципиально отличаются IDE от JetBrains для C# и TypeScript? А Visual Studio про TypeScript что-то знает?

            +20
            Инструментарием является NPM, который насчитывает 1 298 879 пакетов.

            Напоминаю что разработчики на node абсолютно серьезно выносят вот такие вещи в отдельные модули:
            declare function isPromise<T, S>(obj: Promise<T> | S): obj is Promise<T>;
            export default isPromise;


            У этого безобразия 9,737,367 скачиваний за неделю.
              +1
              Да. Или всякие там isArray :) В целом количество пакетов не показатель, разумеется.
            • UFO just landed and posted this here
                0
                Очень правильное рассуждение. Логика перехода на Node действительно непонятна. Обычно переходят в связи с унификацией кода для фронта и бэка и недостатком квалифицированных бэк-разработчиков C#/Java/GoLang в предприятии
                –2
                сначала мы писали на .NET, затем перешли на .NET Core и потом постепенно сменили стек на Node.JS. Основной причиной была скорость разработки.

                Да, тоже самое ощущал и всегда пишу об этом в разговорах .Net vs Node.JS: удобство и скорость разработки СИЛЬНО возросли. Правда говорят, и вы это также пишите, для больших проектов C# всё же лучше. Я использовал ноду только на средних и маленьких.

                • UFO just landed and posted this here
                    –2

                    В комментах где-то писал и статья здесь есть: писал бота на MS Bot Framework сначала на C#, потом на ноде. Так вот в ноде кода и сущностей в несколько раз меньше и логика много проще получилась.


                    Я сразу делал на 8-м, 10-м, 12-м ноде, с нуля уже с async/await, где старого кода не было.


                    Если что у меня опыта в C# — 5+ лет, а в ноде на тот момент не было вообще.

                    • UFO just landed and posted this here
                    0
                    Присоединюсь, тоже не раз слышал что скорость разработки увеличивается, а почему? Есть уже какой-то готовый инфраструктурный слой? Или просто много времени уходит чио бы разобраться в тонкостях asp net?
                      0

                      Есть и готовые слои, и не надо писать типы и компилировать, если речь именно о js

                    +15

                    Пишешь такой, пишешь на шарпе больше 15 лет, вроде особо не страдаешь. И тут такой эффективный менеджер: оказывается ваши инструментарии не столь удобны и эффективны как в node.js. С завтрашнего дня все новые разделы/проекты пишем на ноде, чтобы ваша производительность выросла в 100500 раз.
                    Я б, мягко говоря, удивился… и я к тому, что если что-то не едет, то надо не кровати двигать.

                      +2

                      У меня только 8 лет на шарпе, и я как раз столкнулся с подобной ситуацией, только вместо node.js (который мне как раз знаком), предлагается Go. Не знаю как реагировать. Есть только подозрение, что цели этой затеи работодателя противоположны моим, как разработчика.

                        +2
                        безусловно переход ради перехода — так себе история для исполнителя. Но Go — вполне себе интересная, хоть и более нишевая штука. И прежде всего надо иметь ответы на ряд вопросов потипу: какую конкретно из ваших проблем Go решает лучше, сколько и нужно ли переписывать легаси с шарпа. Кто еще в команде знает Go. Если ответы на эти вопросы есть и положительны, но вопрос в отсутствии опыта только у вас — ну семеро одного не ждут, ничего не поделаешь, подтянетесь.
                        Однако, если руководство в принципе не ставило эти вопросы в рассмотрение и не спрашивала про опыт команды в Go, а голосом разума вы их не переубедили… ну что ж ¯\_(ツ)_/¯ значит их цели выходят за рамки практической целесообразности.

                        Лично я считаю, что вес опыта (ну не годовалого студента, очевидно) человека в родной для него среде всегда перевесит кпд и преимущества, которые потенциально могут быть реализованы в другой, но незнакомой. По крайней мере это справедливо в ближнесрочной и отчасти среднесрочной перспективе.
                          +1
                          Есть только подозрение, что цели этой затеи работодателя противоположны моим, как разработчика.

                          Освоение бюджета?

                            +2

                            По моим предположениям:


                            1. Если перейти на технологию с более низким порогом входа, можно сэкономить нанимая менее квалифицированных специалистов.
                            2. Через обнуление опыта разработчиков на используемом инструменте, можно поумерить их зарплатные амбиции.
                          0
                          Вы правы, я бы тоже удивился. Но у меня немного другая история
                          +17
                          Предлагаю тему для следующей статьи «.NET Core vs 1C:Enterprise»
                            +5
                            Модули и инструменты

                            Считать преимущество по кол-ву пакетов — мне кажется это такое себе.
                            А вот по среде разработке .NET Core сильно вырывается.
                              –1
                              Почему Net Core и Node.js такие медленные при тяжелой работе с БД? Например в тесте Data Updates выдают RPS 2K и 2.5K, в то время как при использовании современного PHP-фреймворка получаем почти 8К:

                              www.techempower.com/benchmarks/#section=test&runid=e12e0b2d-fc4a-4894-b619-cda198516483&hw=ph&test=update&l=zg24n3-f&a=2&f=zik0zj-zik0zj-zik0zj-zik0zj-zik0zj-zik0zj-zik0zj-zik0zj-zik0zj-zik0zj-33

                              И это еще без точечных оптимизаций под Techempower.

                              В остальных тестах Comet тоже опережает Net Core с заметным отрывом, не говоря про Node.js, где речь идет о кратном превосходстве.
                                +1
                                Странно, я посмотрел по вашей ссылке и там такой топ на 2020 по композитному индексу:
                                1. github.com/an-tao/drogon — C++ Http сервер
                                2. github.com/actix/actix — Actor Framework на Rust
                                3. github.com/Xudong-Huang/may_minihttp — (НЁХ) неведомое узконаправленное решение
                                Дальше большой отрыв:
                                4. lithium — PHP фреймворк
                                5. jooby.x — Java/Kotlin (практически одинаково с 6)
                                6. ASP.NET Core

                                А вот в 2019 — ASP.NET Core был на 2ом месте
                                0
                                А почему у вас тест помечен как raw ORM?
                                В статье же данные приведены для тестов с full ORM.
                                  +1

                                  Net Core не медленный, просто надо было вместо EF Core брать нормальный linq2db

                                  +2

                                  Пишу на обеих платформах.
                                  Node JS с Typescript — неплохо для бека, за счет мощной системы типов Тайпскрипта. Реально не хватает ее в C#.


                                  В остальном, особенно что касается бизнес-логики, сравнивать нечего — в ноде нету и близко чего-то подобного LINQ, менее удобный dependency injections и много чего другого.

                                    0

                                    В ноде вроде вообще штатного di нет. И даже стандарта де-факто нет.

                                      0
                                      в ноде есть неплохой пакет typedi
                                        +1

                                        Да найти неплохого можно много. Просто, придя на новый проект, очень мало шансов, что будет тот же DI-контейнер, с которым на предыдущем досконально разобрался, вплоть до коммитов в апстрим.

                                    0
                                    Большое спасибо всем, кто не прошел мимо и оставил комментарии!
                                    Я понял, что тема перехода с .Net на node.js оказалась не раскрыта и поэтому написал продолжение на основании личного опыта
                                      0
                                      когда будет выпущен .Net 5.0, в результате чего второе и третье место по сути объединятся

                                      Буду признателен за ссылку на первоисточник в котором говорится, что 5.0 объединит fw4 и core3

                                        0
                                        Я на 100% не уверен, что это первоисточник, но вот — devblogs.microsoft.com/dotnet/announcing-net-5-0-preview-1 (см. третий абзац).
                                        0
                                        ничего они не объединятся. .NET FX (3.5-4.8) останется жит в стадии замороженной функциональности, будет поддерживаться вплоть до окончания жизни платформ, на которых он изначально вышел (а это Windows Server 2012-2019 и параллельные им Windows Desktop версии), а все новые фичи будут выходить ежегодно под флагом очередного .NET, который является ребрендингом .NET Core.
                                          0
                                          У меня та же информация. Думал, может пропустил чего и не придется страдать переводя кучу кода на .net core…
                                            0
                                            Пока что официальная позиция — поддерживайте старый код как есть, мы его не будем ломать. Начинайте новые проекты с .NET Core. Вроде попадаются комментарии об автоматических/полуавтоматических конвертерах FX=>Core. Для Core 3.1 вроде как есть интероп для «классических» библиотек, но часть стека так и останется навсегда в старом FX.
                                        0
                                        >Однако TypeScript так же не дает всю мощь строго типизированного объектно-ориентированного языка которую предлагает C#

                                        Это предложение вызывает сомнение.
                                        С таким же успехом можно написать и так
                                        Однако, TypeScript — является попыткой сделать использование типизированного объектно-ориентированного подхода в JavaScript который не предназначен для этой парадигмы. И сам по себе TypeScript – это попытка снизить порог входа для разработки на JavaScript. Т.к. в достаточно гибком использовании JavaScript легко ошибиться не имея достаточной квалификации. И TypeScript направлен на приближение JavaScript к синтаксису C#, не просто так.

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