Blazor: Техническое введение

Original author: Steve Sanderson
  • Translation
Сегодня команда ASP.NET анонсировала, что проект Blazor был перемещён в репозиторий организации ASP.NET. Мы начинаем стадию эксперимента, чтобы понять сможем ли мы развить Blazor в поддерживаемый продукт. Это большой шаг вперёд!

image

Что такое Blazor? Это фреймворк для браузерных приложений, написанный на .NET и запускающийся с помощью WebAssembly. Он даёт вам все преимущества богатых современных одностраничных приложений (SPA), позволяя при этом использовать .NET от начала и до конца, вплоть до общего кода на сервере и клиенте. В посте с анонсом подробно описаны основные случаи применения, сроки и так далее.

В этом посте я хочу поглубже поговорить о технических деталях для тех, кому интересно как же это работает.

Запуск .NET в браузере


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

На данный момент WebAssembly поддерживается всеми основными браузерами, в том числе и мобильными. Это компактный байткод-формат, оптимизированный для уменьшения объема скачиваемых данных и ускорения исполнения. Несмотря на то, что многие разработчики могли бы так подумать, WebAssembly не привносит никаких новых проблем безопасности, так как это не обычные бинарные файлы (вроде x86/x64) — это новый формат, содержащий байткод, который может делать только то же самое, что и JavaScript.

Так как же он позволяет нам запускать .NET? Всё благодаря тому, что команда Mono добавила поддержку WebAssembly в свой проект. Если вы пропустили новости, то проект Mono стал частью Microsoft в 2016 году. Mono это официальный .NET рантайм для клиентских платформ (таких как нативные мобильные приложения и игры). WebAssembly это просто ещё одна клиентская платформа, поэтому вполне разумно, что Mono должно на ней работать.

Моно может запускаться на WebAssembly в двух режимах: режиме интерпретации и AOT.

Интерпретация


В режиме интерпретации рантайм Mono компилируется в WebAssembly, но ваши .NET сборки — нет. Браузер загружает и запускает рантайм, который в свою очередь может загружать и исполнять стандартные .NET сборки (обычные .NET .dll файлы), собранные обычным .NET тулчейном.

Диаграмма показывающая режим интерпретации

Это похоже на то, как для обычной CLR основное ядро распространяется скомпилированным в нативный код, который затем загружает и исполняет .NET сборки. Единственное ключевое различие в том, что десктопная CLR активно использует JIT-компиляцию для ускорения исполнения, в то время как Mono на WebAssembly работает ближе к классической модели интерпретации.

Ahead-of-time (AOT) компиляция


В AOT режиме ваше .NET приложение превращается в чистые WebAssembly бинарники сразу при сборке. В рантайме не происходит никакой интерпретации — ваш код выполняется как обычный WebAssembly-код. Этот режим всё ещё требует загрузки некоторой части рантайма Mono (таких низкоуровневых .NET сервисов как, например, сборка мусора), но позволяет отказаться от таких компонентов как парсер .NET файлов.

Диаграмма показывающая режим AOT

Это похоже на то, как с незапамятных времён утилита ngen позволяет AOT-компиляцию .NET сборок в нативный машинный код, или на недавно появившийся полноценный нативный AOT .NET рантайм — CoreRT.

Режим интерпретации против AOT


Какой режим лучше? Мы пока что не знаем.

Однако мы знаем, что режим интерпретации даёт гораздо более быстрый процесс разработки, чем AOT. После изменения кода вы можете пересобрать его обычным .NET-компилятором и получить обновлённое приложение в браузере в считанные секунды. AOT-компиляция, в свою очередь, может занимать минуты.

Очевидная мысль — режим интерпретации будет основным для разработки, а AOT — для продакшена.

Но всё это может оказаться совсем не так, потому что режим интерпретации, к удивлению, гораздо быстрее, чем вы могли бы подумать. И мы слышали от ребят из Xamarin, которые используют .NET для нативных мобильных приложений, что обычные (не AOT) .NET сборки очень маленькие и хорошо поддаются компрессии, в отличие от AOT-сборок. Мы будем рассматривать оба варианта пока у нас не появится возможность объективно оценить разницу.

Blazor, SPA фреймворк


Возможность запустить .NET в браузере это хорошее начало, но этого недостаточно. Чтобы быть продуктивным разработчиком приложений вам нужен последовательный набор стандартных решений для стандартных проблем — таких как создание/переиспользование UI, управление состоянием, роутинг, юнит-тестирование, оптимизация сборки и так далее. Всё это должно быть спроектировано вокруг сильных сторон .NET и языка C#, позволяя извлечь максимум из существующей экосистемы .NET и поставляться вместе с первоклассной поддержкой инструментов, как этого ожидает .NET разработчик.

Blazor это всё вышеперечисленное. Он вдохновлён сегодняшними лучшими SPA фреймворками, такими как React, Vue и Angular, а также некоторыми UI стэками от Microsoft вроде Razor Pages. Наша цель — дать веб-разработчикам то, что максимально хорошо сочетается с .NET.

Компоненты


Во всех современных SPA фреймворках приложения построены из компонентов. Компонент обычно представляет из себя какой-то UI элемент: страницу, диалог, набор вкладок или форму. Компоненты могут вкладываться друг в друга, переиспользоваться и разделяться между проектами.

В Blazor компонент это .NET класс, который вы можете написать напрямую (то есть как C# класс) или, что более принято, в виде страницы разметки Razor (.cshtml файл).

Появившийся примерно в 2010 году Razor это синтаксис для комбинирования разметки с C# кодом. Он создан специально для продуктивности разработчика, позволяя вам переключаться между разметкой и C# безо всяких церемоний, с полной поддержкой intellisense. В примере ниже показан простой компонент диалога, описанный в Razor файле MyDialog.cshtml:

<div class="my-styles">
  <h2>@Title</h2>
  @RenderContent(Body)
  <button onclick=@OnOK>OK</button>
</div>

@functions {
    public string Title { get; set; }
    public Content Body { get; set; }
    public Action OnOK { get; set; }
}

Когда вы будете использовать этот компонент, инструментарий знает что вам подсказать:

Анимированная GIF показывающая поддержку компонентов Blazor в инструментах

Многие шаблоны проектирования могут быть построены на этом простом фундаменте, включая популярные паттерны из SPA фреймворков вроде компонентов с состоянием (stateful components), функциональных компонентов без состояния (stateless components) и компонентов более высокого порядка (higher-order components). Вы можете вкладывать компоненты друг в друга, процедурно генерировать их, разделять между библиотеками, запускать юнит-тесты без необходимости наличия браузера и, в целом, жить хорошей жизнью.

Инфраструктура


При создании нового проекта Blazor предложит основные сервисы, необходимые большинству приложений:

  • Шаблоны
  • Роутинг
  • Внедрение зависимостей
  • Ленивую загрузку (то есть загрузку частей приложения по мере необходимости)
  • Юнит-тестирование

Важный аспект архитектуры — всё это опционально. Если вы что-то не используете — это будет удалено из итогового билда при публикации.

Другой важный момент — только несколько самых низкоуровневых частей находятся в ядре фреймворка. К примеру, роутинг и система шаблонов не такие — они реализованы в «юзер-спейсе», то есть этот код может быть написан разработчиком приложения без использования каких либо внутренних API. Поэтому если вам не нравятся наш роутинг или система шаблонов — вы можете заменить их своими. Наш текущий прототип системы шаблонов представляет из себя около 30 строк кода на C#, так что вы легко сможете разобраться и переписать его если захочется.

Развёртывание


Очевидно, что значительная часть целевой аудитории Blazor это ASP.NET разработчики. Для них мы выпустим middleware для прозрачного хостинга UI на Blazor с такими дополнительными возможностями как пререндеринг на сервере.

Не менее важны для нас и разработчики пока совсем не использующие .NET. Чтобы Blazor был жизнеспособен для разработчиков, предпочитающих Node.js, Rails, PHP или любую другую серверную технологию, а то и вовсе пишущих serverless-приложения — мы абсолютно точно не будем требовать наличия .NET на сервере. Результат сборки Blazor-приложения — папка dist, в которой лежат только статические файлы. Мы можете раздавать их со страниц Github, из облачных хранилищ, через Node.js сервера и вообще через что угодно.

Общий код и netstandard


.NET standard это способ описать уровень возможностей, предоставляемых .NET рантаймом или требуемых .NET сборкой. Если ваш .NET рантайм поддерживает netstandard2.0 и ниже, и у вас есть сборка нацеленная на netstandard2.0 и выше, то вы сможете запустить эту сборку на этом рантайме.

Mono на WebAssembly будет поддерживать netstandard2.0 или более высокую версию (в зависимости от сроков выхода). Это означает, что вы сможете использовать свои .NET библиотеки и на бэкенде, и в браузерных приложениях. К примеру, у вас может быть проект с классами моделей бизнес логики — его можно будет использовать и на сервере, и на клиенте. И, конечно же, вы сможете скачивать пакеты из NuGet.

Однако не все .NET API имеют смысл в браузере. К примеру, вы не сможете слушать произвольный TCP сокет, так что System.Net.Sockets.TcpListener не будет делать ничего полезного. Также вы практически наверняка не должны использовать System.Data.SqlClient в браузерном приложении. И это не проблема, так как, во-первых, браузеры всё-таки поддерживают API, которые действительно нужны людям для создания веб-приложений, и во-вторых, у .NET standard есть механизм обработки для таких случаев. При вызове не применимых для конкретной платформы API базовая система классов (BCL) будет выбрасывать исключение PlatformNotSupported. В начале это может приводить к проблемам, однако со временем авторы NuGet-пакетов внесут изменения в свои библиотеки для поддержки разных платформ. Если .NET хочет двигаться в сторону самой бурно развивающейся платформы приложений в мире — это ступень, на которую придётся подняться.

Совместимость с JavaScript/TypeScript


Даже если вы пишете браузерное приложение на C#/F# — иногда бывает нужно подключить чужую JavaScript библиотеку или свой собственный код на JavaScript/TypeScript для вызова какого-нибудь нового браузерного API.

Это должно быть очень просто, так как стандарт WebAssembly спроектирован чтобы взаимодействовать с JavaScript (и это неудивительно) и мы можем легко использовать это в .NET коде.

Чтобы работать с чужими JavaScript библиотеками мы исследуем возможность использования определений типов TypeScript в C# коде с полным intellisense. Это сделает около 1000 самых популярных JS-библиотек очень простыми для интеграции.

Текущий подход для вызова чужих библиотек или вашего JS/TS кода из .NET это регистрация именованной функции в JS/TS файле. Например:

// Это JavaScript
Blazor.registerFunction('doPrompt', message => {
  return prompt(message);
});

… и затем создаём обёртку для вызова из .NET:

// Это C#
public static bool DoPrompt(string message)
{
    return RegisteredFunction.Invoke<bool>("doPrompt", message);
}

Подход с registerFunction имеет приятный бонус в виде хорошей работы с JavaScript-сборщиками вроде Webpack.

И, чтобы поберечь ваше время и нервы, команда Mono работает над библиотекой, которая пробросит стандартные браузерные API в .NET.

Оптимизация


Исторически .NET фокусировался на платформах, где размер приложения не такая уж большая проблема. Не имеет большой разницы весит ли ваше ASP.NET приложение 1МБ или 50МБ. Это средней степени проблема для десктопных или мобильных приложений. Но для браузеров размер загрузки очень критичен.

В защиту можно сказать, что .NET на WebAssembly скорее всего будет загружаться всего один раз. Ведь можно использовать стандартное HTTP кэширование (или даже модные штуки вроде service worker) чтобы гарантировать, что пользователь загрузит ядро рантайма только единожды. А если использовать CDN, то пользователь и вовсе может использовать результаты одной загрузки сразу в нескольких приложениях.

Всё это хорошо, однако я не думаю, что этого достаточно. Если рантайм будет весить 20МБ, то это всё равно слишком много, даже для единоразовой загрузки. Это же не браузерный плагин в конце концов — это обычное построенное по стандартам веб-приложение. Даже самая первая загрузка должна быть быстрой.

Поэтому мы прикладываем много усилий для уменьшения размера загрузки. Мы видим следующие 3 фазы оптимизаций:

1. Уменьшение рантайма Mono


Рантайм Mono содержит много специфичных для десктопа возможностей. Мы надеемся, что Blazor будет содержать урезанную версию Mono, которая существенно меньше, чем полный дистрибутив. При ручной попытке оптимизации я смог удалить около 70% из .wasm файла рантайма без нарушения работы базового приложения.

2. Уменьшение IL кода при публикации


Компоновщик (linker) .NET IL (основанный на компоновщике Mono) выполняет статический анализ, определяя какие части .NET-библиотек могут быть вызваны из вашего приложения, и удаляет всё остальное.

Это похоже на tree shaking в JavaScript, за разницей в том, что IL-компоновщик гораздо более точен и работает на уровне отдельных методов. Это позволяет убрать весь неиспользуемый код системной библиотеки, что даёт огромную разницу в большинстве случаев, часто уменьшая размер приложения ещё на 70+%.

3. Компрессия


Ну и наконец, самое очевидное — мы ожидаем что ваш сервер поддерживает HTTP-сжатие. Это обычно срезает ещё 75% объёма.

Конечно, веб-приложение на .NET никогда не будет таким же миниатюрным как простейшее приложение на React. Наша цель состоит в том, чтобы сделать его настолько небольшим, что обычный юзер на среднем подключении не заметит даже самой первой загрузки, не говоря уже о последующих загрузках из кэша.

Так и зачем это всё нужно?


Нравится это вам или нет, но веб-разработка сильно изменится в ближайшие несколько лет. WebAssembly позволит веб-разработчикам выбирать из гораздо большего списка языков и платформ, чем когда либо. И это хорошо — наш мир наконец-то взрослеет. Разработчики серверного ПО и нативных приложений всегда могли выбирать язык и парадигмы, которые лучше всего подходят для решения их проблем, соответствуют культуре команды и подкреплены имеющимися знаниями. Мечтаете писать функциональщину на Haskell или Lisp для вашего финансового приложения? Хотите немного низкоуровневого C? Вы Apple-разработчик и хотите продолжить использовать свои знания Swift? Всё это придёт в веб.

Не пугайтесь. Это не значит, что вам нужно будет знать все эти языки. Это значит, что все мы станем обычными разработчиками ПО. Ваши текущие знания программирования для браузеров по прежнему актуальны и ценны, но у вас появятся новые пути выразить свои идеи и больше точек соприкосновения с другими сообществами разработчиков.

И наша инициатива состоит в том, чтобы поставить .NET в авангард этого движения, а не тащиться позади, отставая на годы.

Текущий статус


Чувствуете желание попробовать? Притормозите — мы всё ещё на очень ранних стадиях проекта. Пока ещё ничего не готово для скачивания и многое из вышеописанного в процессе разработки. Большинство из вас должны просто расслабиться и подождать, первые пре-альфа билды появится примерно через месяц.

Помните, на данный момент Blazor — эксперимент для команды ASP.NET. Нам потребуется несколько месяцев чтобы понять сможем ли мы сделать из него полноценный, поддерживаемый продукт. Мы ещё ничего не обещаем, поэтому не надо строить свои бизнес-планы вокруг Blazor!

Если же вы сильно заинтересовались, то посмотрите в репозиторий, попробуйте собрать его, позапускать тесты и приходите пообщаться с нами. Можете даже поискать // TODO комментарии и прислать Pull Request, или поделиться идеей о клёвой фиче.


От переводчика


В заключение приведу несколько интересных ссылок:

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

More
Ads

Comments 46

    +5

    Это что же, вскоре JS познает что такое настоящая конкуренция? Дожили наконец-то!

      +3
      А ещё это позволит бэкенд-разработчикам писать что-то для браузера без содрогания и боли =)
        0
        В этом интервью об этом есть немного
        WebAssembly with Brendan Eich
          +1

          Да уж познавали, и не раз:



          Рынок большой, места хватит всем, найдется и для Blazor.

            0
            Есть ещё много таких:
            fable.io
            bridge.net

            но это всё не то.
              0
              Нет, это даже близко не конкуренция.
              Все подобные решения в прошлом обладали огромными техническими проблемами:
              — раздутый бандл на ровном месте (и пока это все еще правда, да);
              — медленное исполнение по сравнению с js;
              — ужасный дебаг (можно сказать, что почти отсутствующий);
              — сложность реализации адекватного транспайлера из сложного языка в js;
              — отсутствие возможности хоть как-то управлять памятью;

              Но есть еще более важные, не технические проблемы:
              — во все давние попытки вкладывали очень мало денег;
              — раньше в вебе сложность задач была скажем так не очень большая, чтобы имело смысл городить какую-то сложную инфраструру;

              WebAssembly снимает огромную нагрузку с плеч разработчиков подобных языков. А сложность задач растет
                0

                Недавно как раз перевод статьи опубликовал: Возможно, вам не нужен Rust, чтобы ускорить ваш JS.


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


                В UI-логике и работе с DOM API особого преимущества тем более ждать не стоит.

                  0
                  Статья хорошая. Но как пример микрооптимизаций.
                  Давайте начистоту: то, что WebAssembly вообще показывает хоть какие-то реальные цифры это есмь случайность. Технология сырая, молодая, никому пока не нужная (в прикладном бизнесе). Пытаться сравнивать по перфомансу WebAssembly и JS сродни сравнению интеллектуальных способностей ребенка и подростка.

                  По сравнению с чистым JS технологии построенные поверх WebAssembly будут обладать следующими фичами:
                  — возможность агресивной оптимизации во время компиляции (практически отсутствует в JS благодаря его интерпретируемости);
                  — zero-cost абстракции;
                  — более адекватная работа с расположением объектов в памяти, а не «надеемся, что V8 как-то все разрулит»;
                  — меньше затрачиваемой памяти (что оказывает влияет на быстродействие системы);

                  И да, во многих приложениях это все окажется несущественным. Но в то же время полноценные приложения смогут жрать меньше в 2-4 раза памяти, цпу, батареии.
            +1
            Вах какой новост!!!
            Будет интересно когда другие платформы вступят в гонку. Не удевлюсь если React как ViewEngine на .NET появится, а «back-end в front-end»-е ASP.NET Core оставят :) Или можно ещё помечтать и WPF во всей красе увидеть. А если приглядеться ещё к этой новости Welcoming Progressive Web Apps to Microsoft Edge and Windows 10, то могут наверное чудеса произойти.
              +1
              Если WPF сможет трансформироваться в корректный DOM — почему нет? Главное понимать, что какой бы магией это не казалось, запускается оно всё в браузере и должно жить по его правилам.
                0
                Вы не путайте понятия XAML и WPF. XAML можно трансформировать в HTML. Но вот графический стэк WPF трансформировать в Web не только сложно, но и вредно. Графика WPF с retained mode для веба хуже значительно, чем immediate mode от (Web)OpenGL.
                0

                React как способ порождения View для .NET уже давно существует — https://reactjs.net/. Тот факт, что он не оформлен в виде ViewEngine ещё не мешает за 15 минут написать метод, возвращающий ActionResult, использующий для рендеринга только реакт.

                  0
                  Да это уже давно, я имел в виду что сам реакт на шарфе напишут. Идея виртуального дума очень прикольная, иммутабельностьб компоненты и всё такое. Скоро запилят API чтоби с WASM c DOM-ом общаться или что то в этом направлении. Помнию читал где то статеику про такое.
                  0

                  Не во всей красе и не WPF, но XAML https://github.com/praeclarum/Ooui/wiki/Xamarin.Forms-with-Web-Assembly

                  +2
                  .Net платформа решила всю инфраструктуру под себя взять?:)
                    +3
                    Microsoft понимает, что они нехило так профукали рынки мобильных, кроссплатформенных и веб приложений. Вот и пытаются навёрстывать. Xamarin, .NET Core, TypeScript, а теперь вот и Blazor. Довольно приятно видеть, что в нынешнем Microsoft даже такой just-for-fun проект как Blazor можете получить поддержку и ресурсы для дальнейшего развития.
                      +2
                      Ну я в целом рад такому подходу. Один язык и масса ему применений. От веба до игр(Unity).
                        +2
                        Язык даже и не один. Подойдёт любой язык CLR-семейства.
                          0
                          + Подойдёт любой язык DLR-семейства… IrpnRuby, IronPython, Iron%WhatEver%.
                    +3
                    Silverlight второе пришествие :-)
                      +4
                      Но на этот раз без плагинов и на открытых стандартах!
                        0
                        «Без СМС и регистрации»
                      +4
                      Отличная новость! Искренне буду рад если .NET займёт часть данного рынка.
                        +4
                        Чтобы работать с чужими JavaScript библиотеками мы исследуем возможность использования определений типов TypeScript в C# коде с полным intellisense. Это сделает около 1000 самых популярных JS-библиотек очень простыми для интеграции.

                        Это, просто, потрясающе. Я не могу подобрать слов.
                          –1
                          Опять теже грабли, проходили же уже GWT.
                            +4
                            Но это ведь не совсем GWT. GWT компилировал Java в JavaScript, что накладывает свои ограничения. А если учесть каким был JavaScript ещё лет 5 назад, то трансляция джавы кажется ещё более ужасной идеей. WebAssembly же этой некий байт-код, на который отлично ложится компиляция того же дотнета или джавы, которые итак в собственный байт-код собираются. Ну и это открытый стандарт, который развивается силами разных компаний. Думаю в данном случае мы получим совсем другой результат. По крайне мере хочется в это верить.
                              +1
                              Если scalajs, kotlin js и аналоги таргетились в Js, то теперь таргетинг — WebAssembly. Это вроде и здорово, но как только вспоминаешь, что с DOM особо не поработать, то появляются вопросы, надо ли это всё.
                                +1

                                Это в теории звучит прекрасно. А на практике есть демо страница: https://blazor-demo.github.io/ (тут исходники)


                                На ней грузится 1,5 мегабайта WASM файлов, чтобы показать нам "Hello world". Проект еще на ранней стадии и это понятно, но все равно каких-то киллер фич не видно. Да и WebAssembly там используется скорее ради хайпа, чем какой-то реальной выгоды в скорости.


                                Еще можно почитать статью по теме: WebAssembly и манипуляции DOM, где анализируется производимый байткод разных компиляторов.

                                  0
                                  Если уж на то пошло, то хеллоу ворлд на ангуларе будет не сильно меньше весить =) Как они сами говорят, у них есть реализация Mono на asm.js, но она гораздо медленее wasm-версии, так что выгода в скорости заявляется. Киллер-фича тут в том, что можно прям в браузере юзать библиотеки, авторы которых никогда и не думали, что кто-то их будет так запускать.
                                    0

                                    Все это имеет смысл, только если производительность покажется на приемлимом уровне. Пока нет тестов производительности и сравнения с другими технологиями, сложно о чем-то говорить.


                                    Вполне может оказаться, что решение транслировать код в чистый JS без WASM окажется быстрее, потому что делать вызовы WASM и обратно — это дорогая операция.

                                +1
                                А GWT вполне себе живой и с версии 2.8 где есть новый jsinterop, я не вижу принципиальных отличий от TypeScript (кроме языка :-))
                                +1
                                www.webtoolkit.eu/wt — вот вам еще одна попытка сотворить невозможное, но уже на базе С++ :)
                                  +3

                                  Я уже путаюсь во всяческих реализациях .NET


                                  • .NET Framework, .NET Core — понятно.
                                  • Mono — оно сейчас развивается независимо от .NET Core/.NET Framework и имеет независимую кодовую базу, реализующую все то же самое? Или нет?
                                  • Xamarin — это на основе Mono
                                  • UWP, WinPhone и прочая плеяда мертворожденных технологий — по-идее их базируется на .NET Framework?

                                  Или я что-то не понимаю?


                                  А новость очень крутая. Я джва года Я давно ждал чего-то подобного.

                                    +1
                                    Mono — это альтернативная, кроссплатформенная реализация .NET Framework. На момент покупки майкрософтом, был почти полностью реализован .NET 4.5 (с некоторыми исключениями, вроде асинхронности и платформенно-зависимых частей).
                                    Именно благодаря Моно появился Xamarin.

                                    .NET Core — это переписанный «с нуля» .NET Framework, более легкий и кросс-платформенный.
                                    • UFO just landed and posted this here
                                        0
                                        Я, конечно, в Microsoft не работаю, поэтому о таких планах не осведомлён. Однако, насколько я понимаю позиционирование, то Mono уже практически никак не отделяется от Xamarin и будет развиваться именно для присутствия на мобилках и в играх. Ну и вот, видимо в браузере.

                                        .NET Core это кроссплатформа для бэкенда.

                                        .NET Framework это виндовс-приложения.

                                        UWP это такой .NET Core для приложений в сторе с мордой на WPF. Так как WPF стандартизовали, то возможно со временем они UWP и превратят в надстройку над .NET Core.

                                        Простой ASP.NET всё ещё поддерживается, но есть ощущение, что это теперь Legacy, который никак развиваться не будет. Как только они более-менее догонят его по фичам в ASP.NET Core, то начнут совсем активно продвигать миграцию и минимизировать усилия по поддержке.

                                        Но это лишь мои мысли и догадки. Нынешний Microsoft, конечно, неплох, но если вспомнить чехарду с ASP.NET 5, Core, DNX, DNVM и этим всем — чёрт его знает, что они ещё могут выкинуть =)

                                        • UFO just landed and posted this here
                                            0
                                            И одновременно с вашими предположениями MS шлет привет и мочит, например, новую структуру проектов на базе json, которая пришла вместе с Core. Что не добавляет уверенности относительно их планов на Core.

                                            Я, в общем, про это в конце и написал.

                                            Смысл Mono при наличии Core тоже не понятен. Вроде бы это была открытая реализация .Net. А теперь у нас их две и обе у MS: Mono и Core.

                                            Всё-таки Mono умеет работать там, где не умеет Core, плюс имеет гуёвый и мобильный стэк построенный поверх себя. Быстро перенести Xamarin на Core видимо не получится, поэтому пока что Mono будет жить.

                                            Ну а ASP.Net только ленивый не пинал: каждый, абсолютно каждый релиз — это на самом деле новый продукт, просто называние похоже.

                                            1.1, 2.0, 2.1 — с точки зрения ASP.NET Core разработчика это не особо крупные обновления. Они хорошие, полезные, но это не разные продукты. Миграция с 1.1 на 2.0 занимала иногда считанные минуты. Заменить project.json на csproj это не катастрофа. Вот между бетами и релиз-кандидатами — там да, были сильные изменения.

                                            Но от компании (а не от кучки ночных красноглазиков) требуется именно разбор завалов и очень четкая стратегия. А ее нет.

                                            С другой стороны большая компания может себе позволить одновременно развивать много направлений и обмениваться успешными наработками.

                                            И акции их продам. Что и всем остальным советую.

                                            Начали за здравие, закончили за упокой.
                                              +1

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

                                              • UFO just landed and posted this here
                                                  0
                                                  ASP.NET Core 2.0 — это фикс к какому «уже существующем проекту»? Удовлетворит ли он главному критерию фикса — полная обратная совместимость?

                                                  Если бы совместимость не ломалась — его бы 1.2, а не 2.0. Разный продукт и потеря совместимости это разные вещи.

                                                  Как этот новый очень быстрый продукт соотносится с продуктом ASP.NET (по названии вроде бы почти одно и то же).

                                                  Это развите идей ASP.NET. Но это не новая версия. А ещё Java и JavaScript тоже похоже называются =)

                                                  А ещё моё любимое: как там в новом проекте с базовой внутренней библиотекой Owin? Если у меня код пользуется Owin во всю, я смогу его использовать в ASP.NET Core 2.0?

                                                  Вроде как вполне — www.nuget.org/packages/Microsoft.AspNetCore.Owin
                                                  • UFO just landed and posted this here
                                                      0
                                                      Какой критерий по которому можно отнести 1.2 и 2.0 к одному продукту? Название? Есть где-то официальный список обратных несовместимостей — вроде сломалось — A, B, С? (Как это делают все нормальные команды и компании)


                                                      Общий код? Общий API с частичной несовместимостью? Что вам ещё нужно? Список несовместимостей очевидно есть, вместе с гайдом по миграции — docs.microsoft.com/en-us/aspnet/core/migration/1x-to-2x

                                                      Правильно ли я вас понимаю, что разработка в ASP.NET (не Core — да-да, мы так должны всегда оговариваться из-за того, что бардак, который вы не хотите признать) — это не развитие идей ASP.NET? Если там есть развитие идей, то каких? Если это развитие идей ASP.NET — то получается целых два проекта для развития одних и тех же идей? Ну и на сладкое: вот этот вот Blazer вкрутили в какой из продуктов (ASP.NET не Core как я понимаю)? Он будет везде или только кое-где? Какая логика в этом? «Здесь — читать, здесь — не читать, а здесь мы рыбу заворачивали.»


                                                      ASP.NET вроде как и не развивается. Там только баги какие-то фиксят. Вся работа идёт только над Core. Blazor пока никто никуда не вкрутил, это сторонний, к тому же экспериментальный, проект. Как и было написано в статье — есть планы предоставить удобную интеграцию для ASP.NET Core проектов. Но для самого Blazor никакой ASP.NET Core не нужен.

                                                      Ага, гуглить я умею. Повторю вопрос: Если у меня код пользуется Owin во всю, я смогу его использовать в ASP.NET Core 2.0? Как Microsoft.AspNet.WebApi.Owin связан с Microsoft.AspNetCore.Owin? Как там с портированием кода при переходе с одной библиотеки на другую? Список несовместимостей? Или это тоже разные продукты? Ну вроде как просто называются Owin?


                                                      Owin это стандарт, есть реализация его поддержки в ASP.NET Core. Вот можете тут почитать — docs.microsoft.com/en-us/aspnet/core/fundamentals/owin. У меня owin нет, с его миграцией я не сталкивался.
                                                    0
                                                    Вы бы еще спросили как ASP.NET Core 2.0 соотносится с ASP, и как там дела с совместимостью :-)
                                                    • UFO just landed and posted this here
                                                0
                                                Mono… Ну и вот, видимо в браузере.
                                                А еще есть CoreRT и среди архитектур там упоминается WASM. И там же есть пример c MonoGame, а какая связь между Mono и .NET Core runtime мне пока не ясно.

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