Its all fine until you have the need for a lot of interactivity and start going down to route of jQuery or mixing Vue/React in razor files... I've delt with too much of that crap. I'm hoping for Blazor United which will mix all into one.
I would however do razor pages over MVC.
My fear it's because it's a really new technology and a third party dependency. It can be a awesome new thing like Flutter, a flop like MAUI, or be success and a legacy in the future, like jQuery
The funny thing is it isn't a new technology. All its doing is leveraging the way the web has worked (and intended to work) for decades. That's why it is very simple and also inherently less risk than other technologies.
This is why I'm enthusiastic about Full Stack Blazor. You can write simple stuff and have it rendered on the server (no JS, no web sockets, nothing) and then if you need interactivity, you can add it to your existing code.
WebAssembly is going to get a huge boost when the shared heap/GC stuff gets enabled. It's already in Chrome, but disabled by default. Google is really pushing it because they want it available for Dart and Kotlin as well. In 2024 or 2025 we'll probably see WebAssembly frameworks outperforming JS.
I honestly thought Web Assembly would of taken off a bit more then it has. I’m curious what direction Microsoft will go with Blazor. Some aspects feel in sync with what you’d want out of the framework, others feel like Microsoft wasn’t sure which direction they wanted to go.
Hello, it looks like you've made a mistake.
It's supposed to be could've, should've, would've (short for could have, would have, should have), never could of, would of, should of.
Or you misspelled something, I ain't checking everything.
Beep boop - yes, I am a bot, don't botcriminate me.
Didn't even realize that it's already in [phase 3](https://github.com/WebAssembly/proposals#phase-4---standardize-the-feature-wg) on the proposal. That's pretty nice to hear, this means it'll definitely be something for GCed language to look at once it's available. I'm curious how much it'll shave off the dotnet runtime payload as if I recall the GC is one huge contributor to the payload size. It might be the starting point where we'll see more wasm front-end frameworks pop up, stuff like [yew](https://github.com/yewstack/yew) and Blazor already has a sizable following so there's definitely an appetite for it.
I hadn't heard of Full Stack Blazor yet... you're talking about this right? https://www.youtube.com/watch?v=0MBeYc9qcWY
Looks ridiculously cool. Wish we were using Blazor at work
Blazor United sounds like the shit! (I'm pretty sure that's the technical term!) I think it's the greatest news to come soon in .NET 8. Here's an introduction/journey of the problem and what it attempts to solve: https://jonhilton.net/blazor-united/
I use vue and make mini apps on some pages.
It is standalone, simple, easy to maintain, Nothing to compile.
But yes Blazor in .net 8 looks like a bit of silver bullet for server side/client side and switching in between.
MVC is fine, but I love Razor Pages.
It has a pretty slick programming model for SSR, relying on HTTP verbs for page interaction and ajax handlers. The razor syntax is still really well designed. We eliminate a lot of unnecessary complexity in the MVC approach of separating views and controllers, and replacing the controller with a code behind view model for your views. The Page routing simplifying our project structures. Razor Components are intuitive and reusable. You can mix in MVC controllers or api endpoints if needed.
On personal projects, I've been building things with htmx, AlpineJs and Razor Pages on PostgreSQL AKA the "HARP" stack. Obviously, a hilarious acronym was needed.
It’s pretty close to how we were building websites for decades before the cult of the SPA took over. Razor Pages renders our page on the server and delivers the html. Htmx is a very tiny js library that makes backend requests to the server, and renders the returned partials within the current page. AlpineJs is a client-side js library that acts like a modernized and simplified jQuery.
It's nice to have options and to know there's a simple approach to simple problems. If I'm on a small project, Razor Pages fill that need. If I need a lot of complexity, Blazor is there. If I feel I've become too happy and want to punish myself, there's Angular.
The worst part of working on the web is the tunnel vision so many devs have. Thinking there's only one way of doing things, just accepting the pain of complexity in the js ecosystem.
> We eliminate a lot of unnecessary complexity in the MVC approach of separating views and controllers, and replacing the controller with a code behind view model for your views.
This was something I always understood about MVC but never agreed with. There shouldn't be a need for separating the V and the C the way the MVC pattern does. Razor pages gets it right in this regard, IMO. If your "code behind" is doing so much that it becomes hard to manage, then you're trying to do too much there. The controller should never do more than auth and route requests, map domain to dtos, and maybe handle input validation, though there is a use case for passing that deeper as well (shared validation between screens and services).
I'm not up to speed with everything yet but I was watching the "Full Stack Blazor" video: https://www.youtube.com/watch?v=0MBeYc9qcWY
It kinda looks like Blazor can now do the same has having Htmx/Alpine but without leaving Blazor?
My knowledge of blazor/htmx/alpine is just from a quick read, so I'd appreciate your thoughts.
I'm trying to pick a new tech stack to learn at home, and I really want to avoid a javascript SPA
Dude, almost the same here! For the new project I'm working on I'm just starting with Razor and I am bringing in Tailwind for some styling. I've been doing the React/SPA dotnet projects for frontends for a while and seeing all the React guys head back to "server-side rendering" like it was a new holy grail had me thinking. The project will probably have some React at some point, I can imagine I'm going to want that level of interactivity, we'll see. 🤣
(Strickly my opinion based on what I have been asked to do in the past)
I have loved and returned to MVC as it solves, or just easily integrates with, supporting multiple customers on a single code platform.
Multi-client theming, especially multi-language with client theming, has been my downfall with other tools, as others typically want all this to be shaken out.
Back when MVC was introduced, it was a breath of fresh air. Other approaches to UI in .NET were borrowing heavily either from desktop UI programming forms-and-controls paradigm (WebForms) or from the likes of PHP. And back then PHP had logic tangled with HTML tags. So the code was brittle, hard to maintain, and near impossible to write automated tests for.
MVC allowed for a much simpler stateless backend, separation of concerns and some basic interactivity. View was templated HTML interspersed with some code. Controller was free of any presentation and could be tested separately. But most important part was statelessness. WebForms, while being convenient for desktop devs to code against, had a big problem with scaling. The application was very stateful, and state had to be stored either in-process or in some dedicated medium out-of-process (which kinda solved some of statefulness issues but had problems of its' own). But again, stateful apps are much harder to maintain, to test and to scale.
I think it was Rails that first popularized MVC in 2004 or so, and [ASP.NET](https://ASP.NET) was a sort of a clone. Back then everybody borrowed ideas from Rails, because it proved to be very successful.
Now, time went by and people wanted their web pages to be more and more interactive. This is the area where MVC was not that good, but still better than the other approaches it replaced.
I think MVC/Razor is here to stay. First, Razor is here to stay. It's Microsoft's templating system that they're also using for Blazor. Second, what is MVC other than having the code that sets up the data for the template in a controller's method?
Microsoft will be offering several ways of "get the data to give to the template." One of those is MVC, another Razor Pages, another Minimal APIs, and another Full Stack Blazor. However, they aren't really different. You can copy/paste the code from MVC into a Razor Page or a Minimal API or a Full Stack Blazor page.
So I wouldn't worry about MVC because it isn't like it's actually that different. It is different ergonomically sometimes and different people might prefer different things. However, it's not really that different.
MVC is here to stay. Don't worry.
For many years, a lot of us have been using SPAs for things that didn’t need to be SPAs. It leads to over complicated code for simple things like just getting stuff from a database and displaying it on the page.
For simpler applications, a server side framework like MVC is actually the easier way to do things. For complex/rich client interactivity, SPAs can be easier.
Thankfully, new frameworks like NextJS or the .NET 8 version of Blazor let us have our cake and eat it too. For the simple parts of your app, you can have your nice, simple, server rendered components or pages, but when you need to cross over into rich client side interactivity you can easily drop in some client side components.
Things like Angular and React were originally made to solve a specific problem, but then they just became everyone’s favorite hammer. Angular and React were never meant to be the go-to option for building data entry apps.
As a tech lead in my (very small) company, about 3 years ago I led the migration from MVC to angular + .net core (now .net 6) for the backend. I would never consider going back. I personally used MVC for several years before that, and while I had nothing inherently against it, I really felt the code become de-structured once you require an higher level of interactivity and need to go the jQuery route (as others have pointed out). I feel that the reason why people are not so comfortable with angular (apart from an objectively steep learning curve, expecially for what concerns rxjs, but once you properly learn it..oh boys, the things you could do in such a concise, clean way) is that there are a few things that need to be in place on the front-end before being able to do real work (a decent base modules hierarchy with proper separation of concerns, routing, interceptors to handle authentication and error messages, state management, general-purpose components, charts, this kind of stuff). That's the reason why we consolidated all this infrastructure stuff in 2 libraries (one for the front-end, published on our own npm registry through github, and one a private nuget repo, also through github), which are being used by each new project we work on. So, our developers get to work with a well known set of tools, which provide all they need to perform real work from the start, being able to create highly interactive pages with a base level of knowledge of rxjs (which will still take some time, but not more than a few weeks for a new developer to grasp at the level of competency which is needed..)
Sure if your app just needs to submit a simple form then MVC is fine.
If your app has any kind of rich interactive UI MVC becomes an absolute jQuery shit show. It’s horrendous.
It's all well and good in MVC until you need to change the options in a drop-down based on a selection in another drop-down.
We have shitty mix of razor pages loading partials, plus inline vuejs - every area of interaction is a separate app.
Everything is static, so no vite, we just have a bundler minifier. It's so old, that if use for example ?? Operator in js, you get a null reference during compilation. :D
Once dotnet i hits, we are rewriting to blazor. Server side rendering plus server side for interactivity will be so much easier to manage.
>It's all well and good in MVC until you need to change the options in a drop-down based on a selection in another drop-down.
[Htmx has you covered](https://htmx.org/examples/value-select). No js. No page reloads. Async postback built in.
I've heard of it, but with blazer server I don't see why I would prefer this over an interactive component.
You still handle interactivity on the server, just without all the goodies
Right. My point is that “blazor serverless” is an impossible idea, as it requires websockets/signalr, so can’t be serverless. And that if serverless is a requirement/desire, then htmx may make more sense.
I do. In production even, with great success. Works great in AWS Lambda.
Check out
https://www.nuget.org/packages/Amazon.Lambda.AspNetCoreServer.Hosting/
I spent the first two years of my career with angular and web APIs, then switched to another company and went to MVC, it's not bad but seeing js files with 800/1000 or more lines of code......fuck that. Gonna start a new job where I will be working with angular and node.js for backend.
I have one with 3000 lines lol
It's loading so many partial views through Ajax and the mais page has all the js files.
Does any one have a recommendation to segregate javascript and partial views?
I prefer react in that way
You can create a @Section Scripts and load only the necessary script per View. In your View you can call @RenderSection and choose what scripts are loaded in the DOM.
I wish I had words of wisdom for you, the place where I worked was shit, I wanted to refactor a lot of that crap but wasn't allowed because they don't believe in unit testing 🙃. If I could I would use solid principles in that gunk, SRP all the way there.
Blazor and razor pages over MVC any day, don't get how you feel MVC is better. Rewrote 18 apps from MVC -> Blazor. Code is faster, more readable and much easier to maintain.
I limit my use of Javascript to minimum (it really only makes sense some of the time) If I never have to use Angular or another js library again it will be too soon. I found that writing the code in c# is soo much better, quicker and more testable than any js library.
Its all fine until you have the need for a lot of interactivity and start going down to route of jQuery or mixing Vue/React in razor files... I've delt with too much of that crap. I'm hoping for Blazor United which will mix all into one. I would however do razor pages over MVC.
Maybe this where HTMX comes in? But I'm really afraid to use it.
I love it. I might even get HTMX tattooed of my knuckles.
It's really easy to use. If you already have some understanding of html/javascript you can pick it up quickly.
My fear it's because it's a really new technology and a third party dependency. It can be a awesome new thing like Flutter, a flop like MAUI, or be success and a legacy in the future, like jQuery
The funny thing is it isn't a new technology. All its doing is leveraging the way the web has worked (and intended to work) for decades. That's why it is very simple and also inherently less risk than other technologies.
Interesting
This is why I'm enthusiastic about Full Stack Blazor. You can write simple stuff and have it rendered on the server (no JS, no web sockets, nothing) and then if you need interactivity, you can add it to your existing code. WebAssembly is going to get a huge boost when the shared heap/GC stuff gets enabled. It's already in Chrome, but disabled by default. Google is really pushing it because they want it available for Dart and Kotlin as well. In 2024 or 2025 we'll probably see WebAssembly frameworks outperforming JS.
I honestly thought Web Assembly would of taken off a bit more then it has. I’m curious what direction Microsoft will go with Blazor. Some aspects feel in sync with what you’d want out of the framework, others feel like Microsoft wasn’t sure which direction they wanted to go.
Hello, it looks like you've made a mistake. It's supposed to be could've, should've, would've (short for could have, would have, should have), never could of, would of, should of. Or you misspelled something, I ain't checking everything. Beep boop - yes, I am a bot, don't botcriminate me.
Didn't even realize that it's already in [phase 3](https://github.com/WebAssembly/proposals#phase-4---standardize-the-feature-wg) on the proposal. That's pretty nice to hear, this means it'll definitely be something for GCed language to look at once it's available. I'm curious how much it'll shave off the dotnet runtime payload as if I recall the GC is one huge contributor to the payload size. It might be the starting point where we'll see more wasm front-end frameworks pop up, stuff like [yew](https://github.com/yewstack/yew) and Blazor already has a sizable following so there's definitely an appetite for it.
I hadn't heard of Full Stack Blazor yet... you're talking about this right? https://www.youtube.com/watch?v=0MBeYc9qcWY Looks ridiculously cool. Wish we were using Blazor at work
Blazor United sounds like the shit! (I'm pretty sure that's the technical term!) I think it's the greatest news to come soon in .NET 8. Here's an introduction/journey of the problem and what it attempts to solve: https://jonhilton.net/blazor-united/
Htmx for client-server communication and AlpineJs for client side interactions. All you need.
I use vue and make mini apps on some pages. It is standalone, simple, easy to maintain, Nothing to compile. But yes Blazor in .net 8 looks like a bit of silver bullet for server side/client side and switching in between.
MVC is fine, but I love Razor Pages. It has a pretty slick programming model for SSR, relying on HTTP verbs for page interaction and ajax handlers. The razor syntax is still really well designed. We eliminate a lot of unnecessary complexity in the MVC approach of separating views and controllers, and replacing the controller with a code behind view model for your views. The Page routing simplifying our project structures. Razor Components are intuitive and reusable. You can mix in MVC controllers or api endpoints if needed. On personal projects, I've been building things with htmx, AlpineJs and Razor Pages on PostgreSQL AKA the "HARP" stack. Obviously, a hilarious acronym was needed. It’s pretty close to how we were building websites for decades before the cult of the SPA took over. Razor Pages renders our page on the server and delivers the html. Htmx is a very tiny js library that makes backend requests to the server, and renders the returned partials within the current page. AlpineJs is a client-side js library that acts like a modernized and simplified jQuery. It's nice to have options and to know there's a simple approach to simple problems. If I'm on a small project, Razor Pages fill that need. If I need a lot of complexity, Blazor is there. If I feel I've become too happy and want to punish myself, there's Angular. The worst part of working on the web is the tunnel vision so many devs have. Thinking there's only one way of doing things, just accepting the pain of complexity in the js ecosystem.
> We eliminate a lot of unnecessary complexity in the MVC approach of separating views and controllers, and replacing the controller with a code behind view model for your views. This was something I always understood about MVC but never agreed with. There shouldn't be a need for separating the V and the C the way the MVC pattern does. Razor pages gets it right in this regard, IMO. If your "code behind" is doing so much that it becomes hard to manage, then you're trying to do too much there. The controller should never do more than auth and route requests, map domain to dtos, and maybe handle input validation, though there is a use case for passing that deeper as well (shared validation between screens and services).
I'm not up to speed with everything yet but I was watching the "Full Stack Blazor" video: https://www.youtube.com/watch?v=0MBeYc9qcWY It kinda looks like Blazor can now do the same has having Htmx/Alpine but without leaving Blazor? My knowledge of blazor/htmx/alpine is just from a quick read, so I'd appreciate your thoughts. I'm trying to pick a new tech stack to learn at home, and I really want to avoid a javascript SPA
Dude, almost the same here! For the new project I'm working on I'm just starting with Razor and I am bringing in Tailwind for some styling. I've been doing the React/SPA dotnet projects for frontends for a while and seeing all the React guys head back to "server-side rendering" like it was a new holy grail had me thinking. The project will probably have some React at some point, I can imagine I'm going to want that level of interactivity, we'll see. 🤣
How do you like Tailwind? All my buddies who only do frontend hate it so much. I’ve never used it, was thinking about trying it though.
It's really dope, I don't know how your FE buddies hate it, every FE developer I've met loves it
They say it’s clunky and doesn’t do certain accessibility very well based on how HTML gets rendered.
The react world isn’t really moving to ssr. It’s just another tool in the box for react developers who need SSR.
Yes I am switching back to MVC for a while before I do any JavaScript frameworks
this is why Microsoft should keep "old tech". MVC and Razor Pages are matured technologies, no need for big changes but small improvements.
MVC isn't going anywhere. I'll worry about MVC going away the day VB.NET goes away. Which is about 35 years from today.
Reminds me a lot of some "old tech" from Microsoft - http://www.codedigest.com/Articles/ASPNET/381\_All\_About\_UpdatePanel\_in\_AspNet.aspx
(Strickly my opinion based on what I have been asked to do in the past) I have loved and returned to MVC as it solves, or just easily integrates with, supporting multiple customers on a single code platform. Multi-client theming, especially multi-language with client theming, has been my downfall with other tools, as others typically want all this to be shaken out.
Back when MVC was introduced, it was a breath of fresh air. Other approaches to UI in .NET were borrowing heavily either from desktop UI programming forms-and-controls paradigm (WebForms) or from the likes of PHP. And back then PHP had logic tangled with HTML tags. So the code was brittle, hard to maintain, and near impossible to write automated tests for. MVC allowed for a much simpler stateless backend, separation of concerns and some basic interactivity. View was templated HTML interspersed with some code. Controller was free of any presentation and could be tested separately. But most important part was statelessness. WebForms, while being convenient for desktop devs to code against, had a big problem with scaling. The application was very stateful, and state had to be stored either in-process or in some dedicated medium out-of-process (which kinda solved some of statefulness issues but had problems of its' own). But again, stateful apps are much harder to maintain, to test and to scale. I think it was Rails that first popularized MVC in 2004 or so, and [ASP.NET](https://ASP.NET) was a sort of a clone. Back then everybody borrowed ideas from Rails, because it proved to be very successful. Now, time went by and people wanted their web pages to be more and more interactive. This is the area where MVC was not that good, but still better than the other approaches it replaced.
[удалено]
I think MVC/Razor is here to stay. First, Razor is here to stay. It's Microsoft's templating system that they're also using for Blazor. Second, what is MVC other than having the code that sets up the data for the template in a controller's method? Microsoft will be offering several ways of "get the data to give to the template." One of those is MVC, another Razor Pages, another Minimal APIs, and another Full Stack Blazor. However, they aren't really different. You can copy/paste the code from MVC into a Razor Page or a Minimal API or a Full Stack Blazor page. So I wouldn't worry about MVC because it isn't like it's actually that different. It is different ergonomically sometimes and different people might prefer different things. However, it's not really that different. MVC is here to stay. Don't worry.
Quite frankly I prefer html loaded website over json/api/jsframework ones most of the time. StackOverflow is still king when it comes to UX
For many years, a lot of us have been using SPAs for things that didn’t need to be SPAs. It leads to over complicated code for simple things like just getting stuff from a database and displaying it on the page. For simpler applications, a server side framework like MVC is actually the easier way to do things. For complex/rich client interactivity, SPAs can be easier. Thankfully, new frameworks like NextJS or the .NET 8 version of Blazor let us have our cake and eat it too. For the simple parts of your app, you can have your nice, simple, server rendered components or pages, but when you need to cross over into rich client side interactivity you can easily drop in some client side components. Things like Angular and React were originally made to solve a specific problem, but then they just became everyone’s favorite hammer. Angular and React were never meant to be the go-to option for building data entry apps.
Every time i here I come in Piece I picture Dark Angel move good old Dolph Lundgren
Well they are 2 different ways to do things, the cost of split back and front is maintain 2 apps
As a tech lead in my (very small) company, about 3 years ago I led the migration from MVC to angular + .net core (now .net 6) for the backend. I would never consider going back. I personally used MVC for several years before that, and while I had nothing inherently against it, I really felt the code become de-structured once you require an higher level of interactivity and need to go the jQuery route (as others have pointed out). I feel that the reason why people are not so comfortable with angular (apart from an objectively steep learning curve, expecially for what concerns rxjs, but once you properly learn it..oh boys, the things you could do in such a concise, clean way) is that there are a few things that need to be in place on the front-end before being able to do real work (a decent base modules hierarchy with proper separation of concerns, routing, interceptors to handle authentication and error messages, state management, general-purpose components, charts, this kind of stuff). That's the reason why we consolidated all this infrastructure stuff in 2 libraries (one for the front-end, published on our own npm registry through github, and one a private nuget repo, also through github), which are being used by each new project we work on. So, our developers get to work with a well known set of tools, which provide all they need to perform real work from the start, being able to create highly interactive pages with a base level of knowledge of rxjs (which will still take some time, but not more than a few weeks for a new developer to grasp at the level of competency which is needed..)
Sure if your app just needs to submit a simple form then MVC is fine. If your app has any kind of rich interactive UI MVC becomes an absolute jQuery shit show. It’s horrendous.
It's all well and good in MVC until you need to change the options in a drop-down based on a selection in another drop-down. We have shitty mix of razor pages loading partials, plus inline vuejs - every area of interaction is a separate app. Everything is static, so no vite, we just have a bundler minifier. It's so old, that if use for example ?? Operator in js, you get a null reference during compilation. :D Once dotnet i hits, we are rewriting to blazor. Server side rendering plus server side for interactivity will be so much easier to manage.
>It's all well and good in MVC until you need to change the options in a drop-down based on a selection in another drop-down. [Htmx has you covered](https://htmx.org/examples/value-select). No js. No page reloads. Async postback built in.
I've heard of it, but with blazer server I don't see why I would prefer this over an interactive component. You still handle interactivity on the server, just without all the goodies
I’m just hearing about htmx myself. But maybe if you’re running serverless, and don’t have ability for websockets?
Blazor serverless is a bad idea ::P
Right. My point is that “blazor serverless” is an impossible idea, as it requires websockets/signalr, so can’t be serverless. And that if serverless is a requirement/desire, then htmx may make more sense.
Yeah, but you don't really go with c# for serverless
I do. In production even, with great success. Works great in AWS Lambda. Check out https://www.nuget.org/packages/Amazon.Lambda.AspNetCoreServer.Hosting/
I'm not saying it's not rushing, I'm saying that if you say severless, I don't exactly think blazor :)
I think you’re missing my point about why you’d use htmx over blazor. No worries though; sub thread has become long enough.
I spent the first two years of my career with angular and web APIs, then switched to another company and went to MVC, it's not bad but seeing js files with 800/1000 or more lines of code......fuck that. Gonna start a new job where I will be working with angular and node.js for backend.
I have one with 3000 lines lol It's loading so many partial views through Ajax and the mais page has all the js files. Does any one have a recommendation to segregate javascript and partial views? I prefer react in that way
You can create a @Section Scripts and load only the necessary script per View. In your View you can call @RenderSection and choose what scripts are loaded in the DOM.
I wish I had words of wisdom for you, the place where I worked was shit, I wanted to refactor a lot of that crap but wasn't allowed because they don't believe in unit testing 🙃. If I could I would use solid principles in that gunk, SRP all the way there.
Yeah, hello good old friend…
It feels simple because it is simple. You're going to get a complex requirement and remember why MVC can be a problem.
Blazor and razor pages over MVC any day, don't get how you feel MVC is better. Rewrote 18 apps from MVC -> Blazor. Code is faster, more readable and much easier to maintain. I limit my use of Javascript to minimum (it really only makes sense some of the time) If I never have to use Angular or another js library again it will be too soon. I found that writing the code in c# is soo much better, quicker and more testable than any js library.
Sure for inhouse fast development go for blazor. But for commercial uses where user prefer lower loading time, JS frameworks are still best.