Предложили использовать для написания админки Blazor WebAssembly. Не публичный сайт, т.е. риск лишь в том, что потом перестанет работать в новых браузерах и придется извращаться.
Кто использует в данный момент — какие реальные подводные камни, стоит ли рисковать?
Здравствуйте, Shmj, Вы писали:
S>Предложили использовать для написания админки Blazor WebAssembly. Не публичный сайт, т.е. риск лишь в том, что потом перестанет работать в новых браузерах и придется извращаться.
S>Кто использует в данный момент — какие реальные подводные камни, стоит ли рисковать?
А в чем риск? WebAssembly запретят? https://developer.mozilla.org/ru/docs/WebAssembly/Concepts
Различные типы кода могут вызывать друг друга по мере необходимости — WebAssembly JavaScript API оборачивает экспортированный код WebAssembly в функции JavaScript, которые можно вызывать обычным способом. А в код WebAssembly можно импортировать и синхронно вызывать обычные функции JavaScript. Фактически, базовая единица кода WebAssembly называется модулем, а модули WebAssembly во многом схожи с модулями ES2015.
Здравствуйте, Serginio1, Вы писали:
S>>Кто использует в данный момент — какие реальные подводные камни, стоит ли рисковать? S> А в чем риск? WebAssembly запретят?
Ну почему то же не спешат переходить — до сих пор юзают React/Angular/Vue... Хотя WebAssembly ждали как 60-летняя пара своего первенца.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>>Кто использует в данный момент — какие реальные подводные камни, стоит ли рисковать? S>> А в чем риск? WebAssembly запретят?
S>Ну почему то же не спешат переходить — до сих пор юзают React/Angular/Vue... Хотя WebAssembly ждали как 60-летняя пара своего первенца.
Здравствуйте, Shmj, Вы писали:
S>Предложили использовать для написания админки Blazor WebAssembly. Не публичный сайт, т.е. риск лишь в том, что потом перестанет работать в новых браузерах и придется извращаться.
S>Кто использует в данный момент — какие реальные подводные камни, стоит ли рисковать?
Здравствуйте, Shmj, Вы писали:
S>>>Кто использует в данный момент — какие реальные подводные камни, стоит ли рисковать? S>> А в чем риск? WebAssembly запретят? S>Ну почему то же не спешат переходить — до сих пор юзают React/Angular/Vue... Хотя WebAssembly ждали как 60-летняя пара своего первенца.
Здравствуйте, DenisCh, Вы писали:
DC>Здравствуйте, Shmj, Вы писали:
S>>>>Кто использует в данный момент — какие реальные подводные камни, стоит ли рисковать? S>>> А в чем риск? WebAssembly запретят? S>>Ну почему то же не спешат переходить — до сих пор юзают React/Angular/Vue... Хотя WebAssembly ждали как 60-летняя пара своего первенца.
DC>Хм... Чтобы жабаскриптёр перешОл на шарп...
DC>Фантастика на третьем этаже...
Ну почему же. Те кто писал Asp.Net на Razor е перейдут.
Да и тот же TypeScript очень близок к C#, а именно на нем пишут React/Angular/Vue
Просто писать на C# наменого удобнее и не нужно возиться с WebPack, npm модулями,кучей настроек.
В C# все привыкли к using, а в том же ангуларе еще куча @NgModule нужно прописывать итд.
Удобство однозначно есть. По сути сейчас все упирается в визуальные компоненты. Как в юзабельности так и в скорости
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Shmj, Вы писали:
S>Предложили использовать для написания админки Blazor WebAssembly. Не публичный сайт, т.е. риск лишь в том, что потом перестанет работать в новых браузерах и придется извращаться.
Чего? Когда это что-то из стандартов W3C перестало вдруг работать в новых браузерах?
Тем более что WebAssembly — это наоборот, новейшая технология, которая скорее на старых браузерах (типа ИЕ 11) не работает.
S>Кто использует в данный момент — какие реальные подводные камни, стоит ли рисковать?
Blazor WebAssembly сам по себе — лучшее из того, что было до сих пор доступно для разработки на стороне браузера.
C#, .NET, Razor-синтаксис для HTML (и партиальные классы на C# к нему!), биндинги, нормальная компонентная модель — все это вместе нереально круто.
Если бы мне предложили его использовать для админки — взялся бы однозначно.
Ну а подводные камни — зависят от требуемого функционала и его наворочености.
Например, потребуется тебе выводить данные в гриде, с виртуальным скроллингом и автоподгрузкой данных, авто-фильтрами в колонках, инплейс редактированием, настраиваемыми колонками и т.п.
С нуля все это писать можно, но очень долго.
Вероятнее всего, придется брать что-то готовое, написанное на JavaScript, разбираться в нем, допиливать напильником до требуемого состояния, дописывать какие-то хелперные функции (на JS, да), оборачивать все это в Blazor компонент — с нормальными свойствами, событиями и методами.
Аналогично — если потребуется какой-нибудь DateTimePicker или еще что.
Сейчас количество готовых компонентов для Blazor не очень велико.
Какие-то совсем базовые есть, типа https://bootstrapdemo.blazorise.com/ или https://blazorstrap.io но это совсем мелочь по сравнению с тем, что есть для Angular или React.
Поэтому, если кто-то думает, что при использовании Blazor WebAssembly можно совсем уйти от JS — то будет сильно разочарован.
По мне — так это главный подводный камень.
Здравствуйте, Shmj, Вы писали:
S>Ну почему то же не спешат переходить — до сих пор юзают React/Angular/Vue...
Кто должны спешить переходить — JS-девелоперы? Так их и на React/Angular/Vue неплохо кормят.
Blazor скорее будут использовать C# девелоперы, которые либо подустали от JS (TS), либо вообще с ним дело имели только изредка.
S>Хотя WebAssembly ждали как 60-летняя пара своего первенца.
Так его совсем другие люди его ждали — вряд ли те, кто юзают React/Angular/Vue.
WebAssembly сильно нужен был всяким гейм-девелоперам, чтобы можно было в браузере использовать всякие движки и либы, писанные на C/C++. И чтобы быстро все работало.
Тем, для кого скорость работы JS была реально узким местом.
А Blazor WebAssembly — это скорее про удобство для разработчика.
Здравствуйте, sgrape, Вы писали:
S>Здравствуйте, Shmj, Вы писали:
S>>Предложили использовать для написания админки Blazor WebAssembly. Не публичный сайт, т.е. риск лишь в том, что потом перестанет работать в новых браузерах и придется извращаться.
S>Сейчас количество готовых компонентов для Blazor не очень велико. S>Какие-то совсем базовые есть, типа https://bootstrapdemo.blazorise.com/ или https://blazorstrap.io но это совсем мелочь по сравнению с тем, что есть для Angular или React.
Запрос в гугле "blazor components":
Radzen — free set of 40+ native Blazor UI controls.
Matblazor — MIT License
Telerik — за деньги
Syncfusion — за деньги
Devexpress — за деньги
...
Это первая страница выдачи гугла.
S>Поэтому, если кто-то думает, что при использовании Blazor WebAssembly можно совсем уйти от JS — то будет сильно разочарован.
Базовое знание JS необходимо. Разве это проблема? Более важно то, что дотнетчику нет необходимости разбираться с angular, react, ... и их экосистемами.
S>По мне — так это главный подводный камень.
Мне кажется главный подводный камень в том что, тем кто занимался бекэндом/десктопом придется разбираться с http, html, css. Но разбираться с этим проще в контексте родной экосистемы.
Здравствуйте, v.a.v, Вы писали:
VAV>Запрос в гугле "blazor components":
VAV>Radzen — free set of 40+ native Blazor UI controls. VAV>Matblazor — MIT License VAV>Telerik — за деньги VAV>Syncfusion — за деньги VAV>Devexpress — за деньги VAV>... VAV>Это первая страница выдачи гугла.
Посмотрел я вопросы там претензии к скорости и функциональности.
То есть пока детские болезни присутствуют какие были и в Ангуларе.
Главное нАчать!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Посмотрел я вопросы там претензии к скорости и функциональности.
А с чем это может быть связано?
Долго загружаются, сбоят — понятно. Но претензии к скорости и функциональности...
Они ведь, наверняка портировали их из своих же angular/react компонентов. То есть алгоритмы работы те же.
Здравствуйте, v.a.v, Вы писали:
VAV>Здравствуйте, Serginio1, Вы писали:
S>> Посмотрел я вопросы там претензии к скорости и функциональности.
VAV>А с чем это может быть связано? VAV>Долго загружаются, сбоят — понятно. Но претензии к скорости и функциональности... VAV>Они ведь, наверняка портировали их из своих же angular/react компонентов. То есть алгоритмы работы те же.
Проблемы в том, что:
— До сих пор нет нормального компилятора из .net в webassembly, сейчас используется интерпретатор и он очень тормозной
— в webassembly еще много чего не хватает, в частности, прямого доступа к DOM, из-за чего пришлось городить интероп на JS и он тоже добавляет проблем с производительностью
по алгоритмам как раз все хорошо, там очень эффективная реализация virtual dom
Здравствуйте, v.a.v, Вы писали:
VAV>Здравствуйте, Serginio1, Вы писали:
S>> Посмотрел я вопросы там претензии к скорости и функциональности.
VAV>А с чем это может быть связано? VAV>Долго загружаются, сбоят — понятно. Но претензии к скорости и функциональности... VAV>Они ведь, наверняка портировали их из своих же angular/react компонентов. То есть алгоритмы работы те же.
Ну немного другие.
Так нужно либо делать прокси на нетовской коллекцией в JS или сериализовывать десериализовывать через Json.
Нужно кэшировать https://github.com/dotnet/aspnetcore/issues/21085#issuecomment-641071760
Есть нюансы. Они известны. Работают над ними
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Проблемы в том, что: ЕА>- До сих пор нет нормального компилятора из .net в webassembly, сейчас используется интерпретатор и он очень тормозной
Вот с этого и нужно начинать — пока еще не реализовали в полной мере.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>Проблемы в том, что: ЕА>>- До сих пор нет нормального компилятора из .net в webassembly, сейчас используется интерпретатор и он очень тормозной
S>Вот с этого и нужно начинать — пока еще не реализовали в полной мере.
Но для админки вполне подойдет и в текущем состоянии
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Shmj, Вы писали:
S>Предложили использовать для написания админки Blazor WebAssembly. Не публичный сайт, т.е. риск лишь в том, что потом перестанет работать в новых браузерах и придется извращаться.
S>Кто использует в данный момент — какие реальные подводные камни, стоит ли рисковать?
Blazor WebAssembly
из плюсов — возможность использовать готовые библиотеки C# в браузере.
подводный камни это компоненты, т.к. это очень сложная абстракция на html и javascript(который если я правильно понял, еще долго будет использоваться для взаимодействия wasm и html-страницы),
отсюда сложность встраивания в архитектуру http, хотя и выглядит многообещающе но порог вхождения слишком высок.
Если требуется сделать насыщенную интерактивную страницу мне кажется проще использовать js (vanilla или react).
Пока раскачаешься много времени пройдет.
Однако, если планируется использовать простые CRUD-страницы без сложного поведения, то можно использовать radzen,
но при этом разницы между клссическим razor pages и темой никакой. Еще когда пробовал использовать серверный блэйзор были проблемы с перегрузкой, т.е. для хранения состояния страницы нужно городить синглтон сервис.
клиентский особо не юзал, но тоже вроде не без граблей.
не понимаю, почему все против js.
fetch("http://service/persons")
.then( r => r.json())
.then( d => console.log(d))
.error( e => console.error(e));
Чем это хуже чеи:
var httpClient = new httpClient ();
try
{
logger.Log(await httpClient.GetAsync("http://service/persons");
}catch(Exception e)
{
logger.Error(e);
}
По-моему, ja последних версий очень приятный и удобный язык( в сравнении)
Здравствуйте, varenikAA, Вы писали: AA>По-моему, ja последних версий очень приятный и удобный язык( в сравнении)
с TypeScript?
Программировать на нескольких языках не проблема, но все равно нужно некоторое время для переключения с одного языка на другой.
Удобнее конечно писать на одном языке и использовать одни и те же библиотеки иметь единую систему классов не только как структуру данных, но и методов, наследования итд
и солнце б утром не вставало, когда бы не было меня
