51–60 of 302 posts
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…
I honestly thought some version of WASM would be popular, performant, and easy to use by now, and not reliant on js/html/css. Like desktop app development in a browser or an actual good version of Silverlight.
There are some plans to support DOM directly from WASM, but at the pace Webassembly features get into the browsers, it is years away if it ever gets done.
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…
I don’t understand this. I’ve used v2 since before release and it’s never been anything more than an initial setup of 5m and then build your app?
Performance:
Blazor WASM lags behind traditional JavaScript frameworks in terms of performance. The WebAssembly runtime is still generally slower than optimised JavaScript code for compute-intensive workloads.
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…
I honestly thought some version of WASM would be popular, performant, and easy to use by now, and not reliant on js/html/css. Like desktop app development in a browser or an actual good version of Silverlight.
The ability to run anything without having to do your own memory management is only just landing now (already in Chrome, next release of Firefox announced today and Safari as per usual is nowhere to be seen and is behind the curve again).
So when you think about what that very first generation of frameworks is going to even look like, it’s safe to say that most of them don’t yet exist.
The only one I know of is Flutter which is going all in on a path that’s genuinely independent of HTML and CSS and going straight to canvas and WebGPU via WASM.
But even that is still a few months away. Blazor takes an interesting approach in that it’s basically one foot in both camps in that it sticks to HTML/CSS and uses DOM rendering to handle the UI while still letting developers stick the overwhelming majority of their application logic in C#.
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…
Interested on how many concurrent users you have for Server to be a problem. Can you elaborate more on your performance issues?
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…
Earlier quoted context omitted.
> 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…
JavaFX never really became a thing, because even at Sun it had a bumpy start with the scripting based language before it got rebooted into Java, just before Sun went down. 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…
Forever burnt into my mind from Programming 1008. And in fairness, much easier to get off the ground than the legions of XML required for JavaFX.
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.
Blazor Server renders the DOM at the server and sends it to the browser. The server also holds on to some state for each client - notably the "current DOM" - so that it can calculate diffs on changes and only send the diffs to the browser.
Blazor Webassembly does the rendering in Webassembly in the browser. The .NET stack runs in the browser. Here, the code renders and diffs in the browser and the the diffs are applied to the DOM as well.
This also means that the same components can run either server-side or client-side. They basically all end up computing DOM diffs and applying those diffs to the actual DOM. Pretty neat, actually.
Each model has it's pro and cons. Blazor Server initialized really quickly and relies on minimal Javascript in the browser. But it creates load and server affinity on the server. Blazor Webassembly offloads all rendering to the browser, but at the cost of an initial load of the code.
In .NET 8 these can now be blended, and a new "auto" mode allows a component to be initially server-side and then client-side when the webassembly code has downloaded.
In addition to that is now (.NET 8) also the static server side rendering (and "enhanced navigation") which you could say is server side components without the "circuit" server affinity and server state of each client. Static server side rendering has some limitations on how interactive they can be - i.e. changing the DOM.