91–100 of 302 posts
I expected something to back the claims in the article, but found none. For instance, there are no performance numbers.
===>>> YES. It takes a bit to wrap your head around, but functional programming is actually very good for UI's. ==>> "As I reach the end of this blog post I want to finish on a positive note. I dare to say it, but could C# learn another thing from F#? Thanks to Fable, an F# to JavaScript transpiler, F# developers have been able to create rich interactive SPAs using F# for quite some time. Developed in 2016, Fable was…
https://github.com/theolivenbaum/h5
https://www.dice.com/career-advice/exploring-bridge-net-c-ja...
https://www.infoq.com/news/2015/02/duocode-csharp-javascript...
I wonder if the community just isn't interested in this approach.
Earlier quoted context omitted.
Very interesting, and the first time I might have been nearly sold on it. Maybe next new project I'll try it out. Razor pages with JavaScript on the front end and automatic diffing on the backend is definitely appealing. As much as I don't like the idea in general of serverside session state. By the way, I think if you used a light-dom framework like alpine or petite-vue you would avoid most of the issues with the pa…
> By the way, I think if you used a light-dom framework like alpine or petite-vue you would avoid most of the issues with the page not recalculating the front-end state on navigation. Unfortunately it's how Blazor Enhanced Navigation works where it compares the rendered content of the new page and diffs in the changes so I'm not expecting it to work by default (i.e. without adopting a workaround) with any JS FX that…
I did that same rewrite (alpinejs to vue3) in a project of mine. I did it for CSP reasons rather than performance/behaviour limitations despite spending quite a while getting recursive generation to work.
The next project has less untrusted input and a simpler datamodel so I went with alpine again and I've not had any issues whatsoever.
Good to know about the bugs/abandonment of petit-vue. Admittedly, I probably shouldn't have recommended it above without having used it.
Earlier quoted context omitted.
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 - until .NET 8 - came in Blazor Server and Blazoe Webassembly variants. 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 brows…
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…
> 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. Oh, hey, I have something relevant to say about this setup. Currently I'm bootstrapping a platform with .NET Core on th…
Can you elaborate on this? I'm not sure I get it, because once you have your view model in asp.net, it seems like it should be easy to derive a JS/TS model from it using various techniques (reflection, source generators, etc.).
Earlier quoted context omitted.
I like .NET, and I believe Blazor represents an unique capability for that tech stack, but using Blazor essentially means eschewing all the traditional web stack tooling that was built up around TS/JS during the past decade for proprietary Microsoft weirdness.
> proprietary Microsoft weirdness .NET (and Blazor) has been open source for at least 7 years now
Earlier quoted context omitted.
Don't forget all the other products Microsoft managed to screw over developers with. Like discontinuing Xamarin.
Sorry for not being up-to-date. I can't read anything about discontinuing Xamarin on wiki: https://en.wikipedia.org/wiki/Xamarin Ok, MS says this: https://dotnet.microsoft.com/en-us/platform/support/policy/x... > Xamarin.Android, Xamarin.iOS, Xamarin.Mac are now integrated directly into .NET (starting with .NET 6) as Android, iOS, and Mac for .NET. If you're building with these project types today, they should be upg…
Maui on the other hand is a turd. It’s such a pain to work with, workloads just plain suck. And if you install . Net 7 and your project targets 6, It will download .net 7 workloads and fail to build. Then 8 comes out and same problem. Have to pin the SDK.
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…
> 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. Oh, hey, I have something relevant to say about this setup. Currently I'm bootstrapping a platform with .NET Core on th…
Yes, you do need to set up some rather strong governance around it for it to work for multiple teams, but you should really be doing that with any technology, and once you do, it’s just excellent. Part of the reason for this is that it’s basically designed from the ground up to require that you build and maintain “template” projects, have strong linting, testing and pipeline governance, so there is a lot of freedom to make it work easily for your organisation exactly the way you want it to. Typescript is obviously not alone in this, but it’s far less opinionated than something like .Net.
The main reason is that .Net always becomes burdensome once you start using it’s included batteries. This isn’t really an issue with C# as much at it is an issue with it’s libraries. Take OData and Entity Framework as an example, the .Net magic behind them sort of share the same model builder, but they do so differently. What this means is that a lot of the cool OData features like patch doesn’t actually work with EF, meaning you’ll either have to rewrite a lot of the model builder (don’t) or have to work around it. .Net has always sort of been like that. It variates between being 50-90% “done” but it never really gets there until it moves on. Like EF, much of the EF 7 road map isn’t implemented yet, but here we are, moving on to EF8.
I think for a lot of use cases it’s a wonderful technology, and Blazor will probably be awesome until Microsoft moves on, but at least around here, it’s also a technology that doesn’t really see adoption in anything but small-midsized companies, and in my opinion, .Net is part of what hinders growth. Obviously not a huge contributor, but once you step out of where it excels, you’re just going to have to fight .Net so much harder than you will with Typescript. Which is sort of interesting considering they are both Microsoft products which align more and more. That being said, it’s not like it’s bad either.