Комментарии 61
Лично я могу рекомендовать каждому c# разработчику попробовать Blazor. Мы уже некоторое время с ним работаем и ещё ни одной строки на JS не написали. А приложение уже кое-что умеет.
сможет ли Blazor за счет WebAssembly быть быстрее современных JS — фреймворков типа React, Angular, Vue
Да ладно, быстрее. Будет шикарно, если просто не будет жутких тормозов при открытии страницы. Так как сейчас работает — смысла нет, я уже забыл что открывал. Ваша демка загружалась секунд 30 — это не приемлемо для использования — просто баловство.
Если кардинально ничего не поменяется — то просто поделка для галочки, не пригодная для реального использования.
Несмотря на большую задержку загрузки в СВОИХ областях вполне будет востребовано.
В таком виде — только для локальных сетей разве что. Если есть вариант доступа через. моб. сети, где скорость плавает — то использовать крайне не комфортно.
Будем надеяться что это просто недоработка.
Оптимизация этой загрузки в будущем очевидна.
Каким образом? Устанавливать сборки вместе с браузером? Или же хранение сборок в локальном кеше браузера?
Не первое вряд ли пойдут производители браузеров. На второе — нет гарантии что пользователь уже посещал сайты на .Net Core — такие будут ждать 30 сек. и не дождуться.
Желательная скорость загружки — до 0.8 сек для среднего интернет-канала. Терпимая — до 2-3 сек.
Если сделают компиляцию в нейтивный код, чтобы страница загружалась хотя бы 1 секунду — тогда можно будет вести речь о конкуренции Angular/React. Желательно быстрее. Пока же это, быть может, подойдет для внутренних/локальных сайтов, которыми пользуются работники одного предприятия в добровольно-принудительном порядке (им за это деньги платят).
Первая загрузка — 8 секунд.
У меня 30 сек., так как сейчас живу на даче и интернет не шибко быстрый. Но при посещении других сайтов — никакого дискомфорта не испытываю — остальные сайты загружаются мгновенно.
Но и 8 сек. — это жуткий дискомфорт. Не требуется сверх-скорость, но ждать более 2-3 сек. — не приемлемо.
Microsoft.CodeAnalysis.* (считай целый компилятор) самые тяжелые библиотеки в этом примере.
Это признают даже в Microsoft. Именно по этой причине в новую версию .NET Core 3.0 войдет не Blazor, а Razor Components (server-side Blazor).
Причина все таже — даже при условии, что вам не нужны тяжеловесы аля Microsoft.CodeAnalysis.* для обычных приложений и использования умного mono linker, который вырезает весь неиспользуемый код, размер минимального приложения довольно велик.
Один из первых «осмысленных» демо примеров был FlightFinder Может появилось что-то более интересное.
А пока — можно только гадать, что будет дальше.
CORS header 'Access-Control-Allow-Origin' does not match…
А вообще-то немного не по себе от того что мой браузер тихо молча скачал dll и запустил код который потенциально может содержать что угодно включая свежайшие эксплоиты.
Прощайте сообщения «нужно обновить флеш плеер». Mono cможет сама себя обновить.
Но баги… конечно могут быть всегда.
А Cors — это не проблема, а защита. И она останеться, потому что все запросы из WASM полностью подчиняются правилам браузера.
Он не выполнит произвольную DLL. Только ту, в которой есть .net assembly и которая собственно сможет выполниться в .net машине, которая запущена в браузерной песочнице.
Нет, это не Silverlight. Тут весь смысл в том, что WebAssembly разрабатывает не Microsoft, а сообщество.
Именно так. Он связан через Mono т.е. в принципе любой желающий может взять и разработать свой Blazor не приложив для этого титанический усилий.
Конечно будут, но не титанические. jQuery же тащат с собой и не жалуются и не просят его встроить в браузер. Продукт ещё даже не вышел, поэтому не надо смотреть на текущий момент. Главное это идея. Они за год настолько сильно изменили Blazor, что очень интересно посмотреть что с ним будет через год, другой.
Уже пару месяцев работаем с Blazor. Пытаемся понять подойдёт ли он нам. Ощущения очень хорошие. Проблемы со скоростью первого запуска есть, но в десктоп браузере они не так заметны, да и надо понимать, что он ещё не вышел.
Также в сторону wasm уже идёт c++ и go.
Конечно, надо ещё доработать процесс отладки. Немного огорчило, что нельзя напрямую из клиента обратится в WCF сервис.
Аааа!!! Где вы раньше были?! Я как раз сейчас с двухэтапной компиляцией мучаюсь. Компоненты, объявленные в компилируемой же сборке упорно не подхватываются даже при двухэтапной сборке. Ощущение, что addTagHelper не видит саму сборку. Че делать и куда копать не понял пока...
Ответ «потому что WebAssembly» ситуацию не проясняет, потому что одной этой составляющей для успеха маловато.
Отвечу сразу вам и Ascar, потому что называется одно и то же преимущество – возможность не писать на ненавистном Javascript
По своему опыту работы с GWT, в более-менее больших приложениях, абстракция все равно протекает и приходится вставлять вставки «нативного» JS.
В этом отношении мне больше нравится подход Rust или Kotlin, где есть нормальная интеграция с веб-платформой, не требующая кучи трюков для вызова браузерного API.
В Blazor я вижу как раз-таки GWT-стиль — скрыть браузерную сущность за толстым слоем абстракций, которые по-любому не смогут поспевать за развитием веб-технологий. И это меня настораживает
Тем самым вы подтвердили мои опасения. GWT тоже фреймворк, и он не смог угнаться за конкурентами.
Аргумент «это будет часть ASP, а значит Майкрософт его не бросит» не убедителен, потому что у Майкрософта уже есть Typescript
Дался Вам этот GWT
Потому что эти проекты похожи как родные братья, только с разницей в 10 лет. И мотивация к появлению одна и та же: «что угодно, лишь бы не JS»
GWT был внутренней разработкой Google, которую они низвестно зачем выложили в Open Source
Я знаю несколько проектов на GWT вне Google, так что рынок был. Sencha GWT для кого-то же создали? Через 10 лет про Blazor тоже так говорить будут: «экспериментальная разработка, непонятно зачем выложенная в OpenSource»?
хайп был уже на стороне NodeJS и «супергероического» AngularJS
Я собственноручно переводил сборку фронтенда с Maven на Grunt. Однозначно получилось удобнее, никакого «ради хайпа» там не было. GWT тоже пробовали, оказалось не так удобно.
Ничто не вечно.
Важно, что постоянно появляются попытки подвергнуть сомнению монополизацию JS в браузерах. Монополия это практически всегда плохо. Мы, как разработчики должны только радоваться данным попыткам, потому что в итоге мы выиграем в любом случае.
В сторону WebAssembly уже идут: Java, C++, Go, C# и это только о которых я знаю.
Комментарии к статье о поддержки WebAssembly в ещё один язык:
- как здорово, давайте свергать монополию JS
Комментарии к статье о программировании IoT на node.js
- все плохо, зачем Javascript лезет не в свою нишу, нужно использовать правильные интрументы.
Либо я что-то не так понимаю, либо здесь двойные стандарты.
Кроме того, монополия на DOM API все ещё в руках JS, так что в итоге Blazor все равно частично транслируется в JS со всеми вытекающими
Это не наброс на JS, это я просто про отсутствие двойного стандарта.
Компиляция и запуск C# и Blazor внутри браузера