Feedback on Blazor Components and why I think it could be more HTML-Friendly (more like taghelpers)

[Bartmax]

Here are some feedback after dealing with blazor for quite some weeks, following the "try and tell what do you think" moto. 😄

From a user point of view, I don't like the "custom elements" framework approach. For example, things like <EditForm Model="@OrderState.Order.DeliveryAddress" OnValidSubmit="@PlaceOrder">, or <NavLink href="myorders" class="nav-tab">

EditForm component will, eventually, render a <form/> html tag and NavLink an anchor <a/>. As a consumer/developer I would love to author it using the proper html elements, similar to how taghelpers works (syntax example):

<form Model="@OrderState.Order.DeliveryAddress" OnValidSubmit="@PlaceOrder"> or <a NavLink href="myorders" class="nav-tab"> or <a @NavLink href="myorders" class="nav-tab">

(I understand that Blazor Components and Html Tag Helpers are two different technologies, this is not about bringing Tag Helpers to Blazor Components but to making it more HTML friendly)

The reason I think this has value is

1. Is and feel way more intuitive,
2. It aligns better with other net frameworks (mvc/razor pages)
3. It doesn't prevent <CustomComponent> in any way, so it's an addition not a replacement.
4. Very similar to tag helpers syntax. Easy switching context from one to another.
5. New comers to the framework will learn/use basic components (and even advanced 3er party ones) much more easily.
6. Very readable code for anyone without experience with blazor.
7. (if done well) Plugins/extension by 3rd parties will be able to profit on this creating more understandable and less documentation hunting.

Using a very simple sample of a "custom" table component could look more like:

<table Items="@forecasts"  PageSize="4">
    <thead>
        <th @SortKey>Date</th>
        <th>TemperatureC</th>
        <th>TemperatureF</th>
        <th>Summary</th>
    </thead>
    <tbody>
        <td>@context.Date.ToShortDateString()</td>
        <td>@context.TemperatureC</td>
        <td>@context.TemperatureF</td>
        <td>@context.Summary</td>
    </tbody>
</table>

instead of :

<BlazorGrid Items="@forecasts" PageSize="4">
    <GridHeader>
        <th>Date</th>
        <th>TemperatureC</th>
        <th>TemperatureF</th>
        <th>Summary</th>
    </GridHeader>
    <GridRow>
        <td>@context.Date.ToShortDateString()</td>
        <td>@context.TemperatureC</td>
        <td>@context.TemperatureF</td>
        <td>@context.Summary</td>
    </GridRow>
</BlazorGrid>

which lead 3er party to this:

<KendoGrid parameters...>
    <RowTemplate/>
    <KendoGridColumns>
       <KendoGridColumn parameters.../>
    </KendoGridColumns>
</KendoGrid>

Which I think is a monstrosity, (no offense to telerik, this is fine for how the things are currently settled.)

The other extensible point/workflow this enables is to implement (even copy/paste from documentation) of frameworks agnostic to blazor specifics, but that have blazor component enhancements. For example, let's say I want to make use a component from bootstrap. Ideally I would like to add the acme-blazor-boostrap-dependency, go to bootstrap documentation (not acme one) and read HTML from bootstrap official docs and then extend with Components where necessary, without having to look up for documentation on how bootstrap components are implemented and avoid change all tags to <bs-card>, <bs-modal>, <bs-modal-header>, (or whatever way the bootstrap blazor components were developed) etc, when I want to extend those components.

Philosophically I think doing SPA (or any modern web app development model/framework) should be/feel like building on top of html and not building on a framework.

I understand why this is the current state of web development, I just want to point out as a suggestion because maybe blazor have a chance to make it better than the way currently is

Sorry if the team already went through this design/decision or this was addressed, I didn't find anything.

[mkArtakMSFT]

Thanks for contacting us, @Bartmax. Thank you for your feedback. This is pretty different from the path we've already gone down to. That said, we aren't going to change this.