211–220 of 302 posts
In my previous job, I was on a team using Vue.js for the frontend and ASP.NET Core for the backend. I quickly got tired of the internal plumbing, package management, build configuration, and all the other things not related to the actual functionality of the app that Vue (v2) required at the time. So, when I started my own company last year, I quickly jumped on Blazor Server, which has been an absolute joy from a dev…
Earlier quoted context omitted.
Best practices would dictate that you still build WebAPIs for your Blazor apps, to avoid that potentially happening. It will also give you a clean separation of concerns in your application. Even when I build a traditional MVC application, I still built out my API as a separate layer so I can change out the front-end in the future.
So, in order to use Blazor safely, I need to develop and test everything twice. That's a death knell within itself. You just made my argument for me.
I'm not using it in production yet for many of the reasons discussed in this article although I may revisit it again in .NET 8. The newest modes might actually push it over the top for applications that I develop. I wish there were no downsides because it just is so very nice to code in.
Earlier quoted context omitted.
Contrary to Google, MS never kills any tech. You can still develop Winforms apps today.
Oh, that's handy, I thought MS had stopped supporting it. Good to know that it's still going. I thought they had dropped support in one of the .NET Core versions, before .NET 5+.
Seems like an awful lot of complexity and significant compromises just to get to use C# instead of TS or JS. I wonder what the practical scalability difference there is between streaming updates over a web-socket connection and streaming updates over a long-lived HTTP connection. It sounds like the same exact thing. Hopefully it can keep the complexity of auto mode under the hood.. I don't think app devs want to deal…
The whole discussion around why a .NET shop might choose Blazor over Javascript ecosystem misses these critical things when it comes to developer experience: 1. Antivirus scans — it will take a lot more time for an antivirus to scan the tens of thousands of files in node_modules than whatever dotnet is doing. Especially on Windows 2. Corporate proxy support — the story of proxy support and importing custom certificat…
All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for. Millions of .NET developers across the enterprise world are heaving a sigh of relief to never have to touch JS and be cozy and comfortable in their .NET ecosystem. With the latest addition of fully SSR, Blazor is also well suited for CMS, Blogs, Content Mills, small web apps, portfolio sites, etc. But, as a developer who…
Earlier quoted context omitted.
The problem is, all of this stuff will probably be dead in a few years. I think they would be better off working within established paradigms rather than trying to do something completely new. How about, for example, making it as easy as possible to use React with a C# backend?
Contrary to Google, MS never kills any tech. You can still develop Winforms apps today.
Strange discussion here. I'm a developer in everything for 20 years and the last 7 probably in large JS/TS applications. I switched to Blazor Server for the last year in a new company and it has a montrous amount of benefits. First of all, do not pretend that you are Google or Facebook. This is a repeated mental illness that developers suffer from. No won't face any performance issues. The contrary, Blazor is blazing…
I'll take this opportunity to plug one of my personal projects, a graphical (node-based) regex editor written Blazor WASM: https://github.com/jcparkyn/nodexr