9 ms·
ASP.NET Core Blazor
- pjmlp 3y agoWhile Blazor is a great migration path for Web Forms, it does little for companies with clear FE / BE separation across development teams, where .NET is restricted to SSR/SSG and APIs.
- deleted 3y ago[deleted]
- sixothree 3y agoBlazor is pretty slick. I spent some time with these videos and it might be an easy way to get going. blazortrain.com
- samayylmao 3y agoif you havent used blazor before there are some downsides. The developer experience with blazor is lacking. Debugging tools aren't up to par with other dotnet SDKs. Hot reload only works when not debugging and only if you don't modify member signatures and a plethora of other conditions. Because of the afore mentioned the feedback loop during development can be slow. The razor editor doesn't support all the helpful actions you're used to with dotnet (e.g. cleaning up unused imports). Sometimes the razor editor gives really bizarre errors and you simply need to close Visual Studio and reopen for the. tk disappear I dont mind the framework itself but there's a few design decisions that could have been better. I think there are some good use cases for it though. AOT compilation to wasm is kinda neat for workloads that may benefit from that. I also think that blazor server might just be the most novice friendly way to get I to web development because it abstracts away much of the web. that being said, the blazor server architecture has a plethora of drawbacks.
- wokwokwok 3y ago? Is something new here? Did they update the documentation layout? Blazor has been around for 5 years or so now, and discussed before and this looks… the same?
- virtue3 3y agolooks like 8.0 release? https://github.com/dotnet/AspNetCore.Docs/commit/e8ce5761969417af3de2db2d29db1dc441793166 https://github.com/dotnet/AspNetCore.Docs/commit/e8ce5761969...
- deleted 3y ago[deleted]
- lolinder 3y agoReposts are allowed after a year without significant attention, and it's not uncommon for them to gain traction. Blazor may be old news to you, but it appears there are a lot of people who are still interested or who are learning about it for the first time.
- MauroIksem 3y agoIf they made an easy way for us to move from asp web forms to blazor that'd be ideal. Not bringing web forms to core is fine but without giving us an easy way to migrate to blazor is a big problem imo. There are still a ton of apps and big code bases that run on web forms.
- DaiPlusPlus 3y agoWebForms code cannot be ported over because WebForms' entire architecture is built around a stateful view-layer over stateless server-side code. It's fundamentally broken and incompatible with how the web works (simply look at how WebForms' PostBack system breaks the browser back button and makes it impossible to link to pages or content that can only be accessed via PostBack). There isn't an easy way to move from WebForms to MVC because it's impossible.
- ComputerGuru 3y agoThe sheer amount of greenfield code being written today so dwarfs all the legacy code out there (especially that under consideration for upgrade) that Microsoft has just focused full steam ahead on the former. It’s hard to disagree with the business logic there. (Medium-term migrations from ASP.NET MVC to ASP.NET Core, was more streamlined.)
- lacrimacida 3y agoYes, agree. But at the same time we could agree that microsoft left their older customers with a dead end solution costing a fortune or even imporrible to upgrade. They would be unwise to take microsoft recommendation again but corps seem to continue to do so..
- briHass 3y agoTo be fair, WebForms is 20 years old. It requires .NET Framework, but Microsoft just released another version (4.8.1) of that last year even though they said they were done with 4.8 back in 2019. By the time it's totally dead, companies will have been able to get a quarter of a century out of that tech. That's outright amazing compared to any of the flash-in-the-pan JS front-end technologies. If you used the original AngularJS, for example, you got 10 or so years, and that's not an entire server-side framework.
- TeaVMFan 3y agoI you're after something similar (write a SPA in non-JS) but you prefer Java or Kotlin, check out Flavour: https://flavour.sourceforge.io/ https://flavour.sourceforge.io/ Comparison to Blazor: * https://frequal.com/java/TeaVmVsBlazorWasm1-0.html https://frequal.com/java/TeaVmVsBlazorWasm1-0.html * https://frequal.com/java/TeaVmVsBlazorChart.html https://frequal.com/java/TeaVmVsBlazorChart.html Flavour podcast: https://castini.frequal.com/cast/show/Flavourcast/f7e171e8-22de-4f3b-adbb-5462991343c5 https://castini.frequal.com/cast/show/Flavourcast/f7e171e8-2... Java Magazine article: https://blogs.oracle.com/content/published/api/v1.1/assets/CONT8F9404EB36BE4DBFB2A9E220E42ACCD7/native?cb=_cache_8644&channelToken=4d6a6a00a153413e9a7a992032379dbf https://blogs.oracle.com/content/published/api/v1.1/assets/C... Real, fast-loading apps made with Flavour: * Wordii, a 5-letter word game: https://frequal.com/wordii https://frequal.com/wordii * Tea Sampler: Demo app with code samples of coding with Flavour: https://frequal.com/tea-sampler/ https://frequal.com/tea-sampler/
- iamcreasy 3y ago> I you're after something similar (write a SPA in non-JS) but you prefer Java or Kotlin What would be a Python equivalent?
- alexisread 3y agohttps://pyscript.net/ https://pyscript.net/ it runs pyodide under the hood.
- edandersen 3y agoIf you are a junior developer please do not go anywhere near this, your career will be stunted.
- jiggawatts 3y agoThat’s terrible advice. You’re assuming all the world is identical to Silicon Valley and its startup culture of bashing things with open source rocks instead of just buying a proprietary power tool. Outside of that pond, there is a giant ocean of developers that work in enterprise and make a perfectly respectable income.
- unsignedint 3y agoIndeed, within an enterprise environment featuring a pre-established C# backend, I've discovered that Blazor, particularly Blazor Server, offers exceptional productivity. It essentially facilitates the deployment of a web front end with minimal overhead.
- phillipcarter 3y agoI wouldn't say it's necessarily bad advice. Even in the enterprise where .NET has the most adoption, most people building web apps are doing so with JS/TS. I really doubt Blazor will get big enough so as to be the primary way people build web UIs. Doesn't mean it's not worth learning, but I would agree that a junior shouldn't focus on Blazor first.
- samayylmao 3y agoI think it's bad advice because the fundamentals of web development and core programming concepts are mostly transitive between frameworks. You can learn that on blazor and apply it elsewhere. That being said I have worked with blazor since launch in 2019 and it's one of my least favorite SPA frameworks.
- jiggawatts 3y agoI’m curious to hear any specific critique you have of Blazor.
- taspeotis 3y agoAs someone who likes .NET I have never once seen a Blazor website that works well. Just try dragging and dropping: https://blazordragdrop.azurewebsites.net/ https://blazordragdrop.azurewebsites.net/ The "best" I've seen has been like 100ms of latency.
- debacle 3y agoWow that's severely not great.
- teh_klev 3y agoSeem to work for me. What's broken for you and how can I reproduce?
- mgh95 3y agoThis is because it's the server version. This is equivalent to liveview websites that have roundtrip latency. Do you know if there is a wasm hosted version of this?
- aardvarkr 3y agoAvoid blazer like the plague. I use it in my work and the only reason why is because everyone uses C# and can’t be bothered to learn a second language. Take a wild guess which company that is. It’s an awful architecture that only exists because some exec at Microsoft willed it into existence. There’s a reason why Java doesn’t get used to program real website front ends and I’d never use C# for web dev if I weren’t forced to.
- deleted 3y ago[deleted]
- kumarvvr 3y agoCurious to know more. I have developed a few web apps using it. I actually like the pages + Components separation paradigm and asp.net is pretty fast. Could you explain your perspective on Blazor?
- DaiPlusPlus 3y agoBlazor is based on a build of .NET (CLR + BCL) for WASM - though it is highly optimized and unused code is aggressively removed from the WASM bundles it still means your users will need to download (at least) 6MB of WASM while your SPA loads - which makes Angular look anorexic in comparison. ...which basically restricts Blazor's use to corporate LAN environments, kiosk applications, and (maybe) PWAs - but it's otherwise completely unsuitable for use on the wider public Internet. ...but we know it'll end-up being used on the public web eventually anyway because developer time is worth more than the end user UX.
- cebert 3y agoMicrosoft’s history with UI frameworks has been challenging, with experiences from WPF, Silverlight, and UWP leaving some developers, including myself, hesitant. It would be great to see consistent and long-term support in this area before committing to their UI solutions again. I won’t be burnt again.
- rqtwteye 3y agoSame here
- stetrain 3y agoThis is a direct descendent of ASP.NET MVC which is like 14 years old. Blazor adds live updating of components via websocket using the Blazor Server opiton, or hosts the whole MVC web app in the browser if you are doing Blazor WASM. To me it feels like a direct continuation of the last decade of ASP.NET development.
- JustLurking2022 3y agoI've been using ASP.NET MVC since the preview and wouldn't touch this. It actually feels more like the old ASPX web forms where the components were inscrutable black boxes. Ultimately, I think it's actually better to have separation between UI, client-side state persistence and server-side frameworks.
- oaiey 3y agoJust that they are no longer black boxes (except you build them). And the model is basically the same as for all of the other SPA frameworks).
- lizardking 3y agoIt does feel like web forms, complete with the life cycle methods (component instead of page/control in this case). I built an internal application for a client and it felt like a fusion of react and web forms.
- 3y ago
- bottlepalm 3y agoKind of absurd the company that invented TypeScript does not embrace it at all on the frontend. No native web framework, no frontend component libraries, all while the past 20 years have suffered from wave after wave of questionably supported framework where Microsoft could have easily filled the void. Even React has been abandoned by Meta. Frameworks like Next.js and SvelteKit are eating Microsoft's lunch in the new full stack world. Entity Framework is the only thing I really miss.
- PaulWaldman 3y ago>no frontend component libraries Well, there is this.... https://github.com/microsoft/fluentui-blazor https://github.com/microsoft/fluentui-blazor
- bottlepalm 3y agoNative, not WebForms 2.0. If WebForms was made in javascript to begin with we'd have a stable 20 year old UI framework right now rather than 20 years of disaster after disaster. It really does take a big tech company with a zillion developers to create good frameworks and tools that survive for decades. Things you can build on confidently and not have to worry about when you'll have to do the next rewrite. No one is writing SQL or C# worried about some new version obsoleting all their code or those platforms being abandoned.
- DarkNova6 3y agoI don’t think any company with the size of MS can have a unified tech stack strategy. Inevitably, competing departments will push different technologies.
- tonyedgecombe 3y agoApple seems to be remarkably consistent on this front. Cocoa on macOS and AppKit on iOS, now both moving towards SwiftUI. On the other hand Microsoft tends towards the other extreme. It seems to be continually at war with itself.
- local_crmdgeon 3y agoThe amount I don't like this model is remarkable. Microsoft needs to just buy Vercel. They invented TS, they should lean into the huge successes there.
- elforce002 3y agoLeave vercel alone, hehe. On a serious note, I've been trying to learn .Net & C# for a long time but didn't know where to start. I took a different route and learned other languages (py, js/ts, R, Dart, Swift) and now I don't know if it's worth learning it just for the sake of it.
- neonsunset 3y agoTo be fair, out of these TS/JS and Swift stand out like pretty big ecosystems and languages, I don't know how one developer can fully "learn" all of them to a high proficiency level in a reasonable time. For C# (which is another "big" language), people tend to overlook high quality first-party tutorials and documentation: - https://learn.microsoft.com/en-us/dotnet/csharp/tour-of-csharp/tutorials/ https://learn.microsoft.com/en-us/dotnet/csharp/tour-of-csha... - https://learn.microsoft.com/en-us/aspnet/core/getting-started/?view=aspnetcore-8.0 https://learn.microsoft.com/en-us/aspnet/core/getting-starte... - https://learn.microsoft.com/en-us/dotnet https://learn.microsoft.com/en-us/dotnet (general sitemap of everything that's there)
- wly_cdgr 3y agoIf you had to pick only one language to work with and trendiness wasn't a factor, C# is the best choice. Best docs, extremely wide use case coverage, great professional community, great balance between performance, speed, and ease of use. Best all-purpose language - only JS can seriously compete.
- drewrv 3y agoI’d argue that JS can’t compete but typescript can. Anders Hejlsberg is a freaking genius.
- paddim8 3y agoTypeScript is still limited by being a superset of JavaScript.
- lizardking 3y agoTypescript as a language is arguable more flexible than C#, but everything else about the development experience is smoother with C#.
- qlkjwenf 3y agoBlazor is excellent! The entire JavaScript ecosystem is so fragile and volatile, you will get JS-fatigue very quickly. Each time you change projects you have to learn completely new JS libraries, frameworks, tool, etc. No such problems with Blazor.
- qingcharles 3y agoThe OP linked to v7.0 document, but 8.0 is in RC1 and goes gold in four weeks: https://learn.microsoft.com/en-us/aspnet/core/blazor/?view=aspnetcore-8.0 https://learn.microsoft.com/en-us/aspnet/core/blazor/?view=a... (the even numbers are Long Term Support versions)
- Xeamek 3y agoHow does blazor (server side) compares to Phoenix liveview?
- candl 3y agoHaven't touched Blazor in 2 years. In the context of blazor server, what's the recommended pattern for state management? Does it make sense to use MVVM (e.g. via MVVM Community Toolkit for source generated observable properties etc) or plain C# objects would suffice with manually calling StateHasChanged() whenever necessary? (I guess that since rerenders are driven by DOM events the situations where manually calling StateHasChanged() is quite low)
- samayylmao 3y agoI've been using blazor since release in 2019 and can count on one hand the amount of times a call to StateHasChanged() was used and actually needed when doing a peer review Most of the time I've seen that function used it was due to improperly written asynchronous code.
- RagnarD 3y agoThere are two major flavors of Blazor: Server and WASM. Server is considerably easier to program with because it removes the complexity of making REST calls to a server component. It creates an illusion of seamless coupling between browser client and server methods. In reality, internet delay makes Blazor Server UIs unacceptably slow because UI interaction often results in a round trip call across the net. As well, every browser connection consumes significant resources on the server. WASM is more difficult because of the need to use REST calls (typically) from a client project to the server side project. But the client side can be nearly entirely written in C#, targeting WASM and running in the browser - even including powerful .NET libraries (see NuGet repo.) The server code implements client services. Note that this should all sound very familiar with conventional web apps, except that a radically superior language is used instead of Javascript on the client side. The ProTip is this: if you can make the choice, choose WASM. Even for an intranet app and despite the additional dev work.
- arielcostas 3y agoAlso, since .NET 8 (which will be released next month), there is a new way of using Blazor which combines "normal" SSR (same you'd get with ASP.NET MVC or Razor Pages), Server/WASM functionality and stream rendering. Meaning you'll be able to get the best of all worlds (SSR speed and SEO, and Server/WASM interactivity), all at in one place.
- oaiey 3y agoAnd there is Blazor Hybrid. Which is basically a electron shell / Cordova approach where a web view hosts the UI and the rest is in the regular .NET process on windows, Android, Mac and iOS. Maybe Linux not sure. It is currently a minimum of 4-5 different modes. Blazor is a beast.
- oaiey 3y agoCareful with radical superior. Even as a .NET fanboy I have to respect 2023 JavaScript/ TypeScript.
- graboid 3y agoI agree that WASM is the better option. In my opinion it is however not viable for public-facing sites. The bundle size even if you pull all the tricks is just too big. I am talking about having to download >1MB in the best case before the site is functional. Simply unusable on slow mobile connections. React/Vue/etc. are often sub 100kB, you can even have something like Preact.js at 3kB if you want. I don't understand why this is seemingly not given more priority at MS: https://github.com/dotnet/aspnetcore/issues/41909 https://github.com/dotnet/aspnetcore/issues/41909 My prediction is that this will kill off the technology if they don't find a solution.
- firemelt 3y agoshould I abandon rails and jump onto blazor?
- moogly 3y agoA few months ago I wanted to make a really simple web frontend hosted by a WinForms app (don't ask), and tried Blazor Server since it was going to be used by a single user on a local network. I really disliked how much stuff the `blazorserver` project template created. A bunch of .razor files and .cshtml files (that had Razor code in them) in nested folders the contents of which were quite arcane. I wanted to scale it down to the absolute minimum needed, because I wouldn't need e.g. client-side routing, but the tutorials basically repeated setting up all this boilerplate without really explaining the basics. I spent a couple of hours working backwards trying to simplify this, but didn't really succeed. FWIW, I've worked with .NET since the 1.1 days so I tend to be used to their idioms. Instead I made a Solid.js frontend hosted by in-process Kestrel and just used SignalR directly for all client/server communication. Somehow going into the JS/TS ecosystem (which I've worked a lot in too) had less friction. Very surprisingly, SignalR is not TypeScript friendly at all out-of-the-box. The frontend client could be source generated for sure, and I saw someone had made a tool for that, but still odd that it's not first party. I can appreciate the idea of making an opinionated, scalable, production worthy template (if that is what this is), because in the JS/TS ecosystem the opposite is common with toy examples, but there is something to be said to offer a toy example to explain the underpinnings of the framework.
- torginus 3y agoTbh, since the introduction of .NET 7 WebAssembly, Blazor isn't my preferred way of writing .NET apps in the browser. https://devblogs.microsoft.com/dotnet/use-net-7-from-any-javascript-app-in-net-7/ https://devblogs.microsoft.com/dotnet/use-net-7-from-any-jav... Blazor is 2 things bundled together - a way of running .NET apps in the browser, via WebAssembly, and an SPA framework. Since .NET 7, it has become possible to use just the WebAssembly part. I prefer bundling .NET WASM, with a more traditional frontend framework, like React, since it doesn't suffer from all those issues others have mentioned in the thread. In addition, it's a battle-tested solution that most fronted devs are already familiar - the pool of devs writing kickass Blazor/ASP.NET Razor sites is comparatively tiny.
- graboid 3y agoThat is interesting! Do you find that setup useful for CRUD-style apps too? What parts of your application would typically be written in WASM then? I am asking because if I look at my usecases, I mostly see rendering logic done by a JS framework and a restful API that does little more than serving the frontend by querying the DB and mapping between models.
- torginus 3y agoWell, I had 2 apps written this style in recent memory. One was adapting an existing app with a React frontend and a .NET backend to work in an air-gapped place - we just replaced all the backend calls to calls into the WASM runtime, which did its thing internally. The other was rearchitecting a microservice-based app, where the .NET server basically only served as middle-man, calling into other various services. Eliminating this middle-man and integrating it into the client allowed us to serve the whole thing statically from CloudFront which massively simplified our infra situation. I think where .NET shines is writing big, complex applications, for a simple CRUD app where the only thing I do is prod a database, I'd just go with a simple nodejs server. In my experience, I tend to write all business logic in the back-end, and the front-end's job is mainly just presenting it to the user, so even with fancy SPAs, the bulk of the complexity lives in the back-end. Keep in mind, that with all the super-duper trimming and size optimization options MS has added to .NET, the runtime is still multiple megabytes, so adding WASM .NET to your typical consumer website isn't super feasible, it's more for these niche use cases.
- kcartlidge 3y agoBuilt a few things with Blazor (largely internal tooling). Feels like a cross between Meteor, WebForms, and Phoenix LiveView. Fast and simple. - Server-side rendering is great for internal apps, or public facing ones where interactivity is minimal and you enforce websocket support. Lost connections are still messy, but a single codebase (literally) makes life very simple. - Client-side rendering is great for internal apps, or public facing ones where users are fine with a reasonable-sized up-front traffic hit. Lost connections behave like with any other site, and you can still use shared code and libraries which work unchanged on client and server. I quite like the latter. A DotNet solution with a client C# project, a server C# project, and shared code projects, with the server running an API and the client consuming it using shared models works well and supports end-to-end debugging. I'm also looking forward to trying the DotNet 8 hybrid Blazor improvements. That said, when doing C# I still prefer either plain ASP.Net MVC or a separate client hitting an ASP.Net Web API (pretty much the perfect mix of scalable performance and productive development).
- obeavs 3y agoFor those interested in .NET languages with alternative compilation targets, F#'s Elmish (https://elmish.github.io/elmish/ https://elmish.github.io/elmish/) is pretty unique. We use F# on the front end (instead of TS), and thanks to the Fable compiler (which transpiles F# to JS, Python, Dart, PHP and Rust), most of the benefits of an Elm-style model in the UI can be ported to all sorts of different outputs languages. The rust target is in beta, but its promising because the WASM bundle size stands to be dramatically reduced compared to Blazor. While the default is reactivity library for Elmish is React, you can swap in Avalonia/FuncUI (https://github.com/fsprojects/Avalonia.FuncUI https://github.com/fsprojects/Avalonia.FuncUI) with just a little work as well.