Ads
Comments 74
Получается, что вместо js будет C#, но остальное остаётся как есть — html с css? Вроде раньше говорили что у wasm нет доступа к DOM?
Не совсем понимаю что вы имеете под доступом к DOM?
Что не так с тем что по событию на клиенте меняется HTML и реализовано все это на razor и c#?
Я понимаю что тяжело воспринять разработку без JS. (Или вы чисто о технологическом уровне? Да текущий стандарт предусматривает вызов wasm модулей через JS, это связано больше с реализацией безопасности в браузерах. Но думаю что 2ая версия wasm будет уже работать без JS совсем, тут все зависит от популярности технологии Wasm)
По хорошему js'а не должно быть и под капотом, это выглядит как костыль.

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

Не думаю что быстрый технологический переход возможен без заимствования.
Текущее решение очень удобно. Ведь по сути весь сайт не должен быть на wasm написан. Любой разработчик если требуется какой-то раздел ускорить(например штихкодирование), может взять быструю реализацию на wasm и грузить на своем обычном сайте, а не переписывать весь сайт.
Процесс очень просто реализован сейча:
1) С сервера грузится HTML с JS в котором прописаны ссылки на модули WASM
2) Модули wasm грузятся и передаются браузеру для запуска
3) Браузер далее сам все делает
Очень жду джаваскрипткапца, но пока что-то не выходит каменный цветок.

Анплогично. Пока перешли на Typescript, но C# звучит ещё привлекательней :)


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

Все интегрировано и работает. В корпоративной среде можно спокойно разрабатывать. На то и внедрили все это прямо в net core 3

Да вы же сами в статье пишите что для дебагинга пока ещё надо немного потанцевать с бубном и нет lazy loading. Да и размеры загружаемых библиотек на мой взгляд надо бы как-то поменьше сделать.


Ну и потом вы это уже со всеми браузерам пробовали? Все абсолютно без проблем работают? Даже экзоты и легаси? Даже на андроидах и ios?


Сторонние библиотеки под это дело уже есть? Много их? Как качество? Мы много работаем с KendoUI и их версия под Blazor пока ещё очень рудиментарна.


П.С. То есть я не спорю, вещь интересная и похоже что для Microsoft это серьёзно. Но на данный момент на мой вкус всё ещё сыровато. Будем надеятся что созреет через годик.

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

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


Мы бы очень хотели заставить всех пользоваться сильно ограниченным набором браузеров, но это к сожалению не то чтобы великолепно работает. Особенно если учитывать что "большое начальство" даже не особо понимает в чём проблематика "зоопарка браузеров и девайсов".


Так что вкупе со всеми остальными пунктами нам пока остаётся наблюдать и ждать. И мы далеко не одни кто имеет похожие проблемы или решил подождать по другим причинам.


П.С. Но вот как раз дома я собираюсь с этим делом хорошо поиграться. Потому что если оно хорошо пойдёт, то может и подумаю фирму сменить :)

Да думаю первично это пойдёт в фирмах поменьше так как там более все динамично. Но как читал Amazon использует webassambly на своих сайтах для интернет пользователей (частично модулями на странице). Хотя у них хватит ресурсов чтобы отработать отказ и отрисовать по старинке.

Библиотеки так же активно развиваются и уже имеются продукты от самых известных фирм тот же telerik.

Telerik это и есть KendoUI. И у них даже Angular версия ещё окончательно до ума не доведена. А Blazor они только начали делать.


Но не спорю что много кто уже работает в направлении Blazor'а.

Написал ниже что blazor один из вариантов применения webassambly. Так как стандарт уже принят давно и введён во все современные браузеры, то думаю за этим будущее.

Написал ниже что blazor один из вариантов применения webassambly. Так как стандарт уже принят давно и введён во все современные браузеры, то думаю за этим будущее.

Скажем так: я очень надеюсь что за этим будущее. Но с другой стороны я помню как это в своё время было с Silverlight :)
Хотя конечно там немного другая ситуация была.


Причём для старых браузеров есть вариант blazor на стороне сервера. Я об этом в стате не писал. Там все так же в проекте, просто нет webassambly и работает через signalR.

То, что я про это читал, как-то не вдохновляет такими вещами заниматься. Если уж, то тогда "нормальный" Blazor.

Причём для старых браузеров есть вариант blazor на стороне сервера. Я об этом в стате не писал. Там все так же в проекте, просто нет webassambly и работает через signalR

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

Так это проблемы прикладного софта — скачаете хром или FF и все будет хорошо.
Познавательно. Но неужели иначе никак? На это есть причины, кроме очевидной пользы переиспользования?

Apple не разрешает использовать в приложениях скриптовые движки, которые могут выполнить произвольную внешнюю программу. Отсюда невозможность использовать свой браузерный движок. Приходится довольствоваться существующими системными компонентами WebView, которые, к тому же, несколько урезаны в возможностях по сравнению с Safari.

Что-то мне кажется мобильные браузеры любых производителей используют движек платформы. То есть chrome для ios основан на WebKit.

Такое только на iOS. На андроиде, например, Firefox использует собственный Gecko, хотя миноритарные браузеры вполне могут использовать системный компонент WebView.

Крутая штука. Была бы еще круче, если бы все эти System.dll были предустановлены на винде.

Зачем они должны быть где то установлены? Все загружается в браузер. И работает на любой ОС.

Ну а зачем загружать по сто раз одно и то же для каждого сайта приложения. Тем более .Net Framework на винде стоит из коробки. Тут, конечно, .Net Core, но после выхода единого .Net 5 в следующем году смысла тянуть все из сети уже не будет.

Повторюсь дело в том что это работает на любой ОС. Linux, mac, Android, iOS. Технология webassambly разработана как стандарт для браузеров и ее задействуют многие фирмы производители софта для разработки. Blazor это один из вариантов воплощения.

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

Кстати хотел бы посмотреть на реализацию хоть глазком. Так как сам планирую делать портальчик)

ну у меня пока нет под рукой релизного 13. Но на вчерашней бете 13.1 не пашет. Да насколько я понял, там проблема глубже в самом mono. На маке тоже не пашет. А тестить наверно можно и на таких демо, типо https://blazor-demo.github.io/

у SL был фатальный недостаток: он был слишком хорош ))) В том плане, что даже UI в нём был на xaml при том, что оно было под браузер, и это вызывало разрыв шаблона у web фронтовиков и на нём тупо было некому писать… имхо.

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


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


Это если совсем-совсем упрощать :)

Да здесь не плагин, а встроенная функция в движок. Реализованная по открытому стандарту.

ну флешу его плагинная природа особо не помешала в своё время. Хотя спору нет, этот фактор тоже вносил негатив.

Ну там как обычно ещё и куча политики была. Вполне могу себе представить что если бы Silverlight был не от Microsoft'а, то его бы приняли гораздо лучше и он мог бы и взлететь.
Но сейчас кстати и это на мой взгляд улучшилось и вещи от Microsoft гораздо лучше воспринимаются коммьюнити.

Здесь технология хороша тем что открытый стандарт. Webassembly реализует каждый разработчик браузеров самостоятельно.
У SL был фатальный недостаток, что его поддержка добавлялась плагином к браузеру. Webassembly этого недостатка лишен. Кстати жаль что в Blazor нельзя рисовать интерфейс в XAML…
А в те времена еще не было фронтовиков, тогда еще JQuery-то только-только начинал массово внедряться. Silverlight убил Джобс, когда заявил, что все приложения и казуальные игры должны устанавливаться через Store, что Flash, Flex и Silverlight на iPhone поддерживаться не будут, а сайты должны будут ограничиться HTML и JavaScript. С тех пор и появились разработчики на JavaScript как отдельный вид, до этого если человек знал только JS, HTML и CSS, то считалось, что он «верстальщик» и лох, ему платили как джуниору и советовали выучить какой-нибудь язык программирования. AJAX в те времена еще считался крутой технологией, до сих пор помню, как пытался в Internet Explorer вызвать SOAP веб сервис, распарсить его XML ответ с помощью ActiveX компонента и обновить список товаров без перезагрузки. Сейчас смешно, а тогда это был подвиг.

спасибо, ну пока костыльненько, конечно, но раз 13 уже релизнулась для всех, то выбор невелик, походу придется воспользоваться.

"Спасибо" таким технологиям как Blazor с их 2.5-мегабайтными бандлами, после них 300 Кб типичного Javascript-проекта кажутся чем-то маленьким и шустрым.

Зашел на vtb.ru в сжатом состоянии главная страница скачала 4,5MB данных. И это я еще в онлайн не залезал раздел. Так что давайте будем объективны, разница с JS не большая.

Да, с банковскими сайтами беда, сейчас проверил еще несколько (сбербанк, райфайзен), все грузят как минимум 2-3 Мб JS.


Однако есть и нормальные сайты, например, мобильная версия Хабра (https://m.habr.com), тут всего 250 Кб джаваскрипта.


То есть в случае с JS есть куда худеть, а в Blazor – ничего меньше 2 Мб я в демках не видел.

Ну на мой взгляд было бы странно ожидать что Blazor сразу выдаст маленькие "бандлы". Но по идее сам исполняемый код там не будeт сильно больше чем в JS и проблема скорее в "инфраструктуре" самого Blazor, которую каждый раз приходится паковать в бандлы и тащить с собой.


А такие вещи в принципе решаемы тем или иным способом. Так что думаю рано или поздно Blazor тоже "похудеет".

Так там, так же сейчас, не заботится никто ни о чем. Я в статье показал что происходит на автомате в шаблоне по умолчанию. Худеть есть куда, причем значительно.
А что на счёт полностью компонентного подхода по аналогии с тем же React.js? Такое возможно? Есть уже библиотеки, примеры реализации в подобном стиле?
 <App>
  <Header />
  <Content />
  <Footer /> 
</App>
В Asp.net mvc всегда был компонентный подход, а он появился раньше react.js
Вы про классы тег-хелперы или есть что-то более удобное, более близкое к подходу реакта в плане синтаксиса? Можно ссылку на примеры или совет как искать, если не сложно?

В mvc принято view, partialview.
Хедеров внутри. Думаю для ms первый шаг к клиентскому фреймворку сделан. Далее развитие. И выбор в пользу webassambly очень правильный.

Почитал документация на офф сайте.
Мне кажется или роутинг там какой-то слабый?
В Angular есть всякие аутлеты и т д, а тут что-то такого не увидел…
В остальном, вроде, прикольно.
Так эта маршрутизация на стороне сервера.
А я имел ввиду маршрутизацию на стороне клиента.
Нет не сервера. Постарайтесь понять как это работает. Код на c#, но на стороне клиента.
А что же вы вкладываете в это понятие? Лучше бы привели пример чего нет, так было бы проще поискать вместе.
Мне вот такая тема в Ангуляре понравилась:
angular.io/api/router/RouterOutlet

Т.е в некотором компоненте создается узел с разметкой
 <router-outlet></router-outlet>
, а дальше в этом месте рендерятся дочерние компоненты в зависимости от маршрутов. Нажал на одну кнопку и в этом месте отрендерился один компонент, нажал на другую и другой компонент.

Я пытался нагуглить аналог в Blazor, но что-то не нашел=(

На мой взгляд фича приятная, но не необходимая. И если я не ошибаюсь, то в Angular она тоже была не с самой первой версии.

Я не эксперт по CSS, но моих знаний достаточно чтобы предположить что проблема решается стандартным образом. И самое главное не имеет отношения к теме статьи.
unicss.maxsite.com.ua

Кстати кто-то смог .Net Conf 2019 нормально посмотреть? Там вроде должны были и про Blazor рассказывать. Ничего нового/интересного не было?

Пока что выпустили Blazor Server, который выполняет весь код на сервере. Т.е. по каждому клику на кнопку будет выполняться серверный код (данные передаются с помощью SignalR) со всеми вытекающими минусами. А в мае уже выйдет Blazor WebAssembly, где код выполняется на клиенте.
Only those users with full accounts are able to leave comments. Log in, please.