Комментарии 44
А у вас были попытки смены стека?
Я писал бэк на php, питоне и js, хотя основная моя специализация — .NET
Потому что так ситуация складывалась. Как говорится, жить захочешь — не так раскорячишься.
А у вас были попытки смены стека?
Немного :)
Часть из них была связана со сменой работы, часть — с неумолимым ходом времени, самая приятная последняя часть — с возможностью реализовать идеи, которые давно уже созревали в голове и помощью коллег, особенно 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. Сорри за длинный и немного сумбурный комментарий — так совпало, что я в отпуске и меня несколько раз отвлекали :)
— Мы сейчас делаем маленький проекторы поэтому Node.js, а если проект разростется — то и фиг с ним, гори огнем! Сей проект — кто нибудь на .NET перепилит
Меньшие требования к серверным ресурсам — Node.js не такой прожорливый, как .Net и по-настоящему кроссплатформенный;
Вот что забыл спросить — с каким .NET'ом сравнивали и что именно значит «прожорливость»?
Посыл статьи хороший, выучить что-то новое — очень полезно для кругозора. Я тоже давно на сишарпе, и всегда стараюсь "щупать" все свежие языки/стеки. Но JavaScript — это шаг назад. Почему не TypeScript? В нём-то есть, чему поучиться (развитая система типов).
унифицировать backend и frontend
Это можно сделать на F# (Blazor или Fable) — получается вполне элегантно, и, опять же, интересный язык для изучения.
А ещё это можно сделать на Rust ( Yew ) — для коммерческой разработки не могу рекомендовать на данном этапе, но для хобби проектов — отличный вариант. По перформансу и минимальному размеру в топе. Сам Rust тоже очень рекомендую к изучению — показывает некоторые вещи с новой стороны (концепция ownership).
.Net Core, который претендует на кроссплатформенность
Что значит "претендует"? У него кроссплатформенность получше многих других языков/фреймворков
Node.js не такой прожорливый, как .Net
Замеры проводились? Звучит крайне сомнительно.
Потому что www.techempower.com/benchmarks находится достаточно быстро.
Писать бекенд на nodejs с JavaScript вместо Шарпа, добровольно?
Похоже совсем сильно выгорели :)))
Я много писал на классическом .net, в том числе несколько лет на wpf — это было тёмное время ')
А потом перешёл на .net core web api + angular 2 и старше, также много бекенда на java + spring делал. В итоге мне доставляет большое удовольствие писать бекенд на net core, а фронт на ангуляр 10.
Терпеть не могу чистый JavaScript и стараюсь никак его не касаться
А ещё вот это весь flux/redux…
На мой взгляд flux пытается таким заковыристым способом решить проблему отсутствия типизации. Если создавать модели со строгой типизацией, то смысл flux ускользает
Настоящий программист в треде. Ну как, самоутвердились над "любителями субстанции"? Полегчало? Мне вот дизайн языка go не нравится. Наверное, мне тоже следует насмехаться над всеми, кто на нём пишет?
У js есть немало преимуществ. К примеру, один язык как для фронта, так и для бека, что означает переиспользование библиотек. В некоторых случаях это может быть важно.
Мне вот дизайн языка go не нравится. Наверное, мне тоже следует насмехаться над всеми, кто на нём пишет?
Конечно. Всегда так делаю.
У js есть немало преимуществ. К примеру, один язык как для фронта, так и для бека, что означает переиспользование библиотек. В некоторых случаях это может быть важно.
А в вашей практике были случаи, когда это реально пригождалось?
У js есть немало преимуществ. К примеру, один язык как для фронта, так и для бека, что означает переиспользование библиотек. В некоторых случаях это может быть важно.
C# как ни странно тоже. Blazor хоть и молод, но уже в релизе!
Это очень полезно иногда посмотреть какие подходы используются в других языках. Помогает понять, что лучше подходит для решения поставленной задачи. Я так уже успел поиграться с Delphi, Python, JS/TS+Vue/Angular, Go и C++
Про Visual Basic ладно, можно назвать это делом вкуса, но лично для меня выбор в пользу C# был очевиден.
WebForms был хорош для упрощения перехода в web-программирование windows-разработчиков. Но он же концептуально противоестественен для веба ¯\_(ツ)_/¯
P.S. Давно не следил, они там ещё PostPreInit не успели прилепить? :)
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 вполне своественен.
Когда я говорил про концептуальную противоестественность, подразумевал замену естественной для web'а модели запрос-ответ циклом событий.
У 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. Сейчас мне нечего любить.
Как так — нет? Разве программа в Windows состоит из иерархически организованных компонентов
У нас, видимо, чуть разное понимание либо концептуальности, либо противоестественности :)
VB, в моём понимании ничего не ломает, а просто добавляет абстракции более высокого уровня.
А так ли уж естественна для web именно модель запрос-ответ?
Web — он очень разный.
К примеру, взять SPA
Я имею в виду общение с сервером. Если SPA работает в браузере, периодически отправляя запросы на сервер — почему бы и нет. Если фреймворк/библиотеки для SPA начинают работать с SSR таким образом, чтобы скрыть от разработчика то, что код может выполниться на сервере, а может на клиенте — жди беды. Disclaimer: я не против SSR как такового и беды иногда, наверное, можно и не дождаться :)
Web Forms как раз пытаются «скрыть» от разработчика то, что есть серверный код и клиентский код, которые работают по совершенно разным принципам. Там абстракции не то что дырявые, а туннельные… Что ведёт к попыткам их исправить с помощью новых абстракций. Я не зря про PostPreInit прикалывался. Если помните, в ранних версиях WebForms не было событий вроде PreInit и в сложных случаях, когда много вложенных сложных компонентов начинались «танцы» с тем, в каком событии нужно вызвать код, чтобы он отработал в нужный момент.
P.S. На всякий случай, если это не очевидно. Всё сказанное мной, естественно, моё личное мнение — если кому-то WebForms нравится, удобно, повышает продуктивность, позволяет писать более поддерживаемый код — почему бы и нет — и люди и задачи разные ¯\_(ツ)_/¯
Как известно, в 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 году)
Все время не покидало ощущение того, что там как-то всё через одно и то же место уже много лет.
Подход ангуляра нравится. тайпскрипт нравится, абстракция от браузера и вменяемая структура проекта — нравится. Но вот многомегабайтные блобы из крякозябр в js на выходе — не нравятся категорически.
Как быть — хз. Пока стараюсь обходить стороной и при необходимости использовать pyqt5. Но есть мнение, что рано или поздно придётся себя пересилить.
Ну так в других ЯП код тоже преобразуется то в машинный, то в инструкции виртуальной машины. Часто в таком виде он тоже выглядит как кракозябры. Просто в других ЯП вам их особо не показывают, а на фронте эти кракозябры нужно регулярно доставлять клиенту и их размер становиться критически важен, вот и полезно иногда посмотреть в них, чтобы убрать лишнее.
:)
Во первых, не бывает "языков без многопоточности" (или с многопоточностью), бывают среды исполнения с одной или без. В ноде с 10 версии есть потоки. Таким образом, из коробки имеем как событийную модель для IO-bound, так и работу с потоками для cpu-bound.
Во вторых, если нужна типизация — TS в помощь, там система типов очень удобная. С тем же vscode или webstorm получаем шикарный автокомплит, сверхзвуковой кодинг, моментальные подсказки и подсветки ошибок.
По вычислительным задачам согласен, есть тормоза. Хотя если вычисления будут в рамках int32, то должно летать, на Хабре не так давно был пост о работе с числами в v8.
Работаю с .NET ASP MVC. Начинал с С WinApi, Qt, Delphi. Иногда поглядываю в сторону Typescript, F#, Go в плане развития кругозора и возможного использования в будущем.
На счёт отсутствия типизации. А почему бы не использовать typescript? В своё время открыл фреймворк NestJs+Typescript и мелкие проекты делаю на нем. Очень нравится, из коробки реализованы базовые фичи(логгирование, DI, ORM,) многие вещи реализованы похожим образом как в .net.
Интересно читать. Но хотелось бы, чтобы более детальнее раскрылись плюсы бэка на ноде)
Думаю, будет забавно, если к Вам придет этот же заказчик и попросит те самые "сложные вычисления" и "сложную бизнес-логику".
Меня лично вполне устраивает .NET для бэка, а вот в качестве BFF у Node.js есть одно существенное преимущество — море готовых библиотек.
Дошло до смешного, в одном проекте нужна была интеграция с Active Directory, так вот для Node.js нашлась готовая библиотека, с которой можно было тестировать приложение без поднятия отдельного контроллера домена. А для .NET, как нетрудно догадаться, не нашлась…
P.S. Я не «адвокат» бэка на ноде, но для вычислений, наверное, можно извернуться за счёт вызова кода, написанного на других языках. Другой вопрос, зачем…
Дошло до смешного, в одном проекте нужна была интеграция с 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 — была, сам использовал.
P.S. Да, для тестов, в итоге, какой-то тестовый LDAP и подняли, может даже тот, что вы упоминаете.
P.P.S. Если что, node.js стали использовать не только из-за этого случая :)
Тоже лет 10 прогнал на C# (в основном WPF). Последние годы однозначно стал выгорать.
Начал новый проект на Symfony + Vue и был в восторге от гибкости веба, в отличие от .Net
А у вас были попытки смены стека?Когда-то давно я наоборот перешел с Node.js на .NET Core и был очень рад. Программировать на C# было одно удовольствие, правда не долго, но там уже другое — пришел к выводу, что web мне в целом надоел и не нравится.
Сейчас попытки сменить сферу, но пока безуспешно…
Я подозреваю что к этому имеет отношение хром)
Мелкософты всё пытаются влиться со своим рейзером \ блейзером и т.д. Но упустили время и шанс.
Меняю свой стек с понедельника