Как стать автором
Обновить

Комментарии 43

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

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

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

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

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

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

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

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

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

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

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

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


У этого безобразия 9,737,367 скачиваний за неделю.
Да. Или всякие там isArray :) В целом количество пакетов не показатель, разумеется.
НЛО прилетело и опубликовало эту надпись здесь
Очень правильное рассуждение. Логика перехода на Node действительно непонятна. Обычно переходят в связи с унификацией кода для фронта и бэка и недостатком квалифицированных бэк-разработчиков C#/Java/GoLang в предприятии
сначала мы писали на .NET, затем перешли на .NET Core и потом постепенно сменили стек на Node.JS. Основной причиной была скорость разработки.

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

НЛО прилетело и опубликовало эту надпись здесь

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


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


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

НЛО прилетело и опубликовало эту надпись здесь
Присоединюсь, тоже не раз слышал что скорость разработки увеличивается, а почему? Есть уже какой-то готовый инфраструктурный слой? Или просто много времени уходит чио бы разобраться в тонкостях asp net?

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

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

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

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

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

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

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


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

Считать преимущество по кол-ву пакетов — мне кажется это такое себе.
А вот по среде разработке .NET Core сильно вырывается.
Почему 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, где речь идет о кратном превосходстве.
Странно, я посмотрел по вашей ссылке и там такой топ на 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ом месте
Спасибо, это было интересно!
А почему у вас тест помечен как raw ORM?
В статье же данные приведены для тестов с full ORM.

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

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


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

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

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

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

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

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

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

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

Публикации

Истории