Меняю свой стек с понедельника +21





Приветствую, коллега!

Примерно за год до момента написания этой статьи мне начало казаться, что я начал выгорать. Работа, уже давно превратившаяся в ремесло, перестала приносить то студенческое чувство первооткрытия, знакомое каждому программисту, приносящее эйфорию. Ради этого чувства, ради новых знаний я когда-то просиживал за монитором по 18 часов в сутки. Это давно прошло… но недавно я испытал это чувство снова! Сначала оно было тихим, непривычным из-за длительного перерыва, но со временем оно разгорелось и заполыхало!

Если вы такой же, как и я, программист со стажем около от 12 лет, возрастом в районе 30 лет, задержавшийся в своем родном стойле стеке (особенно если это C# .Net MVC), то приглашаю под кат. Тем, кто моложе — думаю тоже будет полезно, чтобы заранее быть готовыми.

Предыстория начинается с того, что я давно занимаюсь разработкой на стеке C# .Net (ASP, MVC, windows services). Мне кажется, что меня можно назвать кем-то вроде full-stack разработчиком: базы данных, backend, frontend и даже олимпиадное программирование — всё это я через себя пропустил. Не скажу, что я профессионал, но удивить меня чем-то сложно, если речь идет о .Net. Нет, я не ходил на конференции .next и подобные, но я учился с их несколькими старожилами в университете, знаком с некоторыми из них лично, а число запущенных мною в ПЭ проектов среднего масштаба перевалило за 30.

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

Вы себя ещё не узнали? Если вы моложе, обязательно продолжайте читать, у вас всё впереди. Если вы ушли дальше меня, продолжайте читать, а в комментариях расскажите о своем опыте.

Итак, впереди у меня маячило примерно пол года неинтересной работы. Но мы сдали проект на несколько месяцев раньше, узнали кучу крутейших вещей, прокачались в смежных областях и получили массу удовольствия! Не буду долго тянуть… новый проект был сделан на полностью новом стеке: Node.js + React.

Коллеги, предвидя шапкозакидательство, сразу должен оговориться, что решение о смене стека пришло не спонтанно. Несколько месяцев я вынашивал мысль о том, что .Net MVC — не самый лучший выбор, если речь идет о небольших проектах. Подыскивал альтернативы, смотрел по сторонам. О связке Node.js и React я считал, что это инструменты, более заточенные под server-side и client-side, чем C#, но уже первый опыт превзошел все мои ожидания.

Оговорим правила


Во-первых, считаю нужным уточнить некоторые детали и условия, при которых можно считать ключевую мысль статьи — замена стека .Net MVC и Node.JS+React — верной. Я не склонен скатываться в крайности и утверждать, что во всех случаях такое мероприятие будет полезным, поэтому вот краткий перечень исходных ограничений:

  • Проекты с привлечением до 3-5 программистов;
  • Отсутствие существенных вычислений и сложной логики в backend;
  • Наличие возможности и/или необходимости унифицировать backend и frontend;

Проекты с привлечением до 3-5 программистов


Такое ограничение возникло из-за предположения, что при участии в проекте большой команды от 5 человек, речь идет уже о серьезных корпоративных приложениях, которые тяжело будет реализовывать без преимуществ .Net (причем не только ASP.NET, но и Core). Про сами преимущества и недостатки поговорим ниже.

Отсутствие существенных вычислений и сложной логики в backend


Использовать JavaScript (или даже TypeScript, вас это не спасет), язык с динамической типизацией без многопоточности и без Linq, для реализации вычислений или более-менее сложной бизнес-логики, просто нельзя — язык просто для этого не предназначен. Чего не скажешь про C#. Важно учитывать специфику инструмента, чтобы не забивать гвозди микроскопом.

Наличие возможности и/или необходимости унифицировать backend и frontend


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

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

Чек-лист


Стоимость разработки и содержания


Требует ли ваш бюджет низкого порога входа специалистов и невысокой стоимости содержания?

Если у вас небольшая компания или команда программистов, то сложность инструментов разработки отнимает драгоценные ресурсы. Стек Node.js+React обладает рядом неоспоримых преимуществ по сравнению с .Net MVC или Core: 

  1. Унификация backend'а и frontend'а — специалисты смогут работать как fullstack'и легче и проще, чем если бы это был стек C#;
  2. Меньшие требования к серверным ресурсам — Node.js не такой прожорливый, как .Net и по-настоящему кроссплатформенный;
  3. Скорость разработки выше — из-за отсутствия типизации существенно повышается скорость выхода первых версий продукта.


Запуск MVP (minimum viable product) и PoC (proof of concept)


Горят ли ваши сроки для запуска MVP или PoC?

С точки зрения скорости реализации MVP или PoC стек Node.js+React, несомненно, в более выигрышном положении по сравнению со стеком .Net. Принимая во внимание предыдущий пункт о стоимости разработки и содержания, для задачи запуска MVP появляется синергия: быстро, дешево, эффективно. Кроме того, стабильность работы Node.js находится на высоком уровне и не вызывает нареканий.

Среда разработки


Будет ли вам достаточно функциональности «легких» IDE?

Для Node.js в связке с React отлично подходят «легковесные» IDE. Например, VS Code — не требует больших мощностей при разработке, кроссплатформенный редактор, распространяется бесплатно, его функциональности вполне хватает, чтобы комфортно разрабатывать как backend, так и frontend.
Для проектов на C# можно использовать Visual Studio Community — тоже условно-бесплатную IDE, но она уже потребует ресурсов, будет не такой шустрой и не кроссплатформенной.

Типизация языка


Вы сможете обеспечить качественную разработку и поддержку своего проекта, учитывая отсутствие типизации?

Отсутствие типизации в языке — это палка о двух концах. С одной стороны, такой подход позволяет кратно увеличить скорость разработки, уменьшив объем кода. С другой стороны, кратно увеличивается объем тестирования. Кроме того, некоторые ошибки могут проявиться только во время эксплуатации, успешно преодолев все тесты. Крупные проекты делать без типизации становится затруднительно.

Производительность и масштабирование


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

Как известно, в Node.js реализовано однопоточная событийно-ориентированная модель. Это отлично подходит для большого количества запросов, но совершенно не годится для распараллеливания вычислений или реализации сложной бизнес-логики. Таким образом, при выборе стека для backend'а на Node.js, надо отдавать себе отчет о нюансах его работы.

Кроссплатформенность


Вам требуется кроссплатформенность из коробки?

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

Заключение


Богатый мир модулей Node.js позволит вам эффективно и с минимальными затратами реализовать практически любую прикладную задачу от авторизаций в корпоративных системах и rest-api до чат-ботов мессенджеров.

Развертывание приложений Node.js в системах под управлением любой ОС — одно удовольствие и пару команд. А потребность в серверных мощностях могут быть снижены на порядок по сравнению с .Net, и вы можете спокойно выбирать «оплата за ресурсы» в нашем конфигураторе выделенного сервера.

А у вас были попытки смены стека?




Комментарии (42):

  1. arrakisfremen
    /#21933050

    А у вас были попытки смены стека?

    Я писал бэк на php, питоне и js, хотя основная моя специализация — .NET
    Потому что так ситуация складывалась. Как говорится, жить захочешь — не так раскорячишься.

    • Я на PHP, JS, Go, Python, Swift (пол года iOS разрабом поработал на работе куда нанимался С# программистом потому что захотелось попробовать и была возможность), JS, TS, Rust и вот недавно Scala и Idris. Таки вообще не сказал бы что JS даже близко рядом С# который на голову его лучше. Примерно на столько на сколько Idris лучше C#. Судя по всему автор совсем выгорел. Яб лучше на что нибудь по сложнее прешел бы с С#. На Scala или Idris там хотя и так сам по себе C# хорош в плане ЯП чтобы «Работу работать».

  2. OlegAxenow
    /#21933612 / +5

    А у вас были попытки смены стека?


    Немного :)
    Часть из них была связана со сменой работы, часть — с неумолимым ходом времени, самая приятная последняя часть — с возможностью реализовать идеи, которые давно уже созревали в голове и помощью коллег, особенно force (как с идеями, так и с реализацией).

    1. С++, MFC, ATL (windows-приложение, база MS SQL Server, интеграция с офисными приложениями через COM). Сейчас наборчик странноват, вряд ли кому-то интересны подробности, но это было больше 20 лет назад…

    2. Visual Basic, VBA (и старый добрый MS SQL). До сих пор стыдно :) Но задачи такие были…

    3. C#, WinForms (и… правильно — MS SQL, дальше увидите, куда меня это завело). Тогда .NET только вышел, было чертовски интересно его изучать и помогать в этом другим.

    4. С#, ASP.NET (но почти без WebForms) и MS SQL, много MS SQL… В новой компании было принято изрядную часть логики писать в SQL… Не то чтобы я фанат такого подхода, но на пару лет втянулся. К тому же, в очень небольшом коллективе была крайне высокая концентрация крутых программистов и дизайнеров тоже (да, Andreika, я про тебя ;). За счёт этого, не самый лучший (на мой скромный взгляд) архитектурный подход работал хорошо и с точки зрения runtime (а там были десятки тысяч пользователей в день) и с точки зрения скорости разработки и даже не сильно стрёмно было поддерживать. Если вкратце — данные читались с FOR XML, трансформировались в HTML через XSLT, а записывались хранимыми процедурами. Но Bus Factor был не больше 2…

    5. Далее было 2-3.5 (как посмотреть) смены стека на одной работе (за 10+ лет), хотя, спойлер — C# выжил.

    5.1. ASP.NET WebForms (и да, MS SQL). Самый сложный проект на моей памяти с точки зрения количества форм и бизнес-логики. Надо было написать 300+ разных форм, причём дорабатывать и обсуждать с заказчиком в процессе. Если что — это была миграция всех приложений для сотрудников Нью-Йоркского профсоюза гостиничного бизнеса (от мейнфреймов до приложений на MS Access). Пришлось за месяц набросать фреймворк, который позволял и максимально быстро формы лепить и давал возможность быстро навешивать на них бизнес-логику (на C#, не подумайте, что я без логики на SQL уже не мог :). Тем и спаслись. Ну и, опять же, программисты хорошие. Позже я узнал, что этот проект уже пытались сделать до этого 3 конторы, но не смогли как раз из-за объёма (параллельно работать на мейнфрейме, который был ужасен и жрал за сопровождение доллары миллионами заказчик не хотел).

    5.2. Потом, логично, был ASP.NET MVC (и сами знаете что). Ну, тут ничего нового не расскажу.

    5.2.5. Потом попалось несколько проектов, где можно было поэкспериментировать с технологиями. Там был, как обычно, C# и MS SQL, но попробовали и ServiceStack (жутко неудобно) и Angular (ещё 1.x)… Потом был проект для компании, назовём её «Росэлектрон» где с force решили-таки закопать REST и пользоваться чем-то вроде JSON-RPC (самописным), используя node.js в качестве BFF (но мы только потом узнали это модное слово).

    5.3. Теперь используем связку .NET Core + node.js, фронтенд по-разному (где-то React+TypeScript, где-то jQuery), что-то вроде самописного gRPC (да, да,… но когда начинали делать gRPC только начинался и много не хватало), а в качестве БД — MS SQL или, внезапно, PostgreSQL.
    Полёт нормальный, за почти уже 4 года наросло много приятных плюшек (к сожалению и технические долги есть, боремся), но про них не буду, потому что платформа закрытая (по крайней мере, пока).

    P.S. Сорри за длинный и немного сумбурный комментарий — так совпало, что я в отпуске и меня несколько раз отвлекали :)

  3. FoxisII
    /#21933668 / +1

    Критикую решение не на .NET
    — Мы сейчас делаем маленький проекторы поэтому Node.js, а если проект разростется — то и фиг с ним, гори огнем! Сей проект — кто нибудь на .NET перепилит

  4. OlegAxenow
    /#21933750 / +4

    Меньшие требования к серверным ресурсам — Node.js не такой прожорливый, как .Net и по-настоящему кроссплатформенный;


    Вот что забыл спросить — с каким .NET'ом сравнивали и что именно значит «прожорливость»?

  5. kefirr
    /#21933918 / +2

    Посыл статьи хороший, выучить что-то новое — очень полезно для кругозора. Я тоже давно на сишарпе, и всегда стараюсь "щупать" все свежие языки/стеки. Но JavaScript — это шаг назад. Почему не TypeScript? В нём-то есть, чему поучиться (развитая система типов).


    унифицировать backend и frontend

    Это можно сделать на F# (Blazor или Fable) — получается вполне элегантно, и, опять же, интересный язык для изучения.


    А ещё это можно сделать на Rust ( Yew ) — для коммерческой разработки не могу рекомендовать на данном этапе, но для хобби проектов — отличный вариант. По перформансу и минимальному размеру в топе. Сам Rust тоже очень рекомендую к изучению — показывает некоторые вещи с новой стороны (концепция ownership).


    .Net Core, который претендует на кроссплатформенность

    Что значит "претендует"? У него кроссплатформенность получше многих других языков/фреймворков


    Node.js не такой прожорливый, как .Net

    Замеры проводились? Звучит крайне сомнительно.

  6. Simplevolk
    /#21933984

    А почему не использовали Angular\React + asp.net core Web API?

  7. maxbl4
    /#21934108 / +3

    Писать бекенд на nodejs с JavaScript вместо Шарпа, добровольно?
    Похоже совсем сильно выгорели :)))


    Я много писал на классическом .net, в том числе несколько лет на wpf — это было тёмное время ')
    А потом перешёл на .net core web api + angular 2 и старше, также много бекенда на java + spring делал. В итоге мне доставляет большое удовольствие писать бекенд на net core, а фронт на ангуляр 10.
    Терпеть не могу чистый JavaScript и стараюсь никак его не касаться

    • maxbl4
      /#21934142 / -1

      А ещё вот это весь flux/redux…
      На мой взгляд flux пытается таким заковыристым способом решить проблему отсутствия типизации. Если создавать модели со строгой типизацией, то смысл flux ускользает

    • /#21934144

      Есть люди которым js лучше заходит.

      Любители палок и субстанции. Бывают латентные, с виду не очень, слова говорят правильные, а в душе любят из палок соорудить что-нибудь этакое и сверху обмазать. Ну или write-only писатели, как оно там потом будет работать, нам не интересно, мы написали.

      Судя по тому что даже не на typescript, похоже на это.

      Было бы интересно узнать, выбор стека для проекта наверное тоже проходил под критерием — «чего-нибудь новенького узнать, а то выгорел».

      • Kroid
        /#21935886

        Настоящий программист в треде. Ну как, самоутвердились над "любителями субстанции"? Полегчало? Мне вот дизайн языка go не нравится. Наверное, мне тоже следует насмехаться над всеми, кто на нём пишет?


        У js есть немало преимуществ. К примеру, один язык как для фронта, так и для бека, что означает переиспользование библиотек. В некоторых случаях это может быть важно.

        • AnthonyMikh
          /#21942214

          Мне вот дизайн языка go не нравится. Наверное, мне тоже следует насмехаться над всеми, кто на нём пишет?

          Конечно. Всегда так делаю.


          У js есть немало преимуществ. К примеру, один язык как для фронта, так и для бека, что означает переиспользование библиотек. В некоторых случаях это может быть важно.

          А в вашей практике были случаи, когда это реально пригождалось?

        • /#21943406 / +1

          Перечитал свой комментарий правда получилось как-будто хотел обидеть любителей js.

          На самом деле это наблюдение про нескольких людей которых знаю лично и которые как раз попадают под анамнез из статьи, т.е. писали на c#/java перепрыгнули на js и сильно возрадовались. Как раз из-за возможности лепить.

          js как язык позволяет легко делать плохо, чтобы делать хорошо надо постараться и стараться всегда. На том же c#, сделав правильную струкуру проекта, некоторые вещи просто будут невозможно сделать ошибочно.

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

        • Serginio1
          /#21947116

          У js есть немало преимуществ. К примеру, один язык как для фронта, так и для бека, что означает переиспользование библиотек. В некоторых случаях это может быть важно.


          C# как ни странно тоже. Blazor хоть и молод, но уже в релизе!

  8. andreyiq
    /#21934204

    Это очень полезно иногда посмотреть какие подходы используются в других языках. Помогает понять, что лучше подходит для решения поставленной задачи. Я так уже успел поиграться с Delphi, Python, JS/TS+Vue/Angular, Go и C++

  9. mvv-rus
    /#21934242 / +1

    Читаю я этот текст, и мне в голову мысль приходит: зря, наверное, MS забросила Web Forms и Visual Basic. Или там решили, что на таких вот проектах они денег не подымут…

    • OlegAxenow
      /#21934512

      Программировал на том и другом, не соглашусь.

      Про Visual Basic ладно, можно назвать это делом вкуса, но лично для меня выбор в пользу C# был очевиден.
      WebForms был хорош для упрощения перехода в web-программирование windows-разработчиков. Но он же концептуально противоестественен для веба ?\_(?)_/?

      P.S. Давно не следил, они там ещё PostPreInit не успели прилепить? :)

      • mvv-rus
        /#21934872

        WebForms был хорош для упрощения перехода в web-программирование windows-разработчиков. Но он же концептуально противоестественен для веба ?\_(?)_/?

        Ну, я бы сказал, что и VB в 90-х не менее «концептуально противоестественным» для Windows: знал немало программистов, которые тогда от него плевались («как это — программировать мышкой?!»). Но (до выхода Delphi и Borlad C++ Builder) особого выбора средств быстрой разработки у них не было — разве что Powerbuilder или, там, Paradox for Windows, что тоже было не труъ. А то, что считалось труъ, «концептуально естественным» — типа Visual C++ с MFC или же Borland C++ с OWL (и все это с ODBC для работы с БД), — для типичной задачи «легко и быстро сляпать приложение» подходило весьма посредственно.
        Но сейчас, конечно, Web Forms уже не поможет: это раньше формошлепы сидели на VB, а теперь они сидят на React/Angular/View и прочих фреймворках, и JS им вполне заменяет Basic — благо «бейсиковский» безалаберный стиль (по поводу которого некогда ругался ещё Никлаус Вирт) и для JS вполне своественен.

        • alexdesyatnik
          /#21942750

          Извините, что так поздно, просто в интернете кто-то не прав тот стиль, по поводу которого ругался Вирт, не имеет никакого отношения ни к VB, ни к JS. Он говорил про старый бейсик с номерами строк и без какой-либо структуры программы, там можно было с помощью goto свободно прыгать в любое место кода, все переменные были глобальными, и всё это без строгой самодисциплины быстро приводило к хаосу. В определённом смысле тот бейсик ближе к ассемблеру, чем к относительно современным высокоуровневым языкам (включая QBasic/QuickBasic и выросший из него Visual Basic), на которых такой потрясающий уровень безалаберности если и достижим, то с большим трудом.

          • mvv-rus
            /#21945112

            Отсуствие структуры и возможность написания лапшевидного кода — это была только одна из претензий (в равной мере относившейся и к Фортрану). Но была и другая — отсутствие (или, по крайней мере, необязательность) типизации данных. И это никуда не делась ни в QB, ни в VB. И в JS эта, свойственная скриптовым языкам, особенность тоже есть.

        • OlegAxenow
          /#21944314

          У VB нет концептуальных противоречий с Windows. Просто сам язык лично мне не нравится.

          Когда я говорил про концептуальную противоестественность, подразумевал замену естественной для web'а модели запрос-ответ циклом событий.

          • mvv-rus
            /#21945074

            У VB нет концептуальных противоречий с Windows.

            Как так — нет? Разве программа в Windows состоит из иерархически организованных компонентов (т.е. объектов, имеющих внутреннее состояние в виде полей), получающих события через свои обработчики, которые вызываются в соответствии с этой иерархией? А не из оконных процедур (т.е. ни разу не объектов, т.к. все состояние у них — доступное Get/SetWindowLong некоторое количество неструктурированной памяти окна), которым направляются сообщения (весьма низкоуровневые причем)? И это ещё не всё: часть компонентов вообще не имеют в системе связанного именно с ними окна, получающего сообщения от ОС, они реализуются на базе оконной процедуры того окна-контейнера, в котором они содержатся, т.е. их обработчики событий должен вызывать этот контейнер.
            То есть, чтобы получить концептуальную модель, которую использовал VB, требовалось довольно много дополнительного кода — не зря же программа на VB требовала таскать вместе с ней ещё и DLL.

            Когда я говорил про концептуальную противоестественность, подразумевал замену естественной для web'а модели запрос-ответ циклом событий.

            А так ли уж естественна для web именно модель запрос-ответ?
            Web — он очень разный.
            К примеру, взять SPA: там как раз самый что ни на есть цикл событий. И — иерархия компонентов-элементов DOM, каждый из которых является объектом. И — погружение/всплывание событий по этой иерархии изначально организованное самой средой выполнения (браузером), а не как в в Windows — в лучшем случае прилепленное сбоку через управляющие сообщения дочерних окон элементов управления (совсем других, чем сообщения, которые получают эти элементы), а то и вообще — прописанное в коде оконной процедуры контейнера. И взаимодействие с сервером — не через запрос/ответ с полной заменой содержимого окна, а через API, полученные от которого данные потом обрабатываются самим SPA-приложением.
            Или SPA — это не web?

            PS Мое мнение, почему все пошло не так: MS придумала Web Forms и придумала XHR, но не додумалась совместить их друг с другом.

            PPS В те далекие времена, когда я писал программы под Windows, я любил Delhi. Сейчас мне нечего любить.

            • OlegAxenow
              /#21946268

              Как так — нет? Разве программа в Windows состоит из иерархически организованных компонентов

              У нас, видимо, чуть разное понимание либо концептуальности, либо противоестественности :)
              VB, в моём понимании ничего не ломает, а просто добавляет абстракции более высокого уровня.

              А так ли уж естественна для web именно модель запрос-ответ?
              Web — он очень разный.
              К примеру, взять SPA

              Я имею в виду общение с сервером. Если SPA работает в браузере, периодически отправляя запросы на сервер — почему бы и нет. Если фреймворк/библиотеки для SPA начинают работать с SSR таким образом, чтобы скрыть от разработчика то, что код может выполниться на сервере, а может на клиенте — жди беды. Disclaimer: я не против SSR как такового и беды иногда, наверное, можно и не дождаться :)

              Web Forms как раз пытаются «скрыть» от разработчика то, что есть серверный код и клиентский код, которые работают по совершенно разным принципам. Там абстракции не то что дырявые, а туннельные… Что ведёт к попыткам их исправить с помощью новых абстракций. Я не зря про PostPreInit прикалывался. Если помните, в ранних версиях WebForms не было событий вроде PreInit и в сложных случаях, когда много вложенных сложных компонентов начинались «танцы» с тем, в каком событии нужно вызвать код, чтобы он отработал в нужный момент.

              P.S. На всякий случай, если это не очевидно. Всё сказанное мной, естественно, моё личное мнение — если кому-то WebForms нравится, удобно, повышает продуктивность, позволяет писать более поддерживаемый код — почему бы и нет — и люди и задачи разные ?\_(?)_/?

  10. bgnx
    /#21934910 / -2

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

    Вы серьезно? Тогда такой вопрос — как вы собираетесь поддерживать атомарность при выполнении сложной бизнес-логики? Многопоточная модель это прямой путь к race-conditions и неконсистетности данных. Вы знаете что в базах данных (включая postgres, mysql) по умолчанию не включен serializable уровень изоляции и поэтому любую бэкенд-логику которая работает с бд отдельными запросами нужно врапить в эти транзкции (от начала и до конца) иначе рано или поздно у вас появятся race-conditions и неконсистентность данных (https://www.youtube.com/watch?v=5ZjhNTM8XU8)?
    А теперь вопрос — какой тип бд позволяет обрабатывать транзакции с любой логикой (запросы к различным таблицам, включая условия и циклы) c seriazlizable-уровнем изоляции со скоростью > 100к транзакций в секунду? Вы не поверите но это такие базы данных которые выполняют все транзакции в одном потоке и вполне могут быть написаны на Node.js. Яркий пример такой бд — это Tarantool (https://www.youtube.com/watch?v=yrTF3qH8ey8)


    А что касается скорости одного потока javascript — то он вполне находится на уровне с++ (если не относиться наплевательски на советы по производительности) — вот доклад где сравнивается с++ и js — https://www.youtube.com/watch?v=UJPdhx5zTaw и js всего лишь на 17% медленнее чем с++ с O3-флагом оптимизации (и это было еще в 2012 году)

  11. artemlight
    /#21935646

    Хз, я очень долго пытался заставить себя прикоснуться к фронтенду.
    Все время не покидало ощущение того, что там как-то всё через одно и то же место уже много лет.
    Подход ангуляра нравится. тайпскрипт нравится, абстракция от браузера и вменяемая структура проекта — нравится. Но вот многомегабайтные блобы из крякозябр в js на выходе — не нравятся категорически.

    Как быть — хз. Пока стараюсь обходить стороной и при необходимости использовать pyqt5. Но есть мнение, что рано или поздно придётся себя пересилить.

    • Riim
      /#21936728

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

  12. tuxi
    /#21936398

    Вот прямо завтра буду менять стек, вместо резьбового соединения металлопроката, начину использовать дуговую электросварку. Но один инструмент (или технология) обработки все равно останется тем же, что и ранее. Угловая шлифмашинка, в народе «болгарка», очень универсальная и незаменимая вещь.
    :)

  13. RealEgo
    /#21939564

    А у вас были попытки смены стека?

    За 10 лет: Вёрстка -> PHP (Laravel) -> .Net MVC 4 -> Ruby (RoR) -> последние 2 года в основном Js (Vue), но всё веб-веб-веб — надоело. Смотрю в сторону Swift.

  14. Alexandroppolus
    /#21943122

    Во первых, не бывает "языков без многопоточности" (или с многопоточностью), бывают среды исполнения с одной или без. В ноде с 10 версии есть потоки. Таким образом, из коробки имеем как событийную модель для IO-bound, так и работу с потоками для cpu-bound.
    Во вторых, если нужна типизация — TS в помощь, там система типов очень удобная. С тем же vscode или webstorm получаем шикарный автокомплит, сверхзвуковой кодинг, моментальные подсказки и подсветки ошибок.
    По вычислительным задачам согласен, есть тормоза. Хотя если вычисления будут в рамках int32, то должно летать, на Хабре не так давно был пост о работе с числами в v8.

  15. AlexDevFx
    /#21943124

    Работаю с .NET ASP MVC. Начинал с С WinApi, Qt, Delphi. Иногда поглядываю в сторону Typescript, F#, Go в плане развития кругозора и возможного использования в будущем.
    На счёт отсутствия типизации. А почему бы не использовать typescript? В своё время открыл фреймворк NestJs+Typescript и мелкие проекты делаю на нем. Очень нравится, из коробки реализованы базовые фичи(логгирование, DI, ORM,) многие вещи реализованы похожим образом как в .net.

  16. Ukrainsky
    /#21943126

    Интересно читать. Но хотелось бы, чтобы более детальнее раскрылись плюсы бэка на ноде)


    Думаю, будет забавно, если к Вам придет этот же заказчик и попросит те самые "сложные вычисления" и "сложную бизнес-логику".

    • OlegAxenow
      /#21944300

      Похоже, автор статьи либо не читает комментарии, либо просто не отвечает ?\_(?)_/?

      Меня лично вполне устраивает .NET для бэка, а вот в качестве BFF у Node.js есть одно существенное преимущество — море готовых библиотек.
      Дошло до смешного, в одном проекте нужна была интеграция с Active Directory, так вот для Node.js нашлась готовая библиотека, с которой можно было тестировать приложение без поднятия отдельного контроллера домена. А для .NET, как нетрудно догадаться, не нашлась…

      P.S. Я не «адвокат» бэка на ноде, но для вычислений, наверное, можно извернуться за счёт вызова кода, написанного на других языках. Другой вопрос, зачем…

      • /#21944408

        автор статьи либо не читает комментарии, либо просто не отвечает
        Скорее всего это вымысел корпоративного блога.

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

      • mvv-rus
        /#21945096

        Дошло до смешного, в одном проекте нужна была интеграция с Active Directory, так вот для Node.js нашлась готовая библиотека, с которой можно было тестировать приложение без поднятия отдельного контроллера домена. А для .NET, как нетрудно догадаться, не нашлась…

        Так как я программист ненастоящий, то средства доступа к каталогу LDAP из .NET мне использовать не довелось. Но мне, ныне как специалисту именно по AD, странно это, что не нашлось библиотеки. Потому что у MS кроме AD Directory Services (AD DS), с доменами и аутентификацией, есть ещё и отдельный AD Lightwait Directory Services (AD LDS), который — просто сервер LDAP, ко всем заморочкам с доменами отношения не имеющий. И основной протокол доступа к содержимому каталога что AD DS, что AD LDS — один и тот же: LDAP (вряд ли кто-то в разработке для Интернет/интранет использует специфические именно для AD DS вещи на базе RPC (более строго — DCE RPC), типа API репликации). По крайней мере, средства доступа через LDAP — что древнее средство доступа к AD на базе COM Automation — ADSI, что современный модуль доступа в Powershell — ActiveDirectory называется (и который наверняка работает через стандартную библиотеку .NET Framework) — совершенно одинаково позволяют работать как с AD DS, так и с AD LDS, только сервер с портом им правильный указать надо.
        Единственно, что я слышал в минус .NET в плане LDAP — что в .NET Framework нет интеграции LDAP с ADO.NET, т.е. возможности обращения к содержимому каталога с использованием SQL (но это не точно), а вот в ADSI, с ADO — была, сам использовал.

        • OlegAxenow
          /#21946300

          Я сам лично этой проблемой не занимался, да и дело было года 4 назад. Но разработчик, которому я доверяю, сказал, что посмотрел на варианты и нормально работающего решения не было (именно в ASP.NET).

          P.S. Да, для тестов, в итоге, какой-то тестовый LDAP и подняли, может даже тот, что вы упоминаете.
          P.P.S. Если что, node.js стали использовать не только из-за этого случая :)

  17. levkinoHabr
    /#21943128

    Тоже лет 10 прогнал на C# (в основном WPF). Последние годы однозначно стал выгорать.


    Начал новый проект на Symfony + Vue и был в восторге от гибкости веба, в отличие от .Net

  18. abrigantech
    /#21943130

    Хотел бы немного уточнить, разве правильно сравнивать MVC архитектуру и SPA? Если уж сравнивать, то Blazor и React, мне кажется, что это более правильно.

  19. Kernell
    /#21943132

    То чувство, когда читаешь первые пару абзацев и узнаешь себя (только стаж официальный у меня около 8 лет, а не 12).

    А у вас были попытки смены стека?
    Когда-то давно я наоборот перешел с Node.js на .NET Core и был очень рад. Программировать на C# было одно удовольствие, правда не долго, но там уже другое — пришел к выводу, что web мне в целом надоел и не нравится.

    Сейчас попытки сменить сферу, но пока безуспешно…

  20. KOTaSYS
    /#21943134

    Спасибо за статью. Я тоже задумываюсь о том что бы написать на Node вместо Java/Kotlin где-то по тем же причинам — скорость разработки + свежесть стэка

  21. pamidur
    /#21943138

    Не совсем согласен с утверждением что VSCode — легковесен. Расширяем — да, кросплатформенен — да, удобен — может быть. Но вот в плане потребления ресурсов — полноценная Visual Studio у меня на ноуте живет на час больше от батареи по сравнению с VSCode. Это в режиме кодинг + тесты (c#), и там и там включены анализаторы.

    Я подозреваю что к этому имеет отношение хром)

  22. devopg
    /#21943140

    да давно уже тренд vue (или аналог) + .net web api.
    Мелкософты всё пытаются влиться со своим рейзером \ блейзером и т.д. Но упустили время и шанс.