Comments 22
Вкладку "Memory" в девтулзах лучше не открывать, во избежание инфаркта. Вкладку "Network" - тоже. Приложение на моем любимом фреймворке весит 10kb. Продолжать?
Совсем худо? С телефона особо не поглядеть, но первоначальная загрузка оооочень долгая
t.me/WebAssembly_ru/45428
Все равно сколько показывает Memory и Network, зато можно нормально написать на c#, не выбиваясь из экосистемы. Ну не всем заходит этот JS.
Всё так, WebAssembly сама по себе немаленькая, а тут ещё и дотнет запихивать приходится. Ушёл пить горькую...
Почему то секунд 10 наблюдаю прелоадер, хотя по идее все должно быть очень быстро (если использовался blazor server).
У нас используется client-side, поэтому при первой загрузке знатно подтормаживает. Сегодня делаются попытки подпереть скорость загрузки и SEO добавлением серверного пререндеринга, но он сильно усложняет дело и это пока больше в режиме экспериментов.
Привет! Вообщем это дело такое себе, мы больше года использовали клиентское приложение но сейчас переехали на сервер. Будьте осторожны при использовании клиентского приложения так как скорость очень медленная и если проверить его на разных устройствах то будут большие проблемы например некоторые грузят его по 10-20 секунд. Ну и ещё сео - это отдельная часть которая не очень то хорошо работает с клиентом и после переезда на сервер и фишек из .NET 6 позволили сделать это красиво и быстро. Если могу чем то помочь то пиши, рад буду ответить.
Спасибо! Да проблема медленной загрузки и СЕО очевидна, но если ставить стандартный лендинг на входе, где этих проблем не будет, и предполагать, что в само приложение пойдут уже только те, кому оно действительно нужно, то 10-секундное ожидание client-side версии уже не так сильно будет бить по доходимости.
Серверная версия конечно решает проблему долгой загрузки, но приносит другие. У вас на беке монолит? Используете контейнеры? Делать зацепление совмещением бека и интерфейса в одном само по себе удовольствие ниже среднего, ведь будут ещё и другие реализации, но если у вас бессостоятельные сервисы и оркестрация, то отваливающиеся вебсокетные подключения придётся как-то обрабатывать и это отдельная боль. Если приложение развёрнуто в Азуре, то там хотя бы можно сделать прокси control-plate, который эту проблему должен решать, а в других местах такого может не быть и придётся велосипедить. Опять же, рендерить на сервере это огромное количество ресурсов, маркетинг с "бесплатным тарифным планом" будет влетать в копеечку. В общем, в серверном варианте свои заморочки - и все они влияют на то, что Blazor так и не может сегодня набрать обороты.
Кинете ссылку на своё серверное приложение? Очень интересно.
Так и не понял, в чем удобство по сравнению со связкой TS+React+MobX.
Да нет там особого профита. Просто у людей пригорает от вида JS/TS. Ну вот не заходит им, а взять в команду выделенного фронтенда, возможно, бюджет не позволяет. Вот и страдают.
Но в таких кейсах, почему-то всегда забывают о том что за любой комфорт надо платить, и в конце концов это низкий перфоманс и большое время загрузки. Выше кстати уже написали, что лучше в DevTools не заглядывать. С чего бы это, да? :)
Как по мне. Не вижу никакой проблемы делать фронт отдельно на JS/TS + ваш любимый фреймвок (React/Anguar/Vue etc), а бек на С#.
то, что оно грузится около 10-15 секунд это так и задумано? я где-то видел, что кто-то из МС отвечая на вопрос по блейзору и тому, что он пипец какой огромный рантайм тянет за собой - ответил, что дотнет6 там все шито крыто и рантайм там влазит в 2 мб. но что-то я такого не наблюдаю
Задумка с этим blazor-ом была интересная, но как дело подошло к релизу все больше похоже, что что-то с ним не так.
1) Получился новый фреймворк сильно отличающийся и от WinForms и от Razor-a. Такой React на C#. Т.е. толку от предыдущего опыта разработки UI на C# мало, нужно изучать все заново.
2) WebAssembly версия получилась медленной. Изначально там не было ahead of time компиляции, грешили на это. В .NET 6 ее вроде завезут, но это сильно увеличит время компиляции и размер бинарников. И возможно все равно будет медленно. С нативными приложениями (например, WinForms) по восприятию не сравнить.
3) WebAssembly получилась огромной. Размер сжатых бинарников, загружаемых клиенту, под 4 Мб. А при включенной ahead of time компиляции - под 8 Мб. И это для hello world проекта. Это будет постоянной головной болью при разработке и сопровождении. Как уменьшить размер начальной загрузки, как уменьшить объем потребляемой памяти и т.п. Оно нам надо?
4) Серверный режим работает на веб сокетах. Постоянно нужно сетевое соединение. Весь рендеринг идет на сервере. Очень-очень-очень на любителя.
5) Взаимодействие с существующими js библиотеками, скажем так, будет непростым.
6) Ну и традиционно для Microsoft все закончится тем, что новая версия фреймворка будет требовать новую версию Visual Studio, какую-нибудь новую версию браузера или работать только на Windows 12. Или вообще забьют на него в пользу другого решения. Не забываем Silverlight.
Основной минус всей идеи в том, что лезть в js придется. И эта синхронизация далеко не всегда проходит как надо. Но есть крутые механизмы для transclusion куда можно типизированный контекст передавать. В ангуляре тоже есть такое, но только без типа. В целом тот же ангуляр гораздо профитнее.
Blazor: SPA без джаваскрипта для SaaS на практике