Aspnetcore: Разделите .NET Core для WASM Experience от Blazor

Привет, @EisenbergEffect! Основная работа над WebAssembly выполняется командой Mono. Мы создаем Blazor на основе того, что они предоставляют. Другие участники сообщества .NET также могут делать это бесплатно, и некоторые из них уже это делают ( Ooui , Uno , cshtml5 ). Вы можете следить за развитием mono.wasm в репозитории Mono .

Меня очень не интересует компиляция Mono в WebAssembly. Меня интересует только .NET Core. Я прошу примерно следующее:

• Используйте .NET CLI для создания проекта .NET Core C #.
• Используйте .NET CLI, чтобы скомпилировать мой проект .NET Core в WASM, имея 3 выхода, описанные выше.

@ danroth27 Это поддерживается сегодня?

Ребята из Mono также работают над полной опережающей компиляцией кода .NET для WebAssembly вместе с поддерживающим MSBuild SDK. Последнее обновление, которое они опубликовали, было http://www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/. @mhutch , вероятно, лучший контакт для получения последней информации о статусе.

Меня не интересует Моно. Меня интересует только .NET Core. Есть ли история для .NET Core WASM?

Есть ли история для .NET Core WASM?

Не сейчас. .NET Core сегодня в основном используется для кроссплатформенных серверных сценариев. Mono - это среда выполнения .NET, используемая сегодня для кроссплатформенных клиентских сценариев (Android, iOS, macOS, игры). Большинство сценариев WebAssembly сегодня - это клиентские сценарии, поэтому Mono - самый дешевый способ продвижения вперед прямо сейчас. Со временем разумно ожидать сближения, но это займет некоторое время.

FWIW Я действительно думаю, что в первую очередь необходимо решить проблему времени выполнения и целевых платформ. Когда я слышу, что мне нужно использовать два разных варианта .NET для создания приложения ... использовать Mono для вашего клиента, а затем использовать .NET Core для вашего сервера ... это меня совсем не волнует. Я просто хочу использовать .NET Core и, честно говоря, забываю о существовании любых других .NET. Один .NET пожалуйста :)

@EisenbergEffect с точки зрения потребителя должен быть в значительной степени деталью реализации, в которой среда выполнения запускает ваш код.

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

@ danroth27 Просто немного отзывов от моей команды разработчиков, мы также хотели бы, чтобы Blazor в конечном итоге использовал .NET Core. Нас не интересует Mono или даже полная платформа .NET. Нам нужна одинаковая среда выполнения на клиенте и сервере.

Нас не интересует Mono или даже полная платформа .NET. Нам нужна одинаковая среда выполнения на клиенте и сервере.

Что ж, независимо от того, что мы делаем, у вас не будет точно такой же среды выполнения на сервере и в браузере: среда выполнения браузера должна быть основана на WebAssembly, а серверная - нет. Это похоже на то, что работа на iOS принципиально отличается от работы на сервере. Объединяющим фактором на клиенте и сервере является .NET Standard. Тем не менее, я думаю, что мы разделяем вашу цель, заключающуюся в желании унификации для единой имплементации среды выполнения. В долгосрочной перспективе Microsoft не имеет смысла владеть и поддерживать две среды выполнения по удвоенной цене. Работа по сближению уже происходит во многих отношениях. Все больше и больше кода в Mono и .NET Core используется совместно. Но переход к единой среде выполнения по-прежнему является серьезным трудом, на который уйдет некоторое время.

А пока Blazor - это эксперимент, и мы экспериментируем с тем, что можно заставить работать сегодня 😃

@ danroth27 Спасибо за отличный ответ, Дэн!

Отлично, полностью согласен

Во вторник, 15 мая 2018 г., 10:54, paulost [email protected] написал:

@ danroth27 https://github.com/danroth27 Спасибо за отличный
ответ, Дэн!

-
Вы получаете это, потому что подписаны на эту беседу.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/aspnet/Blazor/issues/835#issuecomment-389046589 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/ACnwPz_cCiVg6iti9VR9pQWY34_Hibf4ks5tymapgaJpZM4T-jpA
.

@EisenbergEffect У меня было

Чтобы получить только компоненты среды выполнения браузера:
https://jenkins.mono-project.com/job/test-mono-mainline-wasm/label=ubuntu-1804-amd64/

... Теперь я возвращаюсь к созданию собственного стека пользовательского интерфейса на основе XAML на C #, ориентированном на WebGL.

Чтобы быть ясным, речь идет не об использовании технологий сторонних разработчиков. Речь идет о желании использовать только .NET Core. Я ищу один кроссплатформенный .NET с открытым исходным кодом и унифицированным кроссплатформенным интерфейсом командной строки. Не два или три .NET или несколько компиляторов. Я мог подумать, что новые усилия будут сосредоточены вокруг .NET Core и унификации, поэтому меня удивило, что WASM предназначен только для Mono и требует другого набора инструментов.

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

Я говорю это со всей искренностью, я хочу снова полюбить .NET. Пожалуйста, отнеситесь к этому серьезно.

Я говорю это со всей искренностью, я хочу снова полюбить .NET. Пожалуйста, отнеситесь к этому серьезно.

Мы серьезно относимся к этой проблеме и активно работаем над конвергенцией различных сред выполнения .NET. Но это займет время, и мы вполне можем решить, что в краткосрочной перспективе из практических соображений имеет смысл перейти к Mono с более длительным планом конвергенции с .NET Core.

Мне все еще нужны 3 .NET для создания моих сервисов и клиентов

Я предполагаю, что вы имеете в виду три .NET Framework, .NET Core и Mono. Хорошая новость заключается в том, что мы объявили на BUILD, что .NET Core 3 будет поддерживать настольные приложения Windows, поэтому мы надеемся, что это снизит потребность в одной из этих сред выполнения и предоставит дополнительные доказательства того, что конвергенция является нашей общей целью.

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

WASM - довольно необычная цель. Мало того, что JIT-компиляция невозможна, такие вещи, как потоки, файлы и сокеты, имеют очень разные модели по сравнению с большинством других платформ. Mono имеет множество существующих технологий, разработанных для портов на другие необычные / ограниченные платформы, такие как iOS, watchOS, PS4 и т. Д., Которые помогают с портом WASM, такие как интерпретатор IL, совместная приостановка сборщика мусора, полный AOT (что на удивление сложно для дженериков) с совместным использованием дженериков. , Бэкэнд битового кода LLVM и управляемое связывание.

Я полностью ожидаю, что тип проекта WASM Mono будет использовать проекты в стиле SDK, с SDK MSBuild, поставляемым через NuGet и доступным с dotnet .

Думаю, я чувствую здесь ненависть к Моно, не так ли?
Пожалуйста, не спешите выбросить Моно. Помните, когда Microsoft не любила Linux? Mono был там для разработчиков C #. Помните, когда Microsoft не любила Mac OS? Моно снова был там. Теперь JavaScript ест наши обеды, угадайте, кто появится? Вы держите пари, Mono здесь, чтобы спасти положение, будучи первым полноценным доменом .net, запущенным на Wasm. Пожалуйста, проявите немного уважения!

Послушайте, мы, разработчики C #, любим Mono. Они делают фантастическую работу. Оставьте Mono в покое. Если крутой парень .Net Core захочет повеселиться, это тоже нормально, НО ОСТАЕТСЯ МОНО!

@humbersoft Если вам нужна причина, по которой мы "ненавидим" Mono, я дам вам ее. Он видит такие ошибки в консоли вашего браузера: «WASM: он должен был быть установлен в папке` / Users / builder / jenkins / workspace / test-mono-mainline-webassembly / label / highsierra / sdks / out / wasm-interp / Каталог lib / mono / 4.5 / mscorlib.dll ". Кто такой Дженкинс? Какое странное сообщение! Очевидно, что разработчик Mono жестко запрограммировал свой личный путь во время выполнения.

@paulost Jenkins - это служба непрерывной сборки. Ищи это. Это очень популярно.

Спасибо @MisinformedDNA, но почему Mono говорит мне, что он должен быть установлен именно по этому пути в моей системе? Я не пытаюсь создать Mono, а использую его только для запуска приложения Blazor. Поставляемая среда выполнения не должна сообщать вам о своем пути к службе сборки.

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

Наконец, Xamarin работает на Mono, на котором, вероятно, работают тысячи мобильных приложений. Это хорошо сделанная технология. Было бы лучше иметь одну среду выполнения? Конечно. Но .NET Framework - это только Windows, а Mono позже был создан как порт для совместимости с Linux, а .NET Core затем был создан для лучшей масштабируемости в облаке. Вы действительно думаете, что MS предпочитает управлять тремя отдельными средами выполнения? Конечно, нет. Но не каждый язык имеет масштабы или амбиции .NET. Кроме того, если вы его пропустили, MS переносит WPF, WinForms и UWP на .NET Core 3.0 . За .NET Core будущее, но на это потребуется время.

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

В этом конкретном случае среда выполнения пытается определить каталог сборки среды выполнения (который содержит файлы, подобные mscorlib.dll) на основе ее текущего местоположения в файловой системе, а последний вариант - это путь, по которому была скомпилирована среда выполнения. В wasm концепция «расположения файловой системы» на самом деле не применима ... В других подобных встроенных настройках код встраивания обычно регистрирует настраиваемый преобразователь сборки (например, для разрешения из zip-архива Android APK), и я думаю, что это не так. здесь еще не установлено.

@PaulOst
Это то, что касается жизни на переднем крае, вы, вероятно, порежетесь. Mono для WASM находится на ранней стадии и является экспериментальной, но более полной, чем DotNet Anywhere, на которой изначально был основан Blazor. Это точно еще не доработано, поэтому ошибок, подобных той, с которой вы столкнулись, следовало ожидать.

Некоторым разработчикам нравятся горячие моменты, некоторым лучше подождать, пока все не станет прохладным и спокойным. Это горячие моменты, возможно, вам нужно немного скорректировать свои ожидания. Я понимаю перспективу, вам нужен безупречный продукт. Можете ли вы представить себе ожидание, пока .NET Core нацеливается на Wasm? Они могут не дойти до этого до 3 лет. Mono - надежный продукт, и хорошо, что они есть у Microsoft, иначе у нас не было бы истории .NET для WASM и многих других платформ.

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

При всем вышесказанном, Blazor может даже не увидеть свет по ряду веских причин. Запланируйте и это.

Я пошел дальше и начал создавать движок Xaml, который изначально работает в браузере. Вы можете проверить это здесь: https://github.com/XamlEngine/Samples

Присоединиться к этому обсуждению немного поздно, но удивлено, что так много людей обеспокоены тем, как работает их стандартный код .NET. Прикрепите любую метку к среде выполнения - Mono, .NET Core, FlubberGast - независимо от того, какая фактическая среда выполнения будет отличаться. .NET Core на сервере ни в коем случае не будет таким же, как .NET Core на WASM или компилироваться с WASM. Так кого, черт возьми, это волнует?

Важно то, как резина встречается с дорогой или насколько легко получить доступ к этому рабочему коду. Я согласен с @EisenbergEffect , что более простой путь нижнего уровня к загрузке .NET может стать огромным стимулом для .NET в целом.

Почему бы не сделать это серьезным толчком в дополнение к тому, что делает Blazor, поскольку это, несомненно, приведет к инновациям в различных способах использования .NET в браузере. Это может стать огромным плюсом для видимости NET, если появится множество новых проектов, использующих .NET новыми и инновационными способами в браузере. Я уверен, что Роб спрашивает, потому что у него есть идеи о том, как создать какой-то новый фреймворк :-)

Это возможно сегодня с текущим модулем Mono.wasm и в будущем с .NET Core или, по крайней мере, с компилятором Mono AOT, но я думаю, что создание стандартного интерфейса хостинга, который может облегчить загрузку .NET в браузер, будет иметь большое значение для эта цель. Фактическая среда выполнения затем может быть подключена и заменена по мере появления обновленных технологий и ресурсов.

Это кажется огромной возможностью для .NET стать одним из первых приверженцев области веб-сборки. То, что я увидел с Blazor, выглядит многообещающим, но я думаю, что он не думает достаточно прогрессивно, если это единственная официальная точка воздействия WASM на .NET. Мне очень нравится модель Blazor и то, что она позволяет, но я думаю, что это лишь верхушка айсберга того, что было бы возможно, если бы экосистема для запуска .NET была такой же простой, как создание стандартного .NET-приложения. Я не обязательно говорю здесь о UI-фреймворках, но даже о возможности начальной загрузки и вызова свободных классов .NET либо в качестве точки входа, либо в качестве обработки, например Web Worker, либо даже в качестве средства взаимодействия с существующими приложениями JavaScript. Даже для этого преимущества совместного использования некоторого бизнес-кода / кода проверки могут быть невероятно ценными.

Большой потенциал - было бы здорово реализовать это как можно больше, упростив использование этой технологии даже для битов более низкого уровня!

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

О, я не думаю, что Blazor не прогрессивный - я пояснил в своем сообщении выше. Даже просто поигравшись с этим, я могу с уверенностью сказать, что это будет отличный способ создавать приложения. Есть так много маленьких моментов, когда вы просто идете - это было бы такой болью в Javascript / Typescript.

Я считаю, что они должны также добавить необработанные функциональные возможности .NET в дополнение к материалам Blazor. Эта инфраструктура в любом случае должна быть построена для поддержки Blazor, так почему бы не раскрыть ее в более удобном для пользователя виде, чтобы было просто офигительно легко перенести .NET-хостинг в клиентское приложение.

Я не уверен, что понимаю, Blazor позволяет нам использовать большую часть функциональности .NET. Каких именно функций, по вашему мнению, не хватает?

Мне нужно использовать Blazor. Что делать, если у меня есть существующее HTML-приложение или я создаю что-то с помощью другого фреймворка и мне не нужен Blazor? По-прежнему существует отличный вариант использования для предоставления доступа к .NET-коду в браузере вне HTML-фреймворка (совместное использование кода проверки, утилит и т. Д. И т. Д.).

Мне нужно использовать Blazor. Что делать, если у меня есть существующее HTML-приложение или я создаю что-то с помощью другого фреймворка и мне не нужен Blazor? По-прежнему существует отличный вариант использования для предоставления доступа к .NET-коду в браузере вне HTML-фреймворка (совместное использование кода проверки, утилит и т. Д. И т. Д.).

Я не понимаю. Blazor по сути:

1. Синтаксис Razor для веб-компонентов,
2. различные помощники JS-взаимодействия,
3. WebAssembly .NET на основе моно

Предположительно, вы хотите второго и третьего из них, и первое вам не вредит.

Я считаю, что они должны также добавить необработанную функциональность .NET в дополнение к материалам Blazor. Эта инфраструктура в любом случае должна быть построена для поддержки Blazor, так почему бы не раскрыть ее в более удобном для пользователя виде, чтобы было просто офигительно легко перенести .NET-хостинг в клиентское приложение.

Как я понимаю, в этом и заключается цель усилий mono.wasm . Мы часто называем Blazor и mono.wasm одновременно, но на самом деле Blazor - это просто веб-фреймворк. Это mono.wasm, который обеспечивает базовую среду выполнения .NET на основе WebAssembly. Другие фреймворки могут быть построены поверх той же среды выполнения, а альтернативные фреймворки уже существуют ( Ooui , Uno ). @kumpera @mhutch , вероятно, те люди в команде Xamarin, которые могут рассказать об опыте разработки, который они надеются реализовать при использовании mono.wasm независимо от какой-либо конкретной инфраструктуры пользовательского интерфейса.

На сегодняшний день zip-файл обеспечивает чрезвычайно простую поддержку для написания приложений C # без Blazor. Этого достаточно для проверки технологии, но для этого требуется много ручной работы.

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

Какой zip-файл?

@EisenbergEffect вам следует заботиться о .NET Standard, а не .NET Core.
Убедитесь, что ваши зависимые API полагаются на .NET Standard, и у вас все хорошо.

@weitzhandler Я думаю, вы упускаете мою точку зрения. Если я хочу создать что-то с .NET, мне нужно установить какой-то конкретный набор инструментов, не так ли? Я начал работать с .NET более 15 лет назад, поэтому лично я не считаю это пугающим или запутанным (хотя я предпочитаю не устанавливать на моем компьютере квазидупликационные инструменты). Но представьте себе человека, у которого нет опыта работы с .NET и который является пользователем Mac. Они решают, что хотят создать приложение .NET, как интерфейсное, так и внутреннее. Они слышат, что .NET Core - это новейшая и шикарная вещь, поэтому они проходят через ритуал, чтобы установить .NET CLI и VS Code. Затем они обнаруживают, что не могут построить свой интерфейс на этом. Им нужно найти другой набор инструментов (с другим названием, из другого места, с другим руководством и т. Д.). Опять же, представьте, что у них нет предшествующей истории с .NET. Это не лучший опыт в первый раз. Хорошо, теперь представьте, что этот человек является архитектором или техническим директором, который пытается дать новую оценку .NET либо впервые, либо через несколько лет. Может быть, они задают направление своей компании. Вы хотите, чтобы этот опыт получил от этого человека или его технических советников именно такой опыт? Они собираются сравнить его с Go, Node, Rust и т. Д.

Что касается моих личных ощущений, моя толерантность довольно низкая после стольких лет и стольких версий .NET. Я пытаюсь помочь таким людям, как @ danroth27, немного понять, что должно произойти, чтобы люди вроде меня снова заинтересовались .NET. Это еще не все, но немного больше унификации, безусловно, поможет. Я просто хочу установить один интерфейс командной строки и VS Code. Процесс установки и запуска полнофункционального .NET-приложения на платформах, отличных от Windows, не должен быть более сложным, чем это.

Моя первоначальная публикация была предназначена для того, чтобы нарисовать простую картину того, как должна выглядеть «северная звезда» WASM с точки зрения разработки и вывода результатов сборки. Я устанавливаю интерфейс командной строки, пишу некоторый код C # (с любым редактором, который мне нужен), а затем выполняю команду интерфейса командной строки для сборки моего кода C # в WASM, создавая разумный набор выходных файлов (wasm, привязки, типы). Это должно быть целью. Если его сегодня нет, это понятно. Но давайте удостоверимся, что мы плывем на корабле .NET в правильном направлении, к наилучшему возможному опыту, а не довольствуемся тем, что просто проще или быстрее всего для инженеров Microsoft.

@EisenbergEffect
Роб, я согласен, что в конечном итоге цель будет состоять в том, чтобы .NET Core работал повсюду, даже заменив им Mono.
Я бы даже хотел, чтобы в .NET Core был включен « .NET UI Standard », который везде одинаково отображается, но .NET Core относительно свежий. .NET Standard был лучшим решением, чтобы обрисовать это расхождение в форме, и в настоящее время не похоже, что вы можете попросить чего-то лучшего.

Я голосую за замену Mono на .NET Core по тем же соображениям, что и @EisenbergEffect .

@EisenbergEffect У меня есть мечта о калибровочном микроконтроллере для Интернета, это то, что вы имеете в виду? На самом деле я начал работать над духовным преемником с помощью knockout и Duocode (JavaScript-порт mscorlib) задолго до того, как веб-сборка стала популярной.

@AndersMalmgren Aurelia во многом похожа на Caliburn.Micro для современного Интернета. Версия vNext, над выпуском которой мы работаем в этом году, даже поддерживает альтернативные средства визуализации, поэтому она может отображать не только HTML, но и собственные настольные, трехмерные и консольные приложения. Он написан на TypeScript, а не на .NET. Возможно, в будущем появится возможность перенести Aurelia на .NET Core, когда эта технология станет еще немного зрелой.

Тем не менее, поскольку Microsoft создает Blazor, у меня меньше шансов лично создать что-либо для .NET WASM, потому что это поставило бы меня в конкуренцию с Microsoft. Из истории мы знаем, что ни один открытый исходный код в экосистеме .NET никогда не дает ничего, когда Microsoft решила создать что-то подобное, независимо от того, является ли этот открытый исходный код лучше спроектированным, более расширяемым, более производительным и т. Д. измученный здесь. Единственное, что может изменить это, - это если Microsoft наймет меня, чтобы я возглавил интерфейсную среду и экосистему на основе .NET Core. Но это не был бы Blazor. Blazor неправильно спроектирован (он повторяет анит-шаблоны .NET 10-летней давности), при этом, на мой взгляд, он недостаточно амбициозен, соответствует стандартам или достаточно перспективен. На карту поставлены большие возможности для Microsoft, но окно закрывается. Я пытался убедить разных людей в Microsoft принять то, что они могут сделать, но пока мне это не удалось. Внешний интерфейс просто не кажется сейчас большим приоритетом для Microsoft.

@EisenbergEffect Проблема для меня в том, что Blazor использует Razor, который является MVC. Нам нужен настоящий MVVM, который может использовать всю мощь среды выполнения clr. Как создание шаблонов на основе соглашения о типах и т. Д. Я начал эту работу с DuoCode и knockout и использовал мои Knockout.BindingConventions, чтобы склеить их вместе. У меня даже такой синтаксис работает

public IEnumerable<IResult> Save()
{
    var confirm = new ConfirmResult("Proceed?");
    yield return confirm;

    if (confirm.Result == ConfirmResults.Cancel)
        yield break;

    yield return new service.SendCommand(new SaveSomethingCommand(this.something));
}

https://github.com/AndersMalmgren/Knockout.BindingConventions.DuoCode/wiki/IResult-state-machine

Knockout угас, и мой интерес к нему. Но мечта живет: D

Что ж, я мог бы снова взяться за работу, но с Vue или подобным.

Возможно, Aurelia вместо Vue, поскольку Aurelia происходит от Durandal, который происходит от Caliburn.Micro. Кроме того, у Aurelia есть соглашения, ванильные JS-модели, она работает лучше, имеет строгое соответствие стандартам и намного больше преимуществ, которых нет в других фреймворках 😄

Но это не был бы Blazor. Blazor неправильно спроектирован (он повторяет анит-шаблоны .NET 10-летней давности), при этом, на мой взгляд, он недостаточно амбициозен, соответствует стандартам или достаточно перспективен.

Что с этим не так?

@EisenbergEffect или Аурелия. Мне нравится Aurelia, но поскольку он использует JavaScript или Typescript, который является языком стирания типов, вы теряете всю эту сладкую магию времени выполнения CLR, которую вы можете творить. Плюс JavaScript DI - честно говоря, чушь по сравнению с тем, что вы можете сделать с правильной средой выполнения clr. Я реализовал небольшой контейнер DI для Duocode для того же проекта, упомянутого ранее, и, на мой взгляд, внедрение в интерфейс на основе типов - это путь вперед. Мне нужно изучить модульность Aurelia, в свое время нокаут был очень расширяемым, и Vue, похоже, продолжает эту тенденцию.

@AndersMalmgren Aurelia - вероятно, самая расширяемая интерфейсная среда на сегодняшний день. Реализация vNext, над которой мы работаем, также выводит ее на новый уровень. Вы также можете быть удивлены тем, что мы можем сделать с нашим DI :) Он основан на типах, имеет расширяемое время жизни и т. Д. Поскольку JS имеет встроенную поддержку классов, стирания нет. Мы также можем моделировать интерфейсы с помощью вспомогательного метода DI или Vanilla JS Symbol. Таким образом, TS может объединять их с интерфейсами TS, обеспечивая те же шаблоны, что и .NET. Другими словами, вы можете легко ввести IAuthenticationService в класс во время выполнения 😄 Насколько мне известно, мы - единственный фреймворк, который может это сделать. Я попытался перенести как можно больше хороших частей из Xaml и Caliburn.Micro в Интернет, оставив плохие позади. Таким образом, MVVM в Aurelia даже намного проще и мощнее. Я соберу серию сообщений в блоге об Aurelia для разработчиков Xaml и Aurelia для разработчиков ASP.NET MVC. Это может помочь людям соединить точки и понять, почему и как это делает фронтенд-разработку не только быстрой и простой, но и SOLID.

@manigandham Я много-много лет проработал разработчиком .NET, лидером .NET с открытым исходным кодом и

А для тех, кто меня не знает, я просто хочу добавить, что я не злюсь на все это или на злого человека. Я знаю, что иногда все кажется немного таким, когда ты меня не знаешь и просто читаешь мои комментарии здесь или там. Однако я очень увлечен интерфейсом. Я создавал интерфейсные фреймворки, библиотеки и инструменты почти всю свою карьеру. Это короткие 15 лет, но это сравнительно долгое время, чтобы сосредоточиться на этой области. Итак, я много чего видел, много чего делал и у меня абсолютно твердое мнение. Я увлечен и расстраиваюсь, когда вижу, как Microsoft повторяет старые ошибки или делает вещи, которые, как я уже видел, идут не так, как надо. Итак, у меня здесь нет недоброжелательности. Я действительно хочу, чтобы Microsoft преуспела. Я хочу, чтобы они были лидерами во фронтенде. Я просто расстраиваюсь и немного расстраиваюсь, если честно, когда вижу, что этого не происходит. Я хочу самого лучшего для .NET и ее сообщества.

вы должны простить меня, если я не хочу тратить субботу на написание статьи из 10 тысяч слов о проблемах дизайна с Blazor.

Дело в том, что вы подали заявку, а затем кто-то просто попросил вас подробнее рассказать об этом:

Blazor неправильно спроектирован (он повторяет анит-шаблоны .NET 10-летней давности), при этом, на мой взгляд, он недостаточно амбициозен, соответствует стандартам или достаточно перспективен.

Мне тоже были бы любопытны конкретные примеры.

И, учитывая природу Blazor прямо сейчас, я не уверен, что справедливо сравнивать его со средним продуктом Microsoft. Это еще не продукт, и он разрабатывается открыто гораздо чаще, чем если бы он был.

@chucker Я понимаю. Для меня дешево заявить подобное и не вдаваться в подробности. Я благодарен за то, что вы хотите услышать больше.

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

Тем не менее, я попробую начать что-то обрисовывать. Однако было бы слишком долго писать комментарий на GitHub. Я немного опасаюсь негативной реакции, если я опубликую об этом в блоге. За мою карьеру меня много раз издевались и ненавидели различные группы, которые не любили, когда меня критикуют. Хотя в последнее время в основном это были члены команды Facebook / React, я не уверен, что хочу снова открыться для этого.

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

Я могу подтвердить, что во многих отношениях как известный, так и неизвестный Blazor не идеально разработан, и мы приветствуем любые конструктивные отзывы, чтобы сделать его лучше. Как свидетельствует наш список проблем, есть над чем поработать! И хотя совершенство дизайна почти наверняка останется недостижимым, в конце концов, действительно важно, сочтут ли разработчики использование Blazor продуктивным и полезным. Это кажется достижимым.

@EisenbergEffect Я, безусловно, приветствую любую объективную и конструктивную критику или отзывы, которые могут у вас возникнуть. Как и в случае с любой объективной критикой, я не могу обещать, что это что-то изменит. Могу только сказать, что мы сделаем все возможное, чтобы его внимательно рассмотреть.

Кроме того, никто не заслуживает издевательств или ненависти, и такое поведение явно противоречит нашему Кодексу поведения .

По моему скромному мнению, Blazor уже добился успеха. За 20 лет разработки как с использованием технологий Microsoft, так и сторонних разработчиков я видел, как каждый раз возникала одна и та же закономерность. Когда появляется что-то новое, вы видите разработчиков двух типов. Тот, кто видит в модели программирования средство достижения цели, и тот, кто любит часами возиться с разными библиотеками. Я пытался убедить себя, что использование всех этих разных js-библиотек от всех этих разных компаний дает мне больше мобильности и свободы как разработчика, но вскоре я обнаружил, как все они расходятся в видении, миссии и, к сожалению, совместимости в какой-то момент. Я всегда искал единую модель программирования и понимал, что строгие соглашения - не всегда плохо. Суммируя. Я забочусь о решении, и Microsoft никогда меня не подводила. Некоторые из моих лучших и наиболее часто используемых веб-приложений созданы на базе технологий Microsoft, и я считаю, что Blazor предоставит хорошую унифицированную модель программирования, которая хорошо работает, но не зависит от сотен других библиотек, работающих вместе.

По моему скромному мнению, Blazor уже добился успеха. За 20 лет разработки как с использованием технологий Microsoft, так и сторонних разработчиков я видел, как каждый раз возникала одна и та же закономерность. Когда появляется что-то новое, вы видите разработчиков двух типов. Тот, кто видит в модели программирования средство достижения цели, и тот, кто любит часами возиться с разными библиотеками. Я пытался убедить себя, что использование всех этих разных js-библиотек от всех этих разных компаний дает мне больше мобильности и свободы как разработчика, но вскоре я обнаружил, как все они расходятся в видении, миссии и, к сожалению, совместимости в какой-то момент. Я всегда искал единую модель программирования и понимал, что строгие соглашения - не всегда плохо. Суммируя. Я забочусь о решении, и Microsoft никогда меня не подводила. Некоторые из моих лучших и наиболее часто используемых веб-приложений созданы на базе технологий Microsoft, и я считаю, что Blazor предоставит хорошую унифицированную модель программирования, которая хорошо работает, но не зависит от сотен других библиотек, работающих вместе.

Если бы Microsoft не повлияла извне, мы бы застряли на winforms и webforms.

https://devblogs.microsoft.com/dotnet/introduction-net-5/
Сегодня мы объявляем, что следующим выпуском после .NET Core 3.0 будет .NET 5. Это будет следующий большой выпуск в семействе .NET.

В будущем будет только один .NET, и вы сможете использовать его для работы с Windows, Linux, macOS, iOS, Android, tvOS, watchOS, WebAssembly и т. Д.

Мы представим новые API .NET, возможности среды выполнения и языковые функции как часть .NET 5.