Comments 73

я не особо в курсе, когда там уже можно будет полноценно писать на шарпе под браузер?

Если на Vue.js SPA вести 1.7 мегабайт, то точно такое же на Blazor 21 мегабайт.

Кхм, а есть какое-то примерное понимание, откуда там такие размеры-то? Очень хочется пошутить про то, что он тянет с собой весь CLR, но это уж явно не имеет отношения к реальности.

Тем не менее, это именно так. А вы видите какой-то другой вариант запуска управляемого кода?

А, точно, C# же managed… Я было думал, что оно полностью компилируется в WebAssembly, без использования CLR в run-time.


Впрочем, если я правильно понимаю, с появлением GC integration в WebAssembly, можно ожидать отказ от CLR и уменьшения размеров сборки. Впрочем, не очень понятно, когда это ещё будет.

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

Я правильно понимаю, что прикладной C#-код в итоге не компилируется в WebAssembly, а прислылается на клиент в IL и уже там исполняется внутри CLR?

Вероятно, достаточно доставить до клиента WASM.NET один раз, а другие разы использовать из кэша? Или это невозможно сейчас с WASM?

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

Мне кажется, странно использовать такие приложения на мобильных. Может быть, на планшетах ещё. А какие-то общие пакеты для WASM уже придумали?

Ну на Rust и Yew (Фреймворк под веб ассембли на Rust) приложение весит почти столько же сколько и на Vue так что таки да, дело в рантайме который Blazor тащит с собой.

А вот это, кстати, любопытно уже с другой стороны. :)
Если Rust-приложения не тянут собой лишний рантайм и GC, то почему они не весят меньше?


Вроде как резонно предплоложить (да, я знаю, что хожу по тонкому льду), что логика там плюс-минус та же, что и во Vue-приложениях (или любых других JS-приложениях), но при этом как минимум байт-код должен быть более компактен, чем синтаксис JS.

UFO landed and left these words here
Все происходит на сервере, а клиенту через сокеты передается готовый DOM. Браузеру вообще почти ничего не надо скачивать в начале, но зато вместо этого постоянно по кускам скачивать обновленный DOM.

Хммм, да поправит меня yelbota, но что-то мне это очень сильно напоминает… :)

Да, обсуждали сходство в комментах к моему посту. Непонятен только вес рантайма для сервер-сайд режима. Если он весит мегабайты как Vaadin, то это не имеет особого смысла. Королев специально сделан так чтобы весить минимально.

Месяц отдал на эту интересную штуку. Понравилось, но сыровато. Заявленного рантайма нету, дебаг пробовал запустить и ничего не вышло. Можно делать очень интересные вещи, до которых ангуляр и его братья не дотянутся. Например автоматическое построение формы на основе атрибутов вьюмодели.
Про 21 мб автор немного пошутил. Если правильно поставить зависимости, чтобы клиент не тянул серверные сборки, то получается в разы меньше и работает быстрее. Года через 2-3 сие чудо уже будут требовать в стеке разработчика, так что изучать можно сейчас

А в чём проблема сделать автоматическое построение формы по атрибутам вью-модели на Ангуляре?

Silverlight-ом оно станет, когда будет что-то типа этого: http://testapp.keks-n.net/ (потыкайтесь для интереса инспектором). А пока это обычный веб-фреймворк.

Пушто
1) сделано левой ногой за два дня с целью проверки концепта и сбора граблей
2) Mono в режиме интерпретатора в целом весьма тормознутое


По результатам: инфраструктура для работы в WASM в дотнетах пока очень сырая, отладка отсутствует в принципе, стоит подождать ещё год перед очередной попыткой портирования.

Blazor + NET Core 3 в развитии, надо изучать.
Но, прочитав частушки типа «Больше тудушек богу тудушек!» становится странно, автор лучше бы ошибки исправил в тексте, если в состоянии, чем такое писать.
Например,
Все регистрируется в Startap.cs [запятая] как в обычном asp.net core приложении. Тут ничего нового. А вот внедрение зависимостей для нашей VM таки происходит через публичные свойства [запятая] а не через кноструктор. Свойство просто нужно декорировать отрибутом [<-ОтрЕбутом]
Вот только у меня такое чувство, что нет особого смысла учить эту костыльную штуку, когда есть Vue, Angular и прочее? Есть ощущение, что через пару лет ее выпилят как и Сильверлайт в свое время.

Сервелат выл выпилен не сам по себе, а вместе с NPAPI. На тех же браузерах, которые этот NPAPI всё ещё поддерживают — Silverlight работает до сих пор.


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

А по моим наблюдениям сервелат начали прибивать по политическим соображениям, когда никаких технических препятствий не было. Он мне как технология напомнил песню Бритни: I'm not a girl. Not yet a woman.


В сравнении с WPF он был неудобен и менее функционален. Плюс неудобная модель дистрибьюции и ещё больше проблем сперфомансом, чем у WPF.

Если эта «костыльная штука» будет работать хотя бы приблизительно так хорошо как «Vue, Angular и прочее», то учить её очень даже стоит. Так как она позволяет использовать один и тот же язык и одни и те же библиотеки для фронта и бэка. И это очень многого стоит. Как разработчик ты экономишь кучу времени, которое в том же Angular уходит на дублирование кода. Как фирма ты экономишь кучу денег и времени, так как твоим разработчикам нужно учить на один язык программирования меньше.

То есть на мой взгляд если Microsoft не учудит каких-либо глупостей, то эта штука «взлетит». И я лично с удовольствием на неё перейду годика через два-три.
> Как разработчик ты экономишь кучу времени

А как пользователь мне понравится тащить в 20 раз больше мегабайт?
А с чего вы решили что вы обязательно будете «тащить в 20 раз больше мегабайт»? Если я всё правильно понимаю что в случае «серверной версии» там не сильно много лишнего и тащить то надо будет.
И как-будто всякие Javascript/Typescript/Angular/… библиотеки, которые тащатся сейчас, совсем ничего не весят :)
И как-будто всякие Javascript/Typescript/Angular/… библиотеки, которые тащатся сейчас, совсем ничего не весят :)

Берём (для примера) самый мейнстримовый (и при этом весьма раздутый, если по-честному) стек: React (+ ReactDOM) + Redux + Reselect + Redux-Saga.
Суммарно получаем ~139 kB minified или ~46 kB minified + gzipped.
Даже если накинуть ещё столько же на прикладную логику (хотя это будет уже явно не уровень todo-приложения), Blazor'у ещё расти и расти в этом плане.

А если добавить туда какую-нибудь библиотечку для формочек/контролей и прочего? Сколько тогда будет? И с React я лично не работал, но если брать Angular(a особенно если Angular Elements какие-нибудь) да ещё и с каким-нибудь Kendo, ещё парочку других библиотек добавить, да ещё картиночек, да ещё… то уже пойдут мегабайты. И это не то чтобы абсолютно исключение для веб-страничек…

Ну, самое, опять же, мейнстримовое и разухабистое решение — Redux-Form, ещё 139 kB minified или 26.9 kB minified + gzipped. Безумно много, но суммарно (со всем остальным) даже до половины мегабайта не дотянули.
При этом довольно популярная альтернатива (от тех же авторов, осознавших, какое хтоническое чудовище они породили в виде Redux-Form) — Final-Form, весит всего 14.8 kB minified или 5 kB minified + gzipped.


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


Пока что в сравнении размеров базовой комплектации Blazor очень сильно уступает современным JS-решениям. К тому же, решение с интерпретацией IL на клиенте (см. выше) лично у меня вызывает вопросы касательно производительности выполнения прикладного кода.
Надеюсь, всё это временные проблемы Blazor'а, которые его разработчикам получится преодолеть.

С производительностью там как раз всё в порядке: это ж не чистая интерпретация, а JIT-компиляция статически типизированного языка.


Проблемы тут возможны с долгим стартом и с размером.

То есть у нас JIT-компиляция IL внутри CLR, который работает в WebAssembly VM c JIT? :)

В том, что современный JS компилируется в байт-код на старте приложения и дальше JIT-компилируется нативным JS-движком.


А в случае C# добавляется дополнительная прослойка в виде CLR, что "вызывает вопросы касательно производительности".

А в случае C# добавляется дополнительная прослойка в виде CLR, что «вызывает вопросы касательно производительности».

Не факт. Там есть AOT (вероятно, ещё не полностью допиленный), т.е. в браузер уже уйдёт оптимизированный wasm-код (без IL), который, в свою очередь, ещё может быть JIT-компилирован самим браузером (как и любой другой).

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


А что MSIL что WASM являются полностью статически типизированными, что позволяет результирующему машинному коду не делать никаких проверок типа в рантайме.

В вебфреймворках размер бандла распухает подключением Materials Design и прочих нахлобучек, которых блазоре нет также. Тут ничья. А вот .net runtime не стрипается вообще. Это фундаментальный косяк, что с приложением в память грузятся целиком сборки. Так же и в блазоре щас. Через сеть тянется весь рантайм. Изменится сишарп твоей логики и рантайм заново будет сосаться или браузер сможет в глобальный кэш положить рантайм (GAC в браузере)?

Как я уже выше говорил приложения на Rust весят почти столько же как и под JS с фреймворками так что тут дело в рантайме. Как только запилят встроенный в WASM GC и оптимизируют сборку чтобы в ней был только нужный код то будет и Blazor весит меньше мегабайта. Таки да технология молодая от слова совсем. Имхо — задавит JS фреймворки со временем потому что большинству молодых программистов просто лень учить JS. Вы не представляете себе силу лени. Лет через 5 — 6 когда примерно произойдет смена поколений.
Имхо — задавит JS фреймворки со временем потому что большинству молодых программистов просто лень учить JS. Вы не представляете себе силу лени.

На мой взгляд, с учётом того, сколько нынче JS-разрабочиков, людей, активно изучающих JS (и пойдущих в JS-разработчики через год-другой), ну и уже написанного JS-кода, "сила лени" это скорее аргумент в противоположную сторону. :)


Хотя не уверен, какой смайл здесь более уместен. :(

Я работаю с JS уже долго и лично я им очень недоволен. TS уже лучше, но всё ещё унаследовал некоторые «болезни» JS. Если лично мне дадут возможность писать фронтэнд на языке вроде C#, то я буду танцевать от радости :)

П.С. И да на JS/TS тоже можно работать «правильно» и писать «чистый» код. Но проблема в том что далеко не всегда работаешь только со своим кодом и тут начинаются заморочки.

Я же и не спорю с такой точкой зрения. :)
Но тем не менее индустрия весьма инертна, есть много людей, которые вложили свои силы и время в изучение JS (и очень многим из них весьма комфортно с этим языком), много компаний, которые вложили большие деньги в JS (от Google, вложивший огромное количество сил в свой V8, до продуктовых компаний, выстроивших продукт вокруг JS-стека).

Компании понять можно. Но обычно если выясняется что на новом стэке можно экономить время и деньги, то они не долго тянут с переходом :)
А насчёт людей, которые вложили время в изучение JS… Ясное дело что люди, которые знают JS и не знают C#, в большинстве своём останутся на JS. А вот люди, которые знакомы с JS и C#(а таких на мой взгляд достаточно много), на мой взгляд потихоньку будут избавлятся от JS :)
люди, которые знакомы с JS и C#(а таких на мой взгляд достаточно много)

Всё очень зависит от личного опыта, я вот за всю свою жизнь ни одного живого C#-разработчика не видел (кроме себя разве что, но я не настоящий сварщик). ¯_(ツ)_/¯
Что конечно же совсем не означает, что их нет или мало.


обычно если выясняется что на новом стэке можно экономить время и деньги, то они не долго тянут с переходом

Ох, это очень сложный вопрос.
Тут и количество/запросы разработчиков на рынке нужно учитывать, и вопрос стоимости миграции существующих решений.
Да и JS сегодня позволяет достаточно (окей, более-менее) эффективно писать код под практически все платформы.
Я вот не готов сходу делать такие смелые оценки, что будет для сферического в вакууме бизнеса выгоднее.


off-topic

По моим воспоминаниями, лет пять назад все дружно похоронили Ruby и RoR. Я вот вообще не вижу причин сегодня писать на Ruby.
Однако ж не очень похоже что этот стек умер. :)

Пример:
Visual Studio против VS Code.
Функционал для рядового девелопмента у Code не намного скуднее. Даже иногда наоборот.В Code можно отлаживать Xamarin Android на реальном телефоне, а с VS хз как… Я не нашел способа подрубить дебаггер.


Code написана на js и летает
VS написана на убогом старом VS Shell (c++) а поверх натянут WPF. Топмозит, жрет памяти вагон, и размер установки с нужными тулзами под 30ГБ на системном диске.

Я знаю и то и другое на высоком уровне. Ни в жисть не буду с js слазить. Хватило мне с головой winforms и webforms. Если на шарпе, только wpf с XAML.

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

В ui динамический язык, duck typing в сочетании сдеклараьивным подходом дают больше профита чем статическая типизация.
Как ui разраб на WPF с 2007 года я вас уверяю, что со статической типизацией во фронте под десктоп тоже не сладко. Довольно много сил отнимают церемонии с полиморфизмом, интерфейсами и согласованиями зависимостей. А уж как вы будете писать на шарпе ui я даже представить боюсь.


Было у меня щастье от индусов разных национальностей в поддержку получать WinForms файл главного окна на 25 килострок. Ужосна хххх. Дай то б-г чтоб вам такое не довелось попробовать.

Прозвучит для кого-то ужасно, но есть области, где это совершенно неважно.


Типичный пример — разработка внутрикорпоративных решений. Браузер там используется просто как платформа для запуска приложений. Пользователи открывают "сайт" один раз в день (если не раз в неделю) и, как правило, не закрывают.


Другой пример — оболочки некоторых (за все не скажу) сенсорных терминалов, которые можно увидеть во многих ТЦ и магазинах, работают как веб-приложения. Опять же, такие приложения запускаются один раз (на старте терминала), их размер и скорость инициализации мало кого интересует.


Хорошо это или плохо, но Web очень быстро (и уже давно) растёт и расширяется, так что он давно не ограничивается тем, что мы видим в процессе "веб-сёрфинга". :)

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

Даже в .net core ещё вроде не научились стрипать сборки, чтоб облегчить дистриб и потребление памяти (все сборки грузятся целиком). Поправьте меня если неправ.
Если научат CLR стрипать сборки, тогда может и облегчится. А пока они идут по пути сервелата. Пытаются оптимизировать код в сборках, чтоб они были меньше. Сбрасывают жир в ущерб функциональности.

Один язык — это все фигня. Меня ни в жисть не заставишь на шарпе писать вебовский фронт. Хватит… Надрался я этого долбаного Razor в WebForms с треклятыми постбэками.
Для меня разор… Тьфу… Блазор суть удачное сочетание недостатков WebForms и Silverlight. И предательство M$ с SL/WPF я не забуду. Вместо исправления графического стэка для подъёма производительности они пилят новый сервелатФормз.


ПыСы: я на WPF с 2007 года (а может даже чуть раньше, не помню уж) и для меня VueJS значительно соблазнительные.

Э-э-э, это вы вообще о чём? Какое отношение имеет Razor к WebForms и постбэкам?

Да вы правы. Я смешал две техники. И происходит это потому что у них есть общее. Смешивание декларативки с кодом c#. А разница между <% и @ уже несущественна. Смешивание разных парадигм в одном файле — гадство.

Там разница не между <% и @, а между коряво реализованным компонентным подходом и хорошо реализованной шаблонизацией.


Что же до смешивания парадигм — не вижу никакой особой императивности в цикле foreach пока внутри у него нормальная декларативная разметка. Конечно, это несколько уменьшает возможности постобработки — но для серверной генерации html большего и не требуется.

Вы мне столько написали, отвечу в одном месте.

На тему статической типизации во фронте… Я сам и WebForms писал в своё время и Wpf сейчас пишу и честно говоря вообще никакой проблемы в статической типизации во фронте не вижу. Я ей даже рад, поскольку с ней всeвозможные предшественники, коллеги, подчинённые и авторы сторонних библиотек могут мне нагадить гораздо меньше чем без неё. И писать UI на C# я буду совершенно спокойно, используя например MVVM паттерн. Опять же не вижу вообще никаких причин почему в Wpf это работает, a в Blazor вдруг перестанет.

Дальше перейдём к Razor. Проблема Razor не в том, что он использует C#, а в том что запилен исключительно под MVC паттерн. И C# код там выполняется исключительно в момент генерации вьюшки. Замените в Razor C# на JS или любой другой язык программирования и ничего не изменится. Так что скорее всего просто вам не надо было брать Razor потому что MVC не подходил под ваши задачи.

Ну и самое главное насчёт GAC в кэше браузера при «смене C#». Это вообще какая-то дичь. Я вас наверное удивлю, но Microsoft наконец-то научился кросс-рантайму. Для этого и был придуман .NET-Standard. У наc инфраструктура состоит из .Net Framework(C# 7) и .NetCore(C# 8) и мы спокойно пишем под них общие проекты/библиотеки. И если добавиться какой-нибудь .NetWeb или .NetBlazor рантайм, то если он будет совместим с .NET-Standard 2.0 или выше(а я не вижу почему это должно быть иначе), то я смогу использовать свои библиотеки и там.
И я вообще ожидаю от Blazor что браузер будет тащить мои библиотеки с моего хоста, а рантайм будет тащиться с хоста Microsoft и где-тo кэшится. Аналогично с тем как сейчас хостится JQuery.
Ну или, если уж совсем фантазировать, что браузеры рано или поздно добавят рантайм Blazor в свои сборки.
Проблема Razor не в том, что он использует C#, а в том что запилен исключительно под MVC паттерн

На самом деле нет: кроме ASP.NET MVC существовала ещё и ASP.NET WebPages, где запрос напрямую попадал к cshtml-странице. Более того, такой режим использования Razor до сих пор поддерживается в ASP.NET Core.

Ок, mea culpa, совсем вырезал это из памяти :) Но если человек на этом пытался веб делать, то тогда мне его боль вполне понятна :)
Дальше перейдём к Razor. Проблема Razor не в том, что он использует C#, а в том что запилен исключительно под MVC паттерн. И C# код там выполняется исключительно в момент генерации вьюшки. Замените в Razor C# на JS или любой другой язык программирования и ничего не изменится.

С разором проблема главная в НЕудобстве использования. Смешение парадигм и языков. С ним в презентационном слое получается месиво из 4х языков: c#, js, css, html.

Ну если следовать такой логике, то вашем Vue получается «мессиво» трёх языков, а в том же Angular опять же четырёх(ну если использовать его так, как вы используете Razor). Так что это для меня не особо аргумент.
И если Blazor будет «работать на трёх языках», а именно C#, css, html, то лично я это переживу :)
На тему статической типизации во фронте… Я сам и WebForms писал в своё время и Wpf сейчас пишу и честно говоря вообще никакой проблемы в статической типизации во фронте не вижу. Я ей даже рад, поскольку с ней всeвозможные предшественники, коллеги, подчинённые и авторы сторонних библиотек могут мне нагадить гораздо меньше чем без неё.

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

Ага, ну и расскажите мне как при помощи «культуры проганья, тимлидинга и ревью» я например должен разгребать кривой легаси-проект, написанный кем-то, кого я даже на фирме не застал :)

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

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

А потом вслед за рантаймом ещё летят сборки второстепенные. Я тоже видел видео с вкладкой Network в хроме.

Наверняка через матёрый прослой и бубнотанцы как было в сервелате.

Only those users with full accounts are able to leave comments. Log in, please.