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+.
Presentation from .NET Conf 2023 last week with some of the new stuff: https://www.youtube.com/watch?v=N1weyWS_pL0
Thanks for linking that. The video description mentions they added WinForms to .NET Core in 3.0; maybe I was remembering the .NET Core 2.1/2.2 timeframe, when it wasn't supported in Core?
They don't kill it, they just tie it up in the basement and pretend it never existed.
RIP Silverlight
Silverlight's phase-out primarily stemmed from the browser ecosystem's shift away from plugins. It's worth noting that Silverlight 5 was supported until October 2021, a decade after its release, indicating substantial longevity despite the changing landscape.
Tangentially to the topic of the blogpost, has anyone else noticed that many recent articles on Hacker News feature AI-generated illustrations? They seem to have a unique, AI-specific style and that weird "uncanny valley" like quality where you can easily tell it was, in fact, a machine generated thing?
I used DALL-E 3 to generate the images. I always wanted to include more images in my blog posts, because I personally (and I might be wrong) feel like it sometimes helps to better tell a story or explain a sentiment which you hold as the author. But as a hobby blogger you don't get to have nice illustrations or graphics without paying an arm and leg for something which is just a free blog post. So yeah, I used AI for it and I love it. Also I'm not a native English speaker and I'll admit that I use AI a lot in recent months where I type up my badly worded text ridden with a lot of grammar mistakes and then feed it into a prompt to help me smoothen things out. I actually think I'd be stupid not to do it and I don't see it much different to a book author writing a book and then sending the script to a team of editors who do exactly the same thing, just that now it's a computer doing it faster. I have no shame in admitting this :)
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…
Silverlight was an obvious bust from the beginning, no one with longevity in mind jumped on that ship and fought against anyone pitching it at the time (mostly inexperienced devs, sales people, and tech companies looking to make a quick buck). Anything plug-in based was already on the chopping block by the time it came out. Blazor WASM is, at least, as safe a bet as any popular JS framework. If .NET was still a Windows only thing, I'd stick with the JS frameworks, but now that it's cross platform, I've got no problem choosing Blazor over any other UI framework that just as easily might need a full rewrite in a few years.
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.
Do you not bother testing your JavaScript?
We're discussing which abstraction is between the backend/front end. You said, to use Blazor safely, I also need to deploy WebAPI. I said you therefore need to test and develop it all twice: Blazor and WebAPI.
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.
Thats not always true, they keep some stuff that is a success for a long time, but they are also not afraid to drop there failures like ActiveX, SilverLight, VBScript, ...
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…
As someone in New Zealand that's crazy. The ping to Europe is terrible. To the point that video calls to the UK are painful.
I regularly have video calls from the UK to NZ with no issues at all. Might be your provider.
plus in LOB apps very likely to be in the browsers cache already. And dont forget buisness workstations are usually connected via at least 1GBit Ethernet.
I'm not who you're replying to but designing for excess resources is the kind of thinking that leads to slow software. > And dont forget business workstations are usually connected via at least 1GBit Ethernet. NOPE! More likely they are WiFi connected Dell shitboxes running Windows 11 with 8GB of memory, half of which is taken up by all the browser tabs, Teams, Office, and the 30 horrible little programs that IT depl…
For me, just the fact that I don't have to deal with JS bullshit and ecosystem including node/npm hellhole is a win for me. Before these shiny JS frameworks came along, .NET already had great UI component libraries as well including syncfusion (my favorite) and many others. I only do VueJS when I do use JS but man I can't wait to not write any code in JS.
Yea, I've been using Blazor in .NET 8 through the previews and it's really nice. The Server Side Rendering is fast like any server-rendered stuff. Enhanced Navigation means that pages load even faster since they're just using `fetch` to get the next page and swapping the content (like Turbo in Rails). When I need some interactivity, the page still renders from the server and then the browser downloads the WASM in the…
> With WASM-GC, .NET won't need to ship a garbage collector and WASM-based stuff won't need to copy between WASM and JS for DOM manipulations.
Does this mean the JS-interop performance penalty goes away?
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 need to develop and test everything twice.
That’s…literally the downside of frontend/backend separation of concerns…