Many user-facing APIs + some URLs and identifiers use the term Blazor when it's for all components

[rynowak]

Do a search for Blazor in our repo and you'll find a bunch of references to the term in public API surface that refers to both server-side components and Blazor. Mostly this is the JS code where API is exposed through the window.Blazor global.

I'm thinking that we generally want to reserve the term Blazor for when we're speaking about the pure-client-side parts of the world so we should think about cleaning these up.

[javiercn]

@rynowak aren’t you taking care of this as part of tour PR already?

[rynowak]

No. I cleaned up a bunch of places where we use the terms in comments and stuff. I didn't make changes that will break user code.

Notice that this item says "think about", I didn't make any proposals for what to change it to and how it should look. I'd even be open to arguments that it should stay 😆

[SteveSandersonMS]

I agree we should do this, and I'd propose we do it just by going ahead and accepting that these will be breaking changes.

The number of developers who are using the window.Blazor APIs are probably pretty low by now (since we moved the JS interop to hang off DotNet instead of Blazor). Most of the JS-side Blazor.* APIs really exist only for use by the framework, e.g., by BrowserUriHelper and the renderer etc.

Is there any reason to be more concerned than usual about breaking changes here? Blazor is still 0.x.

[rynowak]

Is there any reason to be more concerned than usual about breaking changes here?

I don't think so. We just do it and put it in the release notes.

[javiercn]

@rynowak Should I rename everything to components and then back to blazor?

Closing this as there's no work left here.