.NET. Прошлое. Настоящее. Будущее

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Привет. Меня зовут Алексей Голубев, и я Lead Software Engineer в компании SoftServe. Вот уже 8 лет я так или иначе связан с .NET, и мне она реально нравится.

.NET за свою долгую жизнь переживалa как взлеты, так и падения. В этой статье мы ретроспективно посмотрим на то, через что прошла платформа, что в ней менялось с годами и в какое светлое будущее ведет она нас.

История развития .NET

В 2000 году Java доминировала по всем фронтам, в том числе в качестве основной платформы для реализации серверных приложений. Созданная компанией Sun Microsystems, Java, реализовала клинг фичу тех лет. Более того, принципы заложенные еще тогда до сих пор актуальны и находят свое воплощение во многих проектах.

Это, конечно же, виртуальная машина Java Virtual Machine (сокращённо JVM). Она позволяла писать и компилировать код всего единожды для разных платформ и процессоров плюс брала на себя все общение с ОС и интерпретацию для процессора. Более того, JWM как платформа позволяла нам использовать разные языки программирования, просто после компиляции они должны превратиться в код, понятный для виртуальной машины. И тут у вас может возникнуть вопрос, а причем тут .NET?

А при том, что в 2000 году компания Microsoft сперва представила, а в 2002-м выпустила платформу .NET, в которую заложены все те же принципы, только в отличие от JVM, .NET работала исключительно для семейства операционных систем Windows, абсолютно игнорируя Linux и всех остальных.

Это, конечно, была не случайность, и Microsoft готовила .NET именно как ответ Java. В то время уже предполагалось (небезосновательно, как выяснилось в дальнейшем), что лицензирование Java для Microsoft не будет продлено в 2003 году (в 2003-м истекал срок выданной Sun Microsystems лицензии). Microsoft действовали на упреждение. Новая стратегия Next Generation Windows Services должна была объединить в единый набор существующие и будущие разработки Microsoft для предоставления возможности пользователям работать со всех беспроводных устройств, обладающих доступом в интернет, как со стационарных компьютеров.

Основное, на мой взгляд, что привнесла .NET, это общение через XML как стандарт. Что нам это дает? Главным образом то, что наш клиент и наш сервер могут быть написаны и работать на чем угодно. Это как выходцы из разных стран, которые общаются на общем английском. Но не стандартом единым, Microsoft еще и предоставила удобные инструменты для автогенерации XML, а ранее разработчики были вынуждены создавать их вручную.

Таким образом .NET позволила Microsoft замкнуть на себе весь процесс разработки как веб-, так и десктоп-приложений. У «майков» был свой веб-сервер IIS, который принимал запросы от пользователя и передавал их в ASP.NET, которая использовала как правило майкрософтовский SQL Server. Клиентом мог быть Internet Explorer, доминант той эпохи, или десктопные приложения, написанные при помощи WinForms. Microsoft сделала все, чтобы замкнуть разработчика на себе и на своих продуктах. Продукты между собой отлично взаимодействовали, а использование чего-то со стороны предполагало страдания.

Популярность .NET росла, в том числе за счет крупных корпораций. .NET зарекомендовала себя не только как стабильная и безопасная платформа. Но и как легко кастомизируемая вещь. То есть бизнес на базе этой платформы мог построить абсолютно любое приложение, плюс не нужно использовать компоненты от малоизвестных вендоров. Тут как в некоторых странах «все свое». Стоит отметить также любовь разработчиков к этой платформе, хотя, конечно, за поддержку только Windows их не критиковал лишь ленивый. В основном рост популярности давал ASP.NET со своими решениями для веб-приложений.

Вышедшие в 2009 году ASP.NET MVC и Web API были настолько хороши, что используются и поддерживаются до сих пор, правда, с припиской Core. Об этом поговорим дальше. Два этих фреймворка обеспечили .NET новый виток роста и дали сигнал всей индустрии.

Стоит отметить, что Microsoft никогда не зарабатывала на .NET напрямую. Сама платформа и ее компоненты, например ASP, были всегда бесплатными. Они зарабатывали на сопутствующем ПО, таком как сама операционная система Windows Server, база данных SQL Server, с которой так хорошо работал ASP.NET, и с самой среды разработки Visual Studio.

Но как бы ни был хорош .NET, его постоянно ругали за поддержку только Windows. Это попыталась исправить стороння компания Xamarin, и уже в 2004-м, то есть спустя всего два года после выхода, выпустила свою платформу Mono, которая принесла свет .NET и C# на устройства под управлением Linux. Имеющий кстати Linux как основу, Android использует до сих пор Mono для работы с приложениями, написанными на .NET. Это специальные приложения, адаптированные до этой платформы, тем не менее, написанные на чистом C# с использованием .NET API. Как ни странно, Microsoft не стала судиться, а позже подружилась с Xamarin и даже ее выкупила. С покупкой Xamarin начался новый виток развития .NET в сторону открытости и кроссплатформенности.

В 2016 году вышла первая версия .NET Core. Она позволяла запускать в начале только ASP.NET MVC, а позже и другие продукты на операционных системах от Apple и Linux. Помимо поддержки других систем, .NET Core имела множество других новшеств. Однако сообщество не сразу поверило в новинку и долгое время избегало ее, стараясь не отходить от канонов и от классики .NET. И их можно понять. После версии 4.5 и 2012 года особо ничего не менялось, каждый год мы получали новую версию. Тем не менее множество нужных фич, таких как поддержка асинхронности, уже была реализовано и не было запроса на изменения.

Все поменялось с приходом все большей компьютеризации и облачных вычислений. Потребности рынка росли, нужно было наращивать мощности. А обслуживание и лицензия на Windows сервера были довольно дорогими, в отличие от бесплатного Linux. Конечно, Linux более требователен в плане настроек, но есть облака, где можно легко поднять приложение на любой операционной системе и где все настройки уже сделаны до тебя. И бизнес начал считать деньги. Чтобы не потерять рынок, .NET была вынуждена адаптироваться. Конечно, плохо терять доходы с лицензий, но если переориентировать .NET уже под облако, то можно стричь доллары уже внутри облака. Поэтому переход на кроссплатформенность — это просто прагматичный шаг, а не милосердие.

.NET сейчас

Если вы интересовались .NET и читали последние новости, то не могли пропустить выход .NET 5. .NET 5 призвана убрать всю эту путаницу с двумя версиями .NET обычной и Core. Теперь .NET только одна и она кроссплатформенная, сочетающая в себе и классическую и версию Core. На этой картинке вы видите, что есть .NET сейчас.

Web

.NET по-прежнему верна паттерну MVC, если вы предпочитаете более олдскульные веб-приложения с полной генерацией HTML на сервере. Только теперь эти приложения работают под любой операционной системой и более не привязаны к Windows.

Так же как и ASP.NET Core API, который представляет собой обычную апишку, куда мы можем послать запросы и получить ответы как в JSON, так и по старинке в XML. Отлично работает с фронтенд-фреймворками типа Angular или React. Кстати, .NET плюс Angular — это классический стек и самый часто встречаемый. В эру больших веб-фреймворков, мобильных приложений, интернета вещей web API как никогда актуальны, и ASP.NET решает эту проблему отлично. Сейчас это самый популярный тип нового проекта.

ML

Стоит отметить и такой проект, как ML.NET, кроссплатформенную и открытую систему машинного обучения для разработчиков .NET. Разработчики могут обучать модель машинного обучения или повторно использовать существующую модель третьей стороной и запускать ее в любой среде в автономном режиме. Это означает, что разработчикам не нужно иметь опыт работы в Data Science, чтобы использовать фреймворк. Первый стабильный релиз фреймворка 1.0 был анонсирован в 2019 году. Так что это довольно свежий, но при этом уже стабильный инструмент. Дотнетчик или дотнетчица могут быть и дата-саентистами тоже.

Mobile

Помните ту самую Xamarin, которая замутила Mono? Так вот, они создали одноименный фреймворк для построения кроссплатформенных производительных мобильных приложений, используя .NET, C# и XAML. XAML — это язык разметки типа HTML.

Благодаря Xamarin в среднем 90% кода приложения может использоваться без изменений на разных платформах. С помощью этого шаблона разработчик может написать всю бизнес-логику на одном языке (или использовать существующий код приложения), но при этом получить характеристики производительности, оформление и поведение, характерные для каждой соответствующей платформы. Приложения Xamarin можно писать на ПК или Mac и компилировать в собственные пакеты приложений, например в файлы с расширением .apk для Android или .ipa для iOS.

Любой дотнетчик или дотнетчица могут быть и мобильными разработчиками тоже.

Desktop

Не оставила .NET в покое и десктопные приложения. У нас все также есть и поддерживаются WPF, WinForms и UWP. Есть, конечно, тут один минус, у всех их так или иначе проблемы с кроссплатформой. Их в принципе можно решить с помощью сторонних библиотек, но пока из коробки только винда. Поддержка всех платформ у WPF ожидается только с приходом .NET 6 (читай — не скоро). Однако если вам нужно ПО только под Windows, то это хорошие инструменты. А winform с большим выбором готовых кнопок, инпутов и так далее позволяет строить приложения ну очень быстро.

IoT

С недавних пор в семействе .NET появился новичок. .NET nanoFramework — это бесплатная платформа с открытым исходным кодом, основанная на .NET и предназначена для малых встраиваемых устройств, микроконтроллеров. С ее помощью можно разрабатывать различные устройства для интернета вещей, носимые устройства, научные приборы, робототехнические устройства, можно создавать прототипы и даже использовать на промышленном оборудовании.

.NET nanoFramework является малой версией «большого» .NET Framework, предназначенного для настольных систем. Разработка приложений ведется на языке C# в среде разработки Visual Studio. Сама платформа — исполнительная среда .NET-кода, это позволяет абстрагироваться от аппаратного обеспечения и дает возможность переносить программный код с одного микроконтроллера на другой, который тоже поддерживает .NET nanoFramework. Программный код на C# для настольных систем, без изменений или с небольшой адаптацией (необходимо помнить про малый объем оперативной памяти) исполнится на микроконтроллере. Благодаря этому разработчики на .NET с минимальными знаниями в области микроэлектроники смогут разрабатывать различные устройства на .NET nanoFramework.

Gaming

Как ни странно, но .NET-разработчику доступна такая опция, как разработка игр. Так как Unity — межплатформенная среда разработки компьютерных игр, поддерживает C# как язык написания игровых скриптов. Unity позволяет создавать приложения, работающие на более чем 25 различных платформах, включающих персональные компьютеры, игровые консоли, мобильные устройства, веб-приложения и другие. На Unity написаны тысячи игр, приложений, визуализации математических моделей, которые охватывают множество платформ и жанров. При этом Unity используется как крупными разработчиками, так и независимыми студиями.

Cloud

Microsoft вовремя адаптировалась и выпустила собственное облако Azure, с которым .NET работает чуть ли не из коробки. Там есть все что нужно для работы любого .NET-приложения (кроме прозрачного биллинга — Microsoft за что вы меня все время чаржите?). Плюс поддержка других языков и систем, конечно.

Что же ждет .NET в будущем

Я считаю, что надо:

1. Сделать .NET более понятным для новичков. Когда-то существовал язык, который, хотя и неуклюже, преодолевал разрыв между настоящими программистами и начинающими любителями. Но Microsoft несколько лет назад отказалась от Visual Basic, а заслуженная репутация Microsoft в области решений с закрытым исходным кодом помешала ей участвовать в образовании в пользу Java и Python. Маловероятно, что что-то, что делает Microsoft сегодня, быстро изменит эту ситуацию. Но некоторые из их целей по снижению входных барьеров в .NET интересны — в частности, идея создания учебной программы по информатике с открытым исходным кодом, которая могла бы выполняться полностью онлайн, то есть даже без Visual Studio, а просто в браузере. Как, например, это реализовано в Jupyter Notebook.

2. Реализовать использование Blazor на декстопе​. Платформа Blazor предназначена для создания интерактивного веб-интерфейса на стороне клиента с использованием .NET. То есть, по сути, создание многофункциональных интерактивных пользовательских интерфейсов на C# вместо JavaScript. Microsoft предложила возможность использовать его и при создании интерфейса десктопных приложений. Может ли это направление развиться во что-то вроде Electron? Пока непонятно, есть только предварительные эксперименты. Независимо от формы, разрыв в реализации различных типов приложений — мобильных, настольных и веб-приложений — остается одной из непреодолимых проблем .NET.

3. Улучшить экосистему .NET. Существует множество причин: некоторые практические, некоторые исторические — почему многие разработчики избегают сторонних инструментов при создании своего стека разработки .NET и используют только решения от Microsoft. Но если .NET будет продолжать развиваться, она должна помочь другим разработчикам добиться успеха, особенно тем, у кого есть проекты с открытым исходным кодом, которые может использовать все сообщество. Не существует единого шага, который решает эту проблему, но Microsoft может многое сделать, чтобы предоставить разработчикам открытого ПО лучшую поддержку, руководство и продвижение.

4. Увеличить скорость разработки​. Это включает в себя долгожданные улучшения, такие как горячая перезагрузка в ASP.NET и заблаговременная компиляция для Blazor. Но производительность разработки также охватывает более широкие вопросы, например скорость сборки проекта и компиляции кода. Это область, в которой, по словам Microsoft, конкурирующие платформы все еще вытесняют .NET.

5. Демократизировать ML.NET. Сегодня мы говорили о ML.NET, библиотеке Microsoft для машинного обучения в .NET. Многие разработчики попробовали это на пробном проекте. Но помимо этого? Разрыв между игрушечными примерами в ML.NET и практической интеграцией огромен — многие разработчики срываются с этого обрыва в момент энтузиазма. Разработчики Microsoft предложили множество небольших улучшений, которые могут помочь неспециалистам интегрировать функции машинного обучения в свои приложения.

.NET 5 уже сейчас предоставляет библиотеки, фреймворки, инструменты и API для создания, тестирования, запуска и развертывания программного обеспечения, предназначенного для всех платформ, включая Windows, Linux, IoT, macOS, iOS, Android, tvOS, watchOS и WebAssembly. А также все устройства, включая настольные компьютеры, веб-браузеры, устройства IoT, планшеты, мобильные телефоны и многое другое. Это серьезная экспансия, и я думаю, Microsoft ее потянет. Xbox же до сих пор жив.

👍НравитсяПонравилось7
В избранноеВ избранном4
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Ничего я не понимаю в ваших фронт-бэк эндах. Но скажу, что в 2002 это был очень правильный и своевременный шаг от майкрософт.
Помню мучения MS на рынке ПО для разрабочки в конце 90х -начале 2000х и как они проигрывали тому же борланду.
.Net Был значительным скачком в этом направлении.

Когда Винда десктопная была на руле, а у всех были кирпичи кнопочные.

Если что тот кирпич (Nokia 8210), весил 79g, какой сейчас телефон весит столько?)

Я имел ввиду скорее не вес, а то, что там звонить можно в основном только)

Неа, ну угадали, еще раньше, кирпичи были такие, с барабаном и модемом на 52к (jvc v90 был самый шик) рядом, мобилки только начали появляться.

Перспективы .Net нужно оценивать не с точки зрения приложений для пользователей, а прежде всего приложений для бизнеса!
Именно в этой нише Microsoft уверенно лидирует — потому что для бизнеса важнее пускай некрасивая и местами кривоватая система — но зато совместимая, надежная и покрытая поддержкой!
Золотое время MS было когда во всех компаниях работали на Windows + MS Office + IE. Базы были на SQL серверах, а все сайты — на ASP.Net. Единая экосистема, которая покрывала все нужды бизнеса.
К сожалению эта синергия дала трещину, когда MS проспала мобильную революцию! У сотрудников появились планшеты и айфоны — а MS нечего было для них предложить. Да и сайты под IE на них работали криво.
Поэтому первая и главная цель .Net сейчас это снова обеспечить единую платформу для разработки всех частей бизнес — системы: бэкенда, фронтенда и мобилы. Xamarin они уже купили, Type Script все больше похож на C#, возможно выстрелит Blazor.
Тот хаос, который творится в ентерпрайз приложениях, где все написано на .Net, а фронт-енд на модных Ангуляре или Реакте (пускай даже на Type Script) — еще долго придется разгребать. То, что в .Net есть «из коробки» и очевидно для применения, например: таймзоны, локализация, работа с валютами, инъекция зависимостей и плагины — во фронтенде делается через сторонние библиотеки и чаще всего через кастомные «велосипеды».
Яркий пример — это как MS переводили свои продукты с ASP.Net на модный SAP интерфейс. Помимо того, что в новом интерфейсе не сделали и половины возможностей старого — так еще и работает он в разы медленнее! Именно так: сходить за новой страницей ASP.Net на сервер оказывается быстрее и очевиднее, чем «на лету» перерисовывать контролы в Реакте. Это особенно грустно потому что пользователь никогда не знает что происходит: данных не видно потому что они еще загружаются? Ничего не происходит потому что событие потерялось и надо еще раз нажать на кнопку? Где-то внутри произошла ошибка и ждать бесполезно? Приложение обломалось при походе на сервер и показывает старые данные из локального кэша? Контролы вошли в вечный цикл обновления (на это в Реакте очень сложно не наступить)?
По-факту все что нужно бизнесу — это удобная технология для формошлепства! Простая и понятная даже для джунов. Как были винформы или вебформы. А еще лучше — как Делфи. При этом современный фронтенд ни разу не простой и не удобный и правильно на нем написать даже простые формы требует глубокого понимания особенностей Ангуляра или Реакта. Так что ниша нового фронтенд-фреймвока от MS (на замену ASP.Net) остается пока открытой.

Так я не пойму. Ты говоришь с одной стороны, что фуллстеки с .NET делают плохой фронт, с другой что бизнес хочет, чтобы были фуллстеки кругом ради экономии. Так что же делать? Золотую середину можешь дать какую-то в ответ?) Я работаю сейчас в компании где фуллстеки не работают, работал как фуллстек в других конторах. Все же понимаю, что без углубления в ASP.NET на бэке не получится из меня хорошего специалиста, который работает не только в монолитах как кусок глыбы, но и в микросервисах более-менее налаженных.

Золотая середина в том, что
— не всегда нужны микросервисы, high-load
— почти всегда достаточно средних фуллстеков, чтобы добится нужного результата

О, это видимо посыл мне пока что не смотреть на варианты high-load и микросервисы по работе. А если соглашаться, то будь добр, развивайся в этом направлении.

— не всегда нужны микросервисы, high-load

Особенно забавно когда насмотрятся картиночек с примитивных примеров где весь бекенд — микросервисы а потом пытаются натянуть это на реальный бизнес=)
Апи гейт + serverless для долгих тасок наше все.

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

Поясню почему фулстеки делают плохой фронт. Потому что для того, что бы делать ХОРОШИЙ фронт нужно не только знать целый зоопарк фронтендовских библиотек — но и иметь НАМНОГО больше опыта, чем на .Net!
Что бы сделать ASP.Net сайт достаточно прочитать одну книгу по .Net, взять готовый шаблон проекта и сделать все по примерам. При этом на этом сайте будет поддержка локализации, RTL языков, разных таймзон и валют, будет секьюрити, будет валидация, будет обработка ошибок и логирование даже если девеловер об этом ничего не знает. Потому что .Net — это готовый фреймворк для сложных бизнес-приложений, в котором все эти возможности предусмотрены изначально.
Теперь начинаем делать фронтенд приложение на Реакте или Ангуляре. Для того, что бы получить тот же набор обязательных в серьезном бизнес приложении вещей нужно найти, выбрать и правильно подключить 3 — 5 других библиотек. Про настройку вебпака, ноды, бабеля и всей фронтендовской билд-магии можно написать отдельную книгу (но еще не написали). Да и вообще я еще ни видел актуальной книги как написать ентерпрайз фронтенд с нуля. Возможно потому что мода на фронтенд фреймвоки постоянно меняется.
Глянем шире: как построить и документировать хорошую, слабо-связанную архитектуру на .Net я представляю прекрасно. Теоретически в Type Script есть почти все те же ООП фичи — но почему-то все приложения, которые я видел переставляли собой дикий микс из контролов, обработки событий и походов на сервер. Никакой внятной слабо-связанной архитектуры, а уж тем более «слоев», или модулей я не наблюдал. Возможно, потому что фулстеки просто не знали как это сделать на фронте.
Мое понимание ситуации: фронтенд фреймвоки разрабатывают что бы делать САЙТЫ. Но в бизнес-приложениях фронтенд это уже не сайт — а фактически полноценный «толстый клиент», который на клиенте делает массу бизнес-логики, а иногда и поддерживает офлайн базу. Поэтому ни один фронтенд-фрейвок не позволяет «из коробки» стартовать ентерпрайз — приложение с хорошей архитектурой.
Опять же: как написать десктоп бизнес-приложение на винформах или WPF есть масса книг и примеров. Как сделать такое-же, только на Ангуляре — даже не знаю где почитать.

Так что же делать?

Это же очевидно: дать возможность .Net девелоперам писать фронтенд так же, как они пишут десктоп или ASP.Net. С привычной объектной моделью и всеми фичами «из коробки». Тогда не нужны отдельные фронтендеры и дотнетчики не будут пытаться как-то слепить фронтенд по примерам со стекоферфлов. Эта идея лежит на поверхности: был Сервелат, теперь Блейзор — но в мире фронтенда MS сильно потеряла лидерство и поэтому продвигать свои идеи им трудно. В моде «чужие» Ангуляр и Реакт, которые делают без оглядки на .Net и без всякой совместимости.

Как вспомню, как я пытался решить проблему с датой и временем в разных проектах — аж мурашки по коже. А когда попробовал Blazor, то раз и проблемы никакой нет, она испарилась..

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

Вобщем неск раз поработав на фронте решил что пусть его месят тем кому нравится. Я на уютном бэке где все по полочкам разложено...

Проблема разделения вида и логики — стара как первый графический интрерфейс. Для нее придумано много патернов: Model — View — Controller, Model — View — ViewModel, Document — View и т.д.
Во фронте изначально такой проблемы не было вообще: потому что фронт был чисто представлением, а данные отправлялись на сервер. Возможностей налепить все вперемешку было немного.

акая-то лютая лапша в перемешку с событиями

Но сейчас веб — приложения это именно полноценные приложения (толстый клиент) с бизнес логикой и часто еще и офлайн базой на клиенте. И если для десктопа в .Net долго придумывали WPF с отделением XAML представления от observable модели и от команд на события, то во фронте такого решения «из коробки» просто нет. Какой бы модный фреймвок не взять — нужно его комбинировать еще с 2-3 библиотеками. А вот такое комбинирование правильно сделать сможет только фронтенд — гуру. Обычный фулстек взяв 2-3 фронтенд библиотеки от разных авторов скорее всего «скрестит ужа и ежа» и получит 5 колесный велосипед с разными колесами.
Вспоминаю как у одной из больших компаний был «свой» фронтенд фреймвок: это была дикая комбинация из JQuery, underscore, mustash, knokout и еще 5-10 модных на то время библиотек контролов. Никакой внятной логики как это все использовать не было — просто выбирай что тебе больше нравится.

Вобщем неск раз поработав на фронте решил что пусть его месят тем кому нравится. Я на уютном бэке где все по полочкам разложено...

Последнее время все больше склоняюсь именно к этому. Вернее — жду, когда фронт опять можно делать на дотнете, где «все по полочкам разложено».

А бывает, что в продуктовой компании есть прямо свой «JS-фреймворк», так что вокруг фронтэнда реально придумывается сейчас безумные велосипеды и костыли.

Поэтому первая и главная цель .Net сейчас это снова обеспечить единую платформу для разработки всех частей бизнес — системы: бэкенда, фронтенда и мобилы. Xamarin они уже купили, Type Script все больше похож на C#, возможно выстрелит Blazor.

Готов поспорить, что такой цели — вернуть всех полностью в экосистему майкрософта не стоит.
Цель по моему разумению стоит — если пишется приложение с использованием .net — то чтобы все оно хостилось в Azure. И для этого создается весь удобный тулинг и поддержка.
И все существующие решения перенести на виртуалки в ажур или мигрировать в какие-то гибридные варианты.

Я тут в рамках az-303 делал миграцию с Hyper-V, не сказал бы что это очень удобно. Еще помню .Net 5 не захотел через CLI в App Service паблишиться, но возможно cli не самая последняя.
Короче на счет удобности azure готов спорить, даже по сравнению с молодым google cloud.

UWP уже мертвее чем Winforms. Туда же поедет и блазор.

Блазор ни разу не «убийца JS». Останется в узком кругу .NET-чиков. Проблем хватает: performance, библиотеки, которые на проде юзать нельзя (из бесплатных), необходимость часто обращаться все к тому же JS за браузерным API и т.д.

Но недавно даже видел первую вакансию на Blazor, процесс идёт)

и последнюю вакансию силверлайта от той же компании?

Вроде бы Blazor не второй сильверлайт, но занимает нишу уже такую же)

У blazor есть преимущество перед silverlight: не нужно устанавливать фреймворк.

Посмотрим, но темп развития JS — фреймворков был заметно быстрее)

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

не согласен, фреймворк — это коробка с инструментами. Как молоток, пила, отвертки — так и в каком-нибудь условном веб-фреймворке — вот инструмент для общения с базой, вот клиент http, вот набор отверток для аутентикации и т.д.

клиент http — вот fetch вызывал и все
для общения с базой — indexedDB, webSQL, у них своё API, не орм там лепить же.

если посмотреть из чего состоит код js framework:
Vue — это на 50% механизм сравнения виртуал дома и эффективного перестроения реальных элементов. И механизм DefineProperty / Proxy.
React — тоже самое только без «DefineProperty / Proxy» руками это пиши, и размер библиотеки в 2 раза больше.
Angular — NgZone, компилятор темплейтов, и гора мусора абстракций.

Тоесть это не инструмент, это адаптер типа неудобного в удобное.

Все мы себе представляем примерно как можно на JS SPA написать без юзания фреймворков. А как же WebAssembly и Блэйзор? Получается должен быть вариант писать на C# напрямую с компиляцией в WASM. И все-таки мне непонятно, почему для доступа к браузерному API ничего не сделано средствами Blazor и не планируется даже? Это ограничения WASM? Вот пример для взаимодействия с local storage
await JSRuntime.InvokeVoidAsync("localStorage.setItem", "name", currentInputValue);
Cерьезно?? JS Interop для того, чтобы просто что-то записать в хранилище? Ну блин..

webassembly.github.io/...​/js-api/index.html#sample

Как видно, можешь импортировать только функции.
А что импортировать, всё на свете?

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

Реальное применение web assembly — это scandit или dynamsoft, недавно интегрировали, обработка QR и barcode разных форматов с камеры телефона, идёт видео поток, оно там рисует даже сверху на канвасе, где этот код, ну и скорость важна.

Однако здесь мы говорим про WASM чистый видимо без фреймворков, как я понял. Получается понимание WASM у меня складывается в выигрыше по производительности, но имея Blazor, где под капотом тот же WASM, то никакого выигрыша тут нет)) только в том, что радость есть от большого любителя .NET и C#.

Там будет скорее всего убийца електрона

Когда ж это дерьмо добьют, на убунте тимс вообще такое лютое говно шо ппц.

Дай обниму.

Но справедливости ради, Slack работает очень прилично. Так что проблема не в электроне, а в кривизне рук разработчиков.

Участвовал в разработке web-приложения на blazor. Веб до этого не любил, но на blazor мне, как приверженцу строго типизированных языков, намного приятнее писать, чем на javascript.
Тем более Telerik, DevExpress развивают компоненты для blazor.
И никаких проблем с производительностью нет.
Согласен, что останется только в узком кругу дотнетчиков. Так как все бегут на курсы javascript-формошлепов, чтоб научиться за месяц зарабатывать 2000$.

Дело не только в том, что кто-то ломится в АйТи из-за денег. Еще целый ряд компаний разделяют на проектах FE и BE — разработчиков. Эта система не изменится уже никогда думаю. Или фронтэндеры чистые вдруг захотят учить Blazor?) Не думаю)

Еще целый ряд компаний разделяют на проектах FE и BE — разработчиков. Эта система не изменится уже никогда думаю.

Очень много компаний НЕ разделяют на проектах FE и BE — а хотят «фулстеков»! Первопричина этого — потому что раньше, в эпоху ASP.Net не нужна была отдельная фронтенд команда! Бизнес справедливо не хочет платит два раза за то, за что раньше можно было платить один.
В итоге имеем или фулстеков, которые пришли из .Net и пишут на фронте жуткую дичь. Или фронтендеров, которых заставляют писать еще и бэк на ноде (с таким же результатом). Очень тяжело сидеть на двух стульях сразу — особенно если они разной высоты!

Хорошо, тогда зачем этот Blazor, если плодить фуллстеков это плохо?

пришли из .Net и пишут на фронте жуткую дичь

Вот писал ты год дичь, два, ну не выйдет же 10 лет писать на фронте дичь?)
Если этот чувак с 14 года пишет Ангуляр, ну наверное ж уже научился?)

За несколько лет работы фуллстеком нельзя назвать себя спецом хорошим и на бэке и на фронте. Вот на бэке пишут микросервисы, на фронте сложные взаимодействия строят между компонентами плоть до State менеджмента серьезного. И попробуй быть ОДНОВРЕМЕННО хорош и там и там, это по пять лет вчистую надо писать как на .NET, так и на Angular.

Ну если растёш со всем этим паралелльно, пока оно в зачаточном положении, то следить не так сложно.

Ну конечно! Если девелопер несколько лет писал на Ангуляр — то наверняка он уже знает какие библиотеки с ним использовать и как делать правильно. Опыт ничто не заменит — об этом и речь.
А кто такой «фулстек»? Это дотнет разработчик, которому сказали «вот ты написал бэк — теперь нужно писать фронт на Ангуляре! Не знаешь Ангуляра ?- пойди почитай.». А следующий проект через год уже надо будет писать на Реакте — потому что клиенту он больше нравится. В итоге фронтенд код такого фулстека на уровне дотнет кода джуна с годом опыта!
Получается что имеем портрет фулстек-синьора:
— 5 лет опыта в дотнет.
— 2 года опыта в Ангуляре.
— 1 год опыта в Реакте.
И его бэкенд код на уровне синьора с интерфейсами, инджекшином и тестами, а его фронтенд код на уровне «мой второй в жизни проект» на этом фронтенд фреймвоке.
И ладно бы в команде был хоть один фулстек с обратным опытом: 5 лет фронтенда и 2 года дотнета. Но фронтендеры редко учат дотнет что бы стать фулстеком. Поэтому получается что ни одного по настоящему опытного фронтендера в команде фулстеров нет — не у кого даже спросить как правильно делать!

Так я так прогорел в одной продуктовой конторе. Там требовался настолько кастомный фронтэнд, что здесь стандартные приблуды Ангуляра не спасали. Естественно фронтэндера опытного нет, а если и есть, то фуллстек якобы и застрял на «старом» JavaScript. Таким образом он придумал свой «фреймворк», естественно без документации, а кому она нужна, кроме его самого?) Он там теперь незаменимая «жемчужина» на продукте.

Так а что кастомного в нем было?
Я понимаю еще кастомный UI фреймворк запилить аля MaterialSuperUI2.0 но весь фронтенд — хз.

Он там теперь незаменимая жемчужина на продукте.

Так он молодец, теперь может придти и сказать 10к или ухожу.

Насчет кастомности там отдельная беда, как на мой взгляд. Это никак не вяжется с пониманием современного фронтэнда. Там в «архитектуре» заложен редактор JS-компонентов в админке (компоненты в понимании того продукта и разработчика его). Как ты думаешь они работают? Ну конечно же через eval(’любой код на JS’).

Ну eval это конечно жестко, очень. 6-8 лет назад уже все знали что это плохо да и не нужно.

Поэтому от меня и хотели решение, чтоб взять приложение, и чтобы после команды на админке можно было сразу изменения на проде использовать без новых билдов заказчику. Вот как настройки чего-то, но вместо них там исходный код — бизнес-правила. Здесь вебпак, настройка билдов выглядит просто лишним, мне настояли прибегнуть к eval. Согласен, такой бред, и я такой ужасной недоархитектуры больше нигде не увижу, надеюсь.

Я даже с коллегой по работе прикладывался, типа а что если в код, который вбивается в админку вбить какую-то мини-игру на JS?) А что, пусть юзеры хоть поразвлекаются, что-то увидят позитивное вместо, например, поиска по куче полей, который может намертво зависнуть))

Та можно было и мйнинг битков присунуть :-)))

Насчет «10к или я ухожу» — это не настолько рисковый парень) потому что он из тех людей, которые «нагреют» себе место в компании и не будут уходить до пенсии видимо.

В итоге что имеем? Техлидов из мира .NET, который и фронтэнд пишут и все говорят: «JS — фреймворки — г....». Если что-то пишется энтерпрайзное, то фрейморк начинает больше мешать, чем помогать.

Уже бы за время нытья какой сложный фронт купил курс на udemy и выучил долбаный реакт или ангуляр. Но нет, давайте уютные вебформы месить, обмазав толстым слоем джейквери для интерактива. Вот это по-нашему, не надо ничего учить 20 лет

Там чувак все время пишет про опыт, который на курсах не нарыть. Надеюсь, это сарказм.

Да какой опыт, он везде пишет что 100500 лет загнивает на каком то лютом легаси где он незаменимый специалист.

Все равно, выучить на курсах звучит так себе) написал бы — поучить на курсах и попробовать на реальных проектах, но лучше не во вред заказчику)

Начать с курсов потому что его суждение такие, как будто он вообще даже не пробовал написать hello world на spa фреймворке.
Понятно что надо писать учебный проект а там и откроются глаза на новое
Даже на тех же курсах на udemy (от автора maximilian schwarzmüller, например) доходчиво обясняют какие есть грабли в управлении состоянием и как их обходить.

Например вот тут сравнивают фремйворки по масштабируемости, пригодности в сервер рендеринг приложениях, производительности, пороге вхождения итд:
www.udemy.com/...​direct/?course_id=1208638
И это в самом базовом курсе.

Можно даже вкратце сказать, что JS и все что на нём завязано не пригодно для тяжеловесного Энтерпрайза. Сколько проектов, столько и решений (или велосипедов с костылями). Поэтому ряд девелоперов остаются на бэке, чтоб не видеть вот эту кашу из непонятных подходов взаимодействия UI и логики.

Как будто типичный проект написаный бекендером на webforms или asp mvc не состоит из мешанины костылей. В большинстве случаев там много хуже чем в спа фреймворках.

Кстати какраз SPA фреймворки сняли с бекендеров ненависную ношу реализации UI (что намного сложнее чем писать rest ендпойнты.)
В ангуляре и реакте какраз уже выработали шаблоны управления состояниев, в ангуляре даже dependency injection юзают. И там есть хоть какая то структура, в отличии от мешанины серверного рендеринга и джейквери подписок в 100500 мест как любят фуллстек бекендеры навоять (причем каждый городит по-своему)

Я согласен с тем, что разделение через rest отдельно, spa отдельно лучше, я говорю что мешанина лютая в самих spa. Я не призываю возвращаться к mvc приложениям. Я за то, чтобы сложный фронтэнд .net-чик не писал или на проекте был полноценный фронтэндщик, причем с хорошими знаниями и скиллами программирования. А фуллстеки пусть будут, если им это интересно, не в ущерб их работе на бэке. Фронты, которые вчера писали только вёрстку — втопку, мне такое тож не нравится.

Все от приложения зависит, например основная масса админок и мелких/средних приложух прекрасно ложатся на постраничный мвц, причем изи вобще, ангуляр, да и вообще спа, там — овериржиниринг.
СПА хорош там где очень много юзер стейт логики, динамической подгрузки данных...

Типичная админка тоже сейчас делается как SPA уже следуя тренду) хотя понятное дело, что может там это особо и не нужно. Вот если там довольно типичный UI можно даже использовать Blazor. Это сэкономит время и ресурсы. И если бэк на проекте хочет себя фуллстеком показать, то он может запедалить эту админку.

И я в его посылах вижу нотки олдскул разработки. Никакого там толстого слоя jQuery не было. Это были тонкие клиенты с понятной логикой любому бэкендеру. Старые добрые server-side приложения с рендерингом страниц чистых. То как Гугл придумали Gmail, сразу всем резко захотелось такой интерактивности. И судя по комментариям от зарубежных коллег в интернете, там не Ангуляр, там нечто свое под колпаком.

А как сейчас без интерактивности? Охота пользоваться интернет магазином который рефрешит все по каждому чиху?
Да, скажете что есть всякие Update panel в ASP, джейквери, только как приложение растет то и с управлением состоянием начинается такой треш, угар и содомия, что уже проще на SPA фреймворке сделать.

К тому же посмотрю потом как будет в .NET работать Hot reload. В мире JS эта фича 100 лет назад появилась и я когда пробовал Blazor, удивился что так нельзя, хотя пробовал Angular года 4 назад и уже Hot reload точно был.

Blazor нужен IL Linker. Без него он производительность не тянет похоже.

Возможно так. Но больше всего смущает, что почти на каждый чих нужно лезть в JS Interop. Почему нельзя сделать доступ к Browser API из Блэйзора прямо? Непонятно.

Сегодня Daniel обьяснил почему оно такое тормознутое, и вот теперь они его починят, но размер этой бороды, который и так огромен станет в 2 раза больше, лол

twitter.com/...​tatus/1433478410978791426

Решили пойти путем реализации AoT-компиляции вместо оптимизаций самого движка. Ну ок, только не думаю что будет прирост ощутимый. Вот есть смартфоны и мобильный браузер Chrome. Байда вся будет весить куда больше и с этим AoT мы разве получим быстрый запуск первый? Нет же походу. А я так надеялся, что в .NET 6 с первым запуском будет получше ситуация.

UWP та Winform на десктопі мертві, нова модна штука це WinUI 3. Вона, правда, і без дотнета може працювати :)

Я поражаюсь, что в вакансиях довольно крупных галер еще встречаю возможность поработать с WinForms, даже не WPF.

WinForms

На нем новых проектов начинается больше чем на UWP.

Сам только классические Win-приложения признаю, а не UWP-поделия. К тому же, у Майкрософт реально провал на мобильном рынке.

WinUI 3

Оно также сдохнет еще до того как библиотеки компонентов Devexpress/Telerik хотя бы наполовину обрастут мясом и пофиксятся самые вопиющие баги.

Колись то точно здохне, але не відразу. По-перше, це гарна альтернатива Winforms/WPF для класичних дотнетчиків, а по-друге це можливість зробити нативний, не дотнетний UI, якої у Microsoft не було вже з часів MFC. Така собі альтернатива Qt.

А кто сказал, что WinUI 3 приложения могут быть кроссплатформенными? Это развитие UWP с подключением традиционных системных API как в WPF допустим. Ты просто Qt упомянул, но там приложения могут быть сделаны под разные Десктопные ОС.

По-перше, це гарна альтернатива Winforms/WPF для класичних дотнетчиків,

Это вообще не альтернатива до тех пор пока не будет достойных контролов. Для того чтобы контролы стали достойными необходимо время. Несколько лет минимум. Но оно подохнет намного раньше.

Среди будущего .NET можно было написать еще про реализацию использования Blazor на мобайле рядом с MAUI.

Я смотрел анонсы blazor для мобилок, но не пойму, зачем оно надо, если есть xamarin/maui. Или это чтоб разрабатывать на blazor и для мобилок, и для браузера одновременно?

Это некий подход Hybrid Apps похожий на Ionic, но билды все же будут нативными, просто рендер Blazor-компонентов будет через обычный WebView.

Якось ви дужке сильно зім’яли 2000-ні, ну і видно, що технології, які вам нецікаві, вам нецікаві :-)
Скажімо, WPF то на свій час був прорив, ця технологія і зараз дещо може.

Мне кажется такой обзор должен был писать человек или группа людей с 17 годами опыта в .NET, а не 8.
И таких людей уверен предостаточно, например, автор этих строк)

Та й в мене самого чотирнадцятий пішов (до того я писав на Делфі) :-)

Даже я, который писал на ASP.NET 1.0, тогда правда 1.1 уже был популярен, это legacy был.
Не могу сказать, что имею право адекватно давать историческое описание для .NET Compact, ощущения от девелопинга на XNA, когда они только появились.

Я помню ощущения при выходе ASP.NET 2.0, какой это был прорыв.
Обалденные статьи Scott Gu. Появление и overuse термина Ajax, PrototypeJS, выход Atlas, Firebug — который был невероятен, по сравнению с возможностями debug в IE6.

Вообщем там надо было варится, чтобы что-то говорить об этом.
Плюс часто оказывается — что что-то очень «новое», это хорошо забытое legacy.

Но как бы ни был хорош .NET, его постоянно ругали за поддержку только Windows. Это попыталась исправить стороння компания Xamarin, и уже в 2004-м, то есть спустя всего два года после выхода, выпустила свою платформу Mono

Взять, например, это утверждение, это очень грубая не точность, и это скажет любой кто в глаза видел Mono в 2005-2010. Открываем wiki.

Xamarin is a Microsoft-owned San Francisco-based software company founded in May 2011[2] by the engineers that created Mono

Тоесть это детище Migelа, и Novell и SUSE намного больше к этому имело отношение.

Однако сообщество не сразу поверило в новинку и долгое время избегало ее, стараясь не отходить от канонов и от классики .NET. И их можно понять. После версии 4.5 и 2012 года особо ничего не менялось, каждый год мы получали новую версию. Тем не менее множество нужных фич, таких как поддержка асинхронности, уже была реализовано и не было запроса на изменения.

Сообщество избегало и не зря, достаточно посмотреть как кинули чуваков, которые побежали писать кодец на .NET Core 1. Переходить на версию .NET в которой, например, не было поддержки TransactionScope, пахло бредом. EF Core без поддержки GroupBy. Особенно забавно когда сейчас просят опыт .NET Core до 2019 года, тоесть больше 3 лет, хотя только ниндзи лезли девелопить там в 2016-2018 годах.

Взять, например, это утверждение, это очень грубая не точность, и это скажет любой кто в глаза видел Mono в 2005-2010. Открываем wiki.

Але Моно довший час був сміливим оупенсоурсом, який рухався незалежно від бажань MS.
А історія про те, як його бразильський автор не зміг отримати американську візу, то свого часу взагалі було мемом. Особисто я використовував Моно для дешевшого хостингу в 2013-2014, ми ще тоді мусили перейти з WebAPI на ServiceStack...

Сообщество избегало и не зря, достаточно посмотреть как кинули чуваков, которые побежали писать кодец на .NET Core 1.

Ага, книжка «Pro ASP.NET Core MVC» в мене просто зараз підставка під монітор :-)

Про Моно накинул бы пару тезисов.
1. WinForm — я не тестировал что-то сложное, но помню то чувство, когда exe сбилденный под .NET Framework, запускался на линуксе как ни в чём не бывало.
2. На Моно был написан Second Life, когда то это было довольно серьозное мультиплеер игруля, миллион юзеров. Что-то типа Roblox сейчас.

WebAPI на ServiceStack

В статье кстати, вообще не упомянуты существования alt.net: Castle, Nancy, на которых реально были вакансии.

я бы еще добавил что Mono дал жизнь MonoGame (en.wikipedia.org/wiki/MonoGame), и так же дал популярность Unity, так как в те года у них был свой форк Mono со своими фиксами

еще пытались написать свою Singularity, перевести файловую систему в винде на mssql и кодить системщину на с#

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

WPF классный, так как использует MVVM. Но производительность его хуже, чем у WinForms (хотя и здесь можно использовать MVVM, но биндиться из xaml намного удобнее, чем из визуального конструктора)

Только этот MVVM реализован не на уровне фреймворка, а прикручивается сторонними библиотеками или можешь сам его реализовать. Другое дело в ASP.NET MVC реализован классно, там програм-дизайнеры постарались. А так, как для меня WPF со своими классными UI-идеями загублен плохой программной архитектурой внутри. Выверхглазный XAML не хочется вспоминать с неинтуивным Binding-синтаксисом и навороченными Dependency Properties.
Мое мнение ссылаться может еще на эту статью: «Семь лет WPF: что изменилось?» habr.com/ru/post/165273
Можно переименовать статью на «Пятнадцать лет WPF: что изменилось?», ничего по сути не изменилось с того времени.

А так что должно было измениться, они уже давно декларировали, что это mature фреймворк и не будут туда ничего добавлять особо кроме фиксов. Они даже не стали имплементить последний стандарт xaml.
Он просто есть и все — бери пользуйся.

Вот и получается, что нет сейчас отточенного инструмента для Десктопа классического. Avalonia не совсем в счёт, ибо не имеет поддержки от самого MS. WinForms хорош для простого UI, все же просто сделать сложный UI там не получится.

Гарний огляд — мені, як людині, далекій від .net, зрозуміло.

Щодо десктопа на платформах інших ніж Windows
Там, кажуть, якась Avalonia є — щось відомо про неї? Наскільки вона придатна?

Щодо майбутнього п.1
Колись був (і до сих пір жевріє) проект IronPython. Він доволі сумісний із стандартним пітоном, за виключенням гострих кутів та платформо-специфічних ліб. На ньому навіть можна програмувати COM-automation (відкрити ворд і щось там поробити). Ще був IronRuby, але я про нього ніц не знаю.
Але чомусь Microsoft його відсунув із свого порядку денного, і він потихеньку загинається.
У них є щось на заміну йому?

Avalonia вполне себе работает, для прода пригодна

IronRuby та IronPython були відповіддю на JRuby та Jython. Була ідея на більше Iron мов(згадується IronLisp), Microsoft зробили фреймворк для цього, але потім перестали фінансувати, після чого IronRuby відразу загнувся.

Подписаться на комментарии