Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename Razor Components back to server-side Blazor #8931

Closed
danroth27 opened this issue Mar 29, 2019 · 49 comments

Comments

@danroth27
Copy link
Member

commented Mar 29, 2019

We initially introduced the Blazor server-side hosting model in Blazor 0.5.0 and then later decided to ship it in .NET Core 3.0. To differentiate client-side and server-side Blazor we decided to give the server-side model a new name: Razor Components. However this has turned out to cause confusion.

To address this confusion we are going to switch back to referring to the application model as Blazor with different hosting models. Blazor apps can be hosted on the server on .NET Core or on the client with WebAssembly. Server-side Blazor support will ship with .NET Core 3.0 and client-side support will come later as soon as the WebAssembly support is ready.

Implementation details:

  • Rename the Razor Components template in .NET Core 3.0 back to “Blazor (server-side)”.
  • Rename the Blazor template to "Blazor (client-side)" for full clarity.
  • Rename services.AddRazorComponents() -> services.AddServerSideBlazor()
  • Rename routes.MapComponentHub<TComponent>() -> routes.MapBlazorHub<TComponent>()
  • Rename components.server.js back to blazor.server.js and components.webassembly.js back to blazor.webassembly.js
  • Align the Blazor package versions to align with the .NET Core 3.0 versions (#8859)
  • Update the icon of the "Blazor (server-side)" templates to match the other Blazor templates
@xclud

This comment has been minimized.

Copy link

commented Mar 29, 2019

Is this an approved decision? Can we still vote?

Personally i am against changing the name. I think Razor Components is a better name. :(

@danroth27

This comment has been minimized.

Copy link
Member Author

commented Mar 29, 2019

@xclud It's an open forum, so feedback is always welcome 😃

We will still refer to the component model as Razor components (i.e. a .razor file will still be a Razor component), but when talking about the application model we are finding it very cumbersome to have different names. There's already quite a bit of momentum behind the name Blazor so we'd like to stick with it. Names are of course subjective - no matter what name we pick not everyone will be happy, but Blazor seems to have served us pretty well so far.

@chrissainty

This comment has been minimized.

Copy link

commented Mar 29, 2019

I think this is a good move. There has been no end of confusion about the relationship between Razor Components and Blazor. To the point that people have thought they are different frameworks, not just different ways of rendering.

Plus, in my personal opinion, Blazor is a cool name.

@EdCharbeneau

This comment has been minimized.

Copy link

commented Mar 29, 2019

As someone who very frequently talks to people about Blazor. Razor Components has been nothing but confusion. It's confusing in terms of: when is a Blazor app a Razor Components app, Razor Components as it relates to [Razor Pages & Razor Class Libraries], and tripping over one's self when saying Razor/Blazor. It also makes writing about Blazor difficult, SEO difficult, I could go on.

@BarnyardTech

This comment has been minimized.

Copy link

commented Mar 29, 2019

Sanity prevails! Thanks so much for this change.

@vertonghenb

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2019

What happeneds with the .razor file extensions, since razor pages are still .cshtml and components are .razor it might be beneficial to call it .blazor? Or call the razor pages also .razor instead of .cshtml?
Quite confusing stuff

@danroth27

This comment has been minimized.

Copy link
Member Author

commented Mar 30, 2019

We're planning to keep the .razor extension for components. Components are based on Razor syntax, but components are handled differently by the Razor compiler, so they need a different file extension.

@ghidello

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2019

What about the blazor hosted template? For the client side model it is the easiest way for:

  • applying the CSP security headers
  • computing the SRI hashes (ideally this will also be needed for the assets downloaded directly by blazor.webassembly.js)
  • compressing the assets (at least until the dll files will be shipped with the wasm content type which is already compressed by the couple of CDNs I tried out)

So I hope that the hosted template will still be present.

@stavroskasidis

This comment has been minimized.

Copy link

commented Mar 30, 2019

I also love this rename back to just "Blazor". ATM talking with people about Blazor and Razor components is just plain confusion.

@SamProf

This comment has been minimized.

Copy link

commented Mar 30, 2019

Blazor is a trchnology with (at least) two hosting model. So, I like Blazor!

@kaldren

This comment has been minimized.

Copy link

commented Mar 30, 2019

One name to rule them all. One Blazor with two different hosting models is definitely better. It saves from a lot of confusion down the road.

@ErikSchierboom

This comment has been minimized.

Copy link

commented Mar 30, 2019

I welcome this change! The new (or old) naming is far less confusing I feel.

@michaelvolz

This comment has been minimized.

Copy link

commented Mar 30, 2019

I agree with @vertonghenb that the file extension should also be renamed to .blazor. It makes much more sense. Both .cshtml and .razor have razor syntax, but only one should have Blazor specific code which would make a .blazor file extension more precise and less ambiguous IMHO.

@duracellko

This comment has been minimized.

Copy link

commented Mar 30, 2019

Short comment: I agree with changing name back from Razor Components to Server-side Blazor.

Long answer: I believe that both client-side and server-side "components" should have same name, whatever it is: Blazor, Razor Components, ASP.NET Core Components. For example React and React Native are much more different technologies and yet they share the same name.

Advantage of Blazor name:

  • It is already well established name in community. Actually it is also understood as technology to run .NET in a browser, that is not 100% correct.
  • It may be easier for people to accept/understand that Blazor can be used without .NET on server-side (actually without any server-side).

Advantage of Razor Components name:

  • Linking with Razor and ASP.NET Core may help people understand that technology will have proper support and stability. Although as Blazor has already got lot of attention I think it's understood as stable technology.
@duracellko

This comment has been minimized.

Copy link

commented Mar 30, 2019

And regarding extension it depends how Razor compilation is extensible. If for example in future there will be static generated Razore pages also with .razor extension and compiler can handle it, then I would keep .razor extension. Basically like .xaml extension is used for controls, pages, resources, application objects.

I think this should be perfectly achievable. I don't know what is current status to support code-behind for Razor components. However, if there is then code-behind defines if component is inherited from ComponentBase or anything else. And this may determine how .razor file should be compiled. And without code-behind default inheritance is ComponentBase and in future there may be possible to change default base class.

However, if future Razor objects would need to have different extension, then .blazor for Blazor components would be much better option.

@poke

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2019

I welcome this change a lot! The name “Razor components” was always a bit confusing because the expectation was that this was a purely server side thing, like everything else Razor does is. So the expectation was that Razor components are, kind of like user controls in WPF, a way to compose custom components using a Razor syntax instead of code (like tag helpers allow).

By renaming this, that confusion gets removed, and we actually do have the chance to eventually come up with server-side composable Razor components at some point.

As for the .razor extension, like others I believe it would make more sense to use .blazor instead. The way I understand it, those files can contain code that is only viable within a Blazor context, since the logic is deeply coupled to the component. I don’t assume that this will be possible to reuse in a non-Blazor context. Also, if the client-side Blazor components will end up using the same thing, I think using .blazor consistently is a better idea to identify Blazor components (which then can be used either server-side or client-side).

@myty

This comment has been minimized.

Copy link

commented Mar 30, 2019

I know @poke and @duracellko both mentioned the term blazor components in passing, but I actually like that as a name. What about Blazor Components instead of Blazor (server-side)?

Oh. and I think .blazor for the extension name is a good idea too.

@poke

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2019

@myty I think conceptually, the components were always “Blazor components” (i.e. you create components with Blazor). “Blazor (server-side)” and “Blazor (client-side)” are the two different hosting models in which you can consume and run the same (I think?) Blazor components. So you would use both “Blazor components” to describe that you are creating a component, and “server-side Blazor” to describe how you are executing the Blazor components.

@myty

This comment has been minimized.

Copy link

commented Mar 30, 2019

@myty I think conceptually, the components were always “Blazor components” (i.e. you create components with Blazor). “Blazor (server-side)” and “Blazor (client-side)” are the two different hosting models in which you can consume and run the same (I think?) Blazor components. So you would use both “Blazor components” to describe that you are creating a component, and “server-side Blazor” to describe how you are executing the Blazor components.

The fact that it was always Blazor components was what sold me on the name. Tell it like it is and it sounds cool too. :)

...but, I also see the confusion between server-side and client-side. It's hard to tell the story without specifically calling them out.

@GoranHalvarsson

This comment has been minimized.

Copy link

commented Mar 30, 2019

Yes! Finally :) Blazor is the true name.

@honkmother

This comment has been minimized.

Copy link

commented Mar 30, 2019

do you even blaze?

@GoranHalvarsson

This comment has been minimized.

Copy link

commented Mar 30, 2019

Yes

@egil

This comment has been minimized.

Copy link

commented Apr 1, 2019

Still a little confused with regards to components:

So if I am building a component library, that works both with server side and client side Blazor, do I refer to the components as "Blazor components" or "Razor components"?

@chrissainty

This comment has been minimized.

Copy link

commented Apr 1, 2019

@egil Based on what Dan Roth said above, a component will still be known as a Razor Component.

We will still refer to the component model as Razor components (i.e. a .razor file will still be a Razor component)

@conficient

This comment has been minimized.

Copy link
Contributor

commented Apr 1, 2019

Adding my vote of approval to this change.

As I see it, a RazorComponent is a C# component written using Razor syntax and C# code. We could use RazorComponents in a wide range of projects, including Blectron (as in the StorageExplorer demo), HTML-generators (e.g. for email body generation in the same way as RazorGenerator does for .cshtml content. They are not confined to just Blazor.

By contrast, Blazor is the application framework that uses RazorComponents on the client, using two different hosting models (WebAssembly and server-side).

image

I've added a diagram that shows how I see it.. comments welcome

@anthcool

This comment has been minimized.

Copy link

commented Apr 1, 2019

Blazor (client-side w/WASM) and Blazor (server-side w/.NET Core) sounds great!

Razor Components for the UIs of both, with Blazor as the framework for the applications irregardless of hosting model. Simple, clean, and as one of my fav comedians would say.... GIT R DONE!

@gustavoosantoos

This comment has been minimized.

Copy link

commented Apr 1, 2019

Blazor client and server-side really sounds good.
And for beginners, is easier to understand the differences between client-side and server-side.

@mrlife

This comment has been minimized.

Copy link

commented Apr 1, 2019

As others have said, there are compelling reasons to consider .blazor (and the "Blazor component" name). Could more rationale behind keeping.razor (and its "Razor component" name) be shared?

This is the rationale up to this point that I could find:

We're planning to keep the .razor extension for components. Components are based on Razor syntax, but components are handled differently by the Razor compiler, so they need a different file extension.

I feel my view may be too simplistic:

const string serverSideName = "Blazor (server-side)";
const string clientSideName = "Blazor (client-side)";

string componentModel = "Razor Components";
string ext = ".razor";

if (serverSideName.Contains("Blazor") && clientSideName.Contains("Blazor"))
{
    componentModel = "Blazor Components";
    ext = ".blazor";
} 

Console.WriteLine(componentModel);
Console.WriteLine(ext);
@danroth27

This comment has been minimized.

Copy link
Member Author

commented Apr 1, 2019

There are a few reasons why we'd prefer to keep the .razor extension:

  • The name is still accurate and descriptive. A .razor file is a UI component written with Razor syntax.
  • Reduce churn. Updating the file extension requires a fair amount coordination across multiple teams and projects. Since we've already done this work for .razor we'd prefer to not do it again unless there is a really good reason to.
  • Insulate the framework from product name or strategy changes . By keeping the component model naming a bit more generic we hope to reduce the impact of any potential name shuffling or changes in the project direction in the future.
@mashbrno

This comment has been minimized.

Copy link

commented Apr 1, 2019

@danroth27 What disturb me is that Razor syntax is in both .cshtml and .razor files. I think there will be confusion which extension is for which Razor Page/Component/MVC view.

Other two points are fair enough.

@poke

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2019

@danroth27

The name is still accurate and descriptive. A .razor file is a UI component written with Razor syntax.

What bothers me about this argument is that a .razor file contains things like event handlers, lifecycle methods, or variable bindings. These concepts are very specific to Blazor and won’t work outside of it. So while it is Razor syntax, it is a very specific flavor of it that enables the client-side logic to be executed.

These things won’t work for purely server-side and server-rendered “Razor components”, which could be a hypothetical thing in the future (since for example render fragments would work pretty nicely on the server too).

So we’re locking the file extension .razor and the name “Razor component” for a specific flavor of Razor that will only ever work for components with embedded client-side behavior.

@TanvirArjel

This comment has been minimized.

Copy link

commented Apr 3, 2019

@danroth27 Almost everybody (including me) is wanting it .blazor instead .razor then why are you wanting to stick to .razor individually. Is there any technical challenges for changing this? or just this is you and your team preference?

Thank you.

@SteveSandersonMS SteveSandersonMS moved this from To do to In progress in Blazor Apr 3, 2019

@guardrex guardrex referenced this issue Apr 4, 2019
19 of 21 tasks complete
@RyoukoKonpaku

This comment has been minimized.

Copy link
Contributor

commented Apr 4, 2019

As @danroth27 mentioned coordinating with multiple teams, I can think of, VS Team, Razor team team, it might be a big chunk of work which each team has differing priorities on tasks.

I can see the .razor extension fitting if it's going to be a more generic thing that describes any kind of components written in Razor like how .xaml is used for both resources and controls in the desktop world.

Say if possible in the future you could use native UWP / xaml controls authored using razor, not html via electron but purely native, as razor's imperative style of constructing controls might be a compelling alternative for .xaml's current declarative way of doing things (especially razor's support for C# control flows).

That's a theoretical example though, at that point you could say that it uses Razor Components but isn't on a Blazor context but rather on a native context like React Native where things can differ like event bindings being different, some Blazor specific attributes not applicable etc...

I see Blazor as a framework that uses Razor Components (.razor) like how React as a framework uses .jsx/.tsx for component composition and like .jsx/.tsx it might be possible for it to be usable on other similar frameworks like how Vue and TKO supports .jsx/.tsx by configuring what the build system does to the .jsx/.tsx files.

@mkArtakMSFT mkArtakMSFT added Working and removed 1 - Ready labels Apr 4, 2019

@javiercn javiercn added Done and removed Working labels Apr 4, 2019

@javiercn javiercn assigned danroth27 and unassigned javiercn Apr 4, 2019

@danroth27

This comment has been minimized.

Copy link
Member Author

commented Apr 4, 2019

Thanks everyone for your feedback on this issue. The Razor Components renaming back to server-side Blazor is done!

We've decided to leave the .razor extension as is for the reasons listed above. We've had a mixture of feedback on this decision. While we appreciate the desire to Blazor all the things, we think the current extension is adequate and we prefer to focus our efforts on getting Blazor ready to ship instead of churning the file extension. Given this decision, I'm going to go ahead and close this issue.

@danroth27 danroth27 closed this Apr 4, 2019

Blazor automation moved this from In progress to Done Apr 4, 2019

@springy76

This comment has been minimized.

Copy link

commented Apr 18, 2019

Please rename the label feature-Components to feature-Blazor, too.

@ImadMichaelAyoub

This comment has been minimized.

Copy link

commented Apr 30, 2019

Dears, I am using vs 2019, I have installed Blazor last version, I have core 3 preview 4, I have create a Blazor project, all pages now are with .razor extension instead of .cshtml, I ran the application, but giving me Loading... without moving to Index.razor page, any help please. Thanks in advance.

@chrissainty

This comment has been minimized.

Copy link

commented Apr 30, 2019

@ImadMichaelAyoub Do you have any error messages in the console? Are you running client-side or server-side Blazor?

I would suggest this is probably not the best place for this discussion. It would probably be best to join the Blazor Gitter channel (https://gitter.im/aspnet/Blazor) and we can help you there.

@ImadMichaelAyoub

This comment has been minimized.

Copy link

commented Apr 30, 2019

Thanks for the reply. I'm using client-side Blazor. It seems application runs index.html file in wwwroot and not moving to index.cshtml in pages folder.

@janellesnowy

This comment has been minimized.

Copy link

commented May 30, 2019

I'm new to Razor and Blazor. It's confusing when searching online for solution, you get tons of razor or old stuff which does not apply anymore, adding more confusion. I vote highly to change change to new name (even to .blazor) so we can search and get the latest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.