Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 69

Планируете использовать в своем проекте нативный функционал, как например WebRTC или WebGL.

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

А можно подробнее? Авалонию можно в браузере запустить?

Да, как .NET 6.0 вышел, так и стало можно. Причём работает сейчас поверх вышеупомянутого Blazor-а. См. гайд (только надо ещё dotnet workload install wasm-tools сделать). Из демок можно потыкать вот это.

Статья с опозданием? .Net 6 давно уже как 4 месяца в релиз вышел и там есть Query parameters

Да вы правы, .Net 6 уже действительно вышел и там есть атрибут [SupplyParameterFromQuery], как раз таки для этих целей. Но по скольку .Net 6 вышел совсем недавно, то высока вероятность, что еще мало кода написанного на этой версии. Поэтому у вас будет выбор, либо переиспользовать старый код и писать обертку для Query параметров. Либо использовать Net 6, но с нуля. Без переиспользования старого кода.

Как только .Net 6 выкатили, апдейтнул сразу на него и переписал Query, пока проблем не наблюдаю

Честно говоря, cons сервер-сайд блейзора выглядят притянуто. Использовал в продакшене, проблем не наблюдал на средних нагрузках

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

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

Поскольку у меня было меньше пользователей, я сошлюсь на Blazor Server in .NET Core 3.0 scenarios and performance - .NET Blog (microsoft.com)

In our tests, a single Standard_D1_v2 instance on Azure (1 vCPU, 3.5 GB memory) could handle over 5,000 concurrent users without any degradation in latency. A Standard_D3_V2 instance (4 vCPU, 14GB memory) handled well over 20,000 concurrent clients

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

НЛО прилетело и опубликовало эту надпись здесь

Не совсем понял комментарий про "Если изменить на...". Зачем нам конвертировать C# в JS, если с помощью Blazor мы как раз хотим уйти от изпользования JS.

НЛО прилетело и опубликовало эту надпись здесь

Например система типов там наверное покруче будет.

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

Если будет один дополнительный шаг перед деплоем

Так этот шаг и так есть. C# => WebAssembly

Вы все верно говорите, не могу понять, где в статье говориться обратное

НЛО прилетело и опубликовало эту надпись здесь

У нас проект прекрасно живёт на Blazor.

Да query params были проблемой, но так как мы активно используем Reactive.Net написать обёртку делов на пол часа. Анимации, работа с графикой, всё прекрасно работает. Для WebGl есть билблиотека SkiaSharp. Мы тоже рендерим Xaml разметку в Canvas, отлично работает.

Когда завезут много поточность будет вообще сказка.

Собственно причина использования проста, мы не стремимся использовать Blazor как фреймворк веб разработки, напротив мы идём в сторону приближения его к Desktop подходам и MVVM.

Шарп плохо компилируется в васм, потому что «у Blazor у которого дженерики не мономорфизируются выходит 5-6 мб на hello world, а такая же программа на Rust у которого они мономорфизируется в несколько килобайт»

А это комменты под офиц. видео
image

А с многопоточностью вы особо не радуйтесь. Там костыль на костыле. Огромное количество ограничений, да так что проект надо будет форкать и переписывать многопоток под васм.

выходит 5-6 мб на hello world

Там же еще фреймворк тащить нужно. Неужели дело в дженериках лишь?

у Blazor у которого дженерики не мономорфизируются выходит 5-6 мб на hello world, а такая же программа на Rust у которого они мономорфизируется в несколько килобайт

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

В Rust для таких шаблонных функций мономорфизация будет использована там где для вызовов используете конкретный trait. Если ограничения допускают dyn Trait - возможно использование boxed traits память под которые выделена на куче - в этом случае никакой мономорфизации не будет. Если интересно про это смотрите https://www.youtube.com/watch?v=tM2r9HD4ivQ (Dynamic vs Static Dispatch in Rust)

Блина... А я за 300$ в месяц работаю. ?

Но хоть проблем нет. Самое сложное в проекте это просто Html и Css, вёрстка сложных картинок и тд.

А код, обмен данными в реальном времени за секунды делается. А раньше наоборот было, вёрстку пишешь неделю, а код ещё 3.

Что то мне это очень сильно напоминает почивший в бозе Silverlight от этой же компании. Сколько было слов и эпитетов - и где все это сейчас?

Очень сильно напоминает тактику https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

почивший в бозе Silverlight

Зрите в корень. Он был привязан к IE. Проиграл IE - проиграли и зависимые технологии. Сейчас такой привязки нет.

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

Silverlight не был привязан к IE, он работал во всех популярных браузерах. Там была привязка к ОС (поддержка была для windows и macOS. На linux был moonlight)

Ваша правда - в некий период работала и в FF и в Chrome в качестве плагинов. Потом убрали.

Хорошо бы вспомнить тех. детали. В частности - по чьей инициативе выпилили? Ведь это не просто JS-расширение а полноценный плагин с доступом к нейтивным библиотекам и платформе. Похоже что Google не хотел способствовать технологии конкурента.

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

На самом деле, в FF он прожил куда дольше чем в IE, за счёт ESR-версии лисы. Собственно, даже сейчас можно поставить ту версию браузера и открыть приложение на сервелате, главное успеть отключить автообновление.


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

Емнип, примерно так было. Одно время IE был браузером #1 и все под него подстраивались. Матюкались - но подстраивались.

IE сказал что нужно Silverlight - все вынуждены были согласиться.

Потом IE сдавал позиции, но все равно по инерции его учитывали. Незаметно для всех ситуация перевернулась и IE оказался в аутсайдерах - тогда все смело его послали.

Silverlight работал через NPAPI, так же как Flash (до того как его встроили в браузеры) и Unity Web Player.


Другие браузеры долгое время поддерживали не Silverlight, а именно NPAPI.

Не забывайте про мобильные устройства, где каналы пока ещё очень далеки от идеала.

Понимаю что канал у всех как минимум 100 Мбит, передача даже сотни МБ не большая трагедия, но все же как то это не правильно не экономить ресурсы.

Если говорить про настольные компьютеры и ноуты там где есть WiFi - с некоторой натяжкой да. А мобильные устройства? Там дай бог если 10 Мбит есть.

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

Потом когда Microsoft это надоест - вам будет стоить колоссальных денег переписывать это добро под современные технологии принятые в вебе.

Так оно компиллится в стандарт - WebAssembly. Компиллер OpenSource.

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

Silverligth изначально поддерживался на Windows и MacOS. Для Linux был порт Moonligth, а с 4ой версии в Silverligth добавлена поддержка Chrome. Поэтому по факту главная причина отказа от Silverligth это смена направления развития. Если мне не изменяет память, то примерно в это же время Microsoft начал говорить, что HTML5 это "наше все". Что касается размера самого Silverligth приложения (без установщика Silverligth), то у нас он составляет 4 мбайта (приложение с 10ками форм, графиков и диаграмм).

Silverlight помер, потому что требовал установки плагина, а потом внезапно html5.

Соглашаюсь. Сейчас работает через WebAssembly - а это стандарт.

Silverlight помер потому что его забросили создатели.


Для сравнения, браузерный Unity изначально тоже требовал плагина, но когда NPAPI отрубили — создатели сделали ему wasm-версию (или сначала asm.js-версию, а потом уже wasm — подробно не разбирался).

Что ж, учитывая, что статья написана человеком, которому Blazor навязали и он изначально относился к нему предвзято, все выглядит совсем неплохо) плюс, .net 6 подвезли, со всякими оптимизациями и новыми фичами. Надо брать.

Предвзятое сравнение.

  1. Плюсы практически не упомянуты, там где упомянуты их степень автор дополнительно занизил . Фраза <<А вот где точно его не следует использовать если вы хотите иметь поддержку старых браузеров, как например IE >> это вообще зашквал, то есть blazor server для автора это слон которого нет.

  2. По характеру статьи видно что автор делал УДАРЕНИЯ на минусы

Приведите пример преимуществ Blazor, которых НЕТ у React или Angular. Я лишь хочу сказать, что все преимущества которые есть у Blazor, есть и в других фреймворках, поэтому смысл переходить на него.

Как насчет отсутствия JS? Вы написали, что все равно прийдется знать JS. Мягко говоря это совсем не так. Наше большое Blazor server-side приложение не использует JS. Оно испольльзует и ChartJS и CodeLens и Гугловые таймлайны... но при этом совершенно свободно от JS. Как? Ответ простой - для всего этого кто-то уже сделал обертки в nuget.

1) Все верно, как я и написал. Blazor можно использовать в некоторых отдельных случаях. Возможно ваше приложение относится как раз таки к таковым.

2) Вы используете обертки, это автоматически означает что вы ограничены лишь тем функционалом, который в него заложили разработчики этой обертки. В 100 случаях из 100 обертка имеет более узкий функционал, чем оригинал, т.к оборачиваются наиболее популярные функции.

3) В случае с JS, вы правы он уступает C# в удобстве. Но работая с C# и TS я не могу сказать, что 2-ой сильно уступает. И если так то почему бы не выбрать более гибкий (а для web это так) инструмент.

При этом обвертки часто opensource и можно допилить необходимый фукнционал и поделиться с ним сообществом.

Запросто) Весь стек настольных разработчиков C# (14% в мире) с минимальным напрягом может начать писать под web, при этом ухода в другие технологии нет, а развитие есть.

Ваша статья называлась <Нужен ли нам .Net в вебе> это конечно холиварное название, но это не значит что нужно однобоко описывать технологию, сбивая людей с толку. Если изначально вам лично технология не нужна, то ...

Нет необходимости делать API и его согласовывать. React или Angular - это есть API, которое мы дергаем и отрисовываем ответы, надо поменять API, надо переделывать на двух сторонах.

В Blazor Server можно грубо говоря в коде компонента прочитать записи из базы данных и циклом отрисовать их сразу в таблицу. А при нажатии на кнопку сразу отправить изменения в базу. Для условного MVP это позволяет делать за часы то, что на связке Angular/React занимает дни. И переделывать опять же за часы.

Можно использовать объекты доменной области, внутренние классы и базу кода компании, т.е. достигается полное переиспользования кода, без дублирования код бэка/код фронта.

Проблема блазора это не только то что надо писать каждый раз обвязки под js, а события. Есть 2 мира событий, те что в браузере из js, и те что в net, надо ловить одно и прокидывать дальше в net, и обратно. У меня на практике возникали бесконечные зацикливания, не говоря уже о тормозах. Мое личное мнение: ни какого профита в серьезных проектах, по сравнению с ангуляром.

Вы про сервер сайд или клиент сайд?

В обоих случаях.

>По скольку размер Blazor приложения существенно больше. 0,8 мб у Angular против 4мб у Blazor, для приложения с одинаковым функционалом. 

В .NET 6 таки размер бандла снизили. А вообще, с учетом того, как сейчас делают сайты на всяких конструкторах и заливают туда несжатые фото по 10-20мб, то 2-4мб это вообще ни о чем.

Это размер приложения, который по сути представляет из себя Hello World. С более менее серьезными проектами, будет не так оптимистично. Не столько важно что 4мб, а то что больше чем в 4 раза.

Сейчас минимальный размер приложения 1-1.5мб на .NET6. С включенным AOT конечно больше.

Будем надеятся, что со временем будет еще лучше

Неверно, DLL в дотнете как правило очень компактны, добавление 10 библиотек в дотнете добавит 500кб, когда в Ангуларе размер бандла может вырасти и на мегабайт

Есть ленивая загрузка DLL  + ее допиливают

У нас довольно сложный проект, сейчас на .NET размер бандла - 3 Мб без AOT. Близкое по объему функционала и сложности приложение на Angular - в сумме бандл и фреймворк - 3,5 Мб. Так что в объеме не всегда выигрышь чувствуется.

Можете дать ссылку на получившийся сайт?

IJSRuntime js;
_module ??= await js.InvokeAsync<int>("./path-to-js-file", "<method name>");

Конечно, так можно использовать JS Interop, но только для alert, onclick и прочего простого функционала. Лучше написать нужное на JS и встроить в Blazor, так будет легче. Тогда возникает вопрос - чем это отличается от вашего прошлого asp net + React (кстати хороший набор бэка с фронтом, но я бы лично взял Angular - про Реакт слышал плохое + это фейсбук, а Vue на рынке мало, зато дока крутая)?

Выводы сделаны правильно - Blazor не убьёт JS пока C# не будет нативно поддерживаться в браузере, а этого ждать ой как не скоро. Хотя для pet-проектов в портфолио шарписта Blazor будет смотреться интересно.

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

Я писал портал и там едиснтвенный JS код был это проверка версий браузера.

Например, в Blazor не получится средствами C# закрывать popup при клике за пределами этого popup-а (только костылями). В JS есть window.onclick по типу:

window.onclick = function(event) {
    var i;
  
    if (!event.target.matches('.js-close')) {
        for (i = 0; i < dropdowns.length; i++) {
            var openDropdown = dropdowns[i];
            if (openDropdown.classList.contains('show')) {
                openDropdown.classList.remove('show');
            }
        }
    }
}

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

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

Вот видимо либо я Вас не понимаю, либо вы Blazor

Там есть такая вещь

Каскадные значения и параметры ASP.NET Core Blazor | Microsoft Docs

Все ваши окошечки модалки и прочее получают эти параметры и вы можете сделать тоже самое, что в JS выше.

Час назад видел такое поведение у элементов devexpress . DxPopup , как им это удалось не знаю, так как мне именно такой функционал не нужен, но удалось

НЛО прилетело и опубликовало эту надпись здесь

Посмотрел старый проект, там это решалось бесплатным RadzenMenu

Для нашего проекта основным минусом стала производительность и отстутвие многопоточности (и работа в UI-потоке). В частности, приходится загружать с бэка довольно большие и сложные объекты, так вот десериализация занимает очень ощутимое время. На сложных вычислениях UI подтормаживает. Но несмотря на это впечатление от технологии скорее положительное.

А вариант с AOT не пробовали для улучшения производительности?

Странный какой-то заказчик. Имея своих разработчиков, знающих C#, обращаться к кому-то еще...

НЛО прилетело и опубликовало эту надпись здесь

Очевидно если лень разбираться/изучать, то не нужно
ASP NET никто не забрал и он дальше развивается, можно дальше использовать его с нужным вам фронтом на JS

Blazor Server - веб-приложение выполняется на сервере. Команды по обновлению DOM/UI в браузере клиента, сервер отправляет через SignalR (WebSocket). По своему опыту работы, Blazor Server отлично подходит для внутренних/корпоративных сайтов, т.к. быстро и просто. Простенькие веб-страницы на bootstrap с CRUD табличек из БД. На работе уже штук 5 таких крутится с Windows аутентификацией/авторизацией. Минимальное использование JS. И один BlazorServer с WebApi+страница с таблицами заказов из БД. Через WebApi сохраняются заказы в БД, а потом в бэкграунде (Hangfire) стучимся в СБП Сбербанка - обновляем статусы заказа ну и т.д.

Blazor WebAssembly - SPA в браузере клиента, ни разу его ещё не использовал, ничего не могу сказать


NET MAUI Blazor Hybrid - это про нативное использование Razor компонентов вместо XAML в WebView для кроссплатформенного MAUI. Написали классные компоненты на Razor, хотим их использовать на других платформах (Android, iOS, Mac Catalyst, Tizen, Windows), вместо стандратного браузера в системе, на этих платформах запускается MAUI приложение с WebView, в котором Razor и вырисовывается

WPF Blazor - тот же самый WPF, просто опять же рисуем Razor компоненты в WebView, который встроили в WPF

Т.е. Blazor уже и так запускается на десктопе/мобилке, через WebView внутри приложения.
В Hybrid'е нет хостинга/запуска приложения в браузере системы, т.к. по сути это не веб-приложение, а отдельно запускаемое приложение с WebView. Т.е. WebView это и есть браузер, но внутри другого приложения

Зарегистрируйтесь на Хабре, чтобы оставить комментарий