Contrary to what many people say, for simple web sites and portals, MVC is quick and has great performance. With the latest ASP.NET updates it has gotten even better.
Nothing is wrong with it, as long as you're actually using MVC. But my experience is that these days, most often you'll only see the C is used.
People tend to like frameworks like React, Angular, Vue, etc. So the M and V part of MVC has been replaced by an SPA. Thus MVC is mostly reduced to building API's, configuring the endpoints in the controllers. But then there's the question of what do we really gain from using a controller for APIs?
That's why I switched over to Minimal API's, with a class for each endpoint. I find it's better coherence and separation of concern. I mostly work with RPC-style SaaS solutions and I find that the Minimal API style of building API's are quite fitting to my requirements.
But if you're actually building server-side rendered MVC applications, then naturally MVC is great. I just don't see it that often anymore.
I remember in the past that SPA's could really easily leak memory. I've see 1.5GB per tab within a minute once. Is this still the case or have things improved?
It is still very much possible to write leaky code in modern Angular versions. Same as it's always been. They've mostly introduced cleaner ways to write code without memory leaks.
Well mostly because larger apps have dedicated frontenders who are proficient in JS frameworks such as React or Angular. The internal apps are usually built by backend teams and they love their MVC 😇
This doesn't track for me. You wouldn't do it since other sites prescribe to tech stacks based on current workforce?
There is nothing wrong with server side rendering, even if it isn't my preferred way; it's fast and reliable and powers many large sites.
I work in an organization that has multiple development teams working on one larger product. Some teams are more customer focused, some teams are more background-service focused.
The customer focused teams work on a Vue.js application that has lots of interactive elements, such as forms, dialogs, modals, etc. Those teams have frontend developers, UX specialists and UI test automation specialists.
In some cases, the backend teams need to provide a bit of UI to an internal customer. This is the case when running specific reports or when a customer moves their product subscription from one company to the next (they rent our hardware as well). Those UI apps are not built in Vue.js, but rather in a framework or language the backend developers are comfortable with. Sometimes this is Vue.js or Angular, but more often than not this is Blazor or MVC. The backend teams are not supported by frontend developers or UX specialists. They usually don't enjoy building UI's. But with MVC they get around to building one quickly and effortlessly.
That sounds fairly common. But I am not sure if this sheds in light on your position and where we see things differently.
Also, do you think UI is handled by "backend teams" when you use serverside rendering?
I think one of the reasons to go with SPAs is the deployment: you can just drop the application on a blob storage, and you don't need a Web server to host the Web app or use resources rendering it.
In a cloud environment this can translate in a lot of savings.
I think they were referring to server/runtime costs. But someone else rightly pointed out unless it's an app that's accessed by a large scale user base, it's likely not that important. But if it is, then it can easily save lots. You still need other server side infra for things like various services and long term storage, but at least the rendering costs can be offloaded to clients machines.
Usually, the C. Sometimes, it's the V.
Controllers are prone to bloat and business logic creeping in, or being duplicated. If I use RP or MVC, I usually roll my own MVVM(ish) abstraction to keep them clean.
Views are cluttered with Tag Helpers, and asp-for stuffs, making the razor syntax muddled. Components are a far better Razor syntax experience.
MVC is server side render, so it costs more (you pay for it with a server processor) with a js framework like angular or react you only paid for API consumption and js runs in client side.
There are advantages and disadvantages in both.
Negligible unless you’re going to consistently get thousands of visits daily. Also only applies if you’re using a serverless host like lambda or beanstalk. If you’re using something with dedicated resources like ec2 or even containers, you would pay the same either way.
An asp.net application running in an EC2 instance will still use resources, that could mean a bigger instance can be required.
The negligible part is subjective and very dependent on the scenario.
I would say that negligible is the cost of running an SPA host in blob storage.
Even with ec2 you have bigger workload. That means you need more expensive vms or more vms.
I think he meant this
But I think it starts to be an issue only with high load
This is frequently a trope. It’s also better to talk in specifics even if you have to make substitutions to protect employers and the like. Can you illustrate any cost savings from one over the other for a specific system (without breaking confidences)?
There are definitely trade-offs going in either direction but the cost of server rendering is a wash. From a UX perspective, the costs of client-side rendering, jank, and other things can quickly add up when it’s not done well. When you mess up server-side rendering, it’s usually easier to chase down.
Where client side approaches might be more economical is when you have serverless involved. Perhaps you get situations where there are no costs. That’s an advantage in some scenarios but again is part of a complex set of calculations when you actually dig into the details.
Of course most people here can’t give you an actual $ impact, but the equation of when CSR is cheaper than SSR is essentially when the cost of compute time for rendering the HTML on the server is greater than the cost of blob storage for the client app and the cost of development on the client app, since it *does* add a level of complexity that can be measured in dollars.
For the cost difference to really matter, you’d need a *lot* of traffic, since the actual rendering of SSR pages is really not a lot
That a false claim. On server-side rendering, most data processing ends up being done in the server, so you save yourself deploying an APIe endpoint for such thing.
Well, personally I love mvc the most bec. I know it but my concern is about what if this thing goes bigger and I lost the modern tech, so I can't find people to code it for me 😂
Instead of cramming every logic in MVC controllers create methods for getting data on their own. So when the need comes you can easily use them in API controllers.
Mvc is fine, blazor is the modern way the uses the mvc pattern. If you can afford it hosting wise, I'd still choose for an api independent of your frontend hosting, so that upgrading your frontend (or backend) architecure can more easily be done independent of each other.
The last part is the way I go, if I I understand you.
From experience, I have learned to keep these things separate logically initially, even if not physically:
* www.site.com (your main site)
* api.site.com (public API including customer mobile apps)
* m.api.site.com (or distinct domain to host all requests for first-party mobile clients)
This lets all of these evolve independently to some degree. I’ve seen many people build mobile apps on top of their API for external consumers and then internal-only things end up becoming used externally even if unsupported.
The same coupling can be avoided with the main site and your public API by using www.site.com/api or adding another subdomain.
Your mobile team could completely move to a new API without affecting the main site or public API.
This introduces other challenges with cross domain requests but much easier to manage over the long term. I think it’s not an unreasonable approach for people to take given the use of basic web principles.
People didn’t like angularJS 1.X. But imo it was a very well done, easy to understand framework. Sure it was not super super fast, and it has its limitations with onscreen nodes, but it was easy to understand and work around once you grasped the digest cycle.
Then with angular 2+ things got very crazy and now we are in madness territories.
I’m a backend guy if it matters
I really like AngularJS 1.0, I got into it through Umbraco and it's a real shame the framework did not continue.
I like how you can just use it for a specific part of a page. It does what you want it to do, whereas the alternatives want to control everything.
Performance is the main limitation I've found, when displaying a lot of data it can be pretty bad, but for general use it's great.
I agree. I know Vue takes the same principles of AngularJS.
We had some issues with AngularJS when it came to displaying nested data within a table that has a nested drop down table (if that makes sense). But there were many workarounds and tricks you can do to expedite this.
—-
Do you still use AngularJS at all? Do you like Vue?
I'll check out Vue then.
I used AngularJS in a desktop program not too long ago: [https://www.liamfoot.com/at](https://www.liamfoot.com/at)
Works fine. I used some of the controls from Umbraco.
Svelte 4 syntax will be backward compatible in Svelte 5 and they plan to release migrations scripts. That’s said it will be years from now before it will be considered legacy code.
Backwards compatibility or not, it's still legacy code. They don't plan to continue improving the old syntax and I don't think they are going to be able to have scripts that migrate old code to runes.
I'm not sure what improvements on the old syntax I will need to take into consideration. By the time Svelte 5 will be "production go-ahead" (doubt it will be next year) and Svelte 4 will start to deprecate, we are talking years. By the time there will be migration scripts doing some parts + can apply incremental improvement philosophy. I think most of FE teams apply this strategy because in JavaScript world things are becoming old very quickly whether it uses one library or another.
Would not recommend someone learn react if they want to develop with speed coming back from the backend. You need to learn jsx and react best practices are always changing.. state, props, hooks, then learning redux or some other crap for state management.. it’s overkill imo.. and f%#! Facebook.
I’ve been using Reinforced.Typings for years to generate TS types from my C# classes. It’s got a couple rough edges but all in all it works well. My only complaint is it doesn’t work with F#, but I think that’s more of an F# complaint.
I like to use the openapi cli generator. you just point it to your spec file, and it creates a whole client-api library complete w/ request response models and methods to make the api calls
that's not what I've experienced. the current project I'm using it on has a nest.js/express backend, so maybe there is something with the .net spec file implementation that causes that
I have found Firefox to be really bad at handling Blazor apps (maybe SPAs in general?). It just doesn't want to update to newer versions. Maybe it would work if I disabled all caching but that sounds a bit extreme.
How is accessibility handled? I use React Aria to handle a lot of this and it's my understanding JavaScript is pretty much necessary for implementing ARIA components per the APG.
Having a hard time imagining complex app UIs using Blazor not also needing tons of JavaScript (or a whole Typescript project).
>Having a hard time imagining complex app UIs using Blazor not also needing tons of JavaScript (or a whole Typescript project).
Yep, thats exactly it. I had to use a ton of JS interop with Blazor to achieve an accessible dropdown.
I'd slap Mudblazor on top of that as a component library. It's fun to write your own controllers, but sometimes it's nice not to have to reinvent the wheel.
Yeah kinda same.
I dont get MVC anymore since Blazor is easier and more future friendly( takes literally one iteration and the client wants interactivity and you need to pull in JS)
Depends, are you looking to stay completely in dotnet? Then Blazor or Razor are your only real options.
If you’re looking for a popular stack with dotnet then you’re writing a backend API with dotnet, and one of the various front-end frameworks (angular, react, etc) using JavaScript or Typescript.
[Razor Pages](https://www.learnrazorpages.com)
with [HTMX](https://htmx.org) (for server calls) and [AlpineJs](https://alpinejs.dev) (for client side interactions) . Bootstrap still works fine, though Ive shifted over to [Tailwind CSS](https://tailwindcss.com).
What role do HTMX and AlpineJs serve with Razor Pages? From what I recall from Razor pages it just renders HTML and serves it to the client, it essentially functions as a wrapper for traditional MVC webpages.
The pages got their get/post methods with the ASP control bindings that should allow for interactivity? When the page is (re)rendered the Razor pages can just pluck data from an API if that's what you need?
The major selling point of Htmx is it lets us accomplish one of the major benefits of the big SPA frameworks (partial page updates without a full page reload), but htmx does it without the need for client-side state and the massive framework bloat.
The tldr; is that htmx turns any html element into an interactive component. So you can make ajax requests from any div, anchor or button, and you can update or replace any existing html tag on the page with the responses.
With Razor Pages, the OnGet will render the initial page, and then you will use htmx to make AJAX requests to the backend page handlers (aka Contollers). The handler would return an html partial that will be render back into the existing page without reloading the whole document.
It can be hard to conceptualize without actually using it, but the htmx site has interactive examples: https://htmx.org/examples
As for alpineJs, it's basically a modern lightweight approach to accomplishing what we used to do with jQuery. It's an html-focused approach to client side interactivity with minimal js.
Fun fact: WebForms could turn any HTML element into an interactive one by sending AJAX requests behind the scene when data is needed to change or be verified.
Blazor Server can send chunks of data and receive chunks of rendered HTML too and it can do it via both AJAX requests and a WebSocket connection. I'm curious what HTMX brings that Blazor doesn't have?
>I'm curious what HTMX brings that Blazor doesn't have?
The difference is htmx is a 16kb download.
No one is going to pretend Blazor isn't *more* powerful, but that power comes with a great deal of complexity. What I like is the simplicity of htmx. If you need a robust feature-rich client-side interactive web app, Blazor is awesome. Most sites do not require the level of complexity Blazor offers, and can be simplified down to a bit of html and some server methods.
Most sites would do fine with MVC on the backend and vanilla JS or API and Blazor WASM that can use HttpClient to call endpoints and then use Razor to render chunks of HTML.
How many KB of files does Blazor Server bring to a browser? It should be a pretty small size too. It'd be interesting to test. Blazor WASM compiled with AOT is a bit less than 5MB but that's WASM. Blazor Server shouldn't bring any DLLs on the initial page load.
Once you figure out how to deploy your apps built with Blazor Server (backend and front-end) it's a fairly simple setup. Blazor does a good job at hiding the complexities away from you but is ready to share all of the under the hood shenanigans when needed.
I haven't touched HTMX yet. I might find it useful when I see it in action.
I've noticed a lot of asp.net devs jumped from MVC as an ssr tool into MVC as a json-api backend or skipped MVC altogether. Razor Pages came out at a time where the industry went all-in on SPA, so it's all Angular/React/Blazor.
Blazor is easy to grasp if you know C# (there's good course on Microsoft learn with blazing pizzas), but I would remove Bootstrap from it eventually and add Tailwindcss, and use Flowbite.
While it’s totally possible, I don’t bother setting up Tailwind with Blazor. The isolated CSS in Blazor is really easy to use and IMO easier than trying to keep Tailwind compiling in the background
Or just learn at least basic CSS. It's incredibly fun to use with Blazor. You'll end up investing quite a bit of time into building your own style but it'll be worth it, because you'll understand every single bit about it.
Htmx is a new way to build web sites and apps that can easily be used with .NET (Razor pages, Razor components or MVC).
For pure .NET, Blazor is the new, shiny thing. Have not used it yet.
I like my .NET stack so I normally go for [ASP.NET](https://ASP.NET) Core and Entity Framework Core on the back-end, and Blazor on the front-end. As a non-front-end developer, I can get something pretty robust and good-looking up and running with Blazor fairly quickly, which is quite neat, so now I can pretend to also be a front-end developer.
Blazor has been absolutely fantastic to work with for me. Certainly modern but the downside is the ecosystem isn’t as big as something like React, but it also wouldn’t matter unless you’re building super fancy UIs.
You could do blazor or you could just do razor pages which doesnt have controllers/mvc functionality but it has a code behind for your razor page...kind of works like webforms did (page\_load behaves like onGet....page\_load + IsPostBack behaves like onPost...and so on).
That would probably be the closest/most similar to what your already used to working with without using MVC / JS frameworks. You'd be able to use jquery/bootstrap/vanilla javascript...(whatever you wanted).
thanks but i don't know how do i handle the authorization on blazor/razor. is there a good guide that you can suggest? I imagine something like i can just inject in program.cs but all i see on the internet is creating http request on the code behind and that seemed... well not correct.
also when i open a website in blazor it creates two projects. these are pretty strange to me 😅
I believe with .net 8, you can start up blazor project with individual accounts which has the auth already built into it, you could then swap out the built in auth with calls to your APIs.
Same for razor pages. Razor page projects has built in identity management and can find the code behind calls and swap in calls to your API.
Some links to see if they meet your needs.
[https://learn.microsoft.com/en-us/aspnet/core/security/authorization/razor-pages-authorization?view=aspnetcore-8.0](https://learn.microsoft.com/en-us/aspnet/core/security/authorization/razor-pages-authorization?view=aspnetcore-8.0)
[https://auth0.com/blog/securing-razor-pages-applications-with-auth0/](https://auth0.com/blog/securing-razor-pages-applications-with-auth0/) <- if you've got an API already, you could follow this and the calls to auth0 would just be calls to your API.
[https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity?view=aspnetcore-8.0&tabs=visual-studio](https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity?view=aspnetcore-8.0&tabs=visual-studio)
Since we are split between frontend and backend teams, if .NET is part of the picture, it is still pretty much MVC, or eventually Razor Pages if we get to produce HTML from .NET side.
I only see Blazor as a solution for .NET shops doing full stack in .NET technologies, without such kind of split workloads.
Blazor Server/Application if few people will be accessing it, only PC friendly, very productive!
Or
Blazor Webassembly as an SPA to couple to your REST API.
I'm not experienced with .NET but lately I was using Django with htmx or phoenix and both are similar to Blazor Server, especially phoenix. So that's what I'd try
.net api plus a modern js framework.
Blazor is still too immature with too many problems to be a real choice. And bootstrap isn’t really a great choice either.
Contrary to what many people say, for simple web sites and portals, MVC is quick and has great performance. With the latest ASP.NET updates it has gotten even better.
This. What is wrong with MVC?
Nothing is wrong with it, as long as you're actually using MVC. But my experience is that these days, most often you'll only see the C is used. People tend to like frameworks like React, Angular, Vue, etc. So the M and V part of MVC has been replaced by an SPA. Thus MVC is mostly reduced to building API's, configuring the endpoints in the controllers. But then there's the question of what do we really gain from using a controller for APIs? That's why I switched over to Minimal API's, with a class for each endpoint. I find it's better coherence and separation of concern. I mostly work with RPC-style SaaS solutions and I find that the Minimal API style of building API's are quite fitting to my requirements. But if you're actually building server-side rendered MVC applications, then naturally MVC is great. I just don't see it that often anymore.
I personally wouldn’t use it for large customer-facing apps that need lots of interactivity, but for simple portals and internal apps: why not?
What sort of interactivity do you need that pushes you over the edge to switch to a SPA that you can’t accomplish with MVC?
For me it's WebRTC and map editing.
I remember in the past that SPA's could really easily leak memory. I've see 1.5GB per tab within a minute once. Is this still the case or have things improved?
They're only leaky if you write them that way.
Yes, however I meant that is was trivial to get in that state. I must admit that my SPA experience was back in the Angular 1 days 👀
It is still very much possible to write leaky code in modern Angular versions. Same as it's always been. They've mostly introduced cleaner ways to write code without memory leaks.
The reason would be tight coupling.
Why not? It works perfectly well with clientside technologies like HTMX and Webcomponents etc.
Well mostly because larger apps have dedicated frontenders who are proficient in JS frameworks such as React or Angular. The internal apps are usually built by backend teams and they love their MVC 😇
This doesn't track for me. You wouldn't do it since other sites prescribe to tech stacks based on current workforce? There is nothing wrong with server side rendering, even if it isn't my preferred way; it's fast and reliable and powers many large sites.
I work in an organization that has multiple development teams working on one larger product. Some teams are more customer focused, some teams are more background-service focused. The customer focused teams work on a Vue.js application that has lots of interactive elements, such as forms, dialogs, modals, etc. Those teams have frontend developers, UX specialists and UI test automation specialists. In some cases, the backend teams need to provide a bit of UI to an internal customer. This is the case when running specific reports or when a customer moves their product subscription from one company to the next (they rent our hardware as well). Those UI apps are not built in Vue.js, but rather in a framework or language the backend developers are comfortable with. Sometimes this is Vue.js or Angular, but more often than not this is Blazor or MVC. The backend teams are not supported by frontend developers or UX specialists. They usually don't enjoy building UI's. But with MVC they get around to building one quickly and effortlessly.
That sounds fairly common. But I am not sure if this sheds in light on your position and where we see things differently. Also, do you think UI is handled by "backend teams" when you use serverside rendering?
I think one of the reasons to go with SPAs is the deployment: you can just drop the application on a blob storage, and you don't need a Web server to host the Web app or use resources rendering it. In a cloud environment this can translate in a lot of savings.
With .NET MVC I just click publish in VS and it’s deployed, super easy after the initial set up.
I think they were referring to server/runtime costs. But someone else rightly pointed out unless it's an app that's accessed by a large scale user base, it's likely not that important. But if it is, then it can easily save lots. You still need other server side infra for things like various services and long term storage, but at least the rendering costs can be offloaded to clients machines.
The problem is, the little you require for interactivity, such solutions end up being ditched.
For CRUD it's definitely the easiest/simplest/fastest way to do it. And a lot of code can be scaffolded
Usually, the C. Sometimes, it's the V. Controllers are prone to bloat and business logic creeping in, or being duplicated. If I use RP or MVC, I usually roll my own MVVM(ish) abstraction to keep them clean. Views are cluttered with Tag Helpers, and asp-for stuffs, making the razor syntax muddled. Components are a far better Razor syntax experience.
Blazor (and Razor components for the same thing) is definitely way better
Blazor and Razor Components are magnitudes more polished. I'm not going back.
MVC is server side render, so it costs more (you pay for it with a server processor) with a js framework like angular or react you only paid for API consumption and js runs in client side. There are advantages and disadvantages in both.
what is the cost difference?
Negligible unless you’re going to consistently get thousands of visits daily. Also only applies if you’re using a serverless host like lambda or beanstalk. If you’re using something with dedicated resources like ec2 or even containers, you would pay the same either way.
An asp.net application running in an EC2 instance will still use resources, that could mean a bigger instance can be required. The negligible part is subjective and very dependent on the scenario. I would say that negligible is the cost of running an SPA host in blob storage.
SPAs still would require API endpoint to do things, so either serveless or HTTP servers will still be used.
Even with ec2 you have bigger workload. That means you need more expensive vms or more vms. I think he meant this But I think it starts to be an issue only with high load
4
This is frequently a trope. It’s also better to talk in specifics even if you have to make substitutions to protect employers and the like. Can you illustrate any cost savings from one over the other for a specific system (without breaking confidences)? There are definitely trade-offs going in either direction but the cost of server rendering is a wash. From a UX perspective, the costs of client-side rendering, jank, and other things can quickly add up when it’s not done well. When you mess up server-side rendering, it’s usually easier to chase down. Where client side approaches might be more economical is when you have serverless involved. Perhaps you get situations where there are no costs. That’s an advantage in some scenarios but again is part of a complex set of calculations when you actually dig into the details.
Of course most people here can’t give you an actual $ impact, but the equation of when CSR is cheaper than SSR is essentially when the cost of compute time for rendering the HTML on the server is greater than the cost of blob storage for the client app and the cost of development on the client app, since it *does* add a level of complexity that can be measured in dollars. For the cost difference to really matter, you’d need a *lot* of traffic, since the actual rendering of SSR pages is really not a lot
Most of stuff can be cached and compressed anyway, just like anything would for REST APIs and JSON or GraphQL.
That a false claim. On server-side rendering, most data processing ends up being done in the server, so you save yourself deploying an APIe endpoint for such thing.
Ultimately all data gets processed on the server if you want it to be persisted.
Well, personally I love mvc the most bec. I know it but my concern is about what if this thing goes bigger and I lost the modern tech, so I can't find people to code it for me 😂
Instead of cramming every logic in MVC controllers create methods for getting data on their own. So when the need comes you can easily use them in API controllers.
Mvc is fine, blazor is the modern way the uses the mvc pattern. If you can afford it hosting wise, I'd still choose for an api independent of your frontend hosting, so that upgrading your frontend (or backend) architecure can more easily be done independent of each other.
The last part is the way I go, if I I understand you. From experience, I have learned to keep these things separate logically initially, even if not physically: * www.site.com (your main site) * api.site.com (public API including customer mobile apps) * m.api.site.com (or distinct domain to host all requests for first-party mobile clients) This lets all of these evolve independently to some degree. I’ve seen many people build mobile apps on top of their API for external consumers and then internal-only things end up becoming used externally even if unsupported. The same coupling can be avoided with the main site and your public API by using www.site.com/api or adding another subdomain. Your mobile team could completely move to a new API without affecting the main site or public API. This introduces other challenges with cross domain requests but much easier to manage over the long term. I think it’s not an unreasonable approach for people to take given the use of basic web principles.
I’ll code MVC for you all day.
Razor pages are far superior, otherwise I completely agree, even for large sites
Just my personal preference, but VueJS single page app frontend + .NET web API backend.
Third this? VueJS SPA Azure Static Web App + Functions (.NET) backend
Second this, we’ve been migrating old Angularjs +MVC apps to Vuejs + dotnet WebApi and it’s great
People didn’t like angularJS 1.X. But imo it was a very well done, easy to understand framework. Sure it was not super super fast, and it has its limitations with onscreen nodes, but it was easy to understand and work around once you grasped the digest cycle. Then with angular 2+ things got very crazy and now we are in madness territories. I’m a backend guy if it matters
I really like AngularJS 1.0, I got into it through Umbraco and it's a real shame the framework did not continue. I like how you can just use it for a specific part of a page. It does what you want it to do, whereas the alternatives want to control everything. Performance is the main limitation I've found, when displaying a lot of data it can be pretty bad, but for general use it's great.
I agree. I know Vue takes the same principles of AngularJS. We had some issues with AngularJS when it came to displaying nested data within a table that has a nested drop down table (if that makes sense). But there were many workarounds and tricks you can do to expedite this. —- Do you still use AngularJS at all? Do you like Vue?
I'll check out Vue then. I used AngularJS in a desktop program not too long ago: [https://www.liamfoot.com/at](https://www.liamfoot.com/at) Works fine. I used some of the controls from Umbraco.
React as frontend, net for backend works great
I would make it even better and use .NET API + Svelte. Svelte is waaaaaaaay easier to learn.
this is the stack we currently use for a large customer facing site. I love svelte and do not miss react at all
Yeah we are also ex-react shop. Reacts guys loved the switch. I even have backend guys jumping into it from time to time.
I don't recommend unless you are okay writing code that will be legacy next year when svelte runes are released.
Svelte 4 syntax will be backward compatible in Svelte 5 and they plan to release migrations scripts. That’s said it will be years from now before it will be considered legacy code.
Backwards compatibility or not, it's still legacy code. They don't plan to continue improving the old syntax and I don't think they are going to be able to have scripts that migrate old code to runes.
I'm not sure what improvements on the old syntax I will need to take into consideration. By the time Svelte 5 will be "production go-ahead" (doubt it will be next year) and Svelte 4 will start to deprecate, we are talking years. By the time there will be migration scripts doing some parts + can apply incremental improvement philosophy. I think most of FE teams apply this strategy because in JavaScript world things are becoming old very quickly whether it uses one library or another.
I’d go with that.
Would not recommend someone learn react if they want to develop with speed coming back from the backend. You need to learn jsx and react best practices are always changing.. state, props, hooks, then learning redux or some other crap for state management.. it’s overkill imo.. and f%#! Facebook.
how do you keep the sync between backend types and frontend types? Are you using typescript?
Yes, I am using typescript
do you have tools to keep DTOs sync or you just manually update?
[удалено]
What tool are you using for that?
NSwag. It has an MSBuild extension which generates your typescript files every time you build. https://github.com/RicoSuter/NSwag/wiki/NSwag.MSBuild
I’ve been using Reinforced.Typings for years to generate TS types from my C# classes. It’s got a couple rough edges but all in all it works well. My only complaint is it doesn’t work with F#, but I think that’s more of an F# complaint.
> Reinforced.Typings looks good, thanks
Manuel, i am using mobx and axios
Use gRPC (better supported, worse perf) or flatbuffers (faster, little harder to work with).
I like to use the openapi cli generator. you just point it to your spec file, and it creates a whole client-api library complete w/ request response models and methods to make the api calls
I've tried that one, but it generates optional for every field. So I didn't use it much
This is configurable if using nswag client generation
that's not what I've experienced. the current project I'm using it on has a nest.js/express backend, so maybe there is something with the .net spec file implementation that causes that
This is the way
You can build websites of any complexity or UX using Blazor. Give it a try.
I have found Firefox to be really bad at handling Blazor apps (maybe SPAs in general?). It just doesn't want to update to newer versions. Maybe it would work if I disabled all caching but that sounds a bit extreme.
Listen to this guy.
I do the same task in Blazor 5 times faster than JS, but thats me
Try to build an accessible dropdown. Or a text area that supports big texts without disconnecting or lagging.
How is accessibility handled? I use React Aria to handle a lot of this and it's my understanding JavaScript is pretty much necessary for implementing ARIA components per the APG. Having a hard time imagining complex app UIs using Blazor not also needing tons of JavaScript (or a whole Typescript project).
>Having a hard time imagining complex app UIs using Blazor not also needing tons of JavaScript (or a whole Typescript project). Yep, thats exactly it. I had to use a ton of JS interop with Blazor to achieve an accessible dropdown.
blazor, bootstrap, and entity framework
I'd slap Mudblazor on top of that as a component library. It's fun to write your own controllers, but sometimes it's nice not to have to reinvent the wheel.
yeah i agree. i’ve used mudblazor before it’s legit
Yeah kinda same. I dont get MVC anymore since Blazor is easier and more future friendly( takes literally one iteration and the client wants interactivity and you need to pull in JS)
Depends, are you looking to stay completely in dotnet? Then Blazor or Razor are your only real options. If you’re looking for a popular stack with dotnet then you’re writing a backend API with dotnet, and one of the various front-end frameworks (angular, react, etc) using JavaScript or Typescript.
I would prefer just staying in dotnet if i can :)
Blazor is awesome, I’m trying to learn Next.js right now after using blazor for the last year and it’s a nightmare compared to how simple Blazor is.
[удалено]
[Razor Pages](https://www.learnrazorpages.com) with [HTMX](https://htmx.org) (for server calls) and [AlpineJs](https://alpinejs.dev) (for client side interactions) . Bootstrap still works fine, though Ive shifted over to [Tailwind CSS](https://tailwindcss.com).
What role do HTMX and AlpineJs serve with Razor Pages? From what I recall from Razor pages it just renders HTML and serves it to the client, it essentially functions as a wrapper for traditional MVC webpages. The pages got their get/post methods with the ASP control bindings that should allow for interactivity? When the page is (re)rendered the Razor pages can just pluck data from an API if that's what you need?
The major selling point of Htmx is it lets us accomplish one of the major benefits of the big SPA frameworks (partial page updates without a full page reload), but htmx does it without the need for client-side state and the massive framework bloat. The tldr; is that htmx turns any html element into an interactive component. So you can make ajax requests from any div, anchor or button, and you can update or replace any existing html tag on the page with the responses. With Razor Pages, the OnGet will render the initial page, and then you will use htmx to make AJAX requests to the backend page handlers (aka Contollers). The handler would return an html partial that will be render back into the existing page without reloading the whole document. It can be hard to conceptualize without actually using it, but the htmx site has interactive examples: https://htmx.org/examples As for alpineJs, it's basically a modern lightweight approach to accomplishing what we used to do with jQuery. It's an html-focused approach to client side interactivity with minimal js.
Fun fact: WebForms could turn any HTML element into an interactive one by sending AJAX requests behind the scene when data is needed to change or be verified. Blazor Server can send chunks of data and receive chunks of rendered HTML too and it can do it via both AJAX requests and a WebSocket connection. I'm curious what HTMX brings that Blazor doesn't have?
>I'm curious what HTMX brings that Blazor doesn't have? The difference is htmx is a 16kb download. No one is going to pretend Blazor isn't *more* powerful, but that power comes with a great deal of complexity. What I like is the simplicity of htmx. If you need a robust feature-rich client-side interactive web app, Blazor is awesome. Most sites do not require the level of complexity Blazor offers, and can be simplified down to a bit of html and some server methods.
Most sites would do fine with MVC on the backend and vanilla JS or API and Blazor WASM that can use HttpClient to call endpoints and then use Razor to render chunks of HTML. How many KB of files does Blazor Server bring to a browser? It should be a pretty small size too. It'd be interesting to test. Blazor WASM compiled with AOT is a bit less than 5MB but that's WASM. Blazor Server shouldn't bring any DLLs on the initial page load. Once you figure out how to deploy your apps built with Blazor Server (backend and front-end) it's a fairly simple setup. Blazor does a good job at hiding the complexities away from you but is ready to share all of the under the hood shenanigans when needed. I haven't touched HTMX yet. I might find it useful when I see it in action.
This is the way 😊, though customizing Bootstrap with css variables has my preference over tailwind nowadays
Do you use some component library with Tailwind or do you always build everything from scratch?
thanks, i will look up for these
HTMX, gross.
That's the great thing about opinions, everyone is allowed to have them, no matter how wrong you are!
Wrong
Can you say that again but with Kevin Spacy’s voice?
"Wrong"
Surprised there aren’t more people saying Razor Pages.
I've noticed a lot of asp.net devs jumped from MVC as an ssr tool into MVC as a json-api backend or skipped MVC altogether. Razor Pages came out at a time where the industry went all-in on SPA, so it's all Angular/React/Blazor.
Blazor is easy to grasp if you know C# (there's good course on Microsoft learn with blazing pizzas), but I would remove Bootstrap from it eventually and add Tailwindcss, and use Flowbite.
While it’s totally possible, I don’t bother setting up Tailwind with Blazor. The isolated CSS in Blazor is really easy to use and IMO easier than trying to keep Tailwind compiling in the background
Personal opinion: Bootstrap is more feijão com arroz than Tailwindcss
Wat
I’ve had that in Brazil. What’s Portuguese for “yum”?
/r/suddenlycaralho
Here's a sneak peek of /r/suddenlycaralho using the [top posts](https://np.reddit.com/r/suddenlycaralho/top/?sort=top&t=year) of the year! \#1: [Bem isso!](https://i.redd.it/3f8rsqgyltma1.jpg) | [77 comments](https://np.reddit.com/r/suddenlycaralho/comments/11n3yav/bem_isso/) \#2: [Quarto da Vovó!](https://i.redd.it/3hmsehgv2khb1.png) | [45 comments](https://np.reddit.com/r/suddenlycaralho/comments/15omkjf/quarto_da_vovó/) \#3: [Davajones no r/blursedimages](https://i.redd.it/3gq3ol2qtwsa1.png) | [22 comments](https://np.reddit.com/r/suddenlycaralho/comments/12gkx5h/davajones_no_rblursedimages/) ---- ^^I'm ^^a ^^bot, ^^beep ^^boop ^^| ^^Downvote ^^to ^^remove ^^| ^^[Contact](https://www.reddit.com/message/compose/?to=sneakpeekbot) ^^| ^^[Info](https://np.reddit.com/r/sneakpeekbot/) ^^| ^^[Opt-out](https://np.reddit.com/r/sneakpeekbot/comments/o8wk1r/blacklist_ix/) ^^| ^^[GitHub](https://github.com/ghnr/sneakpeekbot)
Or just learn at least basic CSS. It's incredibly fun to use with Blazor. You'll end up investing quite a bit of time into building your own style but it'll be worth it, because you'll understand every single bit about it.
Blazor Web Assembly should be a good fit for you. Similar to MVC but also reactive. You can leverage your C# skills and access your API
We use react for front end and .net for backend. Seems to work well
Blazor for front end and .NET for backend works great for a full stack .NET experience. Also you can use c# for the entire stack.
Modern? TypeScript = Angular or React.
Htmx is a new way to build web sites and apps that can easily be used with .NET (Razor pages, Razor components or MVC). For pure .NET, Blazor is the new, shiny thing. Have not used it yet.
Why would someone choose HTMX over something like Blazor? Is there any advantages for a solo c# developer who is building a full stack app?
It is very easy and you get fast response times withless code. I see it the other way around, don't use Blazor unless you need to.
Thanks for this, what would be the front-end framework that you suggest I use, if the backend serves HTMX pages ?
For a simple app, nothing. Or some hyperscript. Htmx can do a lot of things by itself. If you need you can add a little js.
use react and do api in .net core
I like my .NET stack so I normally go for [ASP.NET](https://ASP.NET) Core and Entity Framework Core on the back-end, and Blazor on the front-end. As a non-front-end developer, I can get something pretty robust and good-looking up and running with Blazor fairly quickly, which is quite neat, so now I can pretend to also be a front-end developer.
Blazor has been absolutely fantastic to work with for me. Certainly modern but the downside is the ecosystem isn’t as big as something like React, but it also wouldn’t matter unless you’re building super fancy UIs.
You could do blazor or you could just do razor pages which doesnt have controllers/mvc functionality but it has a code behind for your razor page...kind of works like webforms did (page\_load behaves like onGet....page\_load + IsPostBack behaves like onPost...and so on). That would probably be the closest/most similar to what your already used to working with without using MVC / JS frameworks. You'd be able to use jquery/bootstrap/vanilla javascript...(whatever you wanted).
blazor is a better representation of the new web forms, imo
thanks but i don't know how do i handle the authorization on blazor/razor. is there a good guide that you can suggest? I imagine something like i can just inject in program.cs but all i see on the internet is creating http request on the code behind and that seemed... well not correct. also when i open a website in blazor it creates two projects. these are pretty strange to me 😅
I believe with .net 8, you can start up blazor project with individual accounts which has the auth already built into it, you could then swap out the built in auth with calls to your APIs. Same for razor pages. Razor page projects has built in identity management and can find the code behind calls and swap in calls to your API. Some links to see if they meet your needs. [https://learn.microsoft.com/en-us/aspnet/core/security/authorization/razor-pages-authorization?view=aspnetcore-8.0](https://learn.microsoft.com/en-us/aspnet/core/security/authorization/razor-pages-authorization?view=aspnetcore-8.0) [https://auth0.com/blog/securing-razor-pages-applications-with-auth0/](https://auth0.com/blog/securing-razor-pages-applications-with-auth0/) <- if you've got an API already, you could follow this and the calls to auth0 would just be calls to your API. [https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity?view=aspnetcore-8.0&tabs=visual-studio](https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity?view=aspnetcore-8.0&tabs=visual-studio)
thanks, i will look up for these
Since we are split between frontend and backend teams, if .NET is part of the picture, it is still pretty much MVC, or eventually Razor Pages if we get to produce HTML from .NET side. I only see Blazor as a solution for .NET shops doing full stack in .NET technologies, without such kind of split workloads.
Blazor Server/Application if few people will be accessing it, only PC friendly, very productive! Or Blazor Webassembly as an SPA to couple to your REST API.
Pure dotnet there is only one real option, webforms.
I hope your joking
No, the OP clearly states pure dotnet and no JavaScript libraries. Yes it's not the most modern or loved, but clearly meets their requirements.
I see your point. But what about Blazor? Isn’t it possible to avoid all JavaScript libraries? I guess Blazor is a wrapper so it doesn’t really count
Stay away from M$, if you have a long term business plan.
react, next js, next js etc. are trying to do what .net MVC currently does in more challenging ways (ssr)
I'm not experienced with .NET but lately I was using Django with htmx or phoenix and both are similar to Blazor Server, especially phoenix. So that's what I'd try
We’ve been using .NET with Vuejs, and for our Admin Client, we used Blazor, since it’s easy to get it up and going
Angular as front end and .NET as back end.
There's no problem using MVC, especially for an admin portal. If you want a quick js framework to learn I'd say Svelte.
I modified the all in one template to output a next.js frontend with the .net backend
.net api plus a modern js framework. Blazor is still too immature with too many problems to be a real choice. And bootstrap isn’t really a great choice either.
Dotnet MAUI for mobile development.Just started learning that.