41–50 of 302 posts
A lot of people seem to think that front-end and back-end developers are intrinsically different people. This would be the reason why full-stack frameworks (Kotlin for JavaScript, Scala.js, JavaScript backends, and now Blazor) never really take off. I find this rather strange. I can understand that people specialize, but it's not like typical application front-end or back-ends are rocket science and require a PhD or…
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…
Anyone tried Blazor in production? I checked it out (BRIEFLY) back when it was released, and it looked pretty cool - but there was really not a whole lot of info back then. It's been 4-5 years now, so I'm curious if anyone has actually integrated it into prod
Tbh, I’ve never understood the appeal of server side blazor. High latency is too risky and you may never know that your clients are experiencing it. This hybrid approach in .net 8 is interesting but for a business app, initial load time is a once off thing and only a few seconds anyway. Kind of like an installer in a way.
I have a few criticisms though. I work almost exclusively on Linux now and it was extremely painful to try get an old .net project up and running because Microsoft aggressively sunset old .net versions. 4 years is not that long ago and I didn’t want to go through the pain of upgrading to the latest to make a few minor changes. So I had to dust off an old pc and use that. I understand that the .net core era was a turbulent time for change so maybe that’s why. But dammit, at least leave the old SDK’s up for a decade for this very reason!
Ironically, the slowest part of the system is the hosted sql server instance that is prohibitively expensive to run at a half decent speed with laughably low volumes of data. What a captured market that is when you can simply spin up a free PostgreSQL instance on the same vm and be done with it.
Anyway, to answer your question. Yes, it can be used in production. This one has 3 production instances and is used by about 30 people on a daily basis.
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…
Isn't a Blazor application a giant blob of WASM/Javascript? I understand that Blazor is more designed for internal line-of-business applications that require porting to the web (and would otherwise be a .net application running on windows xp), but it seems pretty untenable to use it as a framework for the web.
I'm optimistic about the auto-rendering mode, which will serve the app via Blazor Server (using a WebSocket connection) the first time the user hits the app. It will download the WebAssembly DLLs in the background so that the next time the user comes by, they will get the WebAssembly-hosted version. It's an interesting mix combining the best of both worlds (hopefully).
Despite working with .Net for decades, I've not jumped to blazor. The reasons are varied, many of which are well articulated in the article, but the most notable throughout various workplaces I've worked at, there's been a hesitance to jump on MS web frameworks in fear of a repeat of silverlight. Silverlight burned a lot of small businesses hard, almost everywhere I've worked has had a silverlight horror story of a p…
That's not really fair to MS since all the web frameworks which were born in that era (Adobe's AIR, JavaFX as a web tech, etc.) died because IE died. And also because Apple killed off browser plugins since they didn't work on the iPhone. Chrome and Firefox took over and there was no longer a need to use browser plugins for SPA's. HTML, CSS and Javascript finally got the features needed to create a proper SPA.
While JavaFX did live on outside of the browser both Adobe RIA and Silverlight were far worse positioned for life outside of the browser (even though both claimed to be usable outside of the browser). Simply because JavaFX was meant to replace Java Swing.
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…
Windows Defender handles node_modules fine, and if you're dumb enough to choose something other than Windows Defender on ... Windows ... that's on you. If you really want you can cut Defender out of the picture too: https://learn.microsoft.com/en-us/windows/dev-drive/#underst...
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…
Despite working with .Net for decades, I've not jumped to blazor. The reasons are varied, many of which are well articulated in the article, but the most notable throughout various workplaces I've worked at, there's been a hesitance to jump on MS web frameworks in fear of a repeat of silverlight. Silverlight burned a lot of small businesses hard, almost everywhere I've worked has had a silverlight horror story of a p…
> there's been a hesitance to jump on MS web frameworks in fear of a repeat of silverlight. That's not really fair to MS since all the web frameworks which were born in that era (Adobe's AIR, JavaFX as a web tech, etc.) died because IE died. And also because Apple killed off browser plugins since they didn't work on the iPhone. Chrome and Firefox took over and there was no longer a need to use browser plugins for SPA…
Oracle isn't a GUI company, beyond the stuff needed for their database products and IDEs, so they also didn't invest that much into it.
Thus most of the Java ecosystem, kept targeting Swing, and for the extent native desktop applications are still around, Swing is good enough.
Android is its own thing, so even one less reason to care about JavaFX.
The article (which basically says Blazor is a bit cumbersome and pointless) has plenty of truth (and a few half-truths) to it but it's assuming that you're using it in a context where pure js + html would just be much better for the end user (wait, isn't pure native better for the end user..). What it doesn't really tackle is the productivity from the developer perspective, very little mental context switching, code…
People don't realize this. Blazor is about the developer. I am a `DevOps/Backend` guy and in my previous job some internal tools were made with Blazor. It was such a joy to work with. Productivity was so high. You add Blazor Radzen components[1] or Syncfusion[2] and suddenly feels like magic. Super complex grid tables can filter, re-order columns, aggregate them and much more functionality for free in 10 lines or few…
Native desktop development is another matter, though.