The first bad step was Microsoft inventing Razor. Intermixing code and view is always a bad idea, but Razor just hasn't nearly enough options to apply templates to different kinds of data without manual intervention. Plus the view can directly access any layer in the system without ever thinking about separation. Want your view to authenticate users? Yes, why not. Want your view to load and store data? Yes, go ahead! You can do whatever you want. Obviously your views will never work in any different framework, but who cares honestly?
But the real cancerous growth is JavaScript. Not only is Umbraco now spamming a perfectly fine SQL database with little bits of text-only JSON snippets, whose values could have been stored perfectly fine in optimized, type-safe and indexable database columns, making it impossible to write scripts to extract data from it without parsing this so-called standardized interchange format, that neither implements schema nor data types.
No, the growth has now also reached backend programming, where C# will only allow you to work with ridiculously overcomplicated code to access it. Not only do you not know which object and property along the graph actually exists, but JSON only has some vague idea of what it's type could be. And due to the lack of a standardized API, you can only step from one property to another, being ever so careful never to encounter an unexpected object or even a null, lest you want your whole website to become a single error message. Plus the Newtonsoft.Json library is a fucking mess due to the guys there thinking they had to somehow reinvent the wheel - fucking JObject and JToken and whatnot. Compare a property to null and it doesn't equal. Try to cast it to a type, still get a fucking exception for trying to cast a null to an actual type. No wonder, the API completely changes when you cast a dynamic JObject to just a JObject. Use the generic API and call Value<T>() you say? That also throws a fucking exception. Cast it with Value<object>() perhaps? Guess what, it now turned into a JValue, and it is STILL NOT NULL. I swear this library only exists to annoy programmers into quitting their jobs, and the only job it had was to parse a practically logic-less string into a usable data structure. I had to attach a debugger because the code is so incoherent that you cannot deduce what is going on just from looking at it. Seven levels of nested ifs deep, and you're still prone to fucking up with an exception just because a user clicks the wrong button in the backend.
We had a perfectly fine markup language, XML, a perfectly fine templating language, XSLT, and a perfectly fine API in the form of XML-DOM and XPath. And a perfectly fine programming language, C#, with strong types and a nice class library. And this is a growth, as it will spread and spread even further because of the increasing reliance on JavaScript-libraries like Angular, instead of going the brave route via Blazor. Ten years ago I have chosen Umbraco because it was brave enough to use XSLT. Now it's becoming a fucking mess, indistinguishable from any other framework, where you spend your time writing Angular controllers in JavaScript instead of doing something useful.
And if you are asking why writing JavaScript controllers is such a bad thing, then you just need to take a good look at the source of media.controller.js and explain to me, why the whole logic that is already implemented in ImageUrlGenerationOptions is repeated here a second time without reusing the initial C# implementation.
Can’t really blame Umbraco, Microsoft or the tech-community for not sticking to 15-20 years old tech. Feel free to use what ever you want and think what ever you want but not sure if your post here provides any value.
I agree there are a LOT of issues in the Umbraco codebase including a massive overreliance on JS styles of programming and reliance on JSON, lack of single-object responsibility, other SOLID principles, etc. However XSLT isn't much better, any XML base is a terrible standard to use due to the bloat & repitition it ends up causing.
TBH i would have loved if they went NoSQL and got rid of the archaic mess and went with blazor for the dynamic side of things.
BUT - Umbraco is very customisable, and has one of he best backoffices for the end users. It also allows for expandability as long as you properly separate your projects.
You don't check for nulls? Too bad, this isn't JS, in strongly typed functionality we need to do null-checking.
I agree that the AngularJS is excessive and pointless (MVC JS layered over MVC) and it's bloody frustrating I cannot just create a viewmodel that handles the logic.
Also this is incorrect
"Intermixing code and view is always a bad idea, but Razor just hasn't
nearly enough options to apply templates to different kinds of data
without manual intervention."
I have done this on numerous accasions by creating a template that can accept generics and then modify how the page appears simply by changing the data annotations and model.
Umbraco is cancerous [rant]
The first bad step was Microsoft inventing Razor. Intermixing code and view is always a bad idea, but Razor just hasn't nearly enough options to apply templates to different kinds of data without manual intervention. Plus the view can directly access any layer in the system without ever thinking about separation. Want your view to authenticate users? Yes, why not. Want your view to load and store data? Yes, go ahead! You can do whatever you want. Obviously your views will never work in any different framework, but who cares honestly?
But the real cancerous growth is JavaScript. Not only is Umbraco now spamming a perfectly fine SQL database with little bits of text-only JSON snippets, whose values could have been stored perfectly fine in optimized, type-safe and indexable database columns, making it impossible to write scripts to extract data from it without parsing this so-called standardized interchange format, that neither implements schema nor data types.
No, the growth has now also reached backend programming, where C# will only allow you to work with ridiculously overcomplicated code to access it. Not only do you not know which object and property along the graph actually exists, but JSON only has some vague idea of what it's type could be. And due to the lack of a standardized API, you can only step from one property to another, being ever so careful never to encounter an unexpected object or even a null, lest you want your whole website to become a single error message. Plus the Newtonsoft.Json library is a fucking mess due to the guys there thinking they had to somehow reinvent the wheel - fucking JObject and JToken and whatnot. Compare a property to null and it doesn't equal. Try to cast it to a type, still get a fucking exception for trying to cast a null to an actual type. No wonder, the API completely changes when you cast a dynamic JObject to just a JObject. Use the generic API and call Value<T>() you say? That also throws a fucking exception. Cast it with Value<object>() perhaps? Guess what, it now turned into a JValue, and it is STILL NOT NULL. I swear this library only exists to annoy programmers into quitting their jobs, and the only job it had was to parse a practically logic-less string into a usable data structure. I had to attach a debugger because the code is so incoherent that you cannot deduce what is going on just from looking at it. Seven levels of nested ifs deep, and you're still prone to fucking up with an exception just because a user clicks the wrong button in the backend.
We had a perfectly fine markup language, XML, a perfectly fine templating language, XSLT, and a perfectly fine API in the form of XML-DOM and XPath. And a perfectly fine programming language, C#, with strong types and a nice class library. And this is a growth, as it will spread and spread even further because of the increasing reliance on JavaScript-libraries like Angular, instead of going the brave route via Blazor. Ten years ago I have chosen Umbraco because it was brave enough to use XSLT. Now it's becoming a fucking mess, indistinguishable from any other framework, where you spend your time writing Angular controllers in JavaScript instead of doing something useful.
And if you are asking why writing JavaScript controllers is such a bad thing, then you just need to take a good look at the source of media.controller.js and explain to me, why the whole logic that is already implemented in ImageUrlGenerationOptions is repeated here a second time without reusing the initial C# implementation.
Someone needs a beer :)
Can’t really blame Umbraco, Microsoft or the tech-community for not sticking to 15-20 years old tech. Feel free to use what ever you want and think what ever you want but not sure if your post here provides any value.
Looks like you forgot to read the Json.NET documentation before using it. Here is the link: https://www.newtonsoft.com/json/help/html/Introduction.htm
I agree there are a LOT of issues in the Umbraco codebase including a massive overreliance on JS styles of programming and reliance on JSON, lack of single-object responsibility, other SOLID principles, etc. However XSLT isn't much better, any XML base is a terrible standard to use due to the bloat & repitition it ends up causing.
TBH i would have loved if they went NoSQL and got rid of the archaic mess and went with blazor for the dynamic side of things.
BUT - Umbraco is very customisable, and has one of he best backoffices for the end users. It also allows for expandability as long as you properly separate your projects.
You don't check for nulls? Too bad, this isn't JS, in strongly typed functionality we need to do null-checking.
I agree that the AngularJS is excessive and pointless (MVC JS layered over MVC) and it's bloody frustrating I cannot just create a viewmodel that handles the logic.
Also this is incorrect
I have done this on numerous accasions by creating a template that can accept generics and then modify how the page appears simply by changing the data annotations and model.
is working on a reply...