The Future of Razor
-
TNCaver wrote:
I don't have a clue what SPA is
SPA = Single Page Application. Web Frameworks such as Angular, Ember.js, Knockout.js, Vue.js, React, etc are examples of SPA frameworks. All of them heavily relies on JavaScript. That's why with Blazor, you don't have to worry about JavaScript as you can fully take advantage of your C# skills to build a dynamic SPA application. Just a thing to note that Blazor is still on it's experimental stage at the moment.
TNCaver wrote:
but surely you don't mean Socialist Party of America or Sperm Penetration Assay :laugh: )
:laugh: :laugh: :laugh:
-
I'm trying to update my skills, and do that while creating a new complex website. My choice is down to AngularJS or Razor. Razor is very attractive because I've been doing C# for ten years. But Wikipedia says the latest release is a preview of 4.0.0-rc1, which came out three years ago come November. Is Razor dead? Should I bother with it?
If you think 'goto' is evil, try writing an Assembly program without JMP.
Current version is 3.2.6, available on NuGet; release was earlier this year. I don't think Razor is dead, I just think that there really isn't that much more to add to it as it is a layout engine to create HTML, which has been stable pretty much for a few years now
Director of Transmogrification Services Shinobi of Query Language Master of Yoda Conditional
-
I particularly declared Razor DOA because of the runtime compilation of page rendering. Have you looked at what Razor, and similar tech, does? At least for Razor, IIRC, it creates code that "string prints" the HTML portions and inserts the C# code, then compiles that and executes it server-side, delivering the HTML portion to the client. It's slow and an absurd way of doing things, IMO, yet pretty much the only way to embed C# inside of HTML. My personal preference, I think mixing client-side HTML markup and Javascript with server-side "pre-rendering" C# into a single file that really shouldn't be anything more than just the "view" and the "view controller" of what gets rendered on the client's browser creates an entangled mess. So I took the route (no pun intended) of keeping my server-side code on the server, my HTML view and view control logic on the HTML/Javascript side, and using AJAX calls for data requests/updates and websockets (SignalR initially, but that became obsolete with direct websocket support) for dynamic updates. And pretty much, I don't even bother with any of those Javascript MVC-style frameworks because doing this kind of stuff is actually really trivial. On the downside, yeah, loading the page then calling the server to load the data adds an additional (at least one) round trip, but I've never noticed a performance issue, particularly as the AJAX calls are asynchronous, and the advantages are numerous -- server-side logging, clean separation of concerns, and having created a server-side API as a side effect so I can use the same POST/GET/etc. calls in headless mode -- no UI. Razor, while cool, seemed to me to be a knee jerk reaction to the likes of things like what Ruby on Rails was doing. I also think that C#'s [named arguments](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/named-and-optional-arguments) was intended to provide some "comfort" to people working purely in Javascript/JSON as the syntax looks JSON-ish. And there are times in C# where I love that feature -- I rarely use it, but it's awesome when you want to provide a value to a specific parameter without having to provide defaults for all the other optional parameters. Without named arguments, the C#-client-side-HTML would look horrid, particularly when using ASP.NET controls, which suck anyways, but that's another story. In fact, by ditching the entire ASP.NET / Razor stack, my websites are blindingly fast, in my not so humble opinion. [edit] But as a result of my c
With today's data-driven sites, there always will be a need for request time calculations. Many have said that Razor resembles Classic ASP or PHP, you could also argue it resembles CFM as well as the ASPX engine which WebForms builds upon. This would make sense, as it is all doing the same thing of interpreting at time of rendering. I see nothing evolutionary or revolutionary in any of these new um-er frameworks. I really never liked the canned "html helpers" that ASPX & Razor offer and would prefer to use my own extension methods. I have no issues of the "pre-render" concept; in all reality all of the content-blocks could just be (Div) IDs to populate from a get-page-content JSON call (to a C# call as you suggested)
Director of Transmogrification Services Shinobi of Query Language Master of Yoda Conditional
-
I particularly declared Razor DOA because of the runtime compilation of page rendering. Have you looked at what Razor, and similar tech, does? At least for Razor, IIRC, it creates code that "string prints" the HTML portions and inserts the C# code, then compiles that and executes it server-side, delivering the HTML portion to the client. It's slow and an absurd way of doing things, IMO, yet pretty much the only way to embed C# inside of HTML. My personal preference, I think mixing client-side HTML markup and Javascript with server-side "pre-rendering" C# into a single file that really shouldn't be anything more than just the "view" and the "view controller" of what gets rendered on the client's browser creates an entangled mess. So I took the route (no pun intended) of keeping my server-side code on the server, my HTML view and view control logic on the HTML/Javascript side, and using AJAX calls for data requests/updates and websockets (SignalR initially, but that became obsolete with direct websocket support) for dynamic updates. And pretty much, I don't even bother with any of those Javascript MVC-style frameworks because doing this kind of stuff is actually really trivial. On the downside, yeah, loading the page then calling the server to load the data adds an additional (at least one) round trip, but I've never noticed a performance issue, particularly as the AJAX calls are asynchronous, and the advantages are numerous -- server-side logging, clean separation of concerns, and having created a server-side API as a side effect so I can use the same POST/GET/etc. calls in headless mode -- no UI. Razor, while cool, seemed to me to be a knee jerk reaction to the likes of things like what Ruby on Rails was doing. I also think that C#'s [named arguments](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/named-and-optional-arguments) was intended to provide some "comfort" to people working purely in Javascript/JSON as the syntax looks JSON-ish. And there are times in C# where I love that feature -- I rarely use it, but it's awesome when you want to provide a value to a specific parameter without having to provide defaults for all the other optional parameters. Without named arguments, the C#-client-side-HTML would look horrid, particularly when using ASP.NET controls, which suck anyways, but that's another story. In fact, by ditching the entire ASP.NET / Razor stack, my websites are blindingly fast, in my not so humble opinion. [edit] But as a result of my c
-
I particularly declared Razor DOA because of the runtime compilation of page rendering. Have you looked at what Razor, and similar tech, does? At least for Razor, IIRC, it creates code that "string prints" the HTML portions and inserts the C# code, then compiles that and executes it server-side, delivering the HTML portion to the client. It's slow and an absurd way of doing things, IMO, yet pretty much the only way to embed C# inside of HTML. My personal preference, I think mixing client-side HTML markup and Javascript with server-side "pre-rendering" C# into a single file that really shouldn't be anything more than just the "view" and the "view controller" of what gets rendered on the client's browser creates an entangled mess. So I took the route (no pun intended) of keeping my server-side code on the server, my HTML view and view control logic on the HTML/Javascript side, and using AJAX calls for data requests/updates and websockets (SignalR initially, but that became obsolete with direct websocket support) for dynamic updates. And pretty much, I don't even bother with any of those Javascript MVC-style frameworks because doing this kind of stuff is actually really trivial. On the downside, yeah, loading the page then calling the server to load the data adds an additional (at least one) round trip, but I've never noticed a performance issue, particularly as the AJAX calls are asynchronous, and the advantages are numerous -- server-side logging, clean separation of concerns, and having created a server-side API as a side effect so I can use the same POST/GET/etc. calls in headless mode -- no UI. Razor, while cool, seemed to me to be a knee jerk reaction to the likes of things like what Ruby on Rails was doing. I also think that C#'s [named arguments](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/named-and-optional-arguments) was intended to provide some "comfort" to people working purely in Javascript/JSON as the syntax looks JSON-ish. And there are times in C# where I love that feature -- I rarely use it, but it's awesome when you want to provide a value to a specific parameter without having to provide defaults for all the other optional parameters. Without named arguments, the C#-client-side-HTML would look horrid, particularly when using ASP.NET controls, which suck anyways, but that's another story. In fact, by ditching the entire ASP.NET / Razor stack, my websites are blindingly fast, in my not so humble opinion. [edit] But as a result of my c
It is curious that you think that mixing HTML and Javascript with C# is a mess, when the mixture of HTML and Javascript itself is a complicated mixture of design and code. That's why I've been rejecting the development of WEB applications for a long time and I focus on the development of Apps using frameworks where design and code are separated. I hope that with Webassembly we can overcome the horrible mix of design and code that is the HTML+Javascript framework.
Sorry for my bad English
-
Current version is 3.2.6, available on NuGet; release was earlier this year. I don't think Razor is dead, I just think that there really isn't that much more to add to it as it is a layout engine to create HTML, which has been stable pretty much for a few years now
Director of Transmogrification Services Shinobi of Query Language Master of Yoda Conditional
-
I'm trying to update my skills, and do that while creating a new complex website. My choice is down to AngularJS or Razor. Razor is very attractive because I've been doing C# for ten years. But Wikipedia says the latest release is a preview of 4.0.0-rc1, which came out three years ago come November. Is Razor dead? Should I bother with it?
If you think 'goto' is evil, try writing an Assembly program without JMP.
If you're going to update your skills, do neural networks instead, and ignore the front-end for one more year. Browser tech and UI in general has been stabilizing and synching up ever since HTML5. WASM is expected to unify the entire stack into a single dominant language. The milestone we need to reach for that to happen, is a workable garbage collector in WASM. Meanwhile, everyone and their cat are preparing to fight for stack dominance. Rust and Qt are already actively going for it, but they have a relatively small following with limited tooling. C# is currently hitching a free ride on Mono's GC implementation, which is no-where near stable enough, but good enough to build exploratory tooling with like Blazor. Meanwhile, .NET Core team is porting everything UI related and Enterprise-legacy related, shoring up for the paradigm shift that's inevitable. I'm guessing Oracle will fuck up during all of this (hey, it's what they do) and miss the opportunity to solidify Java as the dominant language. If we're lucky, we get a full C# stack by 2020, ending this era of language-war nonsense. I don't care who wins it, as long as we unify the stack in the progress.
-
I particularly declared Razor DOA because of the runtime compilation of page rendering. Have you looked at what Razor, and similar tech, does? At least for Razor, IIRC, it creates code that "string prints" the HTML portions and inserts the C# code, then compiles that and executes it server-side, delivering the HTML portion to the client. It's slow and an absurd way of doing things, IMO, yet pretty much the only way to embed C# inside of HTML. My personal preference, I think mixing client-side HTML markup and Javascript with server-side "pre-rendering" C# into a single file that really shouldn't be anything more than just the "view" and the "view controller" of what gets rendered on the client's browser creates an entangled mess. So I took the route (no pun intended) of keeping my server-side code on the server, my HTML view and view control logic on the HTML/Javascript side, and using AJAX calls for data requests/updates and websockets (SignalR initially, but that became obsolete with direct websocket support) for dynamic updates. And pretty much, I don't even bother with any of those Javascript MVC-style frameworks because doing this kind of stuff is actually really trivial. On the downside, yeah, loading the page then calling the server to load the data adds an additional (at least one) round trip, but I've never noticed a performance issue, particularly as the AJAX calls are asynchronous, and the advantages are numerous -- server-side logging, clean separation of concerns, and having created a server-side API as a side effect so I can use the same POST/GET/etc. calls in headless mode -- no UI. Razor, while cool, seemed to me to be a knee jerk reaction to the likes of things like what Ruby on Rails was doing. I also think that C#'s [named arguments](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/named-and-optional-arguments) was intended to provide some "comfort" to people working purely in Javascript/JSON as the syntax looks JSON-ish. And there are times in C# where I love that feature -- I rarely use it, but it's awesome when you want to provide a value to a specific parameter without having to provide defaults for all the other optional parameters. Without named arguments, the C#-client-side-HTML would look horrid, particularly when using ASP.NET controls, which suck anyways, but that's another story. In fact, by ditching the entire ASP.NET / Razor stack, my websites are blindingly fast, in my not so humble opinion. [edit] But as a result of my c
So thats a no from you on Blazor?
-
I'm trying to update my skills, and do that while creating a new complex website. My choice is down to AngularJS or Razor. Razor is very attractive because I've been doing C# for ten years. But Wikipedia says the latest release is a preview of 4.0.0-rc1, which came out three years ago come November. Is Razor dead? Should I bother with it?
If you think 'goto' is evil, try writing an Assembly program without JMP.
I hate the term dead, because webforms & Jquery are supposedly dead, but they are still everywhere and some groups will just not let them go. But I would focus on either AngularJS or React/Redux. I just recently was writing a small app in Razor Pages (as opposed to ASP.NET MVC) and I needed a bootstrap time picker which I found in NPM, (record scratch noise) but the Razor Page project isn't really optimized for using NPM whereas the a fore mentioned JS frameworks are. The more I code w/ JS-based client-side frameworks, the less I like frameworks like Razor, PHP or HAML in Ruby where you write HTML, but every once in a while you break it open and stuff some imperative code in the middle of it. And let's face it, AJAX is a pain in Razor and feels like a hack whereas Angular and React handle it differently. Lastly, Razor is a Microsoft thing, React and Angular are not even though VS supports both frameworks (particularly in .NET Core projects). Learning React and Angular allow me to feel like I'm not so locked into VS much less Windows.
-
So thats a no from you on Blazor?
dennis Cruise wrote:
So thats a no from you on Blazor?
Not necessarily. Nobody said I can't be contradictory. ;)
Latest Article - A Concise Overview of Threads Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
Have you maybe written an article of your approach? It sounds pretty cool and I'd like to see it in action if possible.
Jacquers wrote:
Have you maybe written an article of your approach?
Not yet, it's one of those "on the stack of things to write about."
Latest Article - A Concise Overview of Threads Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
I'm trying to update my skills, and do that while creating a new complex website. My choice is down to AngularJS or Razor. Razor is very attractive because I've been doing C# for ten years. But Wikipedia says the latest release is a preview of 4.0.0-rc1, which came out three years ago come November. Is Razor dead? Should I bother with it?
If you think 'goto' is evil, try writing an Assembly program without JMP.
As recently as 05/16/2018-- [Razor file compilation and precompilation in ASP.NET Core | Microsoft Docs](https://docs.microsoft.com/en-us/aspnet/core/mvc/views/view-compilation?view=aspnetcore-2.1)
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal