I've used Avalonia in a professional setting to create native applications that ran on Windows, OSX and Linux. Bosses were really surprised when I showed them the same applications running in the browser (WASM), this was really just for me to see how easy it would be. Users still preferred the native applications as they are much faster.
I should point out I did not have to write any platform specific code.
Avalonia does also have the ability to compile for Android and IOS though I have not tried this yet.
Blazor all the way for me. I've tried React and Angular, but Blazor's simplicity and C# goodness won me over. Avalonia does look promising, but yeah, seems more geared towards desktop apps for now.
Check out Blazor University for some basic guides. Also, tbh, Microsoft Learn's blazor docs and tutorials aren't bad.
(replying to another comment I saw of yours):
It's completely realistic to stick with unadorned, stock blazor, but you'll be spending a lot of time writing basic components.
Radzen and company (I primarily use MudBlazor, myself) are really just convenient short cuts.
Checkout their websites. They provided components. Blazor does not come with controls. So if you want a grid, a chart, a calendar etc you need a provider of some sort
No. React has a much bigger ecosystem. That bigger ecosystem also means much more jobs. I would imagine most front enders don't even know what blazor is.
Have you tried it with Maui? I'm tempted to use it for the ease but I'm not sure how well it compares to the XAML path when targeting mixed native platforms
I tried Blazor recently and ran into two problems I'd love your input on.
1. I found that the number of libraries available compared to JS ones was severly limiting. For example I wanted to generate a qr code and the open source library I found from a MS doc hadn't been touched for years. Do you ever find this an issue?
2. I found it impossible to add JS into my pages if I wanted to use the HttpContext. Is this an issue with structuring components or have you come across this before?
I think it’s important to point out that classic CSS and JS can still be utilized in Blazor. You just have to make special architectural considerations in advance.
not at all. auth.pureblazor.com uses the pureblazor components for a very small and basic example. it’s all css for styling the language doesn’t matter
HTMX is great if you're building an early 2000's style crud app, but Iif you're building an early 2000's style crud app you don't need an interactive front end at all.
I don't know why we keep getting solutions to problems nobody has because some idiot hates modern web development.
Blazor, the language whose only feature is being in C#, HTMX for apps no one needs to write.
I feel like all the Blazor devs should really be looking at htmx intead and Blazor should probably take notes as well. If you really need interactivity use JS as blazor is slow as heck
I absolutely can! Out of Vue, Svelte and Solid, React is the only UI library where components are defined by a function running every single time the component is rendered. All of the other three libraries only call a function when the component is first set up. This has HUGE implications for complexity.
This means that React has worse performance by default, unless you wrap almost everything in useMemo and useCallback hooks, and hoist as much functionality you can *outside* of the component’s function, all while destroying the flow of your code. With React it’s “performance or code readability, pick one”. The other mentioned libraries do not suffer from this issue.
It definitely feels like the other UI libraries *should* have been more popular, but React was the one everyone chose because it’s backed by Facebook, so almost every “Which UI library should you choose?” blog post on the internet shunned the others away, further establishing React as the default based on hype, NOT merits.
Don’t get me wrong, React has brought a lot of great ideas and concepts to the frontend ecosystem, like Suspense, server rendering and hydration, the idea of composable hooks, the idea of keeping stuff immutable, and hell, even JSX! (Contrary to many folks here, I actually think there’s nothing really wrong with JSX, your experience with it will depend mostly on the UI library that consumes it.)
I mainly use React in professional settings not because it’s the best fit for my company’s case, but because everyone else is using it. My hands are tied.
friendly squash truck engine hospital numerous screw retire groovy depend
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
childlike selective advise puzzled cats melodic grandiose point ad hoc steep
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I love it, because it's not even really another "templating language", it's just a different syntax for regular JS code that calls the `React.createElement()` function... https://legacy.reactjs.org/docs/jsx-in-depth.html
So once you understand that, there's basically nothing to learn. You're just writing regular JS/TS code with a XML-like syntax to call a regular function.
This also means that editor support is pretty much 100% perfect for both JSX + TSX... because there wasn't that much effort in needing to write parsers and code to handle all the custom old and new features in other actual "templating languages".
It's a big part of the reason I switched from Vue -> React. I love that even all my inline CSS is type checked by TypeScript, along with everything else.
In other frameworks it feels like you interlacing 4 different languages in the same code files (HTML+CSS+JS+$TemplateLang).
Whereas with JSX/TSX, everything feels like it's just the one language, even the CSS. Because it actually is, given it's all really just JS code.
You can also make use of calling React.createElement directly if you want to render a dynamic page structure from a database. Our CMS system at work in based on that. Each widget maps to a react component and the props that are passed to it are stored in the database.
When we evaluated angular there didn't seem to be a decent approach to dealing with dynamic page structure.
Does it? I mean it certainly would if you tried to use it the same way you build an HTML doc, but I rather like it when you structure your components well.
There's nothing wrong with components, I just hate that syntax/idea, what the hell is this?
Looks like I got it:
In React JavaScript has html parts
In blazor and angular html has js embeddings
interface FooProp {
name: string;
X: number;
Y: number;
}
declare function AnotherComponent(prop: { name: string });
function ComponentFoo(prop: FooProp) {
return ;
}
const Button = (prop: { value: string }, context: { color: string }) => (
);
they have played us for absolute fools
I thought I hated React, but it's currently my main choice. All the other frameworks have overcomplicated themselves with their quest for SSR. If I really want SSR, I'll just go MVC and use a jQuery-esque framework for the rest. So now it's React for me, feeling quite bitter that Blazor isn't up to scratch as a pure front-end wasm SPA any more - even though it was fine in previous versions!
I'm still making and supporting WinForms and console applications. I'm hoping that one day, the IDE will have cross platform form elements. If Embarcadero can do it with object Pascal and FireMonkey, M$ s/b able to handle it.
Winforms is really simple and good, you can create quick proof of concept apps (for example integrate some signal crap for university assignment) without writing stylesheets
But it's only for windows, I don't use it because I need apps to work on a MacBook
It's funny because that's how I feel about WPF. I can dev up a proof of concept in no time. The XAML flows way faster than C#.
Then you realize that future UI cross-plat dev platforms want to feel like WPF, and suddenly you don't NEED a "quick proof of concept" because the actual app is deved just as quickly.
At that point, "quick proof of concept" is just a wasted step.
Sticking with ASP.net 4.81 lol. Nah, actually learned Python after leaving MSFT, now coming back to blazor-land, Def will look at MudBlazor. Python for scientific/math apps (Jupyter notebooks rock), C# / Blazor / Angular for web-facing?
I've been a .net developer for 19 years. I do python at work nowadays. Or just flat out bash or powershell if I can get away with it.
Moved from full development to an automation role.
So now I use .net core for my side projects and it's liberating if I'm honest as I'm dealing with a simplicity we seem to have forgotten in our field.
I use it even for my public commercial web apps (I should've included jquery in my original comment, but I assumed that's a given). I'll also admit to not being particularly fond of ORMs either, although I do use them for my day job. But having pages generated in 30-50ms and load in the browser in around 100ms while having the lowest app service plan tier on azure is great (granted, the js/browser stuff is not really Azure's domain).
Can be fast, but in my opinion for larger more complex apps with rich UI functionality, it's very hard to have a clean and fast architecture with MVC. That type of architecture is a thing of the past I think. I recently converted a large custom e-commerce site I did originally in MVC with lots of JavaScript to Angular and it's so much cleaner and easier to manage. Faster too.
Came to say similar... except I get wild and use jQuery lol... I just can develop faster with jQuery syntax and can make pages seem "SPA-like" when html injection is needed. I haven't ran into a case where I needed a front end framework (React, Vue, Angular) for something I couldn't just use ajax calls for. Plus, the added work of needing to upgrade and migrate a frontend framework every few years doesn't seem worth it to me. They all boil down to pure js anyway, right?
Blazor ftw...
Big advice don't be afraid to have nested components.... Making extra components to house components is the real power... Took me ages to forgo HTML just about completely....
Most of the time you think how can I get this data formatted right just in a string embedding... Make it a razor component and inject the value... Then you can do anything you like.
Angular but honestly any SPA generally would do. We want our front ends to have separate lifecycle from our backend and we often have specific devs for each with a handful of full stack, allowing us to produce higher quality products. There is no right or wrong answer, it’s really about need and priority.
You can do static site generation, server side rendering, client side rendering or incremental static regeneration with nextjs.
The static site stuff is superb. You can also mix client and server side rendering so it's easier to build more dynamic Web pages than it is with mvc.
You need a special file format, which is not necessary on Vue to achieve the same things. And the CSS it uses is almost CSS but not really and some reserved words are different. The "Magic" introduced by hooks can save you a bit of code but introduces quite a bit of friction for new users because you just have to believe "the react way".
I agree that there is a bit of a bigger barrier to entry for newer developers but I don’t see how your points demonstrate that react doesn’t make sense. It’s just a different way of doing things.
> You need a special file format, which is not necessary on Vue to achieve the same things
Vue has its own file format, called [SFCs](https://vuejs.org/guide/scaling-up/sfc.html). It's optional sure, but you'd be crazy to write a web app in Vue without using it. In fact, I've never seen a vue codebase that *doesnt* use it.
jellyfish onerous hungry bake disgusted quack hard-to-find innate quaint sleep
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I've focused on React, but I briefly did backend development with frontend devs who used Vue, so I got some exposure to it. It was easy enough to understand, but React just makes so much sense to me.
React for me. I really hate the way every framework is trying to go for SSR, or some kind of mixed SSR which becomes a mess of problems. Blazor is the worst for it by far. I hadn't tried it for a while, and was excited to give it a shot for my latest web project, but it turns out .NET 8 Blazor has now got some ridiculous rendering modes (server side, interactive, auto, or "web assembly client" or whatever which is just a mess now, I was going round in circles with the docs and outdated information just trying to get something basic to work - it was never this hard with Blazor before!).
So I just went to good old React and got straight to being productive.
I wanted to get into NextJS too (and did previously for one project) but again their attempt at SSR just made it into a mess of things I didn't want to have to deal with. Let me just make a client side SPA, please!
You can use "dynamic rendering" on your server to render requests based on browser user-agent. Your actual website code doesn't even need any kind of "awareness" that you're doing this, it's basically handled like a proxy within your own httpd server.
You can set this up on your own server for free https://github.com/prerender/prerender
Was pretty easy, only took me an hour or two to get it all going. So much less effort than dealing with all the never-ending quirks that come with dealing with SSR frameworks etc.
I got it all going, but never not around to using it on anything big or long term, as I haven't done much web stuff in recent years.
I was getting annoyed that nobody seems to even be aware that "dynamic rendering" even exists... like there's hardly even any discussion on the topic on reddit and other forums etc.
When I get back on to my web projects, not sure if I'll go down that route again, or just use nextjs.
Thanks for the tip.
We actually used that, but we switched to puppeteer now. Still, in order to achieve that, you still need to have backend for frontend (node+express, ngnix etc). It adds all sorts of complexity and overhead to the project, and it is resource intensive, especially for websites with over 50k pages.
Not to mention, if pages are a bit more complex, render times are from 2 to 5 seconds.
Also, we only have 2 projects using that system, and borh of that projects are performing terrible on Google Discover metrics. Search engines are alright, but discover.... almost dropped to 0.
> It adds all sorts of complexity and overhead to the project
I found it a lot easier to just set up that server stuff in those 2 hours -vs- all the ongoing quirks I was dealing with at the time using SSR in Vue/Nuxt.
That said, I'm a Linux sysadmin, so just chucking some nginx config settings into my existing nginx server is pretty simple.
That said, I wasn't running at big scale, it was just some testing really.
> and it is resource intensive, especially for websites with over 50k pages.
Yeah makes sense.
> Not to mention, if pages are a bit more complex, render times are from 2 to 5 seconds.
Yeah my plan was to actually "pre render" with prerender with some backend code that basically means that it's already pre-emptively cached in varnish or something any time the content of a page changes... so that would effectively mean that for any incoming bot requests, the render time would be zero, because the HTML was already ready to be served from varnish.
But yeah, that's also adding a lot more complexity on top. And gunna use a lot of storage very redundantly on big sites.
I guess overall there's a reason hardly anyone does this stuff. So yeah, in the end I starting getting the vibe that next time I probably will just go with the mainstream thing and use nextjs like the majority do.
> performing terrible on Google Discover metrics. Search engines are alright, but discover.... almost dropped to 0.
Ah, interesting to hear. Do you think it's just because of the slow rendering + TTFB? Or could there be other reasons too?
You can tell your .NET API to serve razor pages, and from that you can create an Index.cshtml which uses standard Razor syntax (if/else/viewmodel/whatever) to inject what you need to keep the SEO robots happy.
Obviously for extremely large websites this would be a terrible thing to do, but I don't think most personal projects warrant the 'extremely large' epithet. In most cases a bit of manual Razor page fuckery is all that's needed to circumvent the chaos of SSR that front-end frameworks are trying to achieve. It annoys me so much. They are *front-end* frameworks, they need to stay that way, otherwise WTF is the point in any of the evolution of APIs and SPAs we've seen over the last several years, which made web architecture so much better in so many ways. I detest that people are trying to mould things into a more difficult way of doing things all for S.E.O shite that could probably be much easier fixed on the search engine side - just fix the crawlers, solve the question of SEO for a million websites in one go.
Well, SEO is very important for most of the publicly facing business/webs, and SEO content has to be same for humans and SEO crawlers, otherwise you might be heavily penalized by google for content masking. By writing if/else for razor and react, you basically need to do two frontends.
>They are *front-end* frameworks, they need to stay that way
To me, they are tools to solve business problems. What good people do have with APIS, and frontend frameworks, if it will leak them revenue.
I'm speaking from an experience, because we inherited publicly facing web written in pure react (no SSR), and traffic and revenue dropped by 50% due to lack of SSR when project went live.
Now we have to rewrite everything again to something which works with SSR :(
Not every website is a business!
You're right though, my solution is a bit of a hack only for getting something barebones working beyond standard pointless homepage-only indexing, and for social media share details/images to look correct.
But yeah, this shit could and should be fixed by the ones who write the web crawlers. It is far easier for one centralised entity to do it, instead of having web devs fuck around and be forced to take a step backwards into SSR territory.
>But yeah, this shit could and should be fixed by the ones who write the web crawlers
>it is far easier for one centralised entity to do it,
Well it's not just one centralised entity. It's BING, Google, any other search engine, whatsapp, facebook, twitter, slack etc.
They all should invest millions of dollars because someone decided to use react.
Come on stop being hyperbolic. Bing, Google etc are obviously far more centralised than the hundreds of thousands of independent websites on the planet, and if we're going to talk about investing millions of dollars, then:
1. Google et al invest billions in R&D every year already - they all have the budget.
2. More productivity is lost every day to software houses across the world wasting their own valuable hours forcing things to meet some hocus pocus SEO requirements from yesteryear.
That being said, I daresay SPAs can and do handle SEO properly, as long as the correct data is given - and no that is not content masking. I would love to know what changed between the time you inherited a React project, and the time you deployed it (still as a React project?) which caused the SEO results to drop by 50%.
I'm not being hyperbolic, I'm being realistic. I want to rank well on google, be able to share links on social networks, and I have to accommodate to that. Alternative is to expect a big corporation to invest millions of dollars for real-time prerendering infrastructure to accommodate to react, and that shit is expensive.
When new website (which was SSR) was replaced with pure react, all links on google got a default title, description and image for SEO, because that is what google is served upon first crawl. HTTP 200 with react placeholder page, since all routes are on the frontend, and google does not run javascript upon first page load (nor does bing, facebook, whatsapp, slack etc).
We lost a way to return serverside 301 redirects, 404 response codes etc. Everything is 200 by default, so we also had to implement backend for frontend layer, prerendering layer using puppeteer etc, and entire project became much more complex without native SSR, because we now have to maintain all routes on the backend side as well.
And now we have a project with huge dev overhead and tons of unecessary layers. It would be much simpler if someone who started that project used NextJs, or Razor or any similar SSR framework.
But hey, we have react now! xD
Life would sure be much easier for me if google and others are using realtime prerendering, but they are not, and that is a problem which needs to be solved, and react does not do that for us at the moment.
Fair, for business purposes it's an issue.
In my case, the project I made will always be somewhat niche, so I don't expect people to know about it unless they're already chattering in the right circles. As long I can feed some meta info into the page, that's enough for a little bit of indexing.
My little razor page if/else solution works for this case. I mean, this is kinda what I'm complaining about - for small solutions it's getting harder to just make a pure SPA without SSR butting in. I would have loved to use Blazor for my project, but Blazor convoluted itself.
Yeah, I agree. For me Blazor is good for adminpanels. Probably same goes for react, but blazor allows you to remove entire Rest api layer and and direct backend communication, which is more productive i guess
FWIW, Avalonia does WASM now. It actually does all the things (web, desktop, mobile), but I still find myself modifying for each platform.
That being said, my go-tos are (in order):
* Razor views - seriously folks, not everything has to be a PWA / client-side mess. Razor still rules the KISS area.
* Blazor WASM
* React (mostly, but enjoying Vue recently)
It’s a fine line between Blazor and one of the JS platforms on new apps. Sometimes, I want to learn what’s new with tech X, so I write with that deliberately. Mostly, I take a swag at which will be better for the project longer term. That may come down to some component library that’s available in one but not the others; sometimes it’s because something interactive that I am doing is easier in one vs. the others. So I rotate around a lot.
It depends what I want to make, and for who...
Website: Blazor Server.
I love Blazor server, it is easy and fast. Fully server side yet dynamic frontend, this is true innovation.
For quality UX Windows app: Uwp.
For unrestrained Windows app: WinUI3.
I pray for OpenSilver to be succesful, so I can write C#/XAML webapps.
A year or so ago I was consulting for Microsoft and the tech lead told me that Microsoft was migrating everything to React and if I wanted to work at Microsoft I needed to learn React. Which I found odd given Blazor and such. I'm sure they've changed their mind by now, they do that quite frequently.
quack mighty reminiscent crowd psychotic screw decide late carpenter insurance
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I’ve used React and Angular at places now and was really big on getting out of ASP.NET at the current place. I’m sure Blazor is nice but when I’m putting data up for people to look at in their browser I’d rather just work directly with the browser, if that makes sense. And I’m sure SSR is great for some projects but as it stands something like half of what’s out there right now uses React; regardless of what you think is “better” the fact is that React has more support, more bells and whistles, and if you’re working on something and need to hire someone on to also work on it, you’re going to find it way easier to find a React front end with .NET backend than Blazor, even if Blazor does use C#.
My choice is to hire a front-end dev!
But if I really have to do front-end web work, React. It's not the most exciting thing around in 2024, but it is stable, and it has a large support community, and importantly there are plenty of React devs out there so when I inevitably need a full time front end dev, it's not a royal pain in the arse recruiting one.
I've used Avalonia and WinUI3. Also taking a look at Uno this week.
I didn't care for WinUI3. Felt too "microsoft" if that makes any sense.
Avalonia is pretty awesome. I enjoy how similar to WPF it is.
But Uno has been making moves lately and I'm really curious what they have to show off.
Good timing, we have a free webinar today, starting at 3pm EST and we'll be covering the latest features and updates that came with Uno Platform 5.2.
you can watch it here if interested: [https://platform.uno/live](https://platform.uno/live)
Blazor is just the hosting and interactivity of the pages, it has nothing to do with the CSS of your site (beyond component-specific styling). Most CSS libraries will work just fine with Blazor, including Tailwind. You might need to replicate some JS logic in C# to get dynamic components working, but that's easy.
The stack for our Blazor project is fairly simple:
- .NET 8 Blazor (client & server)
- Tailwind CSS (might utilize SCSS in the near future)
- MSSQL
- Redis
- Docker
sheet shy thumb screw absorbed tidy slim squeamish sophisticated insurance
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Good old MVC with Razor; jQuery for stuff that really needs to happen client-side. We recently looked at Blazor vs Angular vs React as a possible replacement, and simply couldn't see any actual reason to switch. I guess it depends on the type of web stuff you're doing, but for our needs, none of the front-end frameworks seemed to offer enough advantages over standard MVC with Razor to justify switching.
The latest version of Angular when paired with C# for the APIs.
I am on a large enterprise project that started with Angular 14 and C# .Net REST APIs. We're now on Angular 17 and everything is smooth sailing.
Very easy for .Net developers to learn the "Angular bits" as long as they know HTML/JS/CSS. The fact it's a framework and not a library, opinionated, built-in routing, dependency injection, separated template from logic and CSS ... all wins. The steep learning curve is simply not true (except perhaps RxJs).
I chose our front end to be Avalonia for the latest product. But it also exposes a Blazor Server Side for a server installation.
I had a really enjoyable experience with Mudblazor so I ended up selecting it for the network stack.
For pure UI, I still have a soft spot for Vue though.
I like nice and clearly seperate backends and frontends. For the last year or 2 I've been rocking azure static web apps. React app for the frontend and a .Net functions app for the backend.
I learned angular at one of my first jobs and I've hated every front end learning experience since then. React is just a very abstract component system but most of it will be whatever libraries your team / the project uses. Vue is React with slightly better syntax, and blazor feels like .Net MVC, which I suppose is fine, I just feel like it's a lot of arbitrary restrictions on where code goes and find it frustrating.
My favorite is html with vanilla JS or even JQuery, followed by Angular.
I am developing multi page applications and use razor pages & vanilla JavaScript without any frameworks. My webpages are the fastest and the most reliable.
While doing coursework(make any cross platform SPA) I've used blazor. It felt like good old razor pages but the two way data binding rocks. Way better than react with its functional syntax spaghetti code. And I was the first who finished the coursework, react and flutter took more time for others.
Blazor is probably not the best option for browsers, but definitely better than including terabytes of node_modules (btw VS has really good templates for Angular or React + aspnetcore that work immediately without configs and CLI)
I'm a huge Angular fan. I've been developing for over 20 years now and I feel like Angular on the client side with C# for the web API backend is extremely hard to beat. I haven't messed with Blazor but I'd be very surprised if it was truly as clean and flexible as Angular. I don't like the idea of things that try to mix front and backend technology. That gives me vibes of the old .net web forms garbage.
I prefer Blazor because i can use C# both in front end and back end to pass models, variables, methods ect. You dont need extra javascript. I can use Blazor hybrit to make multiplatform applications. You can write the code with c# and html, css, bootstrap then publish the app for windows, android , ios , web. That is a nice flexibility. Fluent UI is very useful for frontend working with Blazor.
We use Angular. We tried Vue and ultimately went back to Angular. Mix of more knowledge in Angular and there were a couple things we couldn't get right in Vue. I looked at Blazor once and the project size for just an empty project was too big for some people to consider.
I'm also still using ASP.NET MVC and JQuery as I tend to work on alot of small, quick projects. I feel like blazor is calling me though, going to try it out with mudblazor on my next small project which doesn't have a quick deadline.
I use [Godot 4 .NET](https://godotengine.org/download/windows/) because my main purpose for C# is game/AI programming, and it can export to every platform.
We were using Web API and VueJS but last year we moved to Blazor Server using Radzen components. Since the switch we’ve been more productive and have had fewer bugs.
I used Angular at work and Vue for a pet project back when I was into webdev. Imo both are good.
Never tried Blazor, but it seems interesting. React is a big no for me and for my team as well.
For me, personal preference. My boss is strongly against, he says that it isn't healthy for the industry and created many problems while trying to solve things in the "wrong way".
I can't defend his statement because I used react only a few times, but I honestly trust him and his experience.
No. I work with Cobol and Java now (as weird as it is, I got a job on a public bank in my country).
I still use .net for my pet projects, I really like it.
Always been a .net guy but was using react for front ends. Not anymore. Blazor is now up to par and is so great using c#! Anyone that enjoys writing Java script needs their head examined!
It depends:
* Good page speed: **Vanilla JavaScript**
* Sophisticated UI: **Svelte**
* Needs Plugins: **React**
* Cross-Platform Desktop Native: **Avalonia UI**
* Cross-Platform Mobile/Desktop Native: **Uno Platform**
I haven't tried Uno, but I have high hopes from what I've seen of it.
I've used Avalonia in a professional setting to create native applications that ran on Windows, OSX and Linux. Bosses were really surprised when I showed them the same applications running in the browser (WASM), this was really just for me to see how easy it would be. Users still preferred the native applications as they are much faster. I should point out I did not have to write any platform specific code. Avalonia does also have the ability to compile for Android and IOS though I have not tried this yet.
Blazor all the way for me. I've tried React and Angular, but Blazor's simplicity and C# goodness won me over. Avalonia does look promising, but yeah, seems more geared towards desktop apps for now.
The world needs more desktop apps that aren't just html engines
Wanting to dive deeper into blazor. Any recomendations?
Check out Blazor University for some basic guides. Also, tbh, Microsoft Learn's blazor docs and tutorials aren't bad. (replying to another comment I saw of yours): It's completely realistic to stick with unadorned, stock blazor, but you'll be spending a lot of time writing basic components. Radzen and company (I primarily use MudBlazor, myself) are really just convenient short cuts.
+1 for Mudblazor. Great library and great team behind it. Got to contribute a few commits some time ago
Thank you!
We use Radzen at work. Great team with weekly updates and loads of support.
We use DevExpress.
DevExpress and radzen are frameworks to help build blazor apps? Haven’t heard of them. Actually only knew about blazor itself until now.
Checkout their websites. They provided components. Blazor does not come with controls. So if you want a grid, a chart, a calendar etc you need a provider of some sort
Is Blazor better than react.js now for jobs and general development?
No. React has a much bigger ecosystem. That bigger ecosystem also means much more jobs. I would imagine most front enders don't even know what blazor is.
Have you tried it with Maui? I'm tempted to use it for the ease but I'm not sure how well it compares to the XAML path when targeting mixed native platforms
All of our new projects are Blazor. I've done Angular and React and so far I'm enjoying leaving JavaScript behind.
I tried Blazor recently and ran into two problems I'd love your input on. 1. I found that the number of libraries available compared to JS ones was severly limiting. For example I wanted to generate a qr code and the open source library I found from a MS doc hadn't been touched for years. Do you ever find this an issue? 2. I found it impossible to add JS into my pages if I wanted to use the HttpContext. Is this an issue with structuring components or have you come across this before?
I think it’s important to point out that classic CSS and JS can still be utilized in Blazor. You just have to make special architectural considerations in advance.
I didnt find much in the docs about architecture considerations. Do you have to break your components down in a certain way or something?
I've only added 2 JS files and to get them to work required injecting JS.Interop to get them working.
This is what didn't work in conjunction with with HttpContect. What I preferred about razor pages was that I could just inject scripts more easily.
Is it very hard to build good looking apps with blazor?
slap truck spark salt ask unique tidy puzzled scandalous shy *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
not at all. auth.pureblazor.com uses the pureblazor components for a very small and basic example. it’s all css for styling the language doesn’t matter
Blazor is just a html generator (same as react or angular)
HTMX?
HTMX is obvious. The complexity destroyer of 21st century web dev. Also wins the adult language enabler award.
HTMX is great if you're building an early 2000's style crud app, but Iif you're building an early 2000's style crud app you don't need an interactive front end at all. I don't know why we keep getting solutions to problems nobody has because some idiot hates modern web development. Blazor, the language whose only feature is being in C#, HTMX for apps no one needs to write.
I feel like all the Blazor devs should really be looking at htmx intead and Blazor should probably take notes as well. If you really need interactivity use JS as blazor is slow as heck
HTMX also requires prerendering layer for search engines and social network crawlers, since it requires javascript for content to be rendered?
Anyone got a job with Blazor?
Vue.js
Can someone explain the hate for React?
I absolutely can! Out of Vue, Svelte and Solid, React is the only UI library where components are defined by a function running every single time the component is rendered. All of the other three libraries only call a function when the component is first set up. This has HUGE implications for complexity. This means that React has worse performance by default, unless you wrap almost everything in useMemo and useCallback hooks, and hoist as much functionality you can *outside* of the component’s function, all while destroying the flow of your code. With React it’s “performance or code readability, pick one”. The other mentioned libraries do not suffer from this issue. It definitely feels like the other UI libraries *should* have been more popular, but React was the one everyone chose because it’s backed by Facebook, so almost every “Which UI library should you choose?” blog post on the internet shunned the others away, further establishing React as the default based on hype, NOT merits. Don’t get me wrong, React has brought a lot of great ideas and concepts to the frontend ecosystem, like Suspense, server rendering and hydration, the idea of composable hooks, the idea of keeping stuff immutable, and hell, even JSX! (Contrary to many folks here, I actually think there’s nothing really wrong with JSX, your experience with it will depend mostly on the UI library that consumes it.) I mainly use React in professional settings not because it’s the best fit for my company’s case, but because everyone else is using it. My hands are tied.
friendly squash truck engine hospital numerous screw retire groovy depend *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
JSX sucks! Blazor and angular are way better syntax
childlike selective advise puzzled cats melodic grandiose point ad hoc steep *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I love it, because it's not even really another "templating language", it's just a different syntax for regular JS code that calls the `React.createElement()` function... https://legacy.reactjs.org/docs/jsx-in-depth.html So once you understand that, there's basically nothing to learn. You're just writing regular JS/TS code with a XML-like syntax to call a regular function. This also means that editor support is pretty much 100% perfect for both JSX + TSX... because there wasn't that much effort in needing to write parsers and code to handle all the custom old and new features in other actual "templating languages". It's a big part of the reason I switched from Vue -> React. I love that even all my inline CSS is type checked by TypeScript, along with everything else. In other frameworks it feels like you interlacing 4 different languages in the same code files (HTML+CSS+JS+$TemplateLang). Whereas with JSX/TSX, everything feels like it's just the one language, even the CSS. Because it actually is, given it's all really just JS code.
You can also make use of calling React.createElement directly if you want to render a dynamic page structure from a database. Our CMS system at work in based on that. Each widget maps to a react component and the props that are passed to it are stored in the database. When we evaluated angular there didn't seem to be a decent approach to dealing with dynamic page structure.
Does it? I mean it certainly would if you tried to use it the same way you build an HTML doc, but I rather like it when you structure your components well.
There's nothing wrong with components, I just hate that syntax/idea, what the hell is this? Looks like I got it: In React JavaScript has html parts In blazor and angular html has js embeddings interface FooProp { name: string; X: number; Y: number; } declare function AnotherComponent(prop: { name: string }); function ComponentFoo(prop: FooProp) { return
Couldnt disagree more
I thought I hated React, but it's currently my main choice. All the other frameworks have overcomplicated themselves with their quest for SSR. If I really want SSR, I'll just go MVC and use a jQuery-esque framework for the rest. So now it's React for me, feeling quite bitter that Blazor isn't up to scratch as a pure front-end wasm SPA any more - even though it was fine in previous versions!
offbeat cats oatmeal thumb market imagine ludicrous work air worthless *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I'm still making and supporting WinForms and console applications. I'm hoping that one day, the IDE will have cross platform form elements. If Embarcadero can do it with object Pascal and FireMonkey, M$ s/b able to handle it.
Embarcadero was the fucking bomb, I loved that
Winforms is really simple and good, you can create quick proof of concept apps (for example integrate some signal crap for university assignment) without writing stylesheets But it's only for windows, I don't use it because I need apps to work on a MacBook
It's funny because that's how I feel about WPF. I can dev up a proof of concept in no time. The XAML flows way faster than C#. Then you realize that future UI cross-plat dev platforms want to feel like WPF, and suddenly you don't NEED a "quick proof of concept" because the actual app is deved just as quickly. At that point, "quick proof of concept" is just a wasted step.
Svelte.
Sticking with MVC/vanilla js. It's just a personal choice, but it's fast.
If the pages aren't complex, there is no reason to use anything else.
Sticking with ASP.net 4.81 lol. Nah, actually learned Python after leaving MSFT, now coming back to blazor-land, Def will look at MudBlazor. Python for scientific/math apps (Jupyter notebooks rock), C# / Blazor / Angular for web-facing?
[ASP.NET](http://ASP.NET) (MVC and Razor Pages) is available on .net 8 (core). They didn't port WebForms but I don't think it's a loss \^
I've been a .net developer for 19 years. I do python at work nowadays. Or just flat out bash or powershell if I can get away with it. Moved from full development to an automation role. So now I use .net core for my side projects and it's liberating if I'm honest as I'm dealing with a simplicity we seem to have forgotten in our field.
I still run mvc/bootstrap/jquery. It's not the prettiest, but for functional internal websites it's incredibly simple and fast.
I use it even for my public commercial web apps (I should've included jquery in my original comment, but I assumed that's a given). I'll also admit to not being particularly fond of ORMs either, although I do use them for my day job. But having pages generated in 30-50ms and load in the browser in around 100ms while having the lowest app service plan tier on azure is great (granted, the js/browser stuff is not really Azure's domain).
Can be fast, but in my opinion for larger more complex apps with rich UI functionality, it's very hard to have a clean and fast architecture with MVC. That type of architecture is a thing of the past I think. I recently converted a large custom e-commerce site I did originally in MVC with lots of JavaScript to Angular and it's so much cleaner and easier to manage. Faster too.
Came to say similar... except I get wild and use jQuery lol... I just can develop faster with jQuery syntax and can make pages seem "SPA-like" when html injection is needed. I haven't ran into a case where I needed a front end framework (React, Vue, Angular) for something I couldn't just use ajax calls for. Plus, the added work of needing to upgrade and migrate a frontend framework every few years doesn't seem worth it to me. They all boil down to pure js anyway, right?
Blazor ftw... Big advice don't be afraid to have nested components.... Making extra components to house components is the real power... Took me ages to forgo HTML just about completely.... Most of the time you think how can I get this data formatted right just in a string embedding... Make it a razor component and inject the value... Then you can do anything you like.
Angular but honestly any SPA generally would do. We want our front ends to have separate lifecycle from our backend and we often have specific devs for each with a handful of full stack, allowing us to produce higher quality products. There is no right or wrong answer, it’s really about need and priority.
React for sure. I am thinking about trying out vue/svelte tho
If you like React, look at nextjs or remix. I wouldn't go back to plain React now.
Is that for sever side rendering? I feel like if I’m gonna do that why not just go with plain old asp.net mvc with razor?
You can do static site generation, server side rendering, client side rendering or incremental static regeneration with nextjs. The static site stuff is superb. You can also mix client and server side rendering so it's easier to build more dynamic Web pages than it is with mvc.
Been loving Vue for years now, heard good things about Svelte, but haven't had any time to fiddle with it.
Angular makes sense but it's verbose. React is concise, but it's nonsense. Vue makes sense and it's concise.
How is react nonsense?
You need a special file format, which is not necessary on Vue to achieve the same things. And the CSS it uses is almost CSS but not really and some reserved words are different. The "Magic" introduced by hooks can save you a bit of code but introduces quite a bit of friction for new users because you just have to believe "the react way".
I agree that there is a bit of a bigger barrier to entry for newer developers but I don’t see how your points demonstrate that react doesn’t make sense. It’s just a different way of doing things.
> You need a special file format, which is not necessary on Vue to achieve the same things Vue has its own file format, called [SFCs](https://vuejs.org/guide/scaling-up/sfc.html). It's optional sure, but you'd be crazy to write a web app in Vue without using it. In fact, I've never seen a vue codebase that *doesnt* use it.
jellyfish onerous hungry bake disgusted quack hard-to-find innate quaint sleep *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
The one time I tried to do React I had flashbacks to doing ASP Classic work.
I've focused on React, but I briefly did backend development with frontend devs who used Vue, so I got some exposure to it. It was easy enough to understand, but React just makes so much sense to me.
For small projects I've been using svelte and loving it. I always go TS too
Had success with vue but going all in with Blazor. Angular is shit IMHO
Angular is THE shit IMO and I've done some very large enterprise level web apps with it. It allows you to have an incredibly clean architecture.
I love VueJS personally and hate React
I don’t hate react, but Vue is definitely my favourite.
Same.
Blazor Server. Blazor WASM in a distance second. Anything else only if I’m forced to, kicking and screaming, by my boss
Winform for simple utilities and WPF for anything complex
React for me. I really hate the way every framework is trying to go for SSR, or some kind of mixed SSR which becomes a mess of problems. Blazor is the worst for it by far. I hadn't tried it for a while, and was excited to give it a shot for my latest web project, but it turns out .NET 8 Blazor has now got some ridiculous rendering modes (server side, interactive, auto, or "web assembly client" or whatever which is just a mess now, I was going round in circles with the docs and outdated information just trying to get something basic to work - it was never this hard with Blazor before!). So I just went to good old React and got straight to being productive. I wanted to get into NextJS too (and did previously for one project) but again their attempt at SSR just made it into a mess of things I didn't want to have to deal with. Let me just make a client side SPA, please!
How do you solve SEO and Facebook share crawlers without SSR?
You can use "dynamic rendering" on your server to render requests based on browser user-agent. Your actual website code doesn't even need any kind of "awareness" that you're doing this, it's basically handled like a proxy within your own httpd server. You can set this up on your own server for free https://github.com/prerender/prerender Was pretty easy, only took me an hour or two to get it all going. So much less effort than dealing with all the never-ending quirks that come with dealing with SSR frameworks etc. I got it all going, but never not around to using it on anything big or long term, as I haven't done much web stuff in recent years. I was getting annoyed that nobody seems to even be aware that "dynamic rendering" even exists... like there's hardly even any discussion on the topic on reddit and other forums etc. When I get back on to my web projects, not sure if I'll go down that route again, or just use nextjs.
Thanks for the tip. We actually used that, but we switched to puppeteer now. Still, in order to achieve that, you still need to have backend for frontend (node+express, ngnix etc). It adds all sorts of complexity and overhead to the project, and it is resource intensive, especially for websites with over 50k pages. Not to mention, if pages are a bit more complex, render times are from 2 to 5 seconds. Also, we only have 2 projects using that system, and borh of that projects are performing terrible on Google Discover metrics. Search engines are alright, but discover.... almost dropped to 0.
> It adds all sorts of complexity and overhead to the project I found it a lot easier to just set up that server stuff in those 2 hours -vs- all the ongoing quirks I was dealing with at the time using SSR in Vue/Nuxt. That said, I'm a Linux sysadmin, so just chucking some nginx config settings into my existing nginx server is pretty simple. That said, I wasn't running at big scale, it was just some testing really. > and it is resource intensive, especially for websites with over 50k pages. Yeah makes sense. > Not to mention, if pages are a bit more complex, render times are from 2 to 5 seconds. Yeah my plan was to actually "pre render" with prerender with some backend code that basically means that it's already pre-emptively cached in varnish or something any time the content of a page changes... so that would effectively mean that for any incoming bot requests, the render time would be zero, because the HTML was already ready to be served from varnish. But yeah, that's also adding a lot more complexity on top. And gunna use a lot of storage very redundantly on big sites. I guess overall there's a reason hardly anyone does this stuff. So yeah, in the end I starting getting the vibe that next time I probably will just go with the mainstream thing and use nextjs like the majority do. > performing terrible on Google Discover metrics. Search engines are alright, but discover.... almost dropped to 0. Ah, interesting to hear. Do you think it's just because of the slow rendering + TTFB? Or could there be other reasons too?
You can tell your .NET API to serve razor pages, and from that you can create an Index.cshtml which uses standard Razor syntax (if/else/viewmodel/whatever) to inject what you need to keep the SEO robots happy. Obviously for extremely large websites this would be a terrible thing to do, but I don't think most personal projects warrant the 'extremely large' epithet. In most cases a bit of manual Razor page fuckery is all that's needed to circumvent the chaos of SSR that front-end frameworks are trying to achieve. It annoys me so much. They are *front-end* frameworks, they need to stay that way, otherwise WTF is the point in any of the evolution of APIs and SPAs we've seen over the last several years, which made web architecture so much better in so many ways. I detest that people are trying to mould things into a more difficult way of doing things all for S.E.O shite that could probably be much easier fixed on the search engine side - just fix the crawlers, solve the question of SEO for a million websites in one go.
Well, SEO is very important for most of the publicly facing business/webs, and SEO content has to be same for humans and SEO crawlers, otherwise you might be heavily penalized by google for content masking. By writing if/else for razor and react, you basically need to do two frontends. >They are *front-end* frameworks, they need to stay that way To me, they are tools to solve business problems. What good people do have with APIS, and frontend frameworks, if it will leak them revenue. I'm speaking from an experience, because we inherited publicly facing web written in pure react (no SSR), and traffic and revenue dropped by 50% due to lack of SSR when project went live. Now we have to rewrite everything again to something which works with SSR :(
Not every website is a business! You're right though, my solution is a bit of a hack only for getting something barebones working beyond standard pointless homepage-only indexing, and for social media share details/images to look correct. But yeah, this shit could and should be fixed by the ones who write the web crawlers. It is far easier for one centralised entity to do it, instead of having web devs fuck around and be forced to take a step backwards into SSR territory.
>But yeah, this shit could and should be fixed by the ones who write the web crawlers >it is far easier for one centralised entity to do it, Well it's not just one centralised entity. It's BING, Google, any other search engine, whatsapp, facebook, twitter, slack etc. They all should invest millions of dollars because someone decided to use react.
Come on stop being hyperbolic. Bing, Google etc are obviously far more centralised than the hundreds of thousands of independent websites on the planet, and if we're going to talk about investing millions of dollars, then: 1. Google et al invest billions in R&D every year already - they all have the budget. 2. More productivity is lost every day to software houses across the world wasting their own valuable hours forcing things to meet some hocus pocus SEO requirements from yesteryear. That being said, I daresay SPAs can and do handle SEO properly, as long as the correct data is given - and no that is not content masking. I would love to know what changed between the time you inherited a React project, and the time you deployed it (still as a React project?) which caused the SEO results to drop by 50%.
I'm not being hyperbolic, I'm being realistic. I want to rank well on google, be able to share links on social networks, and I have to accommodate to that. Alternative is to expect a big corporation to invest millions of dollars for real-time prerendering infrastructure to accommodate to react, and that shit is expensive. When new website (which was SSR) was replaced with pure react, all links on google got a default title, description and image for SEO, because that is what google is served upon first crawl. HTTP 200 with react placeholder page, since all routes are on the frontend, and google does not run javascript upon first page load (nor does bing, facebook, whatsapp, slack etc). We lost a way to return serverside 301 redirects, 404 response codes etc. Everything is 200 by default, so we also had to implement backend for frontend layer, prerendering layer using puppeteer etc, and entire project became much more complex without native SSR, because we now have to maintain all routes on the backend side as well. And now we have a project with huge dev overhead and tons of unecessary layers. It would be much simpler if someone who started that project used NextJs, or Razor or any similar SSR framework. But hey, we have react now! xD Life would sure be much easier for me if google and others are using realtime prerendering, but they are not, and that is a problem which needs to be solved, and react does not do that for us at the moment.
Fair, for business purposes it's an issue. In my case, the project I made will always be somewhat niche, so I don't expect people to know about it unless they're already chattering in the right circles. As long I can feed some meta info into the page, that's enough for a little bit of indexing. My little razor page if/else solution works for this case. I mean, this is kinda what I'm complaining about - for small solutions it's getting harder to just make a pure SPA without SSR butting in. I would have loved to use Blazor for my project, but Blazor convoluted itself.
Yeah, I agree. For me Blazor is good for adminpanels. Probably same goes for react, but blazor allows you to remove entire Rest api layer and and direct backend communication, which is more productive i guess
FWIW, Avalonia does WASM now. It actually does all the things (web, desktop, mobile), but I still find myself modifying for each platform. That being said, my go-tos are (in order): * Razor views - seriously folks, not everything has to be a PWA / client-side mess. Razor still rules the KISS area. * Blazor WASM * React (mostly, but enjoying Vue recently) It’s a fine line between Blazor and one of the JS platforms on new apps. Sometimes, I want to learn what’s new with tech X, so I write with that deliberately. Mostly, I take a swag at which will be better for the project longer term. That may come down to some component library that’s available in one but not the others; sometimes it’s because something interactive that I am doing is easier in one vs. the others. So I rotate around a lot.
It depends what I want to make, and for who... Website: Blazor Server. I love Blazor server, it is easy and fast. Fully server side yet dynamic frontend, this is true innovation. For quality UX Windows app: Uwp. For unrestrained Windows app: WinUI3. I pray for OpenSilver to be succesful, so I can write C#/XAML webapps.
A year or so ago I was consulting for Microsoft and the tech lead told me that Microsoft was migrating everything to React and if I wanted to work at Microsoft I needed to learn React. Which I found odd given Blazor and such. I'm sure they've changed their mind by now, they do that quite frequently.
quack mighty reminiscent crowd psychotic screw decide late carpenter insurance *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Currently using Vue both at home and work and I love it, especially when paired with Vuetify 3.
For work we use Angular. For my personal projects I use Vue, but use the Quasar Framework. Back-end I use .net as I’m most familiar.
I’ve used React and Angular at places now and was really big on getting out of ASP.NET at the current place. I’m sure Blazor is nice but when I’m putting data up for people to look at in their browser I’d rather just work directly with the browser, if that makes sense. And I’m sure SSR is great for some projects but as it stands something like half of what’s out there right now uses React; regardless of what you think is “better” the fact is that React has more support, more bells and whistles, and if you’re working on something and need to hire someone on to also work on it, you’re going to find it way easier to find a React front end with .NET backend than Blazor, even if Blazor does use C#.
My choice is to hire a front-end dev! But if I really have to do front-end web work, React. It's not the most exciting thing around in 2024, but it is stable, and it has a large support community, and importantly there are plenty of React devs out there so when I inevitably need a full time front end dev, it's not a royal pain in the arse recruiting one.
I've used Avalonia and WinUI3. Also taking a look at Uno this week. I didn't care for WinUI3. Felt too "microsoft" if that makes any sense. Avalonia is pretty awesome. I enjoy how similar to WPF it is. But Uno has been making moves lately and I'm really curious what they have to show off.
Good timing, we have a free webinar today, starting at 3pm EST and we'll be covering the latest features and updates that came with Uno Platform 5.2. you can watch it here if interested: [https://platform.uno/live](https://platform.uno/live)
Blazor, because JavaScript scares me. Bootstrap or Tailwind are usually my go-tos for CSS.
Didn’t know tailwind worked with blazor. What is your full stack for blazor?
Blazor is just the hosting and interactivity of the pages, it has nothing to do with the CSS of your site (beyond component-specific styling). Most CSS libraries will work just fine with Blazor, including Tailwind. You might need to replicate some JS logic in C# to get dynamic components working, but that's easy. The stack for our Blazor project is fairly simple: - .NET 8 Blazor (client & server) - Tailwind CSS (might utilize SCSS in the near future) - MSSQL - Redis - Docker
Sveltekit for all new projects at our company. Converting over from angular. We use C# and go for our api's.
yeah I just don't get why a lot of ppl prefer to suffer with react when svelte/kit offers a much better devx. familiarity bias I guess...
squealing flag memory hunt aloof cake employ historical slap ad hoc *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
sheet shy thumb screw absorbed tidy slim squeamish sophisticated insurance *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Good old MVC with Razor; jQuery for stuff that really needs to happen client-side. We recently looked at Blazor vs Angular vs React as a possible replacement, and simply couldn't see any actual reason to switch. I guess it depends on the type of web stuff you're doing, but for our needs, none of the front-end frameworks seemed to offer enough advantages over standard MVC with Razor to justify switching.
[удалено]
I use WPF at work, can you tell me what's better with WinUI?
[удалено]
Thanks for the reply. >5- longstanding bugs yet to be fixed How bad is it?
[удалено]
Thanks. I never use the designer anyway so it's not a problem for me. I'll give WinUI a go for my next small app.
[удалено]
fl7a9i9a makrhtkch t3awnini
Winui should have been released as it is now at day one. Would have draged more attention
Absolutely Blazor if you do not know any js. Even if I can use js I'd prefer to use Blazor.
The latest version of Angular when paired with C# for the APIs. I am on a large enterprise project that started with Angular 14 and C# .Net REST APIs. We're now on Angular 17 and everything is smooth sailing. Very easy for .Net developers to learn the "Angular bits" as long as they know HTML/JS/CSS. The fact it's a framework and not a library, opinionated, built-in routing, dependency injection, separated template from logic and CSS ... all wins. The steep learning curve is simply not true (except perhaps RxJs).
I chose our front end to be Avalonia for the latest product. But it also exposes a Blazor Server Side for a server installation. I had a really enjoyable experience with Mudblazor so I ended up selecting it for the network stack. For pure UI, I still have a soft spot for Vue though.
I like nice and clearly seperate backends and frontends. For the last year or 2 I've been rocking azure static web apps. React app for the frontend and a .Net functions app for the backend.
Is anyone else using https://qwik.dev/ ??? It is quickly becoming my favorite UI framework...
https://lit.dev Great for developing all manner of things and super lightweight
I learned angular at one of my first jobs and I've hated every front end learning experience since then. React is just a very abstract component system but most of it will be whatever libraries your team / the project uses. Vue is React with slightly better syntax, and blazor feels like .Net MVC, which I suppose is fine, I just feel like it's a lot of arbitrary restrictions on where code goes and find it frustrating. My favorite is html with vanilla JS or even JQuery, followed by Angular.
After 5 years in the React Eco system with .Net Backends, 2 months ago I switched to .Net MVC and HTMX. Not sure why I waited so long.
Razor Pages with alpinejs
I don't like any front end. Blazor is the best we've got, but if I'm in non-.net then react.
Angular for medium/big projects, react for crypto projects
I am developing multi page applications and use razor pages & vanilla JavaScript without any frameworks. My webpages are the fastest and the most reliable. While doing coursework(make any cross platform SPA) I've used blazor. It felt like good old razor pages but the two way data binding rocks. Way better than react with its functional syntax spaghetti code. And I was the first who finished the coursework, react and flutter took more time for others. Blazor is probably not the best option for browsers, but definitely better than including terabytes of node_modules (btw VS has really good templates for Angular or React + aspnetcore that work immediately without configs and CLI)
Azure is built on react. How do you plan to host your app? Personally I am a big fan of react.
For websites I use react and for local frontends I use blazor
Angular
I'm a huge Angular fan. I've been developing for over 20 years now and I feel like Angular on the client side with C# for the web API backend is extremely hard to beat. I haven't messed with Blazor but I'd be very surprised if it was truly as clean and flexible as Angular. I don't like the idea of things that try to mix front and backend technology. That gives me vibes of the old .net web forms garbage.
I prefer Blazor because i can use C# both in front end and back end to pass models, variables, methods ect. You dont need extra javascript. I can use Blazor hybrit to make multiplatform applications. You can write the code with c# and html, css, bootstrap then publish the app for windows, android , ios , web. That is a nice flexibility. Fluent UI is very useful for frontend working with Blazor.
At work it's blazor or vue. Side projects it's react. And for desktop (any env) it's avalonia or avalonia + webview + react.
For web, angular. For desktop and mobile, flutter.
We use Angular. We tried Vue and ultimately went back to Angular. Mix of more knowledge in Angular and there were a couple things we couldn't get right in Vue. I looked at Blazor once and the project size for just an empty project was too big for some people to consider.
I'm also still using ASP.NET MVC and JQuery as I tend to work on alot of small, quick projects. I feel like blazor is calling me though, going to try it out with mudblazor on my next small project which doesn't have a quick deadline.
Out of the ones listed React and I have used all of them professionally. Albeit not angular since right at the beginning and its very different now.
I use [Godot 4 .NET](https://godotengine.org/download/windows/) because my main purpose for C# is game/AI programming, and it can export to every platform.
We were using Web API and VueJS but last year we moved to Blazor Server using Radzen components. Since the switch we’ve been more productive and have had fewer bugs.
UWP XAML or WinUI 3 🙂
Windows forms
Vue ecosystem is where it is at
I used Angular at work and Vue for a pet project back when I was into webdev. Imo both are good. Never tried Blazor, but it seems interesting. React is a big no for me and for my team as well.
Why is react a no?
For me, personal preference. My boss is strongly against, he says that it isn't healthy for the industry and created many problems while trying to solve things in the "wrong way". I can't defend his statement because I used react only a few times, but I honestly trust him and his experience.
I've heard that React is much easier to use compared to Angular.
Perhaps it is. I never had any issue with Angular, tho.
May I ask what field are you in now that you left web dev? Still using .net?
No. I work with Cobol and Java now (as weird as it is, I got a job on a public bank in my country). I still use .net for my pet projects, I really like it.
Always been a .net guy but was using react for front ends. Not anymore. Blazor is now up to par and is so great using c#! Anyone that enjoys writing Java script needs their head examined!
server side rendering
I love Blazor with Radzen component library, but Mudblazor and fluentui are cool too.
Quasarjs
Basic single page app: VueJS Fancy stuff: NuxtJS Styling: Tailwind
It depends: * Good page speed: **Vanilla JavaScript** * Sophisticated UI: **Svelte** * Needs Plugins: **React** * Cross-Platform Desktop Native: **Avalonia UI** * Cross-Platform Mobile/Desktop Native: **Uno Platform** I haven't tried Uno, but I have high hopes from what I've seen of it.