Обновления ASP.NET Core в .NET 6 Preview 1

[buldo]

В треде пол микро API, люди пишут, что фильтры и DI — это слишком сложно и надо позволить писать без всего этого.
Как-то это все странно.

[LexL]

После кидалова с Silverlight, вряд ли кто-то захочет использовать Blazor вообще.

[HellMaster_HaiL]

Blazor не требует от конечного пользователя каких либо дополнительных манипуляций (плагина там или еще чего), является открытым и использует общепринятные веб-технологии. Можно сказать, это такой себе ангуляр, только под веб-ассембли. Хотя осадочек всё же есть, Вы правы.
Мое первое впечателние весьма не плохое, лучше, чем от ангулярки. Уже начали появляться вакансии на рынке с этой технологией. Может займет какую либо нишу среди фуллстеков.

[LexL]

Мне лично в Blazor не нравится четкое разделение на или все на сервере, или все на клиенте. Вариант все на клиенте не рассматривается, ибо килограммы кода тащить, потом ждать компиляцию, бета-тестировать WebAssembly.

Т.е. остается только сервер. Но даже тот сайт, который они сделали (themesof.net) заметно лагает на открытии узлов дерева. Каждый клик мыши идет на сервер по веб-сокетам и получает UI дельту.

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

Плюс, Microsoft такой Microsoft. Когда написание компонентов на Blazor можно было сделать реально легковесным, типо

@component MyComponent
@{ 

public string Name, LastName; 
}
<div>
{Name}<br>{LastName}
</div>

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

Короче, как обычно. Можно было сделать зашибенный React для C#, а получился восьминогий семихрен…

[HellMaster_HaiL]

Т.е. остается только сервер.

Без рест апи все равно не обойтись, а интерфейс уже строить на блейзоре, т.е. все таки юзать «все на клиенте»? Мне лично очень нравится вся «мошь» шарпа.

навешайте на них специальных атрибутов, ведь так не понятно

мне кажется, что это никто не понимает

import { Input} from '@angular/core';
...
@Input() publicProperty : string;

или

export default {
  name: "Item",
  props: {
    city: {}
  }
}

Идеального фреймфорка для фронта еще не придумали ):

[LexL]

Придумали. Называется React.

export const MyComponent = ({name, lastName}) =>
  <div>{name}<br>{lastName}</div>

[HellMaster_HaiL]

Свойства передаются от родительских компонентов к дочерним. Компоненты получают свойства как множество неизменяемых (англ. immutable) значений, поэтому компонент не может напрямую изменять свойства, но может вызывать изменения через callback-функции. Такой механизм называют «свойства вниз, события наверх».

Это сложно назвать идеальным фреймфорком для фронта (как по мне)

[mayorovp]

React и правда тяжело назвать идеальным фреймворком, но вот процитированная вами часть — это единственный адекватный способ работы со свойствами ( с поправкой на то, что неизменяемость значений понимается как мелкая, а не глубокая).

[LexL]

В это и есть его идеальность. Что изменять все можно только единственно правильным способом — через мутацию корневого элемента данных.

Правильная структура этого элемента — залог здорового ререндеринга.

[HellMaster_HaiL]

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

У каждого своя идеальность, но по мне проще прилепить аттрибут на свойство, чем городить по-сути ридонли переменные в контрукторах и колбэки. Имхо, MVVM, при правильной реализации, лучшее, что есть для UI.

[LexL]

MVVM — это лучшее, что придумал Microsoft, но не лучшее из того, что вообще придумали.

За 10 лет MVVM, я склоняюсь к мнению, что callback-и и простые immutable объекты вкупе с Flux принципами — самое простое и эффективное решение. Минимум концепций, максимум возможностей для суперэффективного рендеринга и высокой производительности.

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

Microsoft опять изобрел велосипед, причем не самый лучший. А были все шансы

[LexL]

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

Не забывайте одного, мир на MS не заканчивается. Будьте открыты к новому, думайте своей головой, не бойтесь пробовать.

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

[reitenbach]

Не забывайте одного, мир на MS не заканчивается. Будьте открыты к новому, думайте своей головой, не бойтесь пробовать.

Можете применить Ваш же совет и открыться для Blazor. Успешно используем Blazor уже сейчас и экономим время на разработке SPA приложений. Скорость получается выше чем на React, код легче читать и понимать для новичков. Это не панацея и не всегда он будет подходить, но в целом продукт отличный, а если осуществлят планы, которые освещали, то будет очень-очень круто. Нужен конкурент Javascript'у.

[LexL]

Я уже открывался. Не убедил он меня. Они пошли по пути наименьших затрат, надстроились над Razor, хотя тот сам по себе ужастик.

Мне вот что интересно. Сколько у вас маркапа в коде компонентов? А сколько кода в маркапе? Может быть удобнее расширить C# и добавить в него маркап конструкции, как в VB когда-то? Сделать что-то типо методов расширений, чтобы маркап превратился в их вызовы? Что бы можно было подключить другой namespace и вуаля — другая реализация DOM/XML/HTML?

[reitenbach]

Мы у себя приняли разделение компонента на два файла — верстку (razor) и код (отдельный c# файл partial). В самом razor у нас остается только конструкции if, foreach и т.д.

Я лично не в курсе, как было сделано в VB, поэтому не могу ничего по этому поводу сказать.

[Getequ]

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

[sergeyiljin]

Меня всё ещё интересует один вопрос. Будет ли Blazor загружаться и работать быстрее, чем к примеру React с его Virtual DOM? Пока что React лидирует.

[LexL]

В случае с Реактом, виртуальный дом строится на клиенте и патчится на клиенте, т.е. чисто клиентские дела будут работать быстрее, чем Blazor, который потащит дельту с удаленного сервера по сокетам. Если речь о чистых данных, то в этом случае Реакт тоже выигрывает, т.к. идет передача только самих данных, без UI и сотен DOM-атрибутов, как в случае Blazor, когда по проводу ходят не только данные, но и патчи к UI.

Кто-то скажет, UI патчи идут в бинарном формате, это быстро, модно, молодежно. Но в случае Реакта вам тоже ведь никто не навязывает JSON по RESTу гонять, можно и по-взрослому — бинарные данные по сокетам. BSON и другие форматы вам в помощь, библиотек уже хватает. Компрессию тоже можно на сервере включить, посмотреть.

[reitenbach]

Blazor может работать без сервера, чисто на клиенте.

[sergeyiljin]

Это серверный вариант работы. Я имел ввиду webassembly версию, когда данные грузятся 1 раз, а дальше всё делается в браузере.