Комментарии 73
Интересно зачем микрософт это придумал
Если на Vue.js SPA вести 1.7 мегабайт, то точно такое же на Blazor 21 мегабайт.
Кхм, а есть какое-то примерное понимание, откуда там такие размеры-то? Очень хочется пошутить про то, что он тянет с собой весь CLR, но это уж явно не имеет отношения к реальности.
Тем не менее, это именно так. А вы видите какой-то другой вариант запуска управляемого кода?
А, точно, C# же managed… Я было думал, что оно полностью компилируется в WebAssembly, без использования CLR в run-time.
Впрочем, если я правильно понимаю, с появлением GC integration в WebAssembly, можно ожидать отказ от CLR и уменьшения размеров сборки. Впрочем, не очень понятно, когда это ещё будет.
Я правильно понимаю, что прикладной C#-код в итоге не компилируется в WebAssembly, а прислылается на клиент в IL и уже там исполняется внутри CLR?
А вот это, кстати, любопытно уже с другой стороны. :)
Если Rust-приложения не тянут собой лишний рантайм и GC, то почему они не весят меньше?
Вроде как резонно предплоложить (да, я знаю, что хожу по тонкому льду), что логика там плюс-минус та же, что и во Vue-приложениях (или любых других JS-приложениях), но при этом как минимум байт-код должен быть более компактен, чем синтаксис JS.
Месяц отдал на эту интересную штуку. Понравилось, но сыровато. Заявленного рантайма нету, дебаг пробовал запустить и ничего не вышло. Можно делать очень интересные вещи, до которых ангуляр и его братья не дотянутся. Например автоматическое построение формы на основе атрибутов вьюмодели.
Про 21 мб автор немного пошутил. Если правильно поставить зависимости, чтобы клиент не тянул серверные сборки, то получается в разы меньше и работает быстрее. Года через 2-3 сие чудо уже будут требовать в стеке разработчика, так что изучать можно сейчас
А в чём проблема сделать автоматическое построение формы по атрибутам вью-модели на Ангуляре?
Silverlight-ом оно станет, когда будет что-то типа этого: http://testapp.keks-n.net/ (потыкайтесь для интереса инспектором). А пока это обычный веб-фреймворк.
Пушто
1) сделано левой ногой за два дня с целью проверки концепта и сбора граблей
2) Mono в режиме интерпретатора в целом весьма тормознутое
По результатам: инфраструктура для работы в WASM в дотнетах пока очень сырая, отладка отсутствует в принципе, стоит подождать ещё год перед очередной попыткой портирования.
Но, прочитав частушки типа «Больше тудушек богу тудушек!» становится странно, автор лучше бы ошибки исправил в тексте, если в состоянии, чем такое писать.
Например,
Все регистрируется в Startap.cs [запятая] как в обычном asp.net core приложении. Тут ничего нового. А вот внедрение зависимостей для нашей VM таки происходит через публичные свойства [запятая] а не через кноструктор. Свойство просто нужно декорировать отрибутом [<-ОтрЕбутом]
Сервелат выл выпилен не сам по себе, а вместе с NPAPI. На тех же браузерах, которые этот NPAPI всё ещё поддерживают — Silverlight работает до сих пор.
Но я пока что не могу представить ситуацию, в которой браузеры точно так же дружно отказываются от WebAssembly.
А по моим наблюдениям сервелат начали прибивать по политическим соображениям, когда никаких технических препятствий не было. Он мне как технология напомнил песню Бритни: I'm not a girl. Not yet a woman.
В сравнении с WPF он был неудобен и менее функционален. Плюс неудобная модель дистрибьюции и ещё больше проблем сперфомансом, чем у WPF.
То есть на мой взгляд если Microsoft не учудит каких-либо глупостей, то эта штука «взлетит». И я лично с удовольствием на неё перейду годика через два-три.
А как пользователь мне понравится тащить в 20 раз больше мегабайт?
И как-будто всякие Javascript/Typescript/Angular/… библиотеки, которые тащатся сейчас, совсем ничего не весят :)
И как-будто всякие Javascript/Typescript/Angular/… библиотеки, которые тащатся сейчас, совсем ничего не весят :)
Берём (для примера) самый мейнстримовый (и при этом весьма раздутый, если по-честному) стек: React (+ ReactDOM) + Redux + Reselect + Redux-Saga.
Суммарно получаем ~139 kB minified или ~46 kB minified + gzipped.
Даже если накинуть ещё столько же на прикладную логику (хотя это будет уже явно не уровень todo-приложения), Blazor'у ещё расти и расти в этом плане.
Ну, самое, опять же, мейнстримовое и разухабистое решение — 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 в браузере)?
Имхо — задавит JS фреймворки со временем потому что большинству молодых программистов просто лень учить JS. Вы не представляете себе силу лени.
На мой взгляд, с учётом того, сколько нынче JS-разрабочиков, людей, активно изучающих JS (и пойдущих в JS-разработчики через год-другой), ну и уже написанного JS-кода, "сила лени" это скорее аргумент в противоположную сторону. :)
Хотя не уверен, какой смайл здесь более уместен. :(
П.С. И да на JS/TS тоже можно работать «правильно» и писать «чистый» код. Но проблема в том что далеко не всегда работаешь только со своим кодом и тут начинаются заморочки.
Я же и не спорю с такой точкой зрения. :)
Но тем не менее индустрия весьма инертна, есть много людей, которые вложили свои силы и время в изучение JS (и очень многим из них весьма комфортно с этим языком), много компаний, которые вложили большие деньги в JS (от Google, вложивший огромное количество сил в свой V8, до продуктовых компаний, выстроивших продукт вокруг JS-стека).
А насчёт людей, которые вложили время в изучение JS… Ясное дело что люди, которые знают JS и не знают C#, в большинстве своём останутся на JS. А вот люди, которые знакомы с JS и C#(а таких на мой взгляд достаточно много), на мой взгляд потихоньку будут избавлятся от JS :)
люди, которые знакомы с JS и C#(а таких на мой взгляд достаточно много)
Всё очень зависит от личного опыта, я вот за всю свою жизнь ни одного живого C#-разработчика не видел (кроме себя разве что, но я не настоящий сварщик). ¯_(ツ)_/¯
Что конечно же совсем не означает, что их нет или мало.
обычно если выясняется что на новом стэке можно экономить время и деньги, то они не долго тянут с переходом
Ох, это очень сложный вопрос.
Тут и количество/запросы разработчиков на рынке нужно учитывать, и вопрос стоимости миграции существующих решений.
Да и JS сегодня позволяет достаточно (окей, более-менее) эффективно писать код под практически все платформы.
Я вот не готов сходу делать такие смелые оценки, что будет для сферического в вакууме бизнеса выгоднее.
По моим воспоминаниями, лет пять назад все дружно похоронили 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 очень быстро (и уже давно) растёт и расширяется, так что он давно не ограничивается тем, что мы видим в процессе "веб-сёрфинга". :)
Во вторых это очень молодая технология, наверняка вопрос с размером будет решаться в будущих релизах.
Даже в .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.
Дальше перейдём к Razor. Проблема Razor не в том, что он использует C#, а в том что запилен исключительно под MVC паттерн. И C# код там выполняется исключительно в момент генерации вьюшки. Замените в Razor C# на JS или любой другой язык программирования и ничего не изменится.
С разором проблема главная в НЕудобстве использования. Смешение парадигм и языков. С ним в презентационном слое получается месиво из 4х языков: c#, js, css, html.
И если Blazor будет «работать на трёх языках», а именно C#, css, html, то лично я это переживу :)
На тему статической типизации во фронте… Я сам и WebForms писал в своё время и Wpf сейчас пишу и честно говоря вообще никакой проблемы в статической типизации во фронте не вижу. Я ей даже рад, поскольку с ней всeвозможные предшественники, коллеги, подчинённые и авторы сторонних библиотек могут мне нагадить гораздо меньше чем без неё.
Рукожопы (профессиональные) могут нагадить изрядно и с тем и с другим. Это вопрос культуры проганья, тимлидинга и ревью.
Язык будет один, но подходы все равно в корне отличаются. С блазором бэкендеры будут шурупы забивать молотком и наждачной бумагой полировать поверхность воды.
В презентации NDC от 10 июля Steve Sanderson говорит про 2,3Мб для рантайма.
А потом вслед за рантаймом ещё летят сборки второстепенные. Я тоже видел видео с вкладкой Network в хроме.
Публикации
Blazor + MVVM = Silverlight наносит ответный удар, потому что древнее зло непобедимо