Ваш вопрос немного некорректно поставлен, Blazor не язык программирования и сравнивать его с JS нельзя.
Но если сравнить к примеру, JS фреймворк и Blazor, то пока плюсы по большей части только в том, что можно использовать другой язык программирования со всеми его плюсами и минусами. К примеру, C# в данном случае дает строгую типизацию и свои плюсы в IDE.
На данный момент в Blazor много чего нет, что есть в других фреймворках и к чему уже все привыкли.
По поводу Unity и WPF посмотрите проект uno platform
При использовании модели размещения Blazor Server приложение выполняется на сервере из приложения ASP.NET Core. Обновление элементов пользовательского интерфейса, обработка событий и вызовы JavaScript обрабатываются через подключение SignalR.
А если простым языком, то весь DOM строится и изменяется на сервере, а на клиент приходят только изменения в виде готового DOM дерева. Клиент и сервер держат соединение посредством SignalR (websocket или что поддерживается). К примеру при клике на кнопку, это событие уходит на сервер, там содержится копия DOM в которой и выполняются все действия, а далее происходит отправка изменений на клиент.
Vue очень простой для старта, хорошая документация, красивый синтаксис.
Лично когда я начинал с Angular 2, я не мог спать ночами от всего увиденного ужаса )) И если бы в то время мне бы предложили Vue с его простотой и мощью, то я бы не задумываясь перешел на него. Но когда поработаешь на чем-то серьезном типа React или Angular, то понимаешь, что тебе другого и не нужно.
Все, что вы описали, также есть в React и Angular.
К примеру, если говорить об Angular, то стили и разметка подключаются к компоненту в одном файле, хотя это не рекомендуется, так как в итоге будет каша.
Scoped css идет из коробки.
Для встраивания компонентов в готовый проект есть Angular elements.
Если же говорить про React, то там изначально js и разметка вместе, а встраивание в готовые проекты не сильно сложнее Vue.
Про архитектуру и структуру кода я говорю к тому, что все разработчики на Angular знают гайдлайн, что существенно упрощает ввод разработчиков в команду. Если Вы «грамотный и опытный разработчик», то это не значит, что вся ваша команда будет такой, а react позволяет писать как хочешь и что хочешь.
И вот ещё один секрет, React дружит с typescript
С typescript дружит абсолютной любой код на JS, но тут речь не о дружбе, а том, что все написано на TS и все это дает свои плюсы.
тонны всевозможных библиотек
Видимо вы упустили слово «Встроенных». На любой фреймворк найдется тонна библиотек, но мы говорим о тех, что созданы самой командой фреймворка. Тут плюсы в том, что это все таки фреймфорк, а не библиотека.
P.S. Я не знаю, что за личная неприязнь у Вас к Angular, но советую вам выдохнуть и просто принять, что он есть и им будут пользоваться, хотите ли вы этого или нет.
Я активно работал на React и Angular в проектах и могу сказать, что обе технологии по своему хороши. Также у меня есть опыт работы в крупных IT компаниях и наверное Вас это огорчит, но для больших проектов, очень часто выбирают Angular (особенно в связке с .net core) из-за четкой структуры кода, хорошо продуманной архитектуры, typescript и огромного числа встроенных библиотек.
Я думаю, статья очень полезна для начинающих it компаний. В жизни все может быть и от таких сотрудников никто не застрахован.
Но в средних и крупных компаниях, даже если в документах не прописано как и где работать, тебе все равно придется комитить в репозиторий проекта и порой в строго отведенный временной период, так как там вся команда, даже если их всего 2 человека :)
Так как же отделить программы служебные от неслужебных?
Я конечно не юрист, но разве размещение кода в системах управления версиями не решает эту проблему?
Вся разработка ведется на git, svn или tfs расположенных на серверах компании, вся история разработки включая время тоже фигурирует в нем. А т.к. все трудовые договоры по умолчанию содержат строки, которые гласят, что в рабочее время сотрудник занимается только задачами компании, то будет трудно доказать почему код, который “якобы” принадлежит сотруднику комитился на сервера компании, да еще и в рабочие часы.
Но если сравнить к примеру, JS фреймворк и Blazor, то пока плюсы по большей части только в том, что можно использовать другой язык программирования со всеми его плюсами и минусами. К примеру, C# в данном случае дает строгую типизацию и свои плюсы в IDE.
На данный момент в Blazor много чего нет, что есть в других фреймворках и к чему уже все привыкли.
По поводу Unity и WPF посмотрите проект uno platform
docs.microsoft.com/ru-ru/aspnet/core/blazor/hosting-models?view=aspnetcore-3.1">
А если простым языком, то весь DOM строится и изменяется на сервере, а на клиент приходят только изменения в виде готового DOM дерева. Клиент и сервер держат соединение посредством SignalR (websocket или что поддерживается). К примеру при клике на кнопку, это событие уходит на сервер, там содержится копия DOM в которой и выполняются все действия, а далее происходит отправка изменений на клиент.
Лично когда я начинал с Angular 2, я не мог спать ночами от всего увиденного ужаса )) И если бы в то время мне бы предложили Vue с его простотой и мощью, то я бы не задумываясь перешел на него. Но когда поработаешь на чем-то серьезном типа React или Angular, то понимаешь, что тебе другого и не нужно.
К примеру, если говорить об Angular, то стили и разметка подключаются к компоненту в одном файле, хотя это не рекомендуется, так как в итоге будет каша.
Scoped css идет из коробки.
Для встраивания компонентов в готовый проект есть Angular elements.
Если же говорить про React, то там изначально js и разметка вместе, а встраивание в готовые проекты не сильно сложнее Vue.
С typescript дружит абсолютной любой код на JS, но тут речь не о дружбе, а том, что все написано на TS и все это дает свои плюсы.
Видимо вы упустили слово «Встроенных». На любой фреймворк найдется тонна библиотек, но мы говорим о тех, что созданы самой командой фреймворка. Тут плюсы в том, что это все таки фреймфорк, а не библиотека.
P.S. Я не знаю, что за личная неприязнь у Вас к Angular, но советую вам выдохнуть и просто принять, что он есть и им будут пользоваться, хотите ли вы этого или нет.
Успехов вам и ждем с нетерпением 1.0.
Но в средних и крупных компаниях, даже если в документах не прописано как и где работать, тебе все равно придется комитить в репозиторий проекта и порой в строго отведенный временной период, так как там вся команда, даже если их всего 2 человека :)
Я конечно не юрист, но разве размещение кода в системах управления версиями не решает эту проблему?
Вся разработка ведется на git, svn или tfs расположенных на серверах компании, вся история разработки включая время тоже фигурирует в нем. А т.к. все трудовые договоры по умолчанию содержат строки, которые гласят, что в рабочее время сотрудник занимается только задачами компании, то будет трудно доказать почему код, который “якобы” принадлежит сотруднику комитился на сервера компании, да еще и в рабочие часы.