Should Umbraco default to precompiled Razor views with Hot Reload?

Questions
,
1

I’ve noticed in the documentation that the recommended approach for development is using razor runtime compilation.

I don’t really see this as a recommended approach elsewhere, should Umbraco move towards precompiled Razor views and Hot Reload?

Are there reasons razor runtime compilation is still recommended?

2

I see in a default Umbraco 15 template you get:

  <PropertyGroup>
    <!-- Razor files are needed for the backoffice to work correctly -->
    <CopyRazorGenerateFilesToPublishDirectory>true</CopyRazorGenerateFilesToPublishDirectory>
  </PropertyGroup>

  <PropertyGroup>
    <!-- Remove RazorCompileOnBuild and RazorCompileOnPublish when not using ModelsMode InMemoryAuto -->
    <RazorCompileOnBuild>false</RazorCompileOnBuild>
    <RazorCompileOnPublish>false</RazorCompileOnPublish>
  </PropertyGroup>

Sounds like it’s for the “backoffice to work correctly” - is this a legacy thing for Belle rather than the new Bellissima?

Or is this all because of the Models Builder and how it defaults to in memory?

3

Exactly this.

The Production runtime mode disables the in-memory models builder. Otherwise, because the in-memory models builder is in memory, there are no models at compile time so the views cannot be compiled.

Historically the default has been for Umbraco to “just work” out of the box, keeping things as simple as possible, even if it’s not best practice for real-world production use.

This is one of the reasons the runtime modes exist - to actually enable best-practice configuration for specific environments.

I’d love to see this as the default though - perhaps it’s worth opening this as a discussion or issue on the repo to see if people are ready to move that particular cheese?

4

Great idea, I will get it submitted, thanks for the idea!

5

I actually hate the precompile view because it would break a number of 3rd party stuff which use views for a start.
Secondly I hate it in Kentico because the the processes and steps are just that much more for even small changes and updates.
It is a thing that with streamlining companies especially for me is just the amount of time waisting compiling, managing and deploying even small changes these days is simply to costly.

We need to quickly and easily make view changes and deploy them and by lower end developers/front end and not require a whole deployment process path.

And I have said it in other old forum posts. If you are doing functions, helpers and complex code in those views your are doing it wrong, that stuff needs to in services, helper class and external functions. There should be nothing more then output rendering Razor and HTML.

IF something is default as long as there is the option to turn it off then fine.

6

Thanks for replying

Out of interest, do you usually deploy using a CI/CD pipeline, or is your workflow more manual?

From what you describe, it sounds like you might sometimes make view changes and deploy that single .cshtml file rather than doing a full application deploy?

I can see how that would be quicker in some cases, but from my side, I worry it opens up the risk of inconsistency between source control and production, or increases the chance of human error. We need deployments need to be automated, repeatable, and predictable. Irrelevant of the platform being used.

Also just to add Kentico isn’t doing anything special with Razor views. It just follows the default ASP.NET Core behavior. Views are precompiled at build or publish time, and local development relies on Hot Reload for changes.

So it’s not really a Kentico specific thing, it’s just aligning with how .NET expects Razor projects to work nowadays.

That’s why I’m wondering whether Umbraco should move more in that direction by default, while still allowing flexibility for teams who prefer manual deployment styles.

If you want to add your opinion to the GitHub discussion I’d highly recommend it, see it here.