For anyone who works with C# and .NET, you'll know just how much ceremony even the simplest of tasks can often require. And whilst for business critical applications, arguably the largest market for .NET, this isn't that big of a deal as much of the verbosity of the language helps promote best practice and brings clarity to the codebase.
At the same time though, for those that are just wanting to get stuff done and shipped, it can add quite a bit of process to the job at hand. Given that Umbraco is built on the .NET stack, it comes as no surprise then that these same issues affect Umbraco developers in exactly the same ways.
Two Sides of the Same Coin
For a long time in Umbraco 8- this has worked for two kinds of developers, "the purists" and "the pragmatists". Now I'm going to be clear, neither of these approaches is more "correct" than the other, I personally flip between the two depending on the project. I generally see the choice of approach followed being based on a mixture of company size and quality assurance requirements.
Being a purist means following best practices and having a much more robust code base, but it generally comes at the cost of a much larger code base, and a lot of that aforementioned ceremony you have to follow.
Being a pragmatist on the other hand means not following best practices as closely and focusing more on simplicity of code base and "just making it work". This usually comes at the cost of testability and can often lead to good old spaghetti code.
Needless to say, depending on the types of project you work on, whether they are business critical sites, or just simple brochureware ones, both approaches are entirely valid.
Umbraco 8-
In Umbraco 8- there was very much a concerted effort to cater for both sides.
Based on MVC patterns it was pretty familiar for the purists and with things like route hijacking it was entirely possible to follow this practice, defining logic in Controllers and passing strongly typed content to your Views via View Models.
From an extensions perspective, many packages were available in NuGet form making it easy to install them directly from the IDE.
The pragmatists were also taken care of though. It was pretty much OK to run almost any code inside your Views so if you didn't want to go through the hassle of defining a Controller and Model and compiling it down, you could just access things directly from your Views.
From an extensions perspective, many packages were available in a special Umbraco format that allowed installing via the Umbraco back office without the need of any dev skills, often just the pure act of installing them would make them work, and even things like config management were simplified by things like Health Checks allowing you to apply recommended config changes automatically.
Umbraco 9
With Umbraco 9, whilst I can't take anything away from the amazing effort it has taken to come to be, there have been a lot of changes and it's unfortunate to say but a lot of these changes seem to affect one approach more than the other. That being the pragmatists.
Probably the first of these changes was the move to NuGet packages only which means package installation is now mostly a backend developer privilege. But we've started to see other things too such as changes to response buffering that means some types of code can't run in Views like it did before, and updates to Health Checks that can now no-longer automatically modify settings files to fix issues.
Even things like deployments are somewhat more complex in v9 as a site needs to be entirely taken offline before replacement files can be uploaded.
To be fair to Umbraco though, pretty much all of these changes have been forced upon them by .NET Core itself (hence the title of the blog post). Just the way .NET Core works means that these types of things are just not possible like they used to be. And for Microsoft and those larger development companies that it's mostly targeted at, this is all fine and dandy. But for Umbraco who (hopefully) still wishes to target more pragmatic developers, it's slowly, feature by feature, leaning more towards the purists and becoming less approachable to the pragmatists.
The Answer?
Honestly, I'm not really sure right now. The aim of this blog post is really more to bring awareness to the issue than provide real answers.
I do think some of these things may improve over time. For example .NET 6 re-introduces shadow copying in IIS which means deployments to sites in IIS don't need to be entirely taken offline. I also know that HQ are looking into whether (at least some) NuGet packages can be installed via the back office like the old package format.
But I'm also worried that maybe some things are being lost because there is a slight fear to deviate from Microsoft best practice and introduce Umbraco only concepts in order to make things simpler.
Documentation is surely a small part of the answer, ensuring new approaches are documented and devs can find how to do the things they used to do in the new way, but if those new ways are more verbose, whilst the pragmatists become more knowledgeable, they still have no choice but to follow the best practice approach.
I am hopeful that as Umbraco 9 beds in, balance will be restored between the approaches and that Umbraco will continue to service all types of developers and not just become a purists platform, but for this to happen I think we need people to speak out and not be afraid of being called out for “using it wrong”.
To make your voice heard I urge developers of all perspectives to raise discussions on the Umbraco forums or the GitHub discussions section if something has changed that you think could be done better / made simpler, or if documentation is lacking for new approaches.
Top comments (1)
Interesting article Matt. I think it's a good change but on the other hand it will make it harder to start using Umbraco.
Looking back on how I started Umbraco, I never used a controller and all logic was in a view and I used dynamics all over the place. This made it really easy to learn Umbraco.
Looking back at these projects I hate how they look with my current knowledge and hate when I have to work on them.
In hindsight It would have been a lot better if I followed courses and read the documentation and was forced to use Umbraco in a clean maintainable way. And that's exactly what has to be present when enforcing a "correct" way of working.
Good valuable courses and clear documentation.
In the end I'm glad my team is forced to work with standards and can't cut corners anymore. All the cut corners will hunt you down in the future in my opinion.