Comments 69
Планируете использовать в своем проекте нативный функционал, как например WebRTC или WebGL.
Ну то есть мы через WebGL цельнотянутый XAML UI-тулкит рендерим, а Blazor, оказывается, для использования с ним не пригоден. Ясно.
Статья с опозданием? .Net 6 давно уже как 4 месяца в релиз вышел и там есть Query parameters
Да вы правы, .Net 6 уже действительно вышел и там есть атрибут [SupplyParameterFromQuery], как раз таки для этих целей. Но по скольку .Net 6 вышел совсем недавно, то высока вероятность, что еще мало кода написанного на этой версии. Поэтому у вас будет выбор, либо переиспользовать старый код и писать обертку для Query параметров. Либо использовать Net 6, но с нуля. Без переиспользования старого кода.
Честно говоря, 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.
А это комменты под офиц. видео
А с многопоточностью вы особо не радуйтесь. Там костыль на костыле. Огромное количество ограничений, да так что проект надо будет форкать и переписывать многопоток под васм.
выходит 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)
По мне так это всё как-то сложно выглядит и наверняка требует очень много дорогих специалистов за большие деньги.
Что то мне это очень сильно напоминает почивший в бозе 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 оказался в аутсайдерах - тогда все смело его послали.
Не забывайте про мобильные устройства, где каналы пока ещё очень далеки от идеала.
Понимаю что канал у всех как минимум 100 Мбит, передача даже сотни МБ не большая трагедия, но все же как то это не правильно не экономить ресурсы.
Если говорить про настольные компьютеры и ноуты там где есть WiFi - с некоторой натяжкой да. А мобильные устройства? Там дай бог если 10 Мбит есть.
Это была изначально утопичная идея делать веб на дотнете - в статье как аргумент есть то, что мол разработчики не хотят учить JS - так поверьте сильно дешевле нанять тех что и хотят и умеют, чем переезжать на это чудо. Потом когда Microsoft это надоест - вам будет стоить колоссальных денег переписывать это добро под современные технологии принятые в вебе.
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 подвезли, со всякими оптимизациями и новыми фичами. Надо брать.
Предвзятое сравнение.
Плюсы практически не упомянуты, там где упомянуты их степень автор дополнительно занизил . Фраза <<А вот где точно его не следует использовать если вы хотите иметь поддержку старых браузеров, как например IE >> это вообще зашквал, то есть blazor server для автора это слон которого нет.
По характеру статьи видно что автор делал УДАРЕНИЯ на минусы
Приведите пример преимуществ 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 это так) инструмент.
Запросто) Весь стек настольных разработчиков 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 подтормаживает. Но несмотря на это впечатление от технологии скорее положительное.
Странный какой-то заказчик. Имея своих разработчиков, знающих C#, обращаться к кому-то еще...
Blazor: Нужен ли нам .Net в вебе?
Если нужен, то теперь его ещё и проверять можно с помощью PVS-Studio :)
Они уже надоели своими новыми технологиями. Только привыкнешь к одной, выпускают новую, и приходится ее изучать. Потому что новые nuget-пакеты несовместимы со старыми технологиями, и туториалы перестают делать. С ASP.NET MVC пришлось перейти на ASP.NET Core, с .NET Framework на .NET Core. Теперь еще и это появилось. Я всегда делал бэкенд на C#, а фронтенд на js, в этом нет ничего сложного. Но из-за того, что на blazor нельзя сделать многие элементарные вещи, все равно придется делать сайт с костылями на js. Так что я вообще не понимаю, зачем это выпустили. Изучать еще и это реально лень.
Blazor делится на несколько видов. Мне было бы интересно, если бы можно было создать один проект, который будет работать и в браузере, и в десктопе, и в мобиле. Но вместо этого есть Blazor Server, Blazor Webassembly, Blazor Hybrid для net maui, Blazor Hybrid для wpf, и т.д. Есть какой-то RCL для расшаривания компонентов, но нет нормального, реально гибридного шаблона. Ну сделали бы один blazor на все типы приложений сразу. А так непонятно, для чего оно вообще нужно, кроме того чтоб взрывать мозг разработчикам. Лучше бы развивали старые технологии, чем придумывать новые каждый год, или хотя бы делали их совместимыми. Вот реально не могу понять, нужно ли мне переходить на blazor, и даст ли оно мне какую-то пользу?
Очевидно если лень разбираться/изучать, то не нужно
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 это и есть браузер, но внутри другого приложения
Blazor: Нужен ли нам .Net в вебе?